Keresd a hibát...

... ebben a beküldésre szánt kernel patch-ben.

Az LKML threadet továbbolvasni nem ér.

https://lkml.org/lkml/2015/3/21/106

( sj | 2015. 03. 21., szo – 20:49 )

504 gateway timeout?

--
"Van olyan ember sok az oldalon, akinek a kommentjeinek 100%-a zaj, oket miert nem kommentelitek ilyen lelkesen?" (hrgy84)

( persicsb | 2015. 03. 21., szo – 20:55 )

Komolyan, nem tesztelt előtte? Egyből kibukott volna ez a kis logikai hiba, ami miatt pont az ellenkezőjét csinálja a kód, mint ami a commit message-ben le van írva.

( deje | 2015. 03. 21., szo – 21:03 )

Na pontosan ezért nem C-ben kellene már programozni.

( kmARC v | 2015. 03. 22., v – 09:34 )

Mennyi takolas... Harom szo: Railway oriented programming.

Lepesek egy szebb vilag fele:
0) Mivel egy csomo mas nyelvben is elojohet egy bool ellenorzesekor, hogy lemarad az egy karakternyi negalas, ezert talaljunk jobb nyelvet. Igen, az atyauristen javaban is.
1) Hasznaljunk Just|Nothing pattern matchinget.
2) vagy mivel a Maybe monad, igy do-blockba fuzve szep kodot is kapsz, gotok, ifek, try-catch, es Just|Nothing patmatch nelkul is.
3) PROFIT!!!!

Kivancsi vagyok, mikor aldoz le a C/C++-ban takolt kernelek kora, ha egyaltalan. Illetve van-e elkepzelheto nyelv jelenleg erre (ami nem abbol all, hogy amint hardverhez kell nyulni, C-s FFI van)

Go-val az a baj hogy a Google csinalja. Amit meg tudunk milyen: 50% esellyel egy nap csak bejelentik hogy nem csinaljak tobbe, plusz szeretnek ulni a kodon toketlenkedve semmit nem csinalva evekig. Amit az Apple elkezdett az meg sose volt sok, de legalabb vegigcsinaltak, meghozza gyorsan. A Swiftrol meg megintcsak latszik hogy komolyan veszik, a Go ahhoz kepest egy helyben totyorog mar eleve. Sot, emlekeztetoul a Swift meg egy eves sincs (tavaly nyaron jelentettek be egyaltalan), es mar rengeteg fontos iOS es Mac OS X alkalmazas keszult benne, Goban meg hany eve nincs semmi komolyabb alkalmazas irva ekozben? Mindemelle nyilt a clanggal egyutt, ergo senki nem kenyszerit arra, hogy a Cocoa/Cocoa Touch API-kkal hasznald, onnantol meg hogy ezeket nem hasznalod, tenyleg azt csinalsz vele, amit akarsz. Szerintem a legmegbizhatobb jovokeppel rendelkezo uj generacios kompilalt nyelv a Swift mindenkeppen jelenleg.

Rustot mondjuk nem ismerem, utananezek.

Swiftnek meg valoban kell meg fejlodnie, de ahogy C-nel is eljutottunk oda 45 ev utan, hogy sok esetben nem tudsz olyan optimalis ASM kodot csinalni, mint a C forditok, ugy Swiftnel is siman eljuthatunk oda, hogy nem tudsz olyan optimalis Obj-C kodot (majd abbol assembly-t) irni, mint a Swift foridtok.

Raadasul erdekesseg meg a Swiftben, hogy ha lefordult tipusellenorzessel, lefordithatod anelkul is (-Ofast parameter), de onnantol ugyanazok a problemak fennallnak a forditott koddal, amik C/C++ eseten, csak ugye kicsit gyorsabb, mert futasidoben nem nezi ugyanis a typingos if agakat szigoruan. Megfelelo tesztelesi es kodanalizalasi rendszereket hozzaepitve ebben a gondolatmenetben en megintcsak komoly jovot latok.

Goban meg hany eve nincs semmi komolyabb alkalmazas irva ekozben?

Ebben biztos vagy? Ott van kapásból a Docker. Nem kerestem, de biztos van több is.

-----
„Egy jó kapcsolatban a társunkat az ő dolgában kell támogatni, nem a miénkben.”
rand() a lelke mindennek! :)
Szerinted…

0) Szerintem inkább arról van szó, ha a nyelv kikényszeríti, hogy kiírjad így: ptr != NULL, akkor jobban kiveri az ember szemét egy ilyen elírás. Nekem pl eltartott egy pár percig, mire megértettem, hogy mit is akart volna csinálni a kód és ehelyett mit csinál (egyébként a goto vonta el a figyelmemet, először akörül kerestem a hibát).

Egyébként a bajok nagy részét már a C++ is megoldaná. Hardverhez nyúlkálni abból is lehet és magasabb szintű design patterneket is elég jól lehet benne használni.
---
Régóta vágyok én, az androidok mezonkincsére már!

Meg, de egy C-jellegű switch-case vagy neadjég if-ezés eléggé tönkreteszi a szép kódot (lásd belinkelt if(...) goto), míg ha van rá szintaxcukorka (do-block), kicsit szebb a kód. 


test1 :: Whatever a => ... -> Maybe a
test2 :: Whatever b => ... -> Maybe b

railway :: Maybe String
railway = do
    test1 $ ...
    test2 $ ...
    return "MyPreciousString"

Es semmi if, semmi trycatch, etc. megis compile timeba tettunk egy csomo hibakezelest. Nyilvan a koncepcio fenyevekre van a C/C++-tol, a szintaxisrol nem is beszelve.

Ezekkel nekem csak annyi volt mindig a problémám, hog az Exceptionokat is az esetek 99%-ában messze nem ott kezeljük le, ahol kiváltódnak, hanem esetenként 3 réteggel odébb és hagyjuk az egész folyamatot elhalni. Ez meg (számomra ránézésre) ugyanazt eredményezi, mint a Java a checked exceptionjaival: rákényszerít egy halom plusz ellenőrzésre ott, ahol nem lenne rá semmi szükség, csak hagyni kellene megdögleni az egész függvényt, folyamatot, stb.

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

A kivételkezelési alapszabály: A kivételeket nem ott kell kezelni, ahol kiváltódnak, hanem ott, ahol érdemben tudsz tenni azért, hogy az alkalmazás normális mederben folytassa tovább a futását. Ha nincs ilyen réteg, akkor bizony az alkalmazásnak el kell hasalnia, mivel helyre nem állítható állapotban van. Van, amikor egy szint nem tud arról, hogy "na, akkor most mit is kéne itt csinálni", mert az őt hívó absztrakciós réteg tudja csak, hogy mi a teendő, ha mondjuk nem elérhető egy hálózati végpont, nem elérhető egy file stb. Például egy hálózati kódot akár több üzleti logikai alrendszer / objektum / whatever meghívhat, így nem rakhatsz üzleti logikai döntést a hálózatot kezelő kódba, hiába ott fog felbukkanni az Exception.

Az alacsonyszintű kód nem szabad, hogy tudja, mi a teendő az üzleti logikában, ha valami nem várt esemény történik. De azt megteheted, hogy továbbdobsz egy "üzleti" exceptiont mondjuk IOException helyett.

Ezzel én tisztában vagyok, pontosan ezt mondtam én is. Csak egyesek ezt nem egészen értik ezt. Igaz ebben benne van a vaskalapos nézet is, hogy a "hibát mindig le kell kezelni ott, ahol kiváltódik", amit egyetemeken szoktak oktatni.

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

Hát két lehetőséged van (mint ahogy bármely más programozási nyelv esetén):
1) Vagy beépíted az Option(al)/Maybe absztrakciót a fél API-odba és továbbgyűrűzik (ahogy exceptionökkel is tennéd)
2) Vagy pedig a megfelelő szinten, ahol van értelme, eldobod, és nem foglalkozol vele (ahogy exceptiönöknél is tennéd).

A 2)-es pont gyakori. Tfh. van egy pont az üzleti logikádban, ahol egy "Mennyiséget" várnál válaszul, és a "0" válasz értelmezett. Ha bármelyik a kompozált függvényeidből Nothing-gal tér vissza, akkor azt egy ponton 0-vá alakíthatod. De mint ezt mondtam, így működik bármelyik nyelvben.

Hogy akkor mi a szép/jó a fenti kódban? Pontosan ennek a 0-vá alakításnak a módja. ADT-kkel dolgozol (kb. C-s unionokhoz hasonló, amiben van egy enum az union "típusára" vonatkozó adatokkal), amik minden lehetséges típusát ellenőrizned kell (kb. enum-ra switch-case), hogy leforduljon a kódod. Mas nyelven is meg tudod ezt csinalni, de pl. Java/C++ eseten hanyast kapsz eredmenyul (nem nagyon van szintaxisoldalrol megtamogatva), amit aztan nehez karbantartani. Itt van harom megoldas a fenti problemara: 


-- A fuggvenyunk tipusa:
businessLogicFun :: Maybe Int -> Int

-- (1) ADT pattern matching
businessLogicFun Just i = i
businessLogicFun Nothing = 0

-- (2) Mivel rajohettel, hogy ez eleg gyakori, van mar ra fugfveny a std libekben. 
--     A fromMaybe ket parametere: egy default ertek (mi 0-t adunk at,
--     String eseten pl. empty/error Stringet, stb.), es egy Maybe monad. 
businessLogicFun m = fromMaybe 0 m

-- (3) Ugyanaz mint az elozo, de Curryzett verzio => Matematikailag preciz, keveseb verbose  
businessLogicFun = fromMaybe 0

A hibat (ahogy persicsb is irta) a legvegen igyis-ugyis szemantikai szinten kell ellenorizni, a megfelelo helyen. Viszont az eredeti problemam (nekem legalabbis) az volt, hogy a van egy C-s fv a kernelben (lasd OP), akkor a "hibakezeles" miatt tele van rakva goto-val, ifekkel, mashol try-catch-csel. Nem latod ranezesre, mit is kell csinalnia a kodnak. Azt latod, hogy felcsillio elagazas van benne.

Egy do-blokkba szervezett monadikus kod eseten nem ez tortenik. A "hibakezeles" implicit, szintaktikai segitseget kapsz, anelkul, hogy keywordokkel raknad tele a kododat.

Ertelek, de ez a szal onnan indult, hogy elmondtam, mekkora taknyolas folyik, es hogy erre mar feltalaltak szebb megoldasokat.

Ha az eredeti problemafelvetesre is reagalni akarok, akkor elmondhatom, hogy hat igen, egy erosen tipusos nyelv eseten ez nem fordulhat elo, etc. Ezt igy '15-ben kevesnek gondolom. C++-szal/Javaval ugyanugy teletaknyolnad ifekkel, try-catch-csel, nabumm, legalabb a maintainelhetetlen fos _ebben az esetben_ nem lenne _logikailag_ hibas.

Szerk.: Na jo, befejezem. Egy Java/C# mar jobb valasztas (nyilvan nem kernel irasara). Bar teny, hogy a mindennapjaimban az is elofordul, hogy a C-s takolt cucc (linux) nem hagy cserben, mig a Javas nagyonfenszi cucc (mobile bank) meg igen. Ez pedig szepen bizonyitja, hogy attol, hogy egy nyelv jobb, mindig fognak tudni benne takolni :)

Én ugyan nem azt mondom, hogy nem _lehet_ kernelt / meglévő kernelhez modult írni :-) De a nyelvnek nem ez a célja és a jelenlegi architektúrájával soha nem is lesz az. Eleve purefunctional nyelvhez mindenképpen kell GC, ez pedig lassú modulok írásához elég, core funkcionalitáshoz nem.

Ha jól látom a metasepi cikk pont ezt próbálja amúgy megoldani. Ezt a cikket nem ismertem, köszi.

Igazad van, ofkoz a non-strictness (aka laziness) miatt kell a GC. My bad.

Amúgy pont most beszélgettem erről egy hozzáértővel, mert azt gondoltam, hogy egy kis escape analízis, és máris lehet az immutable objektumjainkat mutableként kezelni a compiler szintjén (esetleg még stacken allokálni). Kiderült, hogy - ghc-ben legalábbis - nem ez történik, Generational GC van, amellett pedig nem éri meg vesződni vele, a short-living objectekre jó az (ebből pedig egy pure nyelven sok van).

Sokkal többet szeretnék erről a témáról amúgy tudni mint most, majd egyszer visszanézek még ebbe a topikba :-)

Nagyrészt egyetértek, de mégis vitatkoznék egy kicsit. :) Az optional nagyon jó, ha azt akarod jelezni, hogy normális állapot az, ha valamilyen eredményt nem lehet előállítani. Pl. egy keresésnek nincs találata. De fent inkább hibakezelésről volt szó, amire az optional azért nem feltétlenül a legjobb megoldás, mert nem fogod tudni, hol és milyen hiba történt. Milyen jó is lenne, ha a a kivételkezelést pont ugyanúgy lehetne használni, ahogyan az optionalokat... :)

Try-catch nem pure (IO monadban van ertelmezve). Maybe/Either igen. Ez fontos különbség. Amíg a kódnak nincs mellékhatása, addig tökéletesen lehet az utóbbit használni, és pontosan ez a railway oriented programming lényege; nem is _érdekel_, hogy mi volt a hiba, a lényeg, hogy korrekt kódot kapj minden eset lekezelésével (ifek+goto err helyett). Ha ennél több kell, akkor Either, Writer monad, State monad, stb.

( turul16 v | 2015. 03. 24., k – 11:31 )

Vicces a thread.
En gyakran kihagyok tagadast `halando` szovegbol, lehet meg kene tanulnom bushmanul es akkor minden jo lesz :)

Amit nem lehet megirni assemblyben, azt nem lehet megirni.