Příspěvky

2971

Software / Re:Chrome neuložil otevřený PDF, síť odpojena

« kdy: 24. 08. 2018, 14:05:22 »

Už zase blouzníš. PDF se neotevře, nestáhne, nezobrazí.

Nestáhne se soubor z webovéh serveru. To je ten problém, nějaké zobrazování nebo ukládání s tím nijak nesouvisí. Ani to, že jde o PDF.

Viz http response podivná.

Jaká podivná response? Na tom, co je uvedené v jednom z komentářů, nic podivného není. Prostě HTTP klient nemá k dispozici celý soubor, jen jeho část, tak se zeptá serveru „jestli podporuješ posílání částí souborů, pošli mi jenom tuhle část“. Server odpoví „podporuju, posílám příslušnou část“. Na tom není vůbec nic divného, klient pošle správý dotaz, server to podporuje a správně mu odpoví. Kdyby to server nepodporoval, pošle znovu celý soubor, s čímž by si prohlížeč taky poradil, akorát by se zbytečně stáhlo víc dat.

Otázka je tedy proč chrome vymýšlí takového podivné hlavičky (nebo že by server nějak trolil podle user agent).

Žádné podivné hlavičky, jsou to standardní hlavičky HTTP a server je zná a odpoví na ně správně. Navíc to vůbec není příčina vašeho problému – prohlížeč má jen část souboru, vy ho chcete uložit na disk, takže musí soubor stáhnout celý. Divné je spíš to, proč prohlížeč při prvním dotazu dostane jenom část souboru – podstatné je, jestli je to záměr nebo nějaká chyba.

Chyba v certifikátu? Proč v tom případě curl to zvládne?

Protože curl může důvěřovat jinému seznamu certifikačních autorit, jiným algoritmům atd. Ale pokud se prohlížeči podaří stáhnout alespoň část souboru, chyba certifikátu to určitě nebude.

Každopádně vzhledem k tomu, že stále nevíme URL, odkud to PDF stahujete, nemůže to nikdo vyzkoušet a zjistit, jestli se mu vždy stáhne celý soubor, a chyba je ve vaší síti, nebo jestli je normální, že se stahuje jen část souboru.

Každopádně z toho, co víme, se zatím jako nejpravděpodobnější jeví nějaký síťový problém, který způsobí, že se soubor nestáhne celý. U toho PDF souboru se může projevovat například proto, že je větší, a menší soubory se daří stahovat normálně. To jsou ale jen dohady, protože o tom, jak vypadá síťová komunikace v okamžiku problému, jsme se zatím nedozvěděli nic.

2972

Vývoj / Re:Typový system versus unittesty

« kdy: 23. 08. 2018, 09:27:52 »

Když píšu TDD, tedy nejprve testy, rovnou si rozmyslím, co má implementace umět.

Celý váš komentář bych podepsal, ale tohle ještě zvlášť vypíchnu. TDD znamená, že se na tu funkci nejprve dívám z pohledu jejího uživatele. Takže se mi daleko spíš podaří API navrhnout tak, aby se dobře používalo, ne hlavně aby se mi dobře psala implementace. A když se API dobře používá, je zase menší pravděpodobnost, že ho někdo použije špatně.

2973

Vývoj / Re:Typový system versus unittesty

« kdy: 23. 08. 2018, 00:35:25 »

Ale co by si řekl na to, když by ty ukázkové příklady generoval stroj na požádání? Vzal by sis nějakou funkci, předal jí třeba první argument (a nebo žádný), a stroj by si domyslel tři různé příklady a výsledky, a ty by ti ukázal.

[…]

Byl jsem línej, a napsal jsem si generátor unittestů. Takovej ten postup, kdy si napíšeš prototyp, a pak na něj začneš psát testy - úplně špatně podle TDD, já vím.

Ten generátor měl takové patterny: Int = [INT_MIN, -2, -1, 0, 1, 2, INT_MAX], plus jednoduchá kombinatorika.

To jsou ale úplně triviální funkce, kterých je maličko a pro které se jednotkové testy píšou spíš pro pocit, že testy pokrývám opravdu maximum kódu (navíc se na nich dá snadno nahnat procento pokrytí testy), než že by někdo věřil, že  ten test opravdu odhalí nějakou chybu. Mnohem zajímavější a užitečnější testy jsou na takové funkce, u kterých není takhle na první pohled patrné, co jsou ty významné hodnoty, se kterými je vhodné funkci testovat.

2974

Vývoj / Re:Typový system versus unittesty

« kdy: 22. 08. 2018, 15:20:44 »

A když už jsme u toho, víte o jiných jazycích se záv. typy krom Idrisu, Agdy a Coqu, zejména takových, co se používají v praxi v kritických aplikacích?

Ony se podle mne tolik nepoužívají ani u kritických aplikací. Tam se to pokud vím řeší spíš tak, že je to naprogramované dvakrát nezávisle na sobě a běží to na dvou nezávislých zařízeních. Pokud se na výsledku neshodnou, následuje reset do nějakého bezpečného stavu.

2975

Vývoj / Re:Typový system versus unittesty

« kdy: 22. 08. 2018, 14:47:20 »

Nad záv. typy se korektnost dokazuje symbolicky, nevadí, není-li nějaká hodnota známa. Matoucí IMHO je, že se tomu říká typová kontrola, kterou lidi znají tak nanejvýš z Javy nebo céčka (pythonisti a spol. vůbec).

Nevidím nic matoucího na tom, že se to nazývá typová kontrola – je to přesně to, co lidé znají z JavaScriptu, Pythonu, C nebo Javy, akorát je to na škále důslednosti kontrol ještě dál, než Java nebo C. A tím, jak je to na škále ještě dál, zvětšuje se množství chyb, které dokáže typová kontrola odhalit, a zároveň jsou ty typy čím dál víc svazující a musí se různě „obcházet“.

U dynamicky typovaných jazyků je s hodnotami pracuje tak, že teprve když něco od hodnoty potřebuju, zjistím, zda je požadovaného typu. Třeba uživatel něco zadá, a teprve tam, kde s tím chci pracovat jako s číslem, zjistím, jestli to číslo je. Když někdo přejde na C nebo Javu, může mu připadat svazující, že musí typ určit dopředu a problém s tím, že uživatel nezadal číslo, musí řešit daleko dřív, třeba i zbytečně, protože by se k tomu zpracování jako čísla ani nedostal. Podobně svazující jsou dál generické typy, třeba u kolekcí – bez generických typů si do kolekce naházím jaké objekty mne napadne, a typy řeším až při jejich použití. S generickými kolekcemi najednou musím řešit typ prvků a mám problém do jedné kolekce dostat různé typy. Spousta věcí se přitom vyřeší tak, že „to nemůže nastat“. Třeba vím, že do kolekce strkám jenom stringy, takže nemusím řešit, že by se tam objevilo něco jiného. A závislostní typy jdou ještě dál.

Třeba obyčejné sčítání dvou čísel. V C nebo Javě sečtu dvě 32bitová čísla, a výsledek uložím opět do 32bitové hodnoty. Protože vím, že se tam budou sčítat malá čísla a přetečení „nemůže nastat“. Závislostní typy tohle neumožní, součet dvou 32bitových čísel musím uložit jako 64bitové číslo (nebo jako 33bitové, pokud bude takový typ povolen). A k tomu můžu chtít přičíst další číslo, a můžu dokonce chtít udělat sumu neznámého prvku čísel. Najednou musím řešit „hypotetické“ problémy, které bych v Javě nebo C řešit nemusel, protože přece vím, že tak velká čísla se tam nikdy sčítat nebudou – a jestli bude mít někdo problém, že se suma transakcí na jeho bankovním účtu nevejde do 32bitového čísla, tak mu to rád za nějaké promile z jeho zisku upravím. Stejně tak v Javě nebo C musím řešit „hypotetické“ problémy, které bych nemusel řešit v dynamicky typovaném jazyce.

Přísnost typové kontroly je pak jenom otázka míry, nalezení optimální hranice, kdy při dalším zpřísňování kontrol už nenajdu žádné reálné chyby, za to budu muset řešit „hlouposti“ typu „co kdyby firma měla trilion zaměstnanců“. Když pojedu vlakem, budu radši, když zabezpečovací zařízení bude používat závislostní typy a bude logicky dokázané, že nemůže pustit dva vlaky proti sobě (pokud o nich ví, že), u multimideálního systému pro výběr videa zabudovaného v sedačce přede mnou mi naopak vůbec nebude vadit použití dynamického typování.

2976

Sítě / Re:DNSCrypt výhody

« kdy: 21. 08. 2018, 09:18:01 »

Může to můj poskytovatel vyhodnotit jako obcházení DNS ? je to vůbec nějak právně postihnutelné ?

Vyhodnotit to tak může, ale objektivně nic jako „obcházení DNS“ neexistuje. DNS je decentralizovaná služba, je slušností, aby vám poskytovatel internetu poskytl adresy DNS serverů, které můžete používat pro překlad, ale je jen na vás, zda tuhle službu využijete. Právně postihnutelné to (v ČR) nijak není, je to zcela legální – a to ne babišovským způsobem „nic jste mi nedokázali“, ale nikdo na tom nevidí nic špatného. Prostě ISP vám nabízí nějakou službu, tu samou službu nabízí i jiné subjekty a vy se rozhodnete využít tu službu od jiného subjektu. Běžně se to tak dělá i bez toho maskování dotazů, že se používají veřejné DNS servery, které provozuje např. Google (8.8.8.8 a 8.8.4.4), IBM (9.9.9.9) nebo CloudFlare (1.1.1.1).

2977

Vývoj / Re:Typový system versus unittesty

« kdy: 21. 08. 2018, 07:02:59 »

Teď by tu všichni měli udělat krok zpět, nastudovat si ten Idris a pak pokračovat v debatě.

Myslíte opravdu nastudovat, takže se tu sejdeme znova za pět let? Protože debatu „během půl hodiny jsem si něco přečetl a dospěl jsem k nezdravému přesvědčení“ už tu máme…

2978

Vývoj / Re:Typový system versus unittesty

« kdy: 20. 08. 2018, 16:50:42 »

ArrayList v jave bude vedle sebe ukladat jen reference. Kdyz chci hodnotu tak stejne musim hledat nekde v halde.

Podstatné v této diskusi je, že prvky kolekce ukládá do pole a javovské pole je v paměti uložené v souvislé paměti. Takže když primitivní typy uložíte přímo do pole nebo do kolekce, která umožňuje ukládat primitivní typy, má procesor ty hodnoty v paměti hned vedle sebe. Jinak ano, kolekce ve standardní knihovně Javy umožňují ukládat jen objekty, takže rozdíl mezi java.util.ArrayList a java.util.LinkedList je v tom, že první má odkaz, zatímco druhý má odkaz na odkaz.

2979

Vývoj / Re:Typový system versus unittesty

« kdy: 20. 08. 2018, 16:32:00 »

Rád na přednáškách tvrdím,

Tohle je nejhorší zpráva z celého tématu.

2980

Vývoj / Re:Typový system versus unittesty

« kdy: 20. 08. 2018, 16:30:59 »

Já jsem o žádné flamewar zájem neměl. Text mého příspěvku k flamewar nenabádal.

Jasně. V názvu tématu se na něco ptáte, v textu rovnou odpovíte, arogantně a bez jakéhokoli vysvětlení. A pak to celou dobu přiživujete tím, že sice úplně nechápete základy, ale někde jste zahlédl něco úžasného, z čeho se všichni musí posadit na zadek. To vůbec není odstartování flamewaru…

2981

Vývoj / Re:Typový system versus unittesty

« kdy: 20. 08. 2018, 16:25:56 »

Ja jako programator nemuzu ve vysokourovnovem jazyce optimalizovat na nizke urovni.

Můžete. I u toho vysokoúrovňového jazyka můžete mít zaručené, že pole ten jazyk ukládá jako jednotlivé prvky v paměti vedle sebe. Takže když použijete pole primitivních hodnot, nejde se vám do řádku cache několik hodnot. Když použijete spojový seznam, bude každá položka uložená v paměti někde jinde a procesor bude při průchodu kolekcí pořád jen čekat, než se nahrají data z paměti. A tohle je třeba rozdíl mezi java.util.ArrayList a java.util.LinkedList. Připadají vám Java, Scala nebo Clojure jako dostatečně vysokoúrovňové jazyky? Ano, Java je jen assembler nad bajtkódem, ale stejně…

2982

Vývoj / Re:Typový system versus unittesty

« kdy: 20. 08. 2018, 16:20:33 »

Kde? Asi jsem prehledl...

Zde.

To je ale dost nizkourovnova zalezitost. Myslim, ze v jazycich vyssi urovne s tim stejne moc neudelame, protoze jsme tak daleko abstrahovali od HW, ze nemuzeme optimalizovat na urovni l1 a l2 cache.
To je dan kterou platime za expresivnost jazyku.

Nikoli, tohle výrazně ovlivňuje výkon i u jazyků vyšší úrovně, třeba těch běžících nad JVM. Tam, kde je to kritické, se i kód v těchhle jazycích optimalizuje tak, aby se např. data vešla do řádku cache a minimalizoval se cache miss.

Jmeno toho vlakna naznacuje, ze jde o srovnani toho co jde a nejde udelat typy vs unit testy.
Takze nevim jak BoneFlute, ale za me:
Az uvidim unit test ktery pri behu na Xeonu zahlasi ze dana funkce selze na 486 zacnu resit jak je mozne, ze tohle nedokaze typovy system.

Důležitější je asi obsah, než název. Název vlákna naznačuje, že jde o srovnání, ale text prvního příspěvku je jednoznačný pokus (úspěšný) o rozpoutání flamewar.

Navíc ta vaše podmínka je přísnější, než co požadoval BoneFlute. On se ptal na to, co jde vyřešit testem a nejde to podchytit typovým systémem. A tohle je jeden z příkladů. Je možné napsat test, který na Xeonu selže, protože testovaná funkce byla napsána pro 486 a na Xeonu je příliš rychlá. Typovým systémem toto podchytit nelze.

2983

Vývoj / Re:Typový system versus unittesty

« kdy: 20. 08. 2018, 14:49:46 »

Iterator zajisti optimalni prochazeni kolekce.

Ano. Akorát že já nechci kolekci procházet, já chci získat součet jejích prvků.

Myslel jsem, ze na tom scitani uz jsme se dohodli ze performance rozdil nebude.

Nikoli, to byla pouze vaše chybná domněnka, kterou jsem vyvrátil.

Mozna neco prehlizim. Priklad?

Procesor nemůže pracovat s daty přímo, pracuje s tím, co má v registrech nebo nejbližší cache. Ta cache není moc velká, data do ní se tahají z pomalejší vzdálenější cache, z ještě pomalejší RAM nebo z ještě pomalejšího swapu. Aby procesor na data zbytečně nečekal, pokouší se odhadnout, jaká data budou potřeba, a ty načítá dopředu. Pokud tedy bude způsob procházení kolekce pro procesor předvídatelný, dokáže data včas přednačítat a jejich zpracování bude mnohem rychlejší, než když bude procesor každou chvíli na data čekat.

Navíc dnešní procesory jsou vícevláknové, a zrovna sumace se dá dobře paralelizovat – každé vlákno sečte část kolekce a na závěr se sečtou dílčí součty. Akorát z výše uvedeného důvodu je potřeba, aby každé vlákno zpracovávalo ucelený blok kolekce – tj. první vlákno třeba prvních 16 prvků, druhé vlákno dalších 16 prvků atd. To iterátor neumožňuje, ten by cpal jednotlivé prvky vláknům napřeskáčku (a ještě by se musel mezi vlákny zamykat).

To aby to selhalo pri prekladu na 486 a fungovalo jinde prece nezalezi na tom jestli 486 existuje nebo ne.

Ale ono to nemá selhat při překladu na 486. Má to selhat při překladu kdekoli, pokud by to např. na 486 selhalo při běhu. BoneFlute přece chtěl, aby se jakákoli chyba odhalila už při překladu, ne až při běhu testů.

2984

Vývoj / Re:Typový system versus unittesty

« kdy: 20. 08. 2018, 13:58:35 »

Když to výhodnější nebude, tak to nepoužiju. Ale to neznamená že to nejde.

Čímž jste právě popřel to, čím jste odstartoval celou diskusi. Pokud vím, nelíbilo se vám, že testy se píšou jenom tehdy, když je to výhodné – a chtěl jste je nahradit něčím, co bude provádět kontroly vždy, bez ohledu na to, jestli si programátor myslí, zda je nebo není ta kontrola výhodná.

A mimochodem, s tím dokazováním, že to vždy jde, jste na tom taky dost bledě. Zatím jste neodkázal, že to jde, ani u konkrétních příkladů, natož abyste to dokázal obecně.

2985

Vývoj / Re:Typový system versus unittesty

« kdy: 20. 08. 2018, 13:54:21 »

A optimalizaci prochazeni kolekce to nepotrebuje. Tu zajisti ten iterator.

Nezajistí, protože iterátor neví, jak je výhodné procházet kolekci z pohledu sumační funkce. Vždycky je to něco za něco. Buď můžete mít obecné API, které můžete používat opakovaně, ale za cenu horší optimalizace. A nebo můžete mít kód, který jde až na dřeň toho, co jde z hardwaru vyždímat, pak ale musíte rezignovat na abstrakci a univerzální rozhraní.

Unit test by podle me mel byt platfomne nezavisli.

Proč? Jednotkový test má testovat jednu samostatnou část kódu. Klidně to může být implementace v assembleru něčeho, co je na jiných platformách dostupné jako instrukce procesoru. Ale i kód ve vyšších jazycích může být potřeba otestovat na různých platformách různě.

BoneFlute uz tu popisoval jak to zaridit pri kompilaci na te 486.
Namitka byla pokud vim, ze 486 neni v dobe prekladu k dispozici.
Takze kdyz zjistim, ze mam pozadavek aby to bezelo na 486 tak si nejakou sezenu a zkusim to na ni zkompilovat.
Stejne jako u toho testu, ktery zkusim na nejake pustit.

Ale BoneFlute přece chce, aby bylo vše kontrolované v době překladu, tedy ty informace v typech musí být už v době překladu. Bez ohledu na to, zda nějakou 486 máte nebo nemáte k dispozici, a dokonce bez ohledu na to, zda nějaká 486 už byla či nebyla vytvořena. Když to tam mít nebudete, musíte v typu povolit něco jako „neznámé“, a tím povolíte to, čemu se chtěl BoneFlute vyhnout.