Vývojáři mobilní Datovky prosí o pomoc s testováním beta verze mobilní Datovky s novým grafickým rozhraním, podporou pro tmavý režim a podporou pro VoDZ. Aplikace je zatím dostupná pouze pro zařízení Android a je umístěna v samostatném instalačním kanále Datovka Beta. Tento kanál slouží pro testovaní nové funkcionality a grafického uživatelského rozhraní. Datovka Beta se instaluje jako samostatná aplikace s vlastními daty, která
… více »Harlequin byl vydán ve verzi 1.0.0. Jedná se o TUI (Text User Interface) IDE (Integrated Development Environment) k systému pro správu SQL OLAP databází DuckDB.
Po roce a půl od představení DALL·E 2 představila společnost OpenAI novou verzi DALL·E 3 svého AI systému pro generování "realisticky vypadajících obrázků nebo uměleckých děl" na základě popisu v přirozeném jazyce, viz příklad "kosmonaut na koni fotorealisticky". Jednou z novinek je integrace s ChatGPT.
Nová čísla časopisů od nakladatelství Raspberry Pi: MagPi 133 (pdf) a HackSpace 70 (pdf).
Po půl roce vývoje od vydání verze 44 bylo vydáno GNOME 45 s kódovým názvem Rīga. Přehled novinek i s náhledy v poznámkách k vydání a v novinkách pro vývojáře. Krátké představení na YouTube. Jednou z nejviditelnějších změn je odstranění tlačítka Činnosti (Activities) v levém horním rohu. Nově je tam indikátor ploch. Výchozím prohlížečem obrázků je nově Loupe, nahradil Eye of GNOME (eog). Novou aplikací pro práci s webovou kamerou je Snapshot, nahradil Cheese. Rozšíření GNOME Shellu fungující v předchozích verzích nejsou s verzí 45 kompatibilní.
Linux Foundation představila a zaštítila svobodný a otevřený fork Terraformu s názvem OpenTofu. Ten vznikl pod původním názvem OpenTF jako reakce na přelicencování Terraformu na BSL (Business Source License) společností HashiCorp.
Google oznámil (en), že konverzační AI Bard (Wikipedie) může nyní komunikovat s aplikacemi a službami Google: "Díky nejnovějšímu rozšíření služby může Bard najít a zobrazit relevantní informace z nástrojů společnosti Google, které používáte každý den, jako je například Gmail, Dokumenty, Disk, Mapy, YouTube a Letenky Google, a to i když jsou potřebné informace v různých aplikacích a službách."
Apache Pinot (GitHub, Wikipedie) dospěl do verze 1.0. Jedná se o realtimeový distribuovaný OLAP datastore navržený tak, aby na OLAP dotazy odpovídal s nízkou latencí.
Byla vydána Java 21 / JDK 21. Nových vlastností (JEP - JDK Enhancement Proposal) je 15. Jedná se o LTS verzi. Nová Java / JDK vychází každých 6 měsíců.
Byla vydána betaverze Fedora Linuxu 39, tj. poslední zastávka před vydáním finální verze, která je naplánována na úterý 17. října. Nový Fedora Linux přinese GNOME 45, LibreOffice 7.6, GCC 13.2, …
(rename src desc)
, která přejmenovává nějaký soubor.
Teď já tuto funkci zavolám dejme tomu třikrát, asi takhle:
(randomseq (rename "a.txt" "b.txt") (rename "b.txt" "c.txt") (rename "c.txt" "d.txt") )Z logiky věci (ačkoliv tento příklad není úplně ideální) nám záleží na pořadí těch příkazů. Ale jak naznačuje název té sekvence, tak mi nic nezabrání, abych ty tři funkce nacpal do sekvence, která pořadí příkazů nezaručuje. Což je samozřejmě blbě. A mě se jedná o to, jak, pomocí typů můžu zajistit, abych takovou blbost, viz víše nemohl udělat. Znám IOMonády z Haskellu. Jestli je chápu dobře, tak mám naférovku typ sekvence, která zajišťuje seřaditelnost. A pak mám řečeno, že ta funkce může být použita jen a pouze v této sekvenci. Správně? Jsou i jiné možnosti? Jen pro zajímavost, nad čím dumám: Tak například jsem při své úvaze vymyslel, že ta funkce rename, krom dvou jmen souborů bude mět ještě argument IO přijímající stav filesystému. A návratová hodnota bude výsledný stav filesystému. (To aby to bylo pure funkcionální.) Můžu si vymyslet typ, který bude fungovat jako singleton, takže jakákoliv další funkce, která chce pracovat s filesystémem musí tuto hodnotu "pustit", aby s tím mohla jiná funkce pracovat. Což se mi líbí. Hezky to řeší synchronizaci. Ale už to neřeší pořadí. Jak může funkce pomocí svého typu ovlivnit, jak bude komponovaná do výrazu?
Jazyk? Něco lispoidního?Žádný konkrétní jazyk, jen jsem chtěl popsat problém, a zvolil jsem lispovsko syntax.
Zřejmě se někomu pokoušíš sdělit, že funkce rename má vedlejší efekty. Komu? Kompilátoru? Uživateli?Kompilátoru. Ale ono není jisté, zda se jedná o vedlejší efekt, když výsledek vracím v návratové hodnotě.
Jistě je možné stav fs něčím reprezentovat a předávat si to. Nejsou monády zrovna o tom?Jsou. A existuje i jiný způsob? A navíc, mě ani nejde tak o ten stav, jako spíše o tu nutnost zachovat pořadí (a ano, i o tom právě monády jsou).
Co je přesně cílem? Zabránit uživateli jazyka, aby si střelil do nohy?Defakto ano. Přesněji potřebuji kompilátorovi říct: "Hele, až tohle budeš optimalizovat, tak nezapomeň zachovat pořadí."
není vedlejší efekt, když výsledek vracím v návratové hodnotě.
(rename "a.txt" "b.txt")Výsledkem je přejmenování souboru na souborovém systému, ten typ návratové hodnoty bych chtěl vidět.
Ok, takže obecná úvaha o návrhu programovacího jazyka či prostředí.Tak.
Ano, ano, takto jsem to myslel. "Plná" deklarace té funkce by byla něco jako:není vedlejší efekt, když výsledek vracím v návratové hodnotě.(rename "a.txt" "b.txt")Výsledkem je přejmenování souboru na souborovém systému, ten typ návratové hodnoty bych chtěl vidět.Leda by to právě "stav souborového systému" žralo na vstupu a zas ho to vyhazovalo na výstupu.
(rename io src desc) -> io
Alternativně viz jedna z těch linkovaných úvah o "pure deklaraci" mít u všech knihovních funkcí informaci o jejich čistotě (absenci vedlejších efektů) a dokazovací systém, který si pro uživatelem zadefinovanou věc umí odvodit jestli je čistá nebo ne a bude přerovnávat jen ty čisté. Pak to může dělat takové legrácky, že bude výsledky pure funkcí cachovat, což může některé rekurzivní programy dost zrychlit (memoizace).Chápu to dobře, že to "jiné" řešení spočívá v tom, že se taková funkce prostě jenom označí, že u ní záleží na pořadí? Hmm, a jak může kompilátor zjistit, že víše uvedenou konstrukci nesmí přeložit? Mě napadá právě jen to, že sekvence randomseq má typovou signaturu, že přijímá pouze pure funkce (přesněji, funkce, které deklarovali, že jim na pořadí nezáleží). Myslíš to taky tak? Existují ještě jiné způsoby (krom těch monád)?
No nevím, přijde mi nějaké pochybné na tohle používat typový systém. - Píšeš "Z logiky věci (ačkoliv tento příklad není úplně ideální) nám záleží na pořadí těch příkazů". Tady to tak vypadá - ale jen zdánlivě. Co kdyby jsi se pokoušel ve skutečnosti použitým kódem implementovat nějaký program na (pseudo)náhodné rozmetání souborů na disku (třeba šéfovi, který ti nezvýšil výplatu ?) Chceš, aby takový program nebylo možné implementovat?Ano, to si uvědomuji, proto jsem řekl, že ten příklad není ideální. Jde mi o něco takového:
main :: IO () main file = do putStr $ "Write to file: " ++ file h <- openFile file AppendMode hPutStr h anytext hClose h putStrLn "... done"Kdy mi na tom pořadí záleží, a nemůžu tolerovat, aby mi to překladač přeházel pořadí. Ale je fakt, že ani tady volaný neovlivňuje pořadí. Možná jsem se v tom jen zamotal.
- Pokud to zakóduješ do typového systému, ztratíš možnost typově bezpečně vytvářet takové sekvence za běhu (z uživatelského vstupu).Tak né nutně. Od toho ten typový system je, že určuje co mohu dělat. A když to určím blbě, tak je to chyba programátora funkce, ne uživatele. Za link díky, nastuduji.
getLine :: IO String
print :: String -> IO String
getLine >>= print :: IO String
getLine >>= print
vrací IO monádu, která nejprve zavolá getLine, a na výsledek zavolá print.
Pro tebe je důležitý use case s funkcí rename. Jak by jsi dosáhl to, co potřebuješ, když to bude IO monáda?
Jakého vlastně má být typu (zanedbám možnost selhání rename)?
rename(rename(rename("a.txt", "b.txt"), "c.txt"), "d.txt")
Teďka ovšem chvilka k zamyšlení - k čemu mi vlastně byla IO monáda, když jsem toho samého mohl dosáhnout v obyčejném C - úplně přesně stejně, jak jsem právě napsal nahoře? :) Bohužel, žádný bonus oproti primitivnímu imperativnímu jazyku nepřinesla ...
Teďka ovšem chvilka k zamyšlení - k čemu mi vlastně byla IO monáda, když jsem toho samého mohl dosáhnout v obyčejném C - úplně přesně stejně, jak jsem právě napsal nahoře? :) Bohužel, žádný bonus oproti primitivnímu imperativnímu jazyku nepřinesla ...Zásadní hendikep monád je fakt blbej zápis. Dlouho se na to zvyká. Bonus je v separaci kódu od reality. Když zapíšeš:
rename(rename(rename("a.txt", "b.txt"), "c.txt"), "d.txt")v céčku a zavoláš, tak ti to pokaždý přejmenuje soubor a.txt, (a když nebude, tak to chcípne). Jenže ty to chceš třeba jen otestovat, nebo to přejmennovat na jiném fs, nebo to přejmenovat v transakci, etc. V takovém případě ti imperativní C začne házet klacky pod nohy. (A to nemluvě o tom, když bych to chtěl strojově číst a chápat. Třeba kůli dokazování nějaké bezpečnosti a tak. Ale to už jsme jinde.) Takže přejdeš na objekty a uděláš něco jako:
fs = new IO() fs.rename(fs.rename(fs.rename("a.txt", "b.txt"), "c.txt"), "d.txt") fs.commit()A to už jsi jen krůček od Monád.
Teďka ovšem chvilka k zamyšlení - k čemu mi vlastně byla IO monáda, když jsem toho samého mohl dosáhnout v obyčejném C - úplně přesně stejně, jak jsem právě napsal nahoře? :) Bohužel, žádný bonus oproti primitivnímu imperativnímu jazyku nepřinesla ...Zkoušel jsem přepsat do imperativního jazyka Either a Maybe monádu. A je to v nich strašně ale strašně ukecaný.
Pro tebe je důležitý use case s funkcí rename. Jak by jsi dosáhl to, co potřebuješMoje představa, se kterou si pohrávám je něco takového:
rename (io = getcontext, src:String, dsc: String): String, setcontext(io)Kdy jakože io je argument s defaultní hodnotou, která se získá načtením z contextu, uvnitř té funkce s ním pracuji jako s dalším argumentem, když chci, můžu ten argument použít. Po zavolání té funkce, se ten argument nahradí za hodnotu v kontextu. Takže při volání ten IO nemusím vůbec používat.
(rename src dsc)Jenže mi to ty Monády příliš připomíná, tak jsem se začal ptát. Cílem je udělat čitelnější a pohodlnější zápis těchto druhů funkcí.
Tiskni
Sdílej: