Příspěvky

1276

Vývoj / Re:Zjištění chyby při neúspěchu fwrite()

« kdy: 30. 06. 2018, 20:31:16 »

fwrite() return values jsou docela zmatené, obojí false a 0 znamenají chybu. false je chyba v parametrech, zatímco 0 je chyba provádění (typicky chyba vrácená OS - out of space apod.). Více detailů první komentář v dokumentaci.

Ten komentář je 8 let starý, chování se mohlo změnit. Připadá mi divné, že by se za 8 let tak zásadní chyba v dokumentaci neopravila. Ale neověřoval jsem to.

0 jako korektní hodnota je nesmysl, protože vždycky se musí něco zapsat.

Je možné, že nadstavba PHP chování mění, ale standardní POSIXový write může vrátit i nulu jako normální hodnotu – zapsat se nic nemusí. Při nedostatku místa OS vrátí -1 a v errno bude ENOSPC.

Při zápisu do souboru se bude OS snažit zapsat vše, ale nemusí se mu to podařit. O to je to horší, že to bude skoro vždy fungovat, ale pak se někdy „nepochopitelně“ zapíše jen část.

Nemůžeš tu podmínku hodit do cyklu. Musíš testovat, zda návratová hodnota je větší jak 0 - jak píše @kvr kvr, pak teprve můžeš zkusit zapsat znova. @andreaw.fean zvolil opačnou strategii, a při neúspěchu prostě končí - což je v pořádku.
Ty posixový funkce nefungují.
fwrite() není wrapper nad posixovým fwrite...

Sečteno a podtrženo problém je v tom, že tvá rada byla úplně špatná.

1277

Vývoj / Re:Zjištění chyby při neúspěchu fwrite()

« kdy: 30. 06. 2018, 19:00:56 »

Je mi líto, ale žádné úžasné řešení asi neexistuje.

Funkce fwrite() je jen alias na php_stream_write() a ten nijak zvlášť neřeší důvod nezápisu.
Funkce file_put_contents() sice zařve, že se nepovedlo zapsat ale přičinu, "possibly out of free disk space" si bohapustě vycucá z prstu. Je fakt, že to bude nejčastější příčina, protože práva etc si zjistíš už při fopen().

Pokud skutečně dojde k chybě (což zjistíte testem, zda hodnota vrácená funkci fwrite() je FALSE), bude nejspíš kód chyby v posix_get_last_error(). PHPčkové fwrite je jenom obálka nad libc fwrite(), která vrací chybu v errno, a tuhle hodnotu vrací právě posix_get_last_error().

Není. Nezjistíš.

1278

Vývoj / Re:Zjištění chyby při neúspěchu fwrite()

« kdy: 30. 06. 2018, 18:36:01 »

Opakování zápisu je použito už v tom kódu

Ne, není. Jak jste přišel na to, že při druhém volání se zapíše vše? Volání se musí opakovat tak dlouho, dokud nejsou zapsaná všechna data. Používají se k tomu cykly.

Doufám @andreaw.fean, že tě nenapadne se jeho radou řídit :-)

1279

Vývoj / Re:Zjištění chyby při neúspěchu fwrite()

« kdy: 30. 06. 2018, 18:33:33 »

Je mi líto, ale žádné úžasné řešení asi neexistuje.

Funkce fwrite() je jen alias na php_stream_write() a ten nijak zvlášť neřeší důvod nezápisu.
Funkce file_put_contents() sice zařve, že se nepovedlo zapsat ale přičinu, "possibly out of free disk space" si bohapustě vycucá z prstu. Je fakt, že to bude nejčastější příčina, protože práva etc si zjistíš už při fopen().

1280

Vývoj / Re:Zjištění chyby při neúspěchu fwrite()

« kdy: 30. 06. 2018, 16:47:18 »

Nechápu, jak to souvisí s mojí otázkou?

Máte ten kód špatně. Porovnáváte počet zapsaných bajtů s počtem bajtů k zapsání, a když nesouhlasí, považujete to za chybu. Ale ona to chyba není, počet zapsaných bajtů může být v rozmezí 0 až počet bajtů k zapsání. fwrite prostě zapíše tolik bajtů, kolik zrovna zapsat může, a vy si musíte zkontrolovat, zda už zapsal všechno, a když ne, tak to otočit v cyklu a zapsat další část. Podívejte se na dokumentaci fwrite, tammáte hned v první poznámce příklad, jak má zápis do souboru vypadat správně.

Přečtěte si prosím nejdříve ten kód, dobře?

1281

Vývoj / Re:Typový system versus unittesty

« kdy: 29. 06. 2018, 16:12:31 »

A otázka zní, jaké to tedy má výhody? A dá se to napsat jinak? Typem?

funguje to se současnými technologiemi, nejen s nějakým sci-fi překladačem.

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?

1282

Vývoj / Re:Typový system versus unittesty

« kdy: 29. 06. 2018, 16:11:09 »

Seznam ukázkových příkladů je blízko neformálnímu popisu problému. ... Jakýkoliv typový systém je už o úroveň abstrakce dál. Takže i když už programátoři nebudou hrnout kód, ale jenom formální specifikace, tak budou testy užitečné.

Přijde mi zajímavější, aby ukázkové příklady generoval nástroj na základě specifikace. Včetně okamžiku vývoje.

Dokonce ho může dodat i klient s minimální představou o programování.

No já nevim. To už je otázka spíše psychologická. Veškeré mé zkušenosti s takto neznalími klienty bylo, že mi to museli vysvětlit ústně, protože sami jinak nehli prstem.

1283

Vývoj / Re:Typový system versus unittesty

« kdy: 29. 06. 2018, 14:16:28 »

Spíš se ptáme, jak ten kompilátor požádám, aby ověřil, že funkce řeší kvadratickou rovnici. Typem nebo testem? Jak bude vypadat zápis?

Ne, neptáme. Ptáme se kompilátoru typem. Tak zní zadání.

Ono asi to (nepovinné) vyčlenění testů do extra kódu bude mít něco do sebe...

A otázka zní, jaké to tedy má výhody? A dá se to napsat jinak? Typem?

Jednotkový test sice jde napsat jako znovuimplementace výpočtu, ale nikdy takhle nebyl zamýšlen, protože by trpěl stejnými nevýhodami jako dokonalý typový systém. Proto na to jde opačně - nesnaží se o úplnost, tj. pokrytí všech vstupních kombinací, ale jen těch, u kterých s vysokou pravděpodobností očekává chybu, nebo které reprezentují typické hodnoty, a to tím nejpřímočařejším způsobem, tj. ověření konkrétního výstupu pro konkrétní vstup, čímž dosahuje vysoké efektivity vzhledem k složitosti potřebného aparátu.

V testu se hlavně porovnávají dva diametrálně odlišné popisy. Tam je přece jenom menší šance, že by programátor udělal 2x podobnou chybu.

Ano, křížová kontrola, to jsem unittestům přiznal jako bod :-) To si moc nedovedu představit jak by se dělalo jinak. Ale třeba časem :-)

Ale k čemu je to dobré, když jednotkové testy můžete vytvořit v jakémkoliv jazyku bez potřeby doplnění syntaxe či preprocesoru, a to při větší vyjadřovací schopnosti, protože není třeba vytvářet nový (aťto deklarativní či imperativní) jazyk, ale stačí ten vlastní.

Viděl jsem spoustu testů. A nedomnívám se, že by to byl nějaký zázrak. Je to ukecané, nudlovité, neexpresivní, nedostatečné.

1284

Vývoj / Re:Typový system versus unittesty

« kdy: 28. 06. 2018, 22:11:07 »

Přiznávám se bez mučení, že zde mé znalosti končí. Ale mám rámcovou představu, jak by to mělo jít: pokud vím, že operátor sčítání je, a operátor odčítání není komutativní, tak IMHO není problém to kompilátoru říct. Jak konkrétně by se to zapsalo, to netuším. Mám toho ještě hodně k nastudování.

Mám to chápat tak, že netušíš, jak by se to dalo udělat?

Píšu, že mám rámcovou představu takže evidentně tuším.

1285

Vývoj / Re:Typový system versus unittesty

« kdy: 28. 06. 2018, 22:08:39 »

Nekde tady byla otazka na kvadratickou rovnici.
Zkusim tu myslenku v te citaci ukazat na tom.
Podotykam moji myslenku z te citace a ne kompletne problem reseny v tomto vlakne.
BoneFlute se z toho osype, protoze to neni ani zdaleka to o cem mluvil on.
A taky protoze to bude v jazyce velmi podobnem jave :-)
Vlastne jedinny rozdil proti jave je, ze umi presne floating point operace.

Kód: [Vybrat]

    final static RuntimeException up = new IllegalArgumentException("Does not compute");

    private static Result getRoots(double a, double b, double c){
        double detBody = b*b - 4*a*c;
        if(detBody < 0){
            throw new IllegalArgumentException("Fuck it! I don't have imaginary friends. " + detBody);
        }
        double det = Math.sqrt(detBody);
        double root1 = (-b + det)/2*a;
        double root2 = (-b - det)/2*a;
        return new Result(a,b,c,root1,root2);
    }

    static class Result {
        double root1; double root2;

        Result (double a, double b, double c, double root1, double root2){
            if(root1 + root2 != -(b/a) || root1*root2 != c/a) throw up; 
            this.root1 = root1;
            this.root2 = root2;
        }
    }

Nejvíc bych tomu vytknoul, že si nedovedu představit, že by z takového zápisu byl stroj schopen "pochopit" tu kvadratickou rovnici. Takže nemůže (hypoteticky) "vyvinout" jinou, alternativní implementaci. Zdá se mi to jako algoritmus, který musím "otestovat".

1286

Vývoj / Re:Typový system versus unittesty

« kdy: 28. 06. 2018, 21:27:15 »

Narážíš-li na komutativitu, tak tímto způsobem to zase odhalí i Typ.

Jak ten typ bude vypadat?

Přiznávám se bez mučení, že zde mé znalosti končí. Ale mám rámcovou představu, jak by to mělo jít: pokud vím, že operátor sčítání je, a operátor odčítání není komutativní, tak IMHO není problém to kompilátoru říct. Jak konkrétně by se to zapsalo, to netuším. Mám toho ještě hodně k nastudování.

1287

Vývoj / Re:Typový system versus unittesty

« kdy: 28. 06. 2018, 21:13:46 »

Ale myslím, že je trošku nepochopení, k čemu typový systém je. Byl tady dotaz, že jak testovat v tom mém příkladu, že u:

Kód: [Vybrat]

Num op a b = op a b

nedošlo k prohození "a" a b".

Nutno zopakovat, že to, že došlo k prohození "a" a "b" se v Typu neopodchytí, stejně jako se nepodchytí toto prohození v Unittestech. Tudíž vzhledem k námětu tohoto vlákna je tento dotaz irelevantní.

Jednotkové testy to právě odhalí velmi rychle už při odečítání.

Narážíš-li na komutativitu, tak tímto způsobem to zase odhalí i Typ.

1288

Vývoj / Re:Typový system versus unittesty

« kdy: 28. 06. 2018, 21:02:21 »

Ale myslím, že je trošku nepochopení, k čemu typový systém je. Byl tady dotaz, že jak testovat v tom mém příkladu, že u:

Kód: [Vybrat]

Num op a b = op a b

nedošlo k prohození "a" a b".

Nutno zopakovat, že to, že došlo k prohození "a" a "b" se v Typu neopodchytí, stejně jako se nepodchytí toto prohození v Unittestech. Tudíž vzhledem k námětu tohoto vlákna je tento dotaz irelevantní.

1289

Vývoj / Re:Typový system versus unittesty

« kdy: 28. 06. 2018, 20:57:16 »

Mimochodem, k představě, že všechny jednotkové testy bude umět vytvořit nějaký automat, je vhodné dodat, že až ten automat bude umět pochopit danou doménu a napsat testy, bude umět naprogramovat i ten výkonný kód.

Což je cíl, ke kterému směřujeme.

1290

Vývoj / Re:Typový system versus unittesty

« kdy: 28. 06. 2018, 01:12:47 »

Jestli tě chápu dobře - u typů je někdy blbá ta ultimátnost.

A co je to vlastně ta "ultimátnost"? S tím slovem jsem se ještě nesetkal.

Takové slovo vůbec neexistuje.
Ultimus znamená latinsky poslední.

He, to jsem ani netušil :-)