Příspěvky

1186

Vývoj / Re:Typový system versus unittesty

« kdy: 19. 08. 2018, 21:17:05 »

Případně by se mohl ten požadavek změnit a formalizovat na „trvání funkce musí být v rozmezí x až y ms“. Což se třeba dá zapsat formálně, ale překladač to nemůže zkontrolovat, protože netuší, na jaké cílové platformě ten kód poběží.

Jak nemůže? Proč by nemohl? Ať je platforma jakákoliv, tak čas bude všude stejný ne? Této argumentaci nerozumím.

překladač nezná frekvenci hodin cílového CPU, ta se navíc může za běhu měnit, to nemusí až tak moc vadit, pokud bychom se zabývali jenom nejhorším možným případem

Já tam vidím "ms", takže na frekvenci CPU nezáleží.

Ostatně, to, že rychlost funkce závisela na rychlosti procesoru je pradávná historie. Dneska když se píše hra, tak se určitě nebude opírat o frekvenci CPU, ale o hodiny.

kde byste vzal dobu trvání fragmentu kódu?

Jen si to představ. Vezmeš nějakou hru a dáš ji přeložit pod 486kou, a ono ti to odmítne, protože nejde zaručit potřebnou rychlost. Horní mez je sranda, to stačí jen oříznout.

Tak samozřejmě se můžeme bavit o tom, jak to zjistit, jak moc to jde zaručit, ale je třeba myslet na kontext tohoto vlákna. Porovnáváme to s testy. Pokud to nezvládneš ani testy, tak není nutné řešit jak to udělat typy.

1187

Vývoj / Re:Typový system versus unittesty

« kdy: 19. 08. 2018, 20:53:02 »

Případně by se mohl ten požadavek změnit a formalizovat na „trvání funkce musí být v rozmezí x až y ms“. Což se třeba dá zapsat formálně, ale překladač to nemůže zkontrolovat, protože netuší, na jaké cílové platformě ten kód poběží.

Jak nemůže? Proč by nemohl? Ať je platforma jakákoliv, tak čas bude všude stejný ne? Této argumentaci nerozumím.

překladač nezná frekvenci hodin cílového CPU, ta se navíc může za běhu měnit, to nemusí až tak moc vadit, pokud bychom se zabývali jenom nejhorším možným případem

Já tam vidím "ms", takže na frekvenci CPU nezáleží.

Ostatně, to, že rychlost funkce závisela na rychlosti procesoru je pradávná historie. Dneska když se píše hra, tak se určitě nebude opírat o frekvenci CPU, ale o hodiny.

1188

Vývoj / Re:Typový system versus unittesty

« kdy: 19. 08. 2018, 20:46:05 »

Případně by se mohl ten požadavek změnit a formalizovat na „trvání funkce musí být v rozmezí x až y ms“. Což se třeba dá zapsat formálně, ale překladač to nemůže zkontrolovat, protože netuší, na jaké cílové platformě ten kód poběží.

Jak nemůže? Proč by nemohl? Ať je platforma jakákoliv, tak čas bude všude stejný ne? Této argumentaci nerozumím.

1189

Vývoj / Re:Typový system versus unittesty

« kdy: 19. 08. 2018, 20:42:40 »

Ty vycházíš z předpokladu, že API a implementace jsou od sebe rozdílné.

To není předpoklad, to je definice API.

Obávám se, že to není nijak podstatné.

Byly časy, kdy API funkce (říkejme tomu spíše signatura) vypadala nějak takto:

function substr(String str, Int start, Int len) : String

A v praxi jsme pak museli ošetřit testem, co se stane, když zavoláme substr("abc", 6, -2). Někde uvnitř té funkce bylo definováno, že to má vyhodit výjimku, prázdný řetězec, nebo něco takového. Podstatné ale je, že signatura funkce o této nesmyslnosti nic nevěděla.

Dnes už máme typy na takové úrovni, že dokážeme zohlednit, že substr("abc", 6, -2) nepůjde vůbec přeložit. A myslím, že nikoho nijak zvlášť nezajímá, že kdysi dávno se tvrdilo, že ošetření těchto nesmyslných vstupů je otázka implementace, a nikoliv API/Signatury.

Takže pokud trváš na tom, že API/Signatura a implemnetace/chování jsou dva oddělené světy, tak já ti tvůj názor přeji, ale v takovém případě nám nejde o stejnou věc.

1190

Vývoj / Re:Typový system versus unittesty

« kdy: 19. 08. 2018, 20:30:04 »

jak by tedy vypadaly ty funkce v Elmu?

Ha, omlouvám se! Zde jsem se extrémně nešťastně vyjádřil.

Elm samozřejmě neumí to všechno, o čem jsem hovořil. Elm umí ošetřit právě tu změnu kontraktu na úrovni API. Tedy uvedl jsem ho jako příklad pro použití, kdy testy hlídají, zda se něco změnilo, a abych si toho byl schopen všimnout.

To, že změním chování nějaké funkce, ale vnější signatura (vstup a výstup) zůstane stejná, to by zase mohli podchytit závislostní typy. (Případně se tu objevili příspěvky o dalších technikách.)

A když se to spojí, tak máme ten hypotetický jazyk, který by dokázal nahradit testy v případech užití, které byly uváděny.

1191

Vývoj / Re:Typový system versus unittesty

« kdy: 18. 08. 2018, 23:13:19 »

My uvádíme důkazy (Elm), že to tak není.

Vy pouze uvádíte příklady, kde jazyk neumožňuje definovat žádné API – takže nezbývá, než být API definované někde bokem, v dokumentaci. A na kontrolu toho API opět potřebujete testy.

Toto nepozoruju. Uvedl jsem konkrétní příklad jazyka. Ten jazyk umožňuje definovat API. A tento jazyk si dokáže ohlídat nekompatabilní změny v implementaci, kdy by implementace změnila chování.

Samozřejmě je to změna API.

Takže každá změna implementace je změna API. To pak ale není API. A co se týče praktického použití by takový systém byl úplně stejný, jako dynamicky typované jazyky. Protože byste při každé změně implementace automaticky všude změnil typy.

Je to zcela stejné jako testy. Změním-li implementaci tak, že se změní chování, musím tomu zohlednit testy. Změním-li v Elmu imlementaci tak, že se změní chování, musím to zohlednit v typech. Pokud změním implementaci tak, že chování bude zachováno, nezmění se API, a nemusím nic měnit. Nehledal bych v tom žádnou složitost.


No, na závěr tohoto můžu maximálně doporučit, aby si se na ten Elm mrknul, mohlo by to být pro tebe poučné. Námětem tohoto vlákna nebylo to, někoho tady učit typy, nebo přesvědčovat co všechno se dá pomocí typů udělat, takže já to tady za sebe uzavírám.

1192

Vývoj / Re:Typový system versus unittesty

« kdy: 18. 08. 2018, 23:01:58 »

Funkce:
foo1 x y = x + y
a
foo1 x y = y + x

Jsou různé implemnetace, ale mají stejné API, protože stejnou funkčnost.

Ale tohle je přeci krásný příklad toho, že to tak není! Dokud bude operátor + komutativní, tak předpoklad platí, ale pokud ho někdo přepíše tak, že komutativní už nebude, tak to přestane fungovat správně, ale API zůstalo stejné. No a to ohlídají právě unit testy.

Zkuste se naladit na tu myšlenku: v okamžiku když by se změnil ten operátor, a přestal být komutativní, tak se změní typová signatura toho operátoru. Díky tomu se samozřejmě transitivně změní všechny typy, které na tom závisí. Takže to nepůjde přeložit. Což je přesně to, co řeší testy, a typy mohou taky.

1193

Vývoj / Re:Typový system versus unittesty

« kdy: 18. 08. 2018, 20:57:56 »

A ja uz se po nekolikate snazim rict, ze to nemusi byt pravda. Kdyz budu mit vhodny typovy system a budu chtit, tak muzu zaridit aby kazda nekompatibilni zmena implementace nutne znamenala zmenu API.

Ano, vy jste už poněkolikáté zaměnil kompatibilitu API a kompatibilitu implementace. Já stále píšu o kompatibilitě API a vy na to pokaždé reagujete kompatibilitou implementace. Ne každá změna implementace znamená změnu API.

Obávám se, že on to nezaměňuje. On mluví o tom, že API zasahuje i do implementace. Že typ, nebo API vidí, že se změnila implementace (přesněji ani ne tak implementace, jako chování). Ty vycházíš z předpokladu, že API a implementace jsou od sebe rozdílné. My uvádíme důkazy (Elm), že to tak není.

... Ten kód, který závisel na tom, že to trvá určitou dobu, se rozbije.

Je to zrychlení nekompatibilní změna API?

Ano. Samozřejmě je to změna API.

I když ta doba trvání nikde nebyla zdokumentovaná, nebyl to účel té funkce a jenom to tak náhodou vyšlo. Dá se na takový případ napsat jednotkový test? Mohl by to typový systém řešit jinak, než že by každá změna implementace znamenala nekompatibilní změnu, a tím pádem by veškerá typovost šla k šípku, protože by nic nezáviselo na typech ale na konkrétních implementacích?

Takhle to ale přeci vůbec není.

Funkce:
foo1 x y = x + y
a
foo1 x y = y + x

Jsou různé implemnetace, ale mají stejné API, protože stejnou funkčnost.

Zatímco
foo2 x y = x / y
a
foo2 x y = y / x

už mají různé API, protože různou funkčnost.

1194

Vývoj / Re:Typový system versus unittesty

« kdy: 17. 08. 2018, 21:22:35 »

Pro jistotu ještě explicitně uvedu, že „nemění používané API“ neznamená, že se nijak nezmění chování té funkce navenek. Např. pokud se ta funkce používala jen pro vstupní hodnoty 1–10, když se změní výsledek, který vrací pro 11, není to změna používaného API.

Pokud je vstupni typ funkce integer 1 - 10 tak aby zacala vracet i pro 11 budu muset zmenit typ vstupu. Takze API.

Jen doplním, že ten Elm si zjistí, zda došlo k nekompatabilní změně algoritmu, a tuto změnu propíše do API jako tu major verzi. Takže ten semver je součástí toho typu. Vzhledem k tomu, že Elm je téměř pure, tak to nepřekvapí. Bylo by zajímavé zjistit, kde má hranice (já jsem se tomu žel nevěnoval tolik, kolik bych chtěl - zatím).

1195

Vývoj / Re:Typový system versus unittesty

« kdy: 17. 08. 2018, 21:16:15 »

Je to jenom jiný úhel pohledu pořád na totéž:

Formální správnost programu vs. zamýšlená funkčnost.

...zatímco nepřátelé jednotkových testů přitom marně čekají na akademický důkaz, že obojí typový systém NEzvládne, aby se mohli při tom čekání chlácholit tím, že do té doby mají pravdu...

Takhle tu budete v tom případě asi debatovat ještě hodně dlouho...

Já si pamatuju na kdysi, kdysi nějaký vlákno fóra, kde se rozebíralo statické typování, haskell, python. Bylo to dlouhý, a hodně inspirativní. Třeba jen od tohoto vlákna očekáváš něco, co není jeho cílem. Někteří z nás tu třeba nechtějí najít univerzální rozhodnutí, nebo si nepotřebují nic dokazovat. Jen se pokoušíme zjistit, co kdo k tomu ví zajímavého. Můžeš k tomu pomoct. (Ale taky nemusíš :-) )

1196

Vývoj / Re:Typový system versus unittesty

« kdy: 17. 08. 2018, 21:10:25 »

zatím se tu neobjevil jediný kus fungujícího kódu.

Bez ohledu na to, zda máte pravdu, toto nebylo požadavkem.

1197

Vývoj / Re:Typový system versus unittesty

« kdy: 17. 08. 2018, 17:32:10 »

Kdyz bude funkce ochranena typem tam nepujde ohnout aniz by se zmenil ten typ a tudiz kompilator stejne zarve protoze tam kde ji volam ja bude typ nekompatibilni.

Ano, přesně tak.

Mimochodem docela inspirativní, a dokonce z produkce je jazyk Rust a jeho borrows. Což je zase něco jiného než s čím se obvykle setkáváme. Je zajímavé, kolik chyb je schopen při kompilaci najít.

1198

Vývoj / Re:Typový system versus unittesty

« kdy: 17. 08. 2018, 16:16:10 »

Dobře, máš pravdu. Ale vzhledem k námětu tohoto vlákna nás zajímá právě ten sci-fi překladač.
Takže, dá se to napsat jinak? Typem?

jestli tomu rozumím správně, vy překladači zadáte dva vzorce a on ověří, že jsou ekvivalentní.

Ano. Taky.

Jak to souvisí s typem?

Proč se ptáš?

1199

Vývoj / Re:Typový system versus unittesty

« kdy: 17. 08. 2018, 16:13:09 »

...

Myslim, ze tohle typovy system nedokaze podchytit.

Je to myslím moc pěkný usecase, ač už jsem na něco podobného tuším reagoval.

Zdá se, že mnoho přispěvovatelů si tu vyláme zuby na rozdílu mezi "tohle typový systém nedokáže podchytit protože princip" versus "nesetkal jsem se s typovým systémem, který by to dokázal podchytit".

Například jazyk Elm by toto mohl dát. Jakmile někdo vezme funkci, a ohne si ji, tak se změní major verze té funkce a už nepůjde napasovat, a celé to nepůjde zkompilovat. Což je IMHO právě ta ochrana (ochrana rozhodně užitečná), o které mluvíš.

1200

Software / Re:Novy uzivatel je clenem skupiny root, gpasswd tvrdi opak!

« kdy: 16. 08. 2018, 19:35:53 »

Diky, /etc/skel jeste zkusim..ale stejne, odebrat by jit melo!
...
Tak jsem koukal do /etc/skel , u me je to slozka s obsahem:
-rw-r--r-- 1 root root   220 Sep 19  2012 .bash_logout
-rw-r--r-- 1 root root  3771 Jun 24  2016 .bashrc
drwxr-xr-x 1 root root    66 Aug 11 17:44 .config
-rw-r--r-- 1 root root  8980 Oct  4  2013 examples.desktop
-rw-r--r-- 1 root root 14965 Apr  9 19:28 .face
drwxr-xr-x 1 root root    10 Aug 11 17:44 .kde
-rw-r--r-- 1 root root   807 Apr  4 20:30 .profile

Ej, sorry, to je mimo.

Podle man stránky k useradd tak platí, že pokud není určena skupina, tak záleží na nějakém příznaku USERGROUPS_ENAB v /etc/login.defs, případně GROUP v /etc/default/useradd. (Fedora) Mrkni, zda v tom souboru nemáš GROUP=0