Byla vydána beta verze openSUSE Leap 16. Ve výchozím nastavení s novým instalátorem Agama.
Devadesátková hra Brány Skeldalu prošla portací a je dostupná na platformě Steam. Vyšel i parádní blog autora o portaci na moderní systémy a platformy včetně Linuxu.
Lidi dělají divné věci. Například spouští Linux v Excelu. Využít je emulátor RISC-V mini-rv32ima sestavený jako knihovna DLL, která je volaná z makra VBA (Visual Basic for Applications).
Revolut nabídne neomezený mobilní tarif za 12,50 eur (312 Kč). Aktuálně startuje ve Velké Británii a Německu.
Společnost Amazon miliardáře Jeffa Bezose vypustila na oběžnou dráhu první várku družic svého projektu Kuiper, který má z vesmíru poskytovat vysokorychlostní internetové připojení po celém světě a snažit se konkurovat nyní dominantnímu Starlinku nejbohatšího muže planety Elona Muska.
Poslední aktualizací začal model GPT-4o uživatelům příliš podlézat. OpenAI jej tak vrátila k předchozí verzi.
Google Chrome 136 byl prohlášen za stabilní. Nejnovější stabilní verze 136.0.7103.59 přináší řadu novinek z hlediska uživatelů i vývojářů. Podrobný přehled v poznámkách k vydání. Opraveno bylo 8 bezpečnostních chyb. Vylepšeny byly také nástroje pro vývojáře.
Homebrew (Wikipedie), správce balíčků pro macOS a od verze 2.0.0 také pro Linux, byl vydán ve verzi 4.5.0. Na stránce Homebrew Formulae lze procházet seznamem balíčků. K dispozici jsou také různé statistiky.
Byl vydán Mozilla Firefox 138.0. Přehled novinek v poznámkách k vydání a poznámkách k vydání pro vývojáře. Řešeny jsou rovněž bezpečnostní chyby. Nový Firefox 138 je již k dispozici také na Flathubu a Snapcraftu.
Šestnáctý ročník ne-konference jOpenSpace se koná 3. – 5. října 2025 v Hotelu Antoň v Telči. Pro účast je potřeba vyplnit registrační formulář. Ne-konference neznamená, že se organizátorům nechce připravovat program, ale naopak dává prostor všem pozvaným, aby si program sami složili z toho nejzajímavějšího, čím se v poslední době zabývají nebo co je oslovilo. Obsah, který vytvářejí všichni účastníci, se skládá z desetiminutových
… více »rad bych zde zacal maly tutorialek o tom jak si napsat interpetr programovaciho jazyka. kazdy spravny programator, by si mel za zivot urcite nejaky programovaci jazyk napsat. vite, jaky to dela dojem na zenske, kdyz je balite se slovy: "nechcete, abych vas uvedl do taju sveho interpretru?" jelikoz z urcitych duvodu pisu dialekt schemu, tak bych se o nektere poznatky rad podelil a jelikoz se to vleze na par set radku nebude to ani tezke. berte to spis jako inspiraci, nez nejake fundamentalni cteni.
vetsina clanku o jazycich zacina popisem gramatiky. zacnu trosku netradicni modelem prace s pameti. hodne zasadnim rysem jazyka byva jak pracuje s pameti. sice se muze zdat, ze automaticka sprava pameti je domenou trendy jazyku jako java nebo c# a opravdovi muzi ji nepouzivaji, ale garbage collector je tu uz nekdy od konce 50. let, kdy byl vymyslen pro lisp.
jednoduchy model automaticke spravy pameti vychazi z myslenky, ze kazdy kousek pameti si u sebe drzi pocet odkazu (pocitadlo) na dany blok v pameti. a pokud je vytvoren odkaz na dane misto, zvysi se pocitadlo, pokud je odkaz zrusen pocitadlo se snizi. kdyz pocet odkazu spadne na 0, je pamet uvolnena. tento princip je pouzity treba ve smart pointrech.
krasna je teorie, oskliva je praxe. tento pristup ma velkou radu neduhu -- at uz je to rezije, kterou spotrebuje pocitadlo na sve ulozeni a operace scitani/odecitani taky nejaky cas zaberou. to nemluvim o tom, ze kdyz se jedna o vice vlaknovou aplikaci, je nutne, aby pocitadlo bylo chranene nejakym mutexem a to taky neco stoji. nejhorsi na tom je, ze pocitani odkazu nemusi vubec fungovat a muze delat osklive memory-leaky kvuli cyklickym odkazum. pocitani odkazu, i pres to, ze jde snadno pouzit a implementovat, se v praxi moc nepouziva, co vim, tak jej pouziva visual basic 6.0 a delphi na nektere typy datovych struktur.
bezne garbage collectory vychazi opet z myslenky, ze pamet se nebude pouzivat (a tudiz je uvolnitelna) v pripade, ze na ni nevede odkaz z nejakeho jineho kousku pameti. z teoretickeho pohledu je pamet rozdelena na kousky, ktere jsou provazany jako orientovany graf skladajici se z nekolika komponent. jenomze jak poznat, ktere casti jsou dostupne a ktere uz ne? neni to tezke. dostupne casti pameti jsou ty, ktere jsou odkazovany od nekud ze zasobniku nebo ze staticke promenne.
garbage collectoru je vicero druhu a jednotlive rysy se mezi sebou kombinuji. ale to je na uplne jiny clanek. napsat slusny garbage collector je docela veda. osvedcil se mne boehmuv konzervativni garbage collector, ktery jde velice snadno zaclenit do stavajicich c/c++ aplikaci. nekteri o nem rikaji, ze je pomaly, ale z open source collectoru je jeden z nejrychlejsi, podporuje slusnou radku platforem (vcetne amd64, coz je u rady collectoru problem) a ma vynikajici vykon ve vicevlaknovych aplikacich. nasel jsem par clanku, ze v ibm maji neco lepsiho... ale zdrojaky nejak nedali k dispozici. kdyby nekdo vedel o necem podobnem, dejte mne vedet.
pouzivani je proste, jak bulharska stripterka:
staci linkovat proti knihovne "gc", pridat na zacatek kazdeho souboru "#include <gc/gc.h>
" a pouzit nekterou funkci pro alokaci.
GC_MALLOC(x)
-- je obdobou bezneho mallocu, jedna se o nejobecnejsi funkci a pokud opravdu provedete v stavajici aplikaci nahradu malloc
u za GC_MALLOC
a odstraneni volani free()
, mela by aplikace bezetGC_MALLOC_ATOMIC(x)
-- alokuje pamet stejne jako predchozi funkce (potazmo makro), jenom s tim rozdilem ze dava collector napovedu, ze dana oblast neobsahuje odkaz do jine oblasti pameti (napr. pole doublu, intu, atp.), teoreticky by to melo zrychlit beh, ale osobne jsem moc velky rozdil nevidelpokud aplikace ma bezet ve vicevlaknovem prostredi je nutne v souborech pouzivajici neco z knihovny pthread, pred inkluzi gc.h deklarovat makro GC_THREADS
a collector nektere funkce obali svymi.
co je ale hezka vec, boehmuv kolektor se umi optimalizovat, aby kazde vlakno si alokovalo data zvlast a nemuselo dochazet k zamykani. staci pouzivat funkci GC_local_alloc(x)
, popr. deklarovat makro GC_REDIRECT_TO_LOCAL
a to prevede vsechny volani GC_MALLOC
na "optimalizovane". ma to ale jednu neprijemnou vlastnost. collector si uklada informace pomoci pthread_set_specfic, takze pokud je funkce volajici GC_local_alloc
zavolana primo z procesu a ne z vlakna, zacne se chovat nepredvidatelne (teda segfaultuje). ale to jde resit, ze se v procesu spusti samostatne vlakno a predaji se mu jenom argumenty aplikace. (no jo, thready jsou v unixu cizorody element a prace s nimi neni tak komfortni jako treba ve windows)
pro vetsi nahled do problematiky garbage collectoru muzu doporucit stranky pana boehma, ktery vyvraci nektere myty a pak velice pekne pocteni http://www.sidhe.org/~dan/blog/archives/000200.html, kde jsou collectory popsane mnohem srozumitelneji nez ode me.
Tiskni
Sdílej:
reference counting jsem zminil, protoze presto ze je hodne nedokonaly v praxi se stale pouziva, at uz ve zminenych jazycich, ci aplikacich se smart pointry (a ze tech je). a v implementaci schemu jde docela snadno pouzit (vyzkouseno), ale za cenu degradace rychlosti.V podstatě není důvod proč ho používat jinak než jako nouzovou nadstavbu nad existující správou paměti (to je případ právě těch smart pointerů).
pro spravu pameti jsem zvolil boehmuv gc, protoze odpada samotna implementace garbage collectoru a tudiz napsat interpretr je snadnejsi a rychlejsi ;-] je to proste jak ve vetsine soucasnych jazyku -- alokuj si co potrebujes a o nic vic se nestarej.To je právě otázka...
mohl byste se prosim rozepsat o potencialnich problemech s pouzitim konzervativniho gc, pred vlastnim? (pominu-li skutecnost, ze konzervativni gc se obcas netrefi)Nejde ani tak o problémy, jako spíše že není žádný prostor pro vylepšení a přizpůsobení. Vlastní GC umožňuje například řešit fragmentaci paměti nebo může být i plně paralelní, atd. To ale závisí na tom, jaké jsou s tím interpreterem plány. Konzervativní C garbage collector má ale jednu velkou výhodu - zjednoduší psaní samotného interpreteru.