Na čem aktuálně pracují vývojáři GNOME a KDE? Pravidelný přehled novinek v Týden v GNOME a Týden v KDE.
Před 70 lety, 7. června 1954, ve věku 41 let, zemřel Alan Turing, britský matematik, logik, kryptoanalytik a zakladatel moderní informatiky.
NiceGUI umožňuje používat webový prohlížeč jako frontend pro kód v Pythonu. Zdrojové kódy jsou k dispozici na GitHubu pod licencí MIT.
Open source platforma Home Assistant (Demo, GitHub, Wikipedie) pro monitorování a řízení inteligentní domácnosti byla vydána ve verzi 2024.6. Z novinek lze vypíchnout lepší integraci LLM (OpenAI, Google AI, Ollama) nebo podporu Matter 1.3.
IKEA ve Spojeném království hledá zaměstnance do své nové pobočky. Do pobočky v počítačové hře Roblox. Nástupní mzda je 13,15 liber na hodinu.
Alyssa Rosenzweig se v příspěvku na svém blogu Vulkan 1.3 na M1 za 1 měsíc rozepsala o novém Vulkan 1.3 ovladači Honeykrisp pro Apple M1 splňujícím specifikaci Khronosu. Vychází z ovladače NVK pro GPU od Nvidie. V plánu je dále rozchodit DXVK a vkd3d-proton a tím pádem Direct3D, aby na Apple M1 s Asahi Linuxem běžely hry pro Microsoft Windows.
Byla vydána (𝕏) květnová aktualizace aneb nová verze 1.90 editoru zdrojových kódů Visual Studio Code (Wikipedie). Přehled novinek i s náhledy a animovanými gify v poznámkách k vydání. Ve verzi 1.90 vyjde také VSCodium, tj. komunitní sestavení Visual Studia Code bez telemetrie a licenčních podmínek Microsoftu.
Byla vydána (Mastodon, 𝕏) nová verze 2024.2 linuxové distribuce navržené pro digitální forenzní analýzu a penetrační testování Kali Linux (Wikipedie). Přehled novinek se seznamem nových nástrojů v oficiálním oznámení.
Počítačová hra Tetris slaví 40 let. Alexej Pažitnov dokončil první hratelnou verzi 6. června 1984. Mezitím vznikla celá řada variant. Například Peklo nebo Nebe. Loni měl premiéru film Tetris.
MicroPython (Wikipedie), tj. implementace Pythonu 3 optimalizovaná pro jednočipové počítače, byl vydán ve verzi 1.23.0. V přehledu novinek je vypíchnuta podpora dynamických USB zařízení nebo nové moduly openamp, tls a vfs.
Možná jste i vy někdy řešili otázku, jaký formát použít pro uložení výchozí konfigurace vašeho skriptu či aplikace. U shellových skriptů, si většinou vystačíte s jednoduchým textovým souborem, ve kterém jsou přiřazené výchozí hodnoty proměnných stejně jako ve skriptu – takový soubor si pak může skript natahovat rovnou při spuštění. Pro složitější konfiguraci je však lepší pracovat se strukturovanými formáty, jako je XML, YAML, nebo JSON.
Ovšem zpracování strukturovaného formátu přímo shellovým skriptem vyžaduje napsání parsovací funkce, která nemusí být triviální záležitostí. Proto je lepší držet se unixové filozofie a pro jejich zpracování využívat specializované procesory.
Snad nejrozšířenějším formátem pro uložení strukturovaných dat v současnosti je XML, pro jehož zpracování je k dispozici řada nástrojů počínaje těžkotonážními XSLT parsery v javě a subtilní aplikací xmlstarlet konče. Právě posledně jmenovaná aplikace se mi velice osvědčila při zpracování velkých XML souborů. Nechci vás zatěžovat zdlouhavým popisem co všechno umí, proto vás odkazuji na jeho manuálovou stránku a jeden ukázkový příklad ve zdejší poradně, který uvedl již před sedmi lety Fuky.
Dalším poměrně rozšířeným strukturovaným formátem je JSON, se kterým se můžete setkat na nejrůznějších místech. Kupříkladu u QMP konzole QEMU, nebo u souborů které používá rmlint
, o kterém jsem tu rovněž před časem psal (viz rmlint - řešení duplicit. I pro něj existuje podobná malá svižná aplikace – jq, která dovoluje výstup zpracovávat podobně, jako když aplikujeme sed
na obsah textových souborů. Viz několik ukázkových příkladů
Tiskni Sdílej:
[WRAPPER_B] socket = /tmp/xnbd_wrapper.B.ctl port = 8250 volumes = ['/testovaci/disc.img' ,'/testovaci/cd.iso'] address = localhost [WRAPPER_A] socket = /tmp/xnbd_wrapper.A.ctl port = 777 volumes = ['/next/disc.img' ,'/next/cd.iso'] address = 10.0.0.1Podotýkám, že v tomto případě nejde o konfiguraci shellového skriptu, nýbrž pouze o ukázku toho co považuji za složitější konfiguraci.
socket_A = '/tmp/xnbd_wrapper.B.ctl' port_A = 8250 volumes_A = ('/testovaci/disc.img' ,'/testovaci/cd.iso') address_A = localhost socket_B = '/tmp/xnbd_wrapper.A.ctl' port_B = 777 volumes_B = ('/next/disc.img' ,'/next/cd.iso') address_B = '10.0.0.1', který se pak inklůdne (v shellu) a mám hned inicializované proměnné k dispozici bez jakéhokoliv potřebného parsovacího modulu.
<category> <sub page_id="74823" parent_page_id="20331"> <![CDATA[PowerBanky]]> </sub> <sub page_id="75681" parent_page_id="20338"> <![CDATA[Nabíjačky]]> </sub> <sub page_id="71290" parent_page_id="20338"> <![CDATA[Univerzálne nabíjačky]]> </sub> <sub page_id="72975" parent_page_id=""> <![CDATA[]]> </sub> <sub page_id="74824" parent_page_id=""> <![CDATA[]]> </sub> <sub page_id="75676" parent_page_id="20338"> <![CDATA[Mobilné a telefónne príslušenstvo]]> </sub> <sub page_id="76162" parent_page_id="20331"> <![CDATA[Energia na cesty]]> </sub> </category>Nechcelo sa mi hľadať tie najhošie, kde sú niektoré suby prázdne a inak posraté, nepoznám parser ktorý by to rozchodil, preto používam svoj vlastný. Tie parseri nevedia rozchodiť rovnaký tag z/bez atributov a ešte keď sa tam opakujú rovnaké hodnoty atribútov a tagov. Samozrejme je tam niekedy jeden sub a pri ďalšej položke 15 subov. Je pravda, že teoreticky by to šlo vyexportovať do XML aj cez tagy a hodnoty, ale proste také XML v reále od nikoho nedostaneš, takže môj parser tie suby čísluje 1,2,3 ... inak to proste do ničoho neskonvertuješ a ani tabuľkové procesory to nerozchodia, teda už z podstaty nemajú ako. Každé väčšie XML má proste nejaký skurwený formát, entity a ja neviem čo. Jako momentálne dokážem vyťahať údaje hádam z každého XML, ale chvíľu mi trvalo než som nad tým vyhral. Ono väčšina tých úplných parserov je ľahko hacknutelných, pretože je tam ešte podpora ťahania dát z externých súborov.
Je neco cemu bys ty osobne dal prednost?Bohužel je to bída s nouzí... Pro své projekty psané v Céčku používám konfigurační mechanismus z LibUCW, ale nikdy jsem se nedostal k napsání slušných bindingů pro jiné jazyky, mimo jiné proto, že je to celé snad až příliš ukotvené v typovém systému Céčka. Jinak používám různé omezené podmnožiny YAMLu, ale skřípu nad tím zuby od doby, kdy jsem si zkoušel napsat vlastní YAMLový parser :)
/etc/default
, přes kterou lze měnit výchozí hodnoty globálních proměnných a pak (pokud je to nutné) s dílčí konfigurací která se může spravovat přímo skriptem.
Zrovna teď si píšu tool, který umožňuje řídit virtuály v situaci, kdy potřebuji mít z nějakého důvodu odstavený pacemaker. Na jejich řízení (pokud je pacemaker aktivován a služba ve stavu managed) mám svého agenta, který pracuje přímo s QEMU. Nepotřebuji tedy žádný libvirt ani omáčku kolem. Psal jsem o tom před časem v blogpostu o parametru utilization v konfiguraci pacemakeru. Ten tool tedy pracuje se zcela identickou výchozí konfigurací, ale protože nabízí i další možnosti, které původní kvm agent nemá, uvažuji o její paralelní interpretaci v JSON formátu, která by se využívala kupř. při uspání stroje, modifikaci konfigurace VM za běhu, nebo při live migraci. Před šesti lety jsem si už jeden takový tool napsal, možná by byl i použitelný, ale byl závislý i na aplikacích které nejsou běžnou součástí standardní instalace, takže bych ho stejně musel téměř celý přepsat.
Já bych třeba v Perlu použil jednoduchý modul 'Storable', který se mi o to postará. Soubor je pak texťák, ale takový, aby byl co nejlépe a nejrychleji zpracovatelný strojově, takže je pro "čtenáře" skoro nečitelný.<rejp>Neplatí tohle náhodou i pro zdrojáky v tom perlu?</rejp>
Tak jasně, pokud dojde k tomu, že si musíme někam odkládat složitější datové struktury, pak se JSON (případně jiné vhodnější) pro to může hodit.Mimochodem, docela zajímavý je k těmto účelům CBOR. Sémantika podobná jako JSON, ale je binární a mnohem efektivnější jak časově, tak prostorově.
[ { "interfaces": [ { "device": "eth1", "ipv4": "10.0.0.12", "timestamp": 1500558336, "note": "Odstavit až vyprší čas" }, { "device": "eth2" } ] } ]
array[0]="hrušky\0"; array[1]="jablka\0" array[2]="#nějaký komentář\0"
double
(což je v Javě taky 64-bit IEEE 754), celá čísla nejprve jako long
, a pokud se to vleze do integeru, tak jako int
. Viz #stringToValue.
Úplně správně bych si to tedy představoval tak, že pokud se to ani do jednoho z těchto typů nevleze, uloží se to jako BigInteger, resp. BigDecimal.
to má vyřešené dobře. Desetinná čísla to vždy ukládá jako double... což mimochodem také může vést ke ztrátě přesnosti.
Úplně správně bych si to tedy představoval tak, že pokud se to ani do jednoho z těchto typů nevleze, uloží se to jako BigInteger, resp. BigDecimal.No to já také, ale takovou implementaci jsem nejspíš ještě nepotkal. Problém tkví právě v tom, že chování čísel je specifické pro implementaci, takže se na něj prakticky nemůžete spolehnout.
Možná jste i vy někdy řešili otázku, jaký formát použít pro uložení výchozí konfigurace vašeho skriptu či aplikace.Ani ne. Vzhledem k tomu, že všechny moje bastly používají db, tak jediný konfigurák je connstring. Někdy ani to ne, pokud to běží lokálně, tak se to připojí na unix socket s auth pomocí ident. Veškeré další nastavení stejně jako data jsou potom v db. Pokud už se vyloženě něco musí nastavovat, tak je konf soubor v syntaxe daného jazyka (python, bash), který se prostě includuje.