Na YouTube lze zhlédnout nový celovečerní dokumentární film The Story of VS Code | Official Documentary věnovaný Visual Studio Code.
Farid Abdelnour se v příspěvku na blogu rozepsal o novinkám v nejnovější verzi 26.08.0 editoru videa Kdenlive (Wikipedie). Ke stažení také na Flathubu.
Byla vydána nová stabilní verze 8.2 webového prohlížeče Vivaldi (Wikipedie). Postavena je na Chromiu 152. Přehled novinek i s náhledy v příspěvku na blogu.
Byla vydána nová stabilní verze 4.0 svobodného multiplatformního softwaru pro editování a nahrávání zvukových souborů Audacity (Wikipedie). S rozhraním přepsaným do Qt. Přehled novinek také na YouTube. Ke stažení je oficiální AppImage. Zatím starší verze Audacity lze instalovat také z Flathubu a Snapcraftu.
NVIDIA kupuje Hugging Face za 12,93 miliardy dolarů.
Předobjednat si lze nový jednodeskový počítač Arduino VENTUNO Q s předinstalovaným Ubuntu. S 16 GB LPDDR5 a 64 GB eMMC. Pro lokální LLM, agentní AI, počítačové vidění, robotiku…
Hexpair není nejlepší HEX editor na světě a ani se o to nesnaží. Zato je k dispozici kdykoliv a kdekoliv – všude tam, kde máte svůj Vim. Vznikl jako hobby projekt před pár měsíci a dospěl do stavu, kdy by mohl být užitečný širší komunitě. Přepnout do HEX režimu se dá i uprostřed rozdělané práce: Soubor, který už máte otevřený běžným vim file.md, jedním příkazem přepnete do HEX editoru a dalším příkazem ho můžete vrátit zpět do textu. Kurzor přitom
CERN dlouhodobě používal vlastní sestavení RHEL, ze kterého přešel na CentOS Stream. Federico Vaga a Nikos Tsipinakis ale nyní v přednášce na MiniDebConf Winterthur 2026 popisují plán probíhajícího přechodu na Debian pro řízení akcelerátorů. Důvodem k opuštění CentOS Stream jsou zachování zpětné kompatibility se starším hardwarem, kterou Red Hat narušuje, když tlačí sestavení balíčků pro novější verze architektury (x86-64), a nedostatečné nástroje pro sestavování vlastních balíčků a repozitářů.
UZDoom (Wikipedie), tj. fork GZDoom, byl vydán ve verzi 5.0.0. Videopředstavení na YouTube. Podrobný přehled novinek v Changelogu.
"user1";"1";"7" "user2";"2";"6" "user3";"3";"5" "user4";"3";"4" "user5";"4";"3" "user6";"4";"2" "user7";"4";"1"Pokud chci 3 záznamy řazené podle 2. sloupce a potom 3. sloupce, tak to musí vrátit user1, user2, user4. Nepřišel jsem na optimální algoritmus jak dostat 3 záznamy aniž bych musel přečíst celý 1. soubor, celý 2. soubor a pak to limitovat až ve výsledku, což je ale velice datově a výpočetně náročné pro větší množství dat. Určitě už někdo podobný problém řešil. Prosím o pomoc/popis algoritmu pro toto řazení.
sloupec1+sloupec2 = soubor1, řazený vzestupně podle 2. sloupce sloupec1+sloupec3 = soubor2, řazený vzestupně podle 3. sloupce "user1";"1";"7" "user2";"2";"6" "user3";"3";"5" "user4";"3";"4" "user5";"4";"3" "user6";"4";"2" "user7";"4";"1" 1. z prvního souboru vyberu první 3 => user1, user2, user3 2. z druhého souboru vyberu první 3 => user7, user6, user5 3. spojím a zobrazím všechna data "user1";"1";"7" "user2";"2";"6" "user3";"3";"5" "user7";"4";"1" "user6";"4";"2" "user5";"4";"3" 4. omezím na první 3 => user1, user2, user3 = CHYBANeboť primárně řadím podle 2. sloupce, tak user3 a user4 jsou nerozhodně (oba = 3), pomocí druhého sloupce ale zjistím, že user4 je před user3, což se ale při tomto algoritmu neprojeví.
n plus všechny, co mají stejný druhý sloupec jak n-tý
což je ale velice datově a výpočetně náročné pro větší množství datProto je dobré mít ta data v dobře zpracovatelném formátu a udržovat další informace pro jejich rychlé prohledávání a propojování. A tak vznikly databáze.
Nicméně nakonec asi budu řadit tímto algoritmem:1. vyberu n řádků ze zdroje 1 .. - zjistím že m z n řádků nemají jednoznačné pořadí, tak prohledám zdroj 1 znovu a vyberu z n řádky které nemají jednoznačné pořadí + řádky s tímto "indexem", ale za limitem dotazu a postoupím dalšímu zdroji 2. to samé .......
sloupec1+sloupec2 = soubor1, řazený vzestupně podle 2. sloupcetzn. ze vuci sobe nejsou serazeny vubec (teda ano 1. sloupcem) -> to musis imho projit vsechny zaznamy ...
sloupec1+sloupec3 = soubor2, řazený vzestupně podle 3. sloupce
jmeno; cislo; cislo2
-----------------------
"user1";"1";"7"
"user2";"2";"6"
"user3";"3";"5"
"user4";"3";"4"
"user5";"4";"3"
"user6";"4";"2"
"user7";"4";"1"
order by cislo, cislo2 limit 3 = user1, user2, user4
teď ten algoritmus:
- select cislo ... order by cislo limit 3
1 2 3
- select jmeno ... where cislo in (1,2,3) => user1, user2, user3, user4
- pak zjistim ze sporne cislo je u user3 a user4
- select jmeno ... where jmeno in ("user3", "user4") order by cislo2 limit3 => user4, user3 => prerovnam puvodni vyber "user1, user2, user3, user4" na "user1, user2, user4, user3" a omezim na 3 => "user1, user2, user4"
Zásadní vada na kráse je ale ta že tento algoritmus je docela složitý.
Většinou se bude jednat o různé typy relačních databází.Tak pri dotaze z kazdej databazy treba prvych n riadkov utriedenych podla vyslednych ziadanych stlpcov. A nasledne utriedit vsetky takto ziskane riadky (pri 3 databazach teda 3*n riadkov). To je algoritmus uvedeny uz v otazke (a takisto posledny sposob uvedeny v 1. komentari). Ale to utriedenie musi byt vsade rovnake ako vysledne ziadane.
Tiskni
Sdílej: