Bylo vydáno Eclipse IDE 2024-06 aneb Eclipse 4.32. Představení novinek tohoto integrovaného vývojového prostředí také na YouTube.
Proton, tj. fork Wine integrovaný v Steam Play a umožňující v Linuxu přímo ze Steamu hrát hry určené pouze pro Windows, byl vydán ve verzi 9.0-2 (𝕏). Přehled novinek se seznamem nově podporovaných her na GitHubu. Aktuální přehled her pro Windows běžících díky Protonu také na Linuxu na stránkách ProtonDB.
Po roce od vydání verze 15.5 bylo vydáno openSUSE Leap 15.6. Přehled novinek v nejnovější verzi této linuxové distribuce v oznámení o vydání a v poznámkách k vydání.
Byla vydána nová verze 256 správce systému a služeb systemd (GitHub). Nově mimo jiné s run0 jako alternativou k sudo.
Společnost Oracle oznámila spolupráci s Google Cloudem, OpenAI a Microsoftem.
Zítra začne v Brně na FIT VUT třídenní open source komunitní konference DevConf.CZ 2024. Vstup je zdarma, nutná je ale registrace. Na programu je celá řada zajímavých přednášek, lightning talků, meetupů a workshopů. Přednášky lze sledovat i online na YouTube kanálu konference. Aktuální dění lze sledovat na Matrixu, 𝕏 nebo Mastodonu.
Google Chrome 126 byl prohlášen za stabilní. Nejnovější stabilní verze 126.0.6478.55 přináší řadu oprav a vylepšení (YouTube). Podrobný přehled v poznámkách k vydání. Opraveno bylo 21 bezpečnostních chyb. Vylepšeny byly také nástroje pro vývojáře.
Byl vydán Mozilla Firefox 127.0. Přehled novinek v poznámkách k vydání, poznámkách k vydání pro firmy a na stránce věnované vývojářům. Řešeny jsou rovněž bezpečnostní chyby. Nový Firefox 127 je již k dispozici také na Flathubu a Snapcraftu.
Byla vydána (𝕏) nová verze 9.5 z Debianu vycházející linuxové distribuce DietPi pro (nejenom) jednodeskové počítače. Přehled novinek v poznámkách k vydání.
Společnost Raspberry Pi dnes vstoupila na Londýnskou burzu jako Raspberry Pi Holdings plc (investor).
Tiskni Sdílej:
(gcc || g77 || ifort | ...) -g
) a pak je slinkujes dohromady. Do Monte Carlo jsem moc nefusoval, ale muj skolitel ma na ni udelanou sadu programu v C. Tu ti ale nemuzu bohuzel bez jeho svoleni poskytnout. Jinak jsem delal Molecular Dynamics a pouzival jsem na to program DL_POLY, ktery je psan ve FORTRANu:
@ARTICLE{96SMI/FOR, author = {Smith, W., and Forester, T.R.}, title = {DL\_ POLY\_ 2.0: A general-purpose parallel molecular dynamics simulation package}, journal = {J.Mol.Graphics}, year = {1996}, volume = {14}, pages = {136--141}, availability = {reprint av. SIM }, keywords = {SIM DLPOLY}, owner = {milan}
Navíc dneska kdekdo přechází k C, aniž vím proč... Proč?Protože ani C není vhodné pro Pojídače koláčů (programování v C mohou opravdoví programátoři ocenit: žádná kontrola typu, jména mohou mít 7 (10?, 8?) znaků a dodaný užitek datového typu ukazatel není k zahození - podobně jako mít na jednom místě nejlepší části jazyka FORTRAN a assembleru (a to nemluvíme o define)) Zkus se podívat na SciPy, Python sice není Fortran, ale ta knihovna je stejně napsaná v C. Navíc je možné přes modul ctypes kombinovat kód v Pythonu a C, pyfortran umožňuje propojení numpy s fortranem a nějaký f2py pro generování rozhraní z Fortranu do Pythonu ...
Odpověďi na tyto otázky by Ti měly pomoci:
Soukromý názor:
Podle mě je dobré být otevřený novým myšlenkám a postupům, ale nepodlehnout módě. Dát na selský rozum. Ověřit si vše v praxi. Dělat věci nástrojem, který je na danou věc nejšikovnější => naučit se skupinu jazyků pomocí, kterých dokážeš vyřešit snadno a efektivně všechny problémy, které se Ti dostanou pod ruku. Navíc zjistíš-li, že existuje mnohem lepší nástroj, tak se ho zkrátka naučíš používat a vyměníš ho za starý. Ovšem je otázka jestli Ti umožní navázat na předchozí práci a nebude Tě nutit příliš mnoho věcí psát znovu, pak starý nástroj stejně budeš muset dále používat na předchozí projekty.
Jinak není žádný problém ve spolupráci C, Fortran, Python. Pro Python můžeš psát rozšiřující moduly v C i Fortranu. Knihovny v C můžeš využívat ve Fortranu a naopak.
Má už kolem 60 let!!! To snad stačí na to, abych ho prohlásil za stařečka, nebo ne?A Lispaři tě umlátí čepicemi
na jiný schopnější kompilovaný jazyk, třeba to C++Čím to, že jsem četl komplikovaný? C++ a šablony, toť syntaktický humus, ale jinak vcelku užitečná věc (včetně takových věcí jako parciální specializace a podobně). Pokud chce člověk napsat kód, kterému nebude 90% programátorů rozumět, už nemusí používat Lisp (anebo vlastně může)
labmda
, map
a reduce
.
Mě se myšlenka šablon líbí, je to tak trochu ekvivalent maker v Lispu (taky umožňuje udělat mnoho věcí v době překladu), ale ta jejich syntaxe je hnusná a viditelně do jazyka dolepená.
Osobne som prisiel na to, ze pouzivat jedneho molocha na riesenie vsetkych problemov nie je celkom ono. Sam som sa priklonil k nazoru rozdelit jednotlive ulohy na samostatne casti a na kazdu samostatne hladat najlepsie riesenie.
Ovladam C/C++, Javu, dalej Pascal a Fortran (posledne dva len na urovni skolskej vyuky...), samozrejme nejake male skriptikovanie. Ked som si vyberal v com budem pisat, hned som zavrhol pascal a fortran. V pascale nepise skoro nikto a hoci vo fortrane sa pise stale aj u nas velmi vela (KNM na MFF), mne uz jednoducho podobny jazyk nesedi. Okrem toho viem spravit most na volanie fortranovskej kniznice v cecku a cecka z javy, takze mozem pouzit fortranovsku kniznicu v cecku aj v jave.
Nakoniec som zvazoval podla nasl. veci:
Spravil som si nejake benchmarky porovnavajuce rychlost javy a cecka a zistil som ze doby ked bola java radovo pomalsia su davno prec... Z vyvojovych nastrojov su na tom oba jazyky dobre, osobne pouzivam eclipse aj na jeden aj na druhy. Takze zvitazila rychlost vyvoja, osobne v jave pisem rychlejsie (mozno preto, ze neponuka taku bohatost :)
Inak, javu pouzivam prave na konzolove aplikacie (vramci numeriky), na vyzualizacie pouzivam externe programy (nemam ambicie preprogramovat gnuplot...)
Takze momentalne som na tom nasl:
hlavna kostra mojej prace: java
z javy volam jednu ceckovu kniznicu (cez JNI) a okrem toho z nej spustam dalsi program
vypocitane vysledky dalej vizualizujem pomocou gnuplotu a mencodera
Jinak co Vám brání použít funkcionální jazyk? Je jen potřeba říci, že pokud je rychlost vaší preferencí, tak to nebude dobrá volba.Ale kuš už rozumbrado. Takovejch nesmyslů co už jsi tu vyplodil se jen tak nevidí. Jdi už s tím svým C++ tam kam slunce nesvítí. Třeba takový GHC Haskelu dýchá C++ dost zdárně na záda a třeba v jednoduchosti paralelizace se funkcionálním jazykům imperativní geronti nedotádnou ani po kotníky a nedejbože aby to bylo objektové C++.
Pokud tam máte na výpočetní jazyk rychlost, pak neseženete nic lepšího, než imperativní kompilovatelný jazyk. C++, Ada, cokoliv. Doporučuji C++, protože se snese téměř s jakýmkoli jiným jazykem, je to jazyk dělaný na max. rychlost už od počátku a jeho možnosti jsou obrovské. Velká komunita uživatelů a podpora v kompilátorech je samozřejmostí. Vhodnost konstrukcí jazyka C++ k matematice a vyjádření abstraktních výpočtů je daná. Nutno říci, že C++ není nejjednodušší jazyk na učení.Nesezene nic lepsiho nez Fortran - v C musi matematicke funkcne nastavovat errno, ma prisnejsi pravidla pro poradi provadeni operaci a tim padem mensi prostor pro optimalizace atp.
Pro ten druhý jazyk bych doporučil hlavně něco, co má snadné GUI - doporučil bych třeba Python. Python byl původně dělán pro matematiky a i pro něj jsou k dispozici slušné matematické knihovny. Python se naučíte velmi velmi rychle, je až ďábelsky snadný a přitom ohromně schopný jazyk. Co bych určitě nedoporučil? Javu - Java jde ve všem příliš vlastní cestou, je to příliš očesaný jazyk, aby byl pro matematiku užitečný.Javu(+Eclipse) bych urcite doporucil - neni to jazyk ocesany, ale genialnim zpusobem oprosteny od veci na kterych si zavili zastanci OOP radi honi saska, ktere ale snadno vedou na scesti. Jednoduchost Javy naopak vede k cistemu a explicitnimu kodu, a umoznuje existenci silneho IDE, ktere najde vsechny syntakticke (a diky vynucene cistote kodu obvykle i semanticke) chyby a nabidne UPLNY seznam moznych reseni, a to v podstate instantne, kdezto kompilatoru C++ muze u slozitejsich konstrukci trvat odhaleni chyby desitky sekund, a prvni chyba navic obvykle "rozhodi" zbytek kodu, ktery pak hlasi falesne chyby. V Pythonu pak toto nejde vubec, nebot syntakticka spravnost muze zaviset na podminkach za behu, jako treba na vstupnich datech.
a = [1, 2] b = [3, 4] c = a + bCo má být v c? [1, 2, 3, 4]? [4, 6]? Něco jiného? Co násobení? Kartézský součin? Vektorový součin? Skalární součin? Když to budete chtít dělat pořádně a jednoznačně, velice rychle zjistíte že nemáte dost přetížitelných operátorů...