Wydano Mono 2.4 oraz MonoDevelop 2.0

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.


MonoDevelop 2.0

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 😉

żadnych reklam, sama wiedza.

Zarejestruj się na BEZPŁATNY NEWSLETTER i raz w tygodniu otrzymuj najważniejsze wiadmości
ze świata IT, nowych technologii i kryptowalut.

Bez reklam.

  1. Awatar marcinsud
    marcinsud

    zdjęcie się nie powieksza po klinięciu nie wiem czy tak być powinno.
    News dwaplusdobry :P. Samo mono niby zgodne z .net, ale nie zawsze odpali program napisany w .net

    1. Awatar Magnes
      Magnes

      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.

      1. Awatar mith
        mith

        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).

        1. Awatar Magnes
          Magnes

          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ŚĆ.

        2. Awatar Magnes
          Magnes

          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?

        3. Awatar mby7930
          mby7930

          Możesz zarzucić jakimś kodem? Chętnie zobaczę, jak to działa.

        4. Awatar l30n
          l30n

          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

        5. Awatar wolvverine
          wolvverine

          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.

        6. Awatar sprae
          sprae

          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 .

        7. Awatar jellonek
          jellonek

          "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…

        8. Awatar mby7930
          mby7930

          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.

        9. Awatar sprae
          sprae

          "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 😉

        10. Awatar jellonek
          jellonek

          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 😉 )

        11. Awatar jellonek
          jellonek

          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.

        12. Awatar mby7930
          mby7930

          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…

        13. Awatar sprae
          sprae

          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.

      2. Awatar mby7930
        mby7930

        "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.

        1. Awatar Magnes
          Magnes

          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ć.

        2. Awatar sprae
          sprae

          Edycje formatek i kontrolek (WIDGETOW!) masz w Glade. To specjalizowane narzędzie do tego.

        3. Awatar jellonek
          jellonek

          "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? 😉

        4. Awatar sprae
          sprae

          Ja myślę, że to z "delfi"

        5. Awatar jellonek
          jellonek

          i z kalki jezykowej angielskiego "form" tam uzytego? to dosc prawdopodobne…

        6. Awatar Adawo
          Adawo

          @sprae: W delphi są "komponenty" ;p

        7. Awatar sprae
          sprae

          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ć."

    2. Awatar mith
      mith

      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.

      1. Awatar XpT
        XpT

        Przypomniało mi to, że mam wywalić biblioteki mono ze wszystkich systemów.

        1. Awatar jellonek
          jellonek

          jak milo ze ktos w imie fanatyzmu pozbawia sie okreslonych funkcjonalnosci 🙂
          nie tak dawno podobnie robili fanatycy gnome/kde 😉

          ludzka glupota nie zna granic…

        2. Awatar marcinsud
          marcinsud

          @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ć 🙂

        3. Awatar jellonek
          jellonek

          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?

        4. Awatar XpT
          XpT

          Nie, pragmatyka.

        5. Awatar XpT
          XpT

          i jeszcze LMAO, "określonych funkcjonalności", prima aprilis był wczoraj misiu.

  2. Awatar mario
    mario

    w odróżnieniu od bytecodu, który wymaga interpretera, co zwykle wiąże się z pewną utratą wydajności

    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.

    1. Awatar jellonek
      jellonek

      bytecode wyposazony w JIT? muahaha
      zabawny ten skrot myslowy 🙂

  3. Awatar nat
    nat

    pytanie jezykowe, niezartobliwe. jesli juz zostawiamy
    “framework”, to odmieniamy “frameworku” czy “frameworka”?

    1. Awatar pbnan
      pbnan

      Jeśli analogicznie do wyrazu "worek" (tylko czy można? Wszak tutaj mamy ruchome e), to PWN podaje:

      worek -r•ka, -r•kiem; -r•ki, -r•ków

  4. Awatar Energizer
    Energizer

    To MonoDevelop nawet przejrzyście wygląda, ale ja mimo wszystko chyba pozostanę przy Qdevelop.

  5. Awatar Paweł
    Paweł

    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?

    1. Awatar sprae
      sprae

      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.

      1. Awatar mby7930
        mby7930

        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.

        1. Awatar Paweł
          Paweł

          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.

        2. Awatar sprae
          sprae

          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!!!

Dodaj komentarz

Twój adres e-mail nie zostanie opublikowany. Wymagane pola są oznaczone *