abclinuxu.cz AbcLinuxu.cz itbiz.cz ITBiz.cz HDmag.cz HDmag.cz abcprace.cz AbcPráce.cz
AbcLinuxu hledá autory!
Inzerujte na AbcPráce.cz od 950 Kč
Rozšířené hledání
×
dnes 09:11 | Zajímavý článek

Mozilla.cz informuje o vylepšování vlastních about: stránek Firefoxu, konkrétně o odstraňování volání funkce eval() z těchto stránek. Tyto stránky mají přístup k interním součástem Firefoxu, ale protože jsou napsané v HTML a JavaScriptu, mohou být cílem podobných útoků jako webové stránky zobrazované v prohlížeči (např. vložení cizího kódu nebo obsahu), jen s potenciálně závažnějším dopadem. Pokud by se někomu skutečně povedlo kód do

… více »
Ladislav Hagara | Komentářů: 0
dnes 08:55 | Zajímavý projekt

Uživatel GitHubu joeycastillo představil The Open Book Project, jehož cílem je vytvořit open-source čtečku elektronických knih. Projekt se zatím nachází v rané fázi vývoje, už nyní ale obsahuje použitelný návrh hardware prototypu „Feather Wing“, jehož cílem má být ověření konceptu na 4,2palcovém displeji. Tento koncept je postaven na kitu Adafruit Feather M4 Express, který ovládá hlavní desku s displeji a tlačítky. Po úspěšném ověření

… více »
Bystroushaak | Komentářů: 1
dnes 05:00 | Nová verze

Byla vydána verze 5.0.0 svobodného systému pro detekci a prevenci průniků a monitorování bezpečnosti počítačových sítí Suricata (Wikipedie). Přehled novinek v oficiálním oznámení a v aktualizované dokumentaci.

Ladislav Hagara | Komentářů: 0
včera 20:33 | Zajímavý projekt

Byly zveřejněny schémata, firmware a instrukce pro sestavení trackballu Ploopy. Ten používá Arduino, senzor PMW3360 a 1,75palcovou kouli. Zdrojové soubory jsou šířeny pod open-hardware licencí CERN a GNU GPLv3. Tvar je inspirovaný klasickým trackballem Microsoft Trackball Explorer, jehož výroba byla ukončena kolem roku 2005 bez náhrady; projekt Ploopy se k tomu ale z právních důvodů nehlásí. Již vyrobené díly je možno objednat za 200 kanadských dolarů. Další podrobnosti v příspěvcích uživatele crop_octagon na Redditu.

Fluttershy, yay! | Komentářů: 10
včera 20:22 | Nová verze

Vyšlo desktopové prostředí KDE Plasma 5.17. Novinkou je např. „noční režim“ (pro X11, nejen Wayland), skrytí upozornění při prezentacích (když je připojena obrazovka se stejným obrazem), lepší podpora HiDPI, optimalizace využití zdrojů a mnoho drobných zlepšení a oprav.

Fluttershy, yay! | Komentářů: 2
včera 12:55 | Pozvánky

Spolek OpenAlt zve příznivce otevřených řešení a přístupu na 169. brněnský sraz, který proběhne v pátek 18. října od 19:00 v restauraci Racek (Jungmanova 5). Před srazem proběhne v 18:00 komentovaná prohlídka nových prostor hackerspacu base48 (přístup je z Mojmírova náměstí).

Ladislav Hagara | Komentářů: 8
včera 05:55 | Bezpečnostní upozornění

V příkazu sudo byla nalezena a ve verzi 1.8.28 byla již opravena bezpečnostní chyba CVE-2019-14287. V souboru /etc/sudoers lze nastavit, aby daný uživatel mohl konkrétní příkaz spouštět s právy libovolného uživatele (ALL) nebo libovolného uživatele kromě uživatele root (ALL, !root). Spustí-li tento uživatel daný příkaz se sudo s volbou -u#-1 nebo -u#4294967295, tj. pod uživatelem -1 nebo 4294967295, nebude vyžadována autentizace a příkaz se spustí pod právy roota.

Ladislav Hagara | Komentářů: 1
včera 01:33 | Nová verze

Po více než roce a čtvrt od vydání verze 3.7.0 byla vydána nová verze 3.8.0 programovacího jazyka Python. Přehled novinek v aktualizované dokumentaci. Podrobný přehled změn v Changelogu.

Ladislav Hagara | Komentářů: 15
14.10. 16:11 | IT novinky

Ke zhlédnutí na Invidious a YouTube je videozáznam rozborky a sborky mobilního telefonu Librem 5.

Ladislav Hagara | Komentářů: 47
14.10. 13:33 | Komunita

Richard Stallman, zakladatel hnutí svobodného softwaru, se dnes v e-mailové konferenci guix-devel vyjádřil, že svobodný software je apolitický, resp. jedinou přípustnou politikou je politika svobodného softwaru. Reagoval na některé návrhy, že by se do svobodného softwaru měl zabudovat feminismus nebo jiný -ismus. Říká, že témata jako komunismus nebo sexuální orientace jsou „off-topic“. Je v pořádku mít politické názory, ale lidé

… více »
xkucf03 | Komentářů: 104
Kdy jste naposledy viděli počítač s připojeným běžícím CRT monitorem?
 (19%)
 (4%)
 (11%)
 (39%)
 (24%)
 (2%)
Celkem 401 hlasů
 Komentářů: 22, poslední 23.9. 08:36
Rozcestník

www.AutoDoc.Cz

Sysinternals také na Linuxu

Microsoft potvrdil portaci vybraných nástrojů z balíku Sysinternals na Linux. Na GitHubu jsou k dispozici zdrojové kódy nástroje ProcDump. Potvrzena je portace nástroje ProcMon [Slashdot].

8.11.2018 00:55 | Ladislav Hagara | Zajímavý projekt


Tiskni Sdílej: Linkuj Jaggni to Vybrali.sme.sk Google Del.icio.us Facebook

Komentáře

Vložit další komentář

8.11.2018 09:06 frr | skóre: 33
Rozbalit Rozbalit vše Re: Sysinternals také na Linuxu
Hm to je asi tak užitečné jako Linux subsystem for Windows. Kdyby namísto nošení dříví do lesa radši oficiálně portnuli strace na Windowsy, nebo lépe, podpořili třeba vývoj APImonitoru od Rohitaba Batry. Možná by se pak pod Windows dalo trochu debugovat, aniž by člověk musel reinstalovat třičtvrtě systému (výměna win32/win64 binárek za "debug versions", včetně kernelových modulů).
[:wq]
8.11.2018 13:56 biolog
Rozbalit Rozbalit vše Re: Sysinternals také na Linuxu
Debugování pod Windows funguje bezvadně i bez nahrazování jakéhokoliv DLLka či kernelových modulů. Stačí ve Visual Studiu zaškrtnout, že má používat Mikrosoftí symbol servery. (U jiných debuggerů bývá obdobný přepínač.)
8.11.2018 14:31 Aleš Kapica | skóre: 49 | blog: kenyho_stesky | Ostrava
Rozbalit Rozbalit vše Re: Sysinternals také na Linuxu
Debugování pod Windows funguje bezvadně … Stačí ve Visual Studiu zaškrtnout,…
Víš, někteří lidé jsou zvyklí debugovat věci na konzoli, a bez klikátek, protože tam vidí co se děje, a výstup mohou si kupř. přesměrovat do souboru k podrobnějšímu prostudování.
8.11.2018 15:03 SkákalPřesOheňAžSiPropálilMokasíny | skóre: 29 | blog:
Rozbalit Rozbalit vše Re: Sysinternals také na Linuxu
Debugování pod Windows funguje bezvadně i bez nahrazování jakéhokoliv DLLka či kernelových modulů. Stačí ve Visual Studiu zaškrtnout, že má používat Mikrosoftí symbol servery. (U jiných debuggerů bývá obdobný přepínač.)
A to řeší ten problém s absencí debug symbolů v non-debug knihovnách atd. slinkovaných oproti non-debug runtime?

Pokud ano, otázka pak je, k čemu ten debug mód vůbec je...
9.11.2018 18:32 biolog
Rozbalit Rozbalit vše Re: Sysinternals také na Linuxu
V DLL a EXE vyrobených microsoftími nástroji nejsou symboly nikdy, ani v debug buildech, ani kdybyste štelovali přepínače překladače a linkeru. Symboly jsou vždy v separátním souboru (*.PDB). PDB soubory jsou volně ke stažení pro snad všechny knihovny systému (pro např mspaint.exe), v normálním Windows, i v tom speciálním "checked build" (viz níže).

Jenom bývají problémy s tím, že pár dní po vydání záplat nebývají k dispozici PDB pro ty změněné kernel32.dll, ntdll.dll a podobné. Četl jsem na nějakém MS fóru, že je to jen nekompetence, a ne security by obscurity. Poslední rok se to subjektivně stává méně.
10.11.2018 12:05 SkákalPřesOheňAžSiPropálilMokasíny | skóre: 29 | blog:
Rozbalit Rozbalit vše Re: Sysinternals také na Linuxu
S čím mam já problém je to, že debug build binárky se musí linkovat proti debug dependencím, takže člověk musí udržovat dvě sady všeho. Je nějak možný se tomuhle vyhnout, ie. mít debug binárku proti release dependencím + runtime?
10.11.2018 22:31 biolog
Rozbalit Rozbalit vše Re: Sysinternals také na Linuxu
Ono záleží na té které dependenci. Když člověk volá funkce v kernel32.dll, user32.dll a spol používají stejné DLL v debug i release, podobné to bývá s DLL třetích stran. Ale například MS C/C++ runtime knihovny a MFC knihovny mají jsou odlišné knihovny (a mají odlišné layouty struktur) v debug a v release - proto se ve windowsím světě považuje za špatnou praxi vystavovat ty závislosti ze své knihovny ven.

Takovou závislostí je i alokační funkce: v debug verzi ta funkce ověřuje spoustu věcí (historicky, od Vist oveřuje hodně vecí i holý systémový alokátor), takže je nutné, aby se alokovalo a uvolňovalo stejným alokátorem. Jinak by byl problém vyvíjet a debugovat DLL nezávisle na ostatních knihovnách. Takže když nějaká knihovna umožňuje externímu kódu alokovat paměť a v ní zkonstruovat objekt, měla by exportovat i funkci, která ten objekt zdestruuje a uvolní paměť pomocí stejného alokátoru. Někdy je ten požadavek splněný přirozeně, někdy se to musí dělat krkolomně. Např s pomocí COMu je to krkolomné vždy, ale aspoň vždy stejně.
11.11.2018 11:36 SkákalPřesOheňAžSiPropálilMokasíny | skóre: 29 | blog:
Rozbalit Rozbalit vše Re: Sysinternals také na Linuxu
TL;DR je to hrůza.
Max avatar 8.11.2018 15:17 Max | skóre: 67 | blog: Max_Devaine
Rozbalit Rozbalit vše Re: Sysinternals také na Linuxu
Myslím, že nikdo nezpochybňuje možnosti debugování vyvíjených app ve VS. "frr" asi narážel na to, že většina windows jsou nedebugovatelný a když něco vyvíjím a chcípá to na nějaké core dll, tak nevím proč. Zda kvůli bugu v API, nebo zda kvůli jiné chybě atd.
Zdar Max
Měl jsem sen ... :(
9.11.2018 17:58 biolog
Rozbalit Rozbalit vše Re: Sysinternals také na Linuxu
Ano, pokud se core dll chová neočekávaně, vrací selhání, nebo nedejbože samo zaviňuje pád, tak symbol servery nepomůžou. Ale nepomůžou ani ty "debug verze" (frr tím asi myslí "checked build"). Na to je potřeba buď googlení nebo zdrojáky (ty jsou dostupné jen u některých knihoven).
8.11.2018 23:56 frr | skóre: 33
Rozbalit Rozbalit vše Re: Sysinternals také na Linuxu
Symbol servery? Tohle jsem neznal, díky za vysvětlivku :-)
[:wq]
9.11.2018 17:38 biolog
Rozbalit Rozbalit vše Re: Sysinternals také na Linuxu
To nastavení je v menu Tools, Options, Debugging, Symbols, v seznamu zaškrtnout položku "Microsoft Symbol Servers". Během ladění se k to mu nastavení dá dostat rychleji kliknutím pravým tlačítkem na zásobníku nebo v seznamu DLLek, ale předchozí postup zabere vždy.

Mám pocit, že při prvním spuštění debuggeru VS samo nabídne, že si ty PDB soubory bude stahovat samo. Raději bych, aby to nastavení bylo ve výchozím stavu zapnuto, ale v tomhle případě dali přednost soukromí před užitečností.
12.11.2018 19:42 x14
Rozbalit Rozbalit vše Re: Sysinternals také na Linuxu
A až tam v tom nastavení budete, tak si cestu pro symbolovou cache nastavte někam jinam než do tempu. Klidně třeba do "c:\Symbols". Vyplatí se to.
k3dAR avatar 8.11.2018 18:32 k3dAR | skóre: 56
Rozbalit Rozbalit vše Re: Sysinternals také na Linuxu
necham stranou, ze bejt uzivatel W10, tak "Windows subsystem for Linux" rozhodne vitam, protoze to neni virtual, neni to ani windows binarky, ale je to "DualSystem", takze bych rozhodne to pouzival a nez dotahovat GNU (a jine) nastroje nativni pro Win, bych vyuzil tohle...

jinak na prelomu stoleti kdyz sem Win jeste pouzival, byli nastroje od SysInternals (btw: nejsou to produkty Microsoftu, ten to jen koupil a prejmenoval na WindowsSysInternal) u me dost pouzivane, odchytit kterej soubor kdy kam a zda uspesne zapisuje/cte kdyz proces/app pustil a/nebo regmon s registrama cteni/zapis uspech/neuspech, dalo se tim dohledat spousta problemu... pretim sem na Amize k temuz (krome Reg) pouzival vybornej SnoopDOS... a nedavno sem tu v diskuzi s nekym resil ze na GNU/Linux NEexistuje program co by monitoroval cteni/zapis konkretnich souboru, coz prave ProcMon na Win dela(l), navic s prehlednym GUI (pro GNU/Linux sem nenasel ani CLI), s moznosti filtrovani, ukladani logu, behu nonstop, nebo pozastaveni logovani atd...
porad nemam telo, ale uz mam hlavu... nobody
8.11.2018 19:39 petr_p | skóre: 59 | blog: pb
Rozbalit Rozbalit vše Re: Sysinternals také na Linuxu

Neexistuje, protože ve vší obecnosti to nelze. (Proces otevře soubor, odlinkuje ho ze souborového systému, pak si uživatel vzpomene, že chce začít sledovat. Navíc to komplikuje možnost duplikovat či posílat deskriptory cizím procesům).

Nicméně kanón na každou velikost ptáka se vždy najde. Obyčejné řešení je lsof -f -- CESTA_K_SOUBORU. Výkonnější řešení v reálném čase je systemtapová sonda. A ultimátní řešení je používat jádro se zapnutým auditem a kýženou operaci dohledat v logu démona auditd.

11.11.2018 00:41 kolemjdoucí
Rozbalit Rozbalit vše Re: Sysinternals také na Linuxu
Proces otevře soubor, odlinkuje ho ze souborového systému, pak si uživatel vzpomene, že chce začít sledovat.
A kam ho odlinkuje? Mplayer otevře channel.conf a než ho začnu chtít sledovat tak fíí a je pryč?
Obyčejné řešení je lsof -f -- CESTA_K_SOUBORU. Výkonnější řešení v reálném čase je systemtapová sonda. A ultimátní řešení je používat jádro se zapnutým auditem a kýženou operaci dohledat v logu démona auditd.
Ano, Správce procesů je linuxová parodie. Spíš je to jen zabíječ procesů krom pár drobnějších možností jako změna pririty. Ten Gnu/Linux moc průhledný není, že něco zapisuje na disk poznáte až je disk plný a nemůžete už zapisovat nic.
12.11.2018 14:12 Vantomas | skóre: 28 | Praha
Rozbalit Rozbalit vše Re: Sysinternals také na Linuxu
A kam ho odlinkuje? Mplayer otevře channel.conf a než ho začnu chtít sledovat tak fíí a je pryč?
Třeba vmware esxi se swapem u virtuálu pracuje tak, že nejprve vytvoří soubor, otevře ho, smaže z filesystému, ale se souborem pracuje dál. Takže se pak stává to, že na NFS serveru vidím, že tam teče zápis 50MB/s, ale když chci přes inotify zjistit kam se to zapisuje, tak nic nezjistím.
14.11.2018 09:25 kolemjdoucí
Rozbalit Rozbalit vše Re: Sysinternals také na Linuxu
Díky, to je ale něco jiného, podobně fungoval flash do /tmp v linuxu i flash do \temp ve Windows, tohle jsou ojedinělé případy rychlé práce v RAM. Proč ale nemůžu sledovat třeba většinu r/w operací když otevřu třeba Firefox. Ano k tomu je ideální lsof ale bohužel není GUI, proč už to dávno není součástí Správce procesů, nechápu. A bohužel s tím nepočítají ani návrhové práce které už byli plánované. https://wiki.gnome.org/ReleasePlanning/FeaturePlans
14.11.2018 09:50 Michal Kubeček | skóre: 71 | Luštěnice
Rozbalit Rozbalit vše Re: Sysinternals také na Linuxu
tohle jsou ojedinělé případy rychlé práce v RAM

Vůbec ne. Ten smazaný soubor je pořád ve filesystému, má svůj inode, alokované bloky (které se podle potřeby ukládají na zařízení) a pracuje se s ním úplně stejně jako s kterýmkoli jiným souborem. Teprve když mu refcount klesne na nulu, fakticky se smaže (uvolní se bloky a inode), ale tak to opět funguje s jakýmkoli jiným souborem.

Proto se také syscall pro "smazání soubouru" jmenuje unlink(). On totiž pouze odlinkuje adresářovou položku, ke skutečnému smazání dojde až ve chvíli, kdy na soubor neodkazuje žádná adresářová položka (mohlo jich být víc) a nepoužívá ho žádný proces. To je většinou hned, ale může to klidně trvat hodiny, dny nebo ještě déle.

14.11.2018 11:28 SkákalPřesOheňAžSiPropálilMokasíny | skóre: 29 | blog:
Rozbalit Rozbalit vše Re: Sysinternals také na Linuxu
Ano, a existují velmi dobré důvody, proč to takhle funguje. Oproti tomu např. mazání souborů na Windows je peklo, nejde smazat soubor otevřený jiným procesem nebo systémem, což v kombinaci s tím, že lidi dnes čím dál více používají všelijaké Google Drive syncery a podobné věci, znamená, že mazání souborů pravidelně náhodně selhává.
14.11.2018 10:35 SkákalPřesOheňAžSiPropálilMokasíny | skóre: 29 | blog:
Rozbalit Rozbalit vše Re: Sysinternals také na Linuxu
Proč ale nemůžu sledovat třeba většinu r/w operací když otevřu třeba Firefox.
Tady se lidi ptají na sledování zápisu/čtení souborů, ale neřeknou pořádně, co vlastně chtějí sledovat a proč (viz XY problem). "Sledováí r/w operací" je širokej pojem.

Co přesně chceš udělat? Pokud chceš zjistit, co dělá konkrétní program - třeba Firefox - ve filesystému, tj. co kam zapisuje/čte, tak na to by ten strace měl posloužit celkom dobře.
Jendа avatar 14.11.2018 15:43 Jendа | skóre: 75 | blog: Výlevníček | JO70FB
Rozbalit Rozbalit vše Re: Sysinternals také na Linuxu
Třeba u mmapovaného souboru ti strace ukáže ten mmap, ale samotné operace už ne. (a u toho myslí předřečník „r/w operací“ každý přístup do takové namapované stránky, nebo jenom když to vyvolá hrábnutí na disk?)
Postavil si radar na kopci. Ale viděl na něm věci.
14.11.2018 19:18 Vantomas | skóre: 28 | Praha
Rozbalit Rozbalit vše Re: Sysinternals také na Linuxu
Tady se lidi ptají na sledování zápisu/čtení souborů, ale neřeknou pořádně, co vlastně chtějí sledovat a proč (viz XY problem). "Sledováí r/w operací" je širokej pojem.
Jelikož kolemjdoucí píše o tom, že to není součástí správců úloh v GUI, tak bych to viděl tak, že se potýká s tím samým co já. Vidím, že mi něco hrabe na disk, ale nevím co. Tak si chci spustit správce úloh a zjistit, že to dělá Chromium, protože se rozhodl pročistit cache s obrázky od hackerů z Alabamy.

Pokud se nemýlím, tak s strace se musí proces už spouštět a tak nějak to vypisuje hrozně moc věcí a vytěžuje zbytečně procesor a určitě tu aplikaci zpomaluje... Což je v tom mnou uváděném případě naprosto nepoužitelné, protože jde o případ, kdy už mi nějaké aplikace běží a najednou se sami od sebe zblázní.
14.11.2018 19:38 SkákalPřesOheňAžSiPropálilMokasíny | skóre: 29 | blog:
Rozbalit Rozbalit vše Re: Sysinternals také na Linuxu
Vidím, že mi něco hrabe na disk, ale nevím co.
Existuje iotop, případně htop taky umí řadit podle I/O.
Pokud se nemýlím, tak s strace se musí proces už spouštět a tak nějak to vypisuje hrozně moc věcí
Nn, můžeš spustit strace připojením (attach) k existujícímu procesu. A můžeš mu říct, aby filtroval a vypisoval jen to, co chceš.

Souhlasim, že to není takhle out of the box kdovíjak user-friendly a že by to šlo zabalit do přívětivějšího (G)UI.
Jendа avatar 14.11.2018 23:16 Jendа | skóre: 75 | blog: Výlevníček | JO70FB
Rozbalit Rozbalit vše Re: Sysinternals také na Linuxu
Existuje iotop, případně htop taky umí řadit podle I/O.
Umíš řadit nikoli podle MB/s, ale podle IOPS? (je mi jasné, že díky readahead tohle může klamat) Minimálně na rotačních discích je to také zajímavá metrika (e.g. zasekaný stroj kvůli tomu, že mailserver neustále přehazuje 4KiB soubory ve frontě, a v iotopu to není vidět, protože to je nepatrný datový tok (navíc pokud je to jenom přesun a fsync, tak se většina propálí na metadatech filesystému)).
Postavil si radar na kopci. Ale viděl na něm věci.
8.11.2018 20:21 SkákalPřesOheňAžSiPropálilMokasíny | skóre: 29 | blog:
Rozbalit Rozbalit vše Re: Sysinternals také na Linuxu
a nedavno sem tu v diskuzi s nekym resil ze na GNU/Linux NEexistuje program co by monitoroval cteni/zapis konkretnich souboru
man strace

Případně dtrace? Nevim teď, jak daleko jsou kluci s tím linuxovým portem, ale třeba by to šlo...
Jendа avatar 9.11.2018 01:51 Jendа | skóre: 75 | blog: Výlevníček | JO70FB
Rozbalit Rozbalit vše Re: Sysinternals také na Linuxu
To bys musel s strace spustit celý systém.

Ale máme audit. Např. (nezkoušel jsem to)
Postavil si radar na kopci. Ale viděl na něm věci.
9.11.2018 06:28 -nd-
Rozbalit Rozbalit vše Re: Sysinternals také na Linuxu
inotifywait
9.11.2018 08:23 luky
Rozbalit Rozbalit vše Re: Sysinternals také na Linuxu
presne tak, jde to pres *notify volani pripadne pres ftrace a dalsi nad tim postavene nastroje. Pripojte si tracefs a presctete si README.
9.11.2018 10:27 melkors | skóre: 13 | blog: kdo_chce_kam
Rozbalit Rozbalit vše Re: Sysinternals také na Linuxu
Historicko-technicka: Ta firma se puvodne jmenovala Winternals, pak na ne skocili pravnici MS a firmicka se prejmenovala na SysInternals
9.11.2018 11:01 debian+
Rozbalit Rozbalit vše Re: Sysinternals také na Linuxu
Potom je este FUSE. ... A info o procese (nazov, atd.) su definovane ako globalne premenne.
8.11.2018 10:24 R
Rozbalit Rozbalit vše Re: Sysinternals také na Linuxu
Este RegMon a uz budem konecne spokojny.
pepe_ avatar 8.11.2018 12:45 pepe_ | skóre: 47
Rozbalit Rozbalit vše Re: Sysinternals také na Linuxu

?

8.11.2018 12:51 debian+
Rozbalit Rozbalit vše Re: Sysinternals také na Linuxu
Hm, ukazka, ako parsuju /proc/PID/stat: src/Process.c
8.11.2018 12:57
Rozbalit Rozbalit vše Re: Sysinternals také na Linuxu
skrytý komentář Náš administrátor shledal tento komentář závadným.

nenávistný komentář

Zobrazit komentář
8.11.2018 13:06 fgsdfgsfdg
Rozbalit Rozbalit vše Re: Sysinternals také na Linuxu
To je naprosto priserny. Ma nekdo predstavu proc je to tak jak to je?
Max avatar 8.11.2018 13:26 Max | skóre: 67 | blog: Max_Devaine
Rozbalit Rozbalit vše Re: Sysinternals také na Linuxu
Levná pracovní síla?
Jinak jsem na to koukal a je to fakt hnus. Sice nejsem programátor, jen občas skriptuji, ale i mně to bije do očí.
Zdar Max
Měl jsem sen ... :(
9.11.2018 01:38 .
Rozbalit Rozbalit vše Re: Sysinternals také na Linuxu
Já jsem programátor a moc by mě zajímalo, co tě bije do očí.
Blaazen avatar 9.11.2018 04:02 Blaazen | skóre: 23 | blog: BL
Rozbalit Rozbalit vše Re: Sysinternals také na Linuxu
Já v C nedělám, ale tohle vypadá na nedodržení DRY (don't repeat yourself), případně DIE (duplicating is evil) a Copy-and-paste programming.
Max avatar 9.11.2018 08:20 Max | skóre: 67 | blog: Max_Devaine
Rozbalit Rozbalit vše Re: Sysinternals také na Linuxu
To ošetření nulových hodnot při čtení. Copy paste té stejné věci na milion řádků. Když je pak něco třeba upravit, tak jak to udělám? Hromadným nahrazováním? Nechápu, proč to negeneruje dynamicky podle toho, co se snaží číst.
Zdar Max
Měl jsem sen ... :(
9.11.2018 08:26 luky
Rozbalit Rozbalit vše Re: Sysinternals také na Linuxu
treba to, proc to nenapsali jako scanf("%u%s%c%u%u%u...", &pid, comm, &state...)
9.11.2018 08:41 luky
Rozbalit Rozbalit vše Re: Sysinternals také na Linuxu
Musi se to cist nadvakrat rozseknuty posledni pravou zavorkou, protoze v comm muze byt mezera. Jinak pouziti scanf nic nebrani.
10.11.2018 12:24 Filip Jirsák | skóre: 67 | blog: Fa & Bi
Rozbalit Rozbalit vše Re: Sysinternals také na Linuxu
Řekl bych, že to bije do očí jenom neprogramátory. Programátoři tuší, jaké možnosti má C a že tohle je standardní způsob ošetření chybových stavů v C. Ale zase je na tom hezky vidět, proč pozdější jazyky zavedly koncept výjimek.
11.11.2018 11:40 SkákalPřesOheňAžSiPropálilMokasíny | skóre: 29 | blog:
Rozbalit Rozbalit vše Re: Sysinternals také na Linuxu
Programátoři tuší, jaké možnosti má C a že tohle je standardní způsob ošetření chybových stavů v C.
Ta ošklivost toho kódu není daná (jen) limitacemi C. I v C by to šlo napsat pěkněji.
Ale zase je na tom hezky vidět, proč pozdější jazyky zavedly koncept výjimek.
Výjimky některé problémy vyřešily, ale na to konto přinesly problémy jiné, neméně nepříjemné.
11.11.2018 13:15 Filip Jirsák | skóre: 67 | blog: Fa & Bi
Rozbalit Rozbalit vše Re: Sysinternals také na Linuxu
Šlo by to napsat jinak. Jestli pěkněji, to je otázka – to záleží na konkrétním kódu a na vkusu.
11.11.2018 21:28 Michal Kubeček | skóre: 71 | Luštěnice
Rozbalit Rozbalit vše Re: Sysinternals také na Linuxu
Tady je řeč o zcela konkrétním kusu kódu.
11.11.2018 22:20 Filip Jirsák | skóre: 67 | blog: Fa & Bi
Rozbalit Rozbalit vše Re: Sysinternals také na Linuxu
Akorát že pouze v jedné variantě. Takže se to těžko porovnává, zda ta druhá, neexistující varianta je pěknější nebo není.
12.11.2018 07:23 Michal Kubeček | skóre: 71 | Luštěnice
Rozbalit Rozbalit vše Re: Sysinternals také na Linuxu
Hm… Takže když se dělá review patche, je naprosto nepřípustné napsat, že by se něco mělo udělat jinak a vysvětlit důvody resp. naznačit jak? Jediný přijatelný způsob je podle vás poslat svou vlastní verzi?
12.11.2018 16:58 Filip Jirsák | skóre: 67 | blog: Fa & Bi
Rozbalit Rozbalit vše Re: Sysinternals také na Linuxu
Jak jste přišel na to, že bych si něco takového myslel? Vy v tomto vlákně někde vidíte vysvětlení důvodů, proč by to mělo být napsáno jinak, nebo dokonce naznačené, jak jinak by to mělo být napsané? Já tu vidím jenom „pěkněji“, a to je dost ošemetné, protože často co jeden považuje za hezčí, jinému připadá jako ošklivější.

Jinak já jsem na začátku reagoval hlavně na představu neprogramátorů, že jakmile se ve zdrojovém kódu nějaké části opakují, je to špatně. Jenže ony se v kódu často opakují třeba takové věci, jako int function() nebo sekvence if () else atd. Protože to jsou prostě výrazové prostředky daného jazyka. Mezi výrazové prostředky nepatří jen klíčová slova, ale i konstrukce na vyšší úrovni. Je správně, nikoli špatně, pokud se tyhle konstrukce na vyšší úrovni opakují, tj. tu samou konstrukci všichni píšou stejně – každý pak na první pohled vidí třeba „aha, tohle je nekonečný cyklus“ a nemusí to detailně luštit z kódu.

No a to, co se v tom kódu opakuje, je pokud vím céčkový idiom pro ošetření chybového stavu. Takže na tom, že se opakuje, nevidím nic špatného, právě naopak – každému je to na první pohled jasné, nemusí každý ten if podrobně číst ale může ho přečíst jako jeden blok „ošetření chyby“. Řešit to ošetření chyby nějakou funkcí, aby se ušetřil jeden řádek kódu, nebo dokonce nějakým makrem, by z mého pohledu bylo ke škodě věci, protože by se tím, zatemnilo, co ten kód vlastně dělá.

Jistě, že by se ten kód dal napsat úplně jinak. Třeba použít nějaký triviální parser, nebo dokonce plnohodnotný parser. Ale to, že by se to napsalo jinak, vůbec neznamená, že by to bylo hezčí nebo dokonce lepší. A bez toho, že někdo alespoň naznačí, jak jinak by to napsal, se to opravdu posoudit nedá.
12.11.2018 17:21 SkákalPřesOheňAžSiPropálilMokasíny | skóre: 29 | blog:
Rozbalit Rozbalit vše Re: Sysinternals také na Linuxu
Jinak já jsem na začátku reagoval hlavně na představu neprogramátorů, že jakmile se ve zdrojovém kódu nějaké části opakují, je to špatně.
Aha, pardon, teď koukám, že jsem v tom původním komentáři přehlídl to "ne" v "neprogramátor"...

Souhlasim, že ta metrika "pěknější kód" je do značný míry subjektivní...
xxx avatar 13.11.2018 21:49 xxx | skóre: 42 | blog: Na Kafíčko
Rozbalit Rozbalit vše Re: Sysinternals také na Linuxu

Je to takovej levl junior:

const char *err[] = {"Can't parse num1",
                      "Can't parse num2",
                      ...}
ret = sscanf(line,"%d %d ...", &num1, &num2, ...);
if(ret < ITEMS) {     
    if(!errno) {         
        fprintf(stderr, "%s", err[ret]);
    else         
        fprintf(stderr, "wtf?");      
    return FAIL; 
}  
return OK; 

Please rise for the Futurama theme song.
20.11.2018 23:07 Martin Mareš
Rozbalit Rozbalit vše Re: Sysinternals také na Linuxu
Račte prominout, ale tady každý, kdo v Céčku v životě něco netriviálního napsal, naprosto jasně vidí, že je to napsané mizerně, a také hned vidí několik různých způsobů, jak to napsat mnohem lépe. Takže pokud se Vám to těžko porovnává, doporučuji vzít si učebnici Céčka a cvičit, cvičit, cvičit...
21.11.2018 07:30 Filip Jirsák | skóre: 67 | blog: Fa & Bi
Rozbalit Rozbalit vše Re: Sysinternals také na Linuxu
Tady se ale bavíme o tom, jak to hodnotí neprogramátoři – u těch bych úplně neočekával, že napsali v C něco netriviálního. Jinak gratuluju, že jste se přidal k lidem, kteří žvaní o tom, jak by to šlo napsat lépe, ale neukážou ani jednu řádku kódu. Samozřejmě, všechno by šlo napsat lépe. Ale často to někomu nestojí za tu námahu napsat to lépe, že.
21.11.2018 07:44 Michal Kubeček | skóre: 71 | Luštěnice
Rozbalit Rozbalit vše Re: Sysinternals také na Linuxu
Tady se ale bavíme o tom, jak to hodnotí neprogramátoři

Opravdu? Já tady totiž o kus výš vidím komentář tohoto znění:

Řekl bych, že to bije do očí jenom neprogramátory. Programátoři tuší, jaké možnosti má C a že tohle je standardní způsob ošetření chybových stavů v C. Ale zase je na tom hezky vidět, proč pozdější jazyky zavedly koncept výjimek.

Podepsán je pod ním (technicky nad ním) jistý Filip Jirsák. A teď vidím, že Martina Mareše to do očí bije (mne mimochodem taky). Takže mi z toho logicky vychází, že pokud jste ten příspěvek nepsal v nějakém naprostém zatmění mysli a nehodláte to tvrzení odvolat, považujete Martina Mareše za "neprogramátora". A to mi připadá hodně odvážné - nebo spíš hodně hloupé.

21.11.2018 08:45 Filip Jirsák | skóre: 67 | blog: Fa & Bi
Rozbalit Rozbalit vše Re: Sysinternals také na Linuxu
Jedna věc je, jestli je někdo mimo tuto diskusi programátor, druhá věc je, jestli do této diskuse přispěl svou ukázkou kódu, která by byla jednoznačně lepší, než ten diskutovaný kód. Já tady vidím jediný příspěvek s kódem, a autora toho kódu oceňuji, že jako jediný našel odvahu jít s kůží na trh. Přestože si nemyslím, že by jeho kód byl lepší nebo horší – je prostě jen jiný, má jiné nedostatky a jiné přednosti.

Pokud někdo do diskuse, kde už bylo jinými slovy řečeno „talk is cheap. Show me the code“ přispěje dalším komentářem bez kódu o tom, jak by se to dalo napsat lépe, sám se tím zařazuje mezi lidi, kteří jen povýšeně trousí moudra, že by to šlo napsat mnohem lépe, ale konkrétní kód neukáže. Při vší úctě k Martinovi Marešovi, zařadit ho v tomto případě mezi „neprogramátory“ je myslím adekvátní reakce.

Že to může být hloupé, to je možné – to bývá docela častý jev v diskusi, že po jednom hloupém příspěvku následují i od ostatních už jenom hloupé příspěvky.

Mimochodem, není zas tak výjimečný případ, kdy laik něco považuje za špatné, skutečný odborník také – ale z úplně jiného důvodu. Řekl bych, že to je i tento případ. Ta opakující se konstrukce, která připadá divná neprogramátorům, je standardní ošetření chyb v C – a nesetkáváme se s ní častěji v jiném kódu proto, že se na ošetření chyb často kašle. Programátorům předpokládám vadí spíš způsob parsování souboru, protože zrovna pro takhle jednoduchý formát existují jiné prostředky, např. sscanf. Ale představte si, že by tam místo jednoduchých číselných údajů bylo něco jiného, třeba občas nějaký datum a čas v ISO formátu.
21.11.2018 09:29 Michal Kubeček | skóre: 71 | Luštěnice
Rozbalit Rozbalit vše Re: Sysinternals také na Linuxu
Pokud někdo do diskuse, kde už bylo jinými slovy řečeno „talk is cheap. Show me the code“ přispěje dalším komentářem bez kódu o tom, jak by se to dalo napsat lépe, sám se tím zařazuje mezi lidi, kteří jen povýšeně trousí moudra, že by to šlo napsat mnohem lépe, ale konkrétní kód neukáže.

Ne. Rozhodně ne. Pokud je kód očividně napsaný nešikovně a hloupě (a tohle je ten případ), nemá každý, kdo na to chce upozornit, povinnost trávit čas tím, že ho bude celý přepisovat, aby splnil vaše náročná kritéria.

Při vší úctě k Martinovi Marešovi, zařadit ho v tomto případě mezi „neprogramátory“ je myslím adekvátní reakce.

Po pravdě, nečekal jsem, že byste se omluvil, na to vás znám už příliš dlouho, ale musím přiznat, že touhle reakcí jste mne přesto dokázal překvapit.

Ta opakující se konstrukce, která připadá divná neprogramátorům, je standardní ošetření chyb v C – a nesetkáváme se s ní častěji v jiném kódu proto, že se na ošetření chyb často kašle.

Možnost, že by někomu nevadil způsob, jak se reaguje na chybu, ale prostě to, že je tam třicetkrát (možná víc, nemám chuť to počítat) za sebou prakticky totožný fragment kódu, vás opravdu nenapadla?

21.11.2018 09:58 Filip Jirsák | skóre: 67 | blog: Fa & Bi
Rozbalit Rozbalit vše Re: Sysinternals také na Linuxu
Ne. Rozhodně ne. Pokud je kód očividně napsaný nešikovně a hloupě (a tohle je ten případ), nemá každý, kdo na to chce upozornit, povinnost trávit čas tím, že ho bude celý přepisovat, aby splnil vaše náročná kritéria.
Já jsem nepsal žádná náročná kritéria. Kritérium bylo jediné – aby ten kód byl lepší, než je ten současný. Což by nemělo být tak těžké, pokud ten kód je napsaný očividně nešikovně a hloupě. Zatím ale kromě silných řečí nemáme nic. Což mi připadá škoda, myslel jsem, že se my, kteří v C neprogramujeme, třeba dozvíme něco nového.
Možnost, že by někomu nevadil způsob, jak se reaguje na chybu, ale prostě to, že je tam třicetkrát (možná víc, nemám chuť to počítat) za sebou prakticky totožný fragment kódu, vás opravdu nenapadla?
Myslím, že už jsem to vysvětloval v prvním komentáři. Ten fragment kódu je pokud vím idiom pro ošetření chybového návratového kódu. C na to nemá žádný syntaktický cukr, takže je ten idiom trochu ukecaný. Ale je to standardní konstrukce, a stěžovat si na opakování je přibližně stejné, jako kdyby si někdo stěžoval, že se při volání funkce vždycky opakují závorky.
21.11.2018 10:37 Michal Kubeček | skóre: 71 | Luštěnice
Rozbalit Rozbalit vše Re: Sysinternals také na Linuxu
Já jsem nepsal žádná náročná kritéria. Kritérium bylo jediné – aby ten kód byl lepší, než je ten současný.

Nemluvil jsem o kritériích pro kód, ale o kritériích pro diskusní příspěvky.

Ten fragment kódu je pokud vím idiom pro ošetření chybového návratového kódu. C na to nemá žádný syntaktický cukr, takže je ten idiom trochu ukecaný. Ale je to standardní konstrukce, a stěžovat si na opakování je přibližně stejné, jako kdyby si někdo stěžoval, že se při volání funkce vždycky opakují závorky.

A s takovým rozhledem máte tu drzost kádrovat lidi jako "neprogramátory"? V tom případě se přidávám k doporučení ohledně učebnice, zejména s důrazem na kapitoly o funkcích a cyklech (zbyde-li čas, možná i makra).

21.11.2018 12:12 Filip Jirsák | skóre: 67 | blog: Fa & Bi
Rozbalit Rozbalit vše Re: Sysinternals také na Linuxu
A s takovým rozhledem máte tu drzost kádrovat lidi jako "neprogramátory"?
Já jsem nikoho nekádroval, v prvním příspěvku, kde jsem psal o neprogramátorech, jsem jenom vypíchl to, co o sobě dotyční napsali sami.
V tom případě se přidávám k doporučení ohledně učebnice, zejména s důrazem na kapitoly o funkcích a cyklech (zbyde-li čas, možná i makra).
Víte, to je právě ta nevýhoda, že se nebavíme o konkrétním kódu. To se tady teď můžeme mlátit učebnicemi do nekonečna. Já se můžu jenom dohadovat, co přesně za kód vám připadá špatně, omlátit vám o hlavu, že to funkce ani cyklus nevyřeší, makra by pomohla, ale zase výrazně znepřehlední kód.

Ten kód, který se na první pohled opakuje, je tohle:
if(token == NULL){
  Trace($ERROR_MESSAGE);        
  return false;
}
Někdo by možná k tomu problematickému kódu zařadil i předchozí výkonný řádek
token = strtok_r(NULL, " ", &savePtr);
Tyhle bloky jsou ale roztroušené mezi jednotlivými řádky výkonného kódu, takže cyklus nijak nepomůže. Cyklus by se dal použít, pokud ten výkonný kód upravíte tak, aby si z nějaké deklarace načítal, jak má data parsovat, kam je uložit a co případně vypsat za chybu. Přidáte jednu úroveň nepřímého volání, pro parsování si vlastně vytvoříte takový jednoduchý DSL a můžete použít cyklus. Už jsem dříve psal, že je to jedno z možných řešení, a že v žádném případě takové řešení nebude automaticky přehlednější, než současný kód.

Druhá možnost je nahrazení toho bloku funkcí. Ovšem ten blok se používá pro řízení toku programu, takže ten if a return tam bude muset zůstat. Takže ten blok můžete zkrátit na tři řádky, místo současných čtyřech nebo pěti. Za cenu, že se dovnitř té funkce schová, že se tam vypisuje chybová zpráva, a za cenu, že se ta funkce bude volat přímo v podmínce ifu. Já to nevidím tak jednoznačně, že by ušetření jednoho nebo dvou řádků kódu bylo takovým kladem, aby to vyvážilo ty zápory.
if(attendError(token, $ERROR_MESSAGE)){
  return false;
}
Možná jste myslel jinou úpravu, ale to se můžu jen dohadovat, když jste žádný kód nenapsal.
21.11.2018 13:40 Michal Kubeček | skóre: 71 | Luštěnice
Rozbalit Rozbalit vše Re: Sysinternals také na Linuxu
makra by pomohla, ale zase výrazně znepřehlední kód

Možná jsem divný, ale např.

if (PARSE_NUM(ppid, strtol, "Parent PID") ||
    PARSE_NUM(pgrp, strtol, "Process group ID") ||
    PARSE_NUM(session, strtol, "Session ID") ||
    ...)
        return false;    

mi přijde o hodně přehlednější než to, co tam vidím teď. Definice toho makra sice nebude zrovna umělecké dílo, ale zase o tolik hůře než jeden současný blok vypadat nebude. A hlavně tam bude jednou, takže zkontrolovat nebo někdy časem opravit ji také bude stačit jednou. Kdokoli bude dělat review, nebude muset pozorně pročítat 440 řádků nudného stále se opakujícího zdrojáku. Kdokoli bude potřebovat tu logiku trochu upravit, nebude muset provádět stejnou změnu na 49 místech, udělá to na jednom.

Cyklus by se dal použít, pokud ten výkonný kód upravíte tak, aby si z nějaké deklarace načítal, jak má data parsovat, kam je uložit a co případně vypsat za chybu. Přidáte jednu úroveň nepřímého volání, pro parsování si vlastně vytvoříte takový jednoduchý DSL a můžete použít cyklus.

No vidíte, že to jde…

Už jsem dříve psal, že je to jedno z možných řešení, a že v žádném případě takové řešení nebude automaticky přehlednější, než současný kód.

Asi by se to dalo napsat tak, aby to bylo nepřehlednější a hůře udržovatelné, ale to neznamená, že to tak být musí. Kdyby ty bloky byly tři (a měl jsem jistotu, že jiný podobný soubor parsovat nebudu), tak neřeknu, ale 49?

21.11.2018 15:20 Filip Jirsák | skóre: 67 | blog: Fa & Bi
Rozbalit Rozbalit vše Re: Sysinternals také na Linuxu
Podle mne se ale nedá přehlednost hodnotit izolovaně. Pokud ten kód někdo bude číst, s největší pravděpodobností bude potřebovat vědět, co to makro kód dělá. Váš kód má tu výhodu, že případné ošetření chyb stačí změnit na jednom místě. A zase má tu nevýhodu, že případnou změnu parsování (bude tam nějaký nový údaj s jiným formátem) znamená změnit to makro, čímž se změní ten kód pro všechny ostatní případy, kde k žádné změně nedošlo. Úplně překopat se to bude muset v případě, kdy bude třeba změnit logiku parsování – třeba tak, aby se zjistily všechny chyby, vypsaly se najednou a teprve pak se program ukončil. Zkrátka se nedá moc předjímat dopředu, jaké budou v budoucnosti potřeba úpravy – a jestli mi to současné makro ty úpravy usnadní nebo naopak zkomplikuje.

Co kdyby těch bloků nebylo 49, ale 1500? Po celé aplikaci, protože by to byla konstrukce, která se v tom projektu tak používá. Mohla by na to být i statická kontrola kódu – jakmile nějaká funkce může vrátit chybový kód, musí za ní následovat if, který bude obsahovat buď komentář, jak o jakou jde chybu a jak se z ní kód zotaví, nebo tam bude zalogována chyba a funkce se ukončí s chybovým návratovým kódem. A těchhle 49 se akorát sešlo takhle divně za sebou.

Samozřejmě se to dá napsat jinak a v mnoha případech ten jiný zápis bude lepší. Ale dovedu si představit situace, kdy je nejlepší právě ten současný zápis. Opakující se podobné bloky kódu neznamenají automaticky špatný kód, což tady spousta komentářů předpokládalo. Zrovna při parsování dat je to naprosto běžné – ostatně proto vůbec vznikly různé generátory parserů, protože ten opakující se kód se v mnoha případech dá vygenerovat automaticky.
21.11.2018 17:44 Michal Kubeček | skóre: 71 | Luštěnice
Rozbalit Rozbalit vše Re: Sysinternals také na Linuxu
Pokud ten kód někdo bude číst, s největší pravděpodobností bude potřebovat vědět, co to makro kód dělá.

Základní informaci mu poskytne jméno, zbytek najde v komentáři nad jeho definicí, včetně popisu argumentů. Když se bude potřebovat podívat, co přesně dělá a/nebo jestli v něm není chyba, najde to na jednom místě, nebude jich muset procházet 49 a zkoumat, jestli se náhodou jedno záměrně trochu neliší nebo jestli v něm není překlep.

Váš kód … zase má tu nevýhodu, že případnou změnu parsování (bude tam nějaký nový údaj s jiným formátem) znamená změnit to makro, čímž se změní ten kód pro všechny ostatní případy, kde k žádné změně nedošlo.

Především bych to takhle pravděpodobně neudělal. To byl spíš takový nástřel, jak rychle a bezpracně dosáhnout podstatně lepšího výsledku. Hlavně se tu ale nebavíme o nějakém hypotetickém naprosto obecném problému, bavíme se o konkrétním kusu kódu, který parsuje /proc/${pid}/stat, tj. soubor, jehož syntaxe se prakticky nemění - a když, tak leda tak, že přibudou další číselné sloupce.

Pokud by se přeci jen někde objevil sloupec s jiným formátem, nic mi nebrání si pro něj napsat jiné makro nebo funkci (s makrem jako wrapperem).

Jestli mi pořád nevěříte, schválně se zkuste podívat, jak vypadá kód na druhé straně, který ten soubor v procfs generuje. Konkrétně doporučuji podívat se, jestli je tam také padesát skoro stejných několikařádkových bloků nebo jestli je to řešené genericky. (A také doporučuji pozornosti komentáře týkající se zpětné kompatibility.)

Co kdyby těch bloků nebylo 49, ale 1500? Po celé aplikaci, protože by to byla konstrukce, která se v tom projektu tak používá.

Tím spíš bych to neřešil takhle stupidně, abych tam měl 1500 skoro stejných devítiřádkových kusů kódu. Podle okolností bych si buď napsal nějaký framework jako tady (spíš pro představu, je to pracovní verze a možná to nakonec bude celé vypadat úplně jinak) nebo použil něco hotového.

Samozřejmě se to dá napsat jinak a v mnoha případech ten jiný zápis bude lepší. Ale dovedu si představit situace, kdy je nejlepší právě ten současný zápis.

To já taky, třeba kdyby ty sloupce byly jen dva. Podstata problému je ale v tom, že tenhle konkrétní parser, tak jak je napsaný, je učebnicová ukázka, jak neprogramovat. A všechny ty vaše hypotetické úvahy, jak by se jiné řešení zkomplikovalo, kdyby cosi, na tom nemění zhola nic, protože tahle šílenost by v takových myšlenkových pokusech neobstála o nic lépe. Tohle je prostě prasárna, se kterou by vás kterýkoli příčetný a zodpovědný maintainer hnal svinským krokem.

A nebo je prostě jako obvykle problém jen v tom, že ostatní účastníci diskuse se zabývají praktickou stránkou věci a neberou ji jen jako argumentační cvičení.

21.11.2018 18:06 Filip Jirsák | skóre: 67 | blog: Fa & Bi
Rozbalit Rozbalit vše Re: Sysinternals také na Linuxu
Nějak nevidím rozdíl mezi vaší přípravou na hypotetickou situaci, že bude potřeba změnit způsob reakce na chyby, a mou přípravou na hypotetickou situaci, že stejným způsobem budu chtít parsovat jiný soubor. Jsem dalek toho hodnotit jeden vytržený soubor se zdrojovým kódem, bez znalosti jakéhokoli kontextu, jako učebnicovou ukázku, jak neprogramovat – zvlášť když tu všichni tvrdí, jak to snadno naprogramovat jinak, ale konkrétní ukázky tu máme jen dvě, a to ještě s komentářem „vlastně bych to takhle neudělal“. Ono to pak skoro vypadá, že vymyslet to opravdu lépe není zas až tak snadné. A že na tom autor toho kódu byl stejně, jako zdejší diskutující – totiž že se nevyplatí investovat čas do toho napsat to lépe. Vhodný čas na vyčištění toho kódu totiž může být tehdy, až se ten kód bude příště upravovat – tehdy už totiž bude znám alespoň jeden případ, kdy ten kód bylo potřeba upravit, a bude možné kód zobecnit tak, aby usnadňoval právě ty úpravy, které se na něj doopravdy dělají.
21.11.2018 18:32 Michal Kubeček | skóre: 71 | Luštěnice
Rozbalit Rozbalit vše Re: Sysinternals také na Linuxu
Nějak nevidím rozdíl mezi vaší přípravou na hypotetickou situaci, že bude potřeba změnit způsob reakce na chyby, a mou přípravou na hypotetickou situaci, že stejným způsobem budu chtít parsovat jiný soubor.

On v tom vlastně až tak zásadní rozdíl není: v obou situacích na tom budete se stávajícím kódem o poznání hůř.

jeden vytržený soubor se zdrojovým kódem, bez znalosti jakéhokoli kontextu

Tady právě žádný kontext není potřeba, protože tak, jak je to napsané, mi to ve vedlejším souboru zcela určitě k ničemu nebude, ať už je v tom vedlejším souboru cokoli. Kontext začne být zajímavý až v okamžiku, kdy se začnu rozhodovat, jaké řešení zvolit, když to budu chtít napsat lépe.

zvlášť když tu všichni tvrdí, jak to snadno naprogramovat jinak, ale konkrétní ukázky tu máme jen dvě, a to ještě s komentářem „vlastně bych to takhle neudělal“

Začínám mít čím dál silnější pocit, že vy jste toho ve skutečnosti nikdy moc nenaprogramoval. Nebo jen předstíráte, že si neuvědomujete, jak velký rozdíl v časové náročnosti je mezi rámcovou představou, jak úlohu řešit, a prezentovatelným řešením odladěným aspoň natolik, abyste nemusel očekávat, že v něm během pěti minut někdo najde nějakou hloupou chybu? A že se kvůli vašim provokacím nikdo nebude psát se zcela konkrétním řešením, když jde o projekt, do kterého stejně nemá nejmenší chuť přispívat? (Ostatně, kdybych zrovna nedělal bisect, už bych se na tuhle diskusi dávno vykašlal i tak.)

Vhodný čas na vyčištění toho kódu totiž může být tehdy, až se ten kód bude příště upravovat – tehdy už totiž bude znám alespoň jeden případ, kdy ten kód bylo potřeba upravit, a bude možné kód zobecnit tak, aby usnadňoval právě ty úpravy, které se na něj doopravdy dělají.

A tímhle mne v tom pocitu jen utvrzujete. On jako do té doby nikdo nebude dělat review ani ten kód číst z jakéhokoli jiného důvodu? Lidem, kteří takovéhle věci píší, a stejně tak těm, kteří je obhajují, bych přál, aby aspoň tak rok jejich práce spočívala v nutnosti přečíst a pochopit cizí kód, který vidí poprvé v životě, rychle se v něm zorientovat a najít a opravit chybu. Možná by ani rok nebyl potřeba, aby se na to začali dívat trochu jinak.

21.11.2018 19:26 Filip Jirsák | skóre: 67 | blog: Fa & Bi
Rozbalit Rozbalit vše Re: Sysinternals také na Linuxu
On v tom vlastně až tak zásadní rozdíl není: v obou situacích na tom budete se stávajícím kódem o poznání hůř.
Reagujete úplně na něco jiného, než je smysl sdělení.
Tady právě žádný kontext není potřeba
Samozřejmě, že je kontext potřeba. Když nevíte, jaká jsou omezení, pravidla, zvyklosti nebo souvislosti, nemůžete vědět, zda to, co je podle vás očividně špatně, nemá nějaký smysl, který nechápete. Odsoudit cokoli na základě povrchních znalostí je strašně snadné.
Nebo jen předstíráte, že si neuvědomujete, jak velký rozdíl v časové náročnosti je mezi rámcovou představou, jak úlohu řešit, a prezentovatelným řešením odladěným aspoň natolik, abyste nemusel očekávat, že v něm během pěti minut někdo najde nějakou hloupou chybu?
Ten rozdíl je tím větší, čím komplexnější a vrstevnatější to řešení je. Takže se také může stát, že dotyčný dospěje k názoru, že než to řešit hezky pomocí složitějších konstrukcí, řešení pak ladit a odchytávat hloupé chyby, vyplatí se to vyřešit přímočaře, prostě nakopírovat kód tak, jak se to má hodnotu po hodnotě parsovat, a nemuset už pak nic ladit a odchytávat hloupé chyby. Možná se to někomu líbit, pak se dotyční pohádají, zda se to má správně řešit pomocí sscanf, maker, funkcí nebo generátoru parserů, na ničem se nedohodnou a tak tam zůstane ten váš ošklivý kód až do doby, dokud to někdo nebude potřebovat opravdu upravit či zobecnit, a pak to přepíše.
On jako do té doby nikdo nebude dělat review ani ten kód číst z jakéhokoli jiného důvodu? Lidem, kteří takovéhle věci píší, a stejně tak těm, kteří je obhajují, bych přál, aby aspoň tak rok jejich práce spočívala v nutnosti přečíst a pochopit cizí kód, který vidí poprvé v životě, rychle se v něm zorientovat a najít a opravit chybu. Možná by ani rok nebyl potřeba, aby se na to začali dívat trochu jinak.
Opravdu vám tenhle kód připadá na pochopení složitější, než kdybyste tam měl makro? Jako je pravděpodobné, že kdyby tam bylo použité řešení se sscanf nebo makro, nejspíš by nikdo nikdo z těch „sice nejsem programátor, ale tohle bije do očí“ svůj komentář nenapsal, ale obávám se, že důvodem by nebylo to, že by ten kód chápali a líbil se jim.
21.11.2018 20:39 Michal Kubeček | skóre: 71 | Luštěnice
Rozbalit Rozbalit vše Re: Sysinternals také na Linuxu
Samozřejmě, že je kontext potřeba. Když nevíte, jaká jsou omezení, pravidla, zvyklosti nebo souvislosti, nemůžete vědět, zda to, co je podle vás očividně špatně, nemá nějaký smysl, který nechápete. Odsoudit cokoli na základě povrchních znalostí je strašně snadné.

Snadné je spíš omíalt takovéhle obecné a bezobsažné fráze pořád dokola jen abyste nemusel připustit, že by to možná mohlo být i trochu jinak, než že vy jediný tomu rozumíte natolik, abyste nahlédl hloubku těch geniálních myšlenek a došlo vám, že ten kód není úplně hloupě napsaný, ale že je vlastně mnohem chytřejší, než kdybychom ho psali my ostatní.

Ten rozdíl je tím větší, čím komplexnější a vrstevnatější to řešení je. Takže se také může stát, že dotyčný dospěje k názoru, že než to řešit hezky pomocí složitějších konstrukcí, řešení pak ladit a odchytávat hloupé chyby, vyplatí se to vyřešit přímočaře, prostě nakopírovat kód tak, jak se to má hodnotu po hodnotě parsovat, a nemuset už pak nic ladit a odchytávat hloupé chyby.

Jasně, "a nemuset už pak nic ladit a odchytávat hloupé chyby". Bylo by to zábavné, kdybych neměl podezření, že tomu snad opravdu věříte.

Možná se to někomu líbit, pak se dotyční pohádají, zda se to má správně řešit pomocí sscanf, maker, funkcí nebo generátoru parserů, na ničem se nedohodnou a tak tam zůstane ten váš ošklivý kód až do doby, dokud to někdo nebude potřebovat opravdu upravit či zobecnit, a pak to přepíše.

Především by v příčetně a zodpovědně maintainovaném projektu takováhle hrůza zůstat neměla z toho prostého důvodu, že by se tam nikdy neměla vůbec dostat. "Uděláme to pořádně teprve až to bude potřeba upravit" je naprostý nesmysl a cesta do pekel. A vůbec celý ten argument ignoruje, že se sice mohou rozcházet názory na to, jestli je elegantnější to či ono řešení, ale že to, o kterém se celou dobu bavíme, je úplně jiná liga. Prostě jako kdyby se fandové fotbalu bavili, jestli se jim víc líbí hra Realu, Bayernu nebo Juventusu, a vy se vytasil s tím, že podle vás nejhezčí fotbal hraje FC Amfora. A pak do krve obhajoval, že váš názor je stejně hodnotný jako ten jejich.

Opravdu vám tenhle kód připadá na pochopení složitější, než kdybyste tam měl makro?

Na pochopení čeho přesně? Na pochopení toho, co by asi tak měl dělat, to vyjde asi tak nastejno. Ale na to, abych mohl říci, co opravdu dělá… na to je ten stávající kód řádově složitější. A problém (jeden z mnoha) je v tom, že to druhé je po čertech důležitější než to první.

21.11.2018 21:20 Filip Jirsák | skóre: 67 | blog: Fa & Bi
Rozbalit Rozbalit vše Re: Sysinternals také na Linuxu
Podsunutý argument (straw man) To si zkoušejte na někoho jiného.
21.11.2018 22:54 Michal Kubeček | skóre: 71 | Luštěnice
Rozbalit Rozbalit vše Re: Sysinternals také na Linuxu

Nemám nejmenší tušení, na kterou část mého komentáře tím prefabrikátem reagujete - a vlastně už mne to ani nezajímá. Až (jestli) se někdy budete chtít bavit o programování, můžeme se k tomuto tématu vrátit. Abych vám dál dělal sparingpartnera pro vaše cvičení v abstraktní rétorice, na to nemám čas ani náladu.

Několik lidí, kteří se programováním v céčku opravdu zabývají a mají i nějaké ty zkušenosti z praxe a skutečných softwarových projektů, se vám tu pokoušelo vysvětlit, že je ten kód zásadně špatně napsaný, přistoupili i na vaši hru na nechápavé dítě a trpělivě vysvětlovali proč a pak dokonce i to, jak by se to dalo udělat lépe. Vše marno, vy si dál vesele dokola opakujete své bezobsažné fráze a trváte na tom, že ten kód je vlastně úplně v pořádku.

21.11.2018 11:21 SkákalPřesOheňAžSiPropálilMokasíny | skóre: 29 | blog:
Rozbalit Rozbalit vše Re: Sysinternals také na Linuxu
Ten fragment kódu je pokud vím idiom pro ošetření chybového návratového kódu.
Ano a jako takový je ten idiom v pořádku. Nicméně pokud jsi nucen vložit tento idiom za téměř každou řádku užitečného kódu v té funkci, je to celkem slušná indikace, že je něco špatně.

Pokud tohle nevidíš, myslim si, že nemá smysl řešit konkrétní alternativní kód. Navíc tak, jak jsi to položil, můžeš vždycky na jakýkoli konkrétní kód s kterým kdokoli přijde namítnout, že elegance kódu je subjektivní, tudíž to nic nedokazuje. Z tohohle důvodu neočekávám, že by se kdokoli z diskutujících babral z psaním kódu, vzhledem k tomu, že z toho nekouká žádný užitek.
21.11.2018 11:48 Filip Jirsák | skóre: 67 | blog: Fa & Bi
Rozbalit Rozbalit vše Re: Sysinternals také na Linuxu
Já souhlasím s tím, že je něco špatně, také jsem to napsal – ukazuje to, proč se do novějších programovacích jazyků často zavádí koncept výjimek (nebo něco podobného), který přesně tenhle problém řeší. Že se kontroluje návratový kód každé funkce, která může skončit chybou, to není špatně – právě naopak, tak by to mělo být vždy. Že ta reakce na chybu bude v jednom úseku kódu velmi podobná, to je normální. Takže zbývá možnost ten společný kód vytknout a opakovaně ho akorát volat. K tomu tady asi všichni směřují, ale tam pak velmi záleží na konkrétním kódu, protože takovéhle zvýšení abstrakce kódu může snadno zhoršit jeho srozumitelnost. Mimochodem, přesně tohle dělají v jiných jazycích ty výjimky – ten přeložený kód je nakonec stejně složitý, často dokonce ještě složitější, ale zápis v daném jazyce je mnohem stručnější a přehlednější.

Samozřejmě je také možné změnit logiku kódu tak, aby to ošetření chybových stavů nemuselo být za každým řádkem výkonného kódu, ovšem to také nepovažuju za šťastné řešení, protože se tím logika programu skrývá.

A nebo jsou možná nějaká elegantní řešení, která neskrývají ani logiku programu, ani ošetření chyb – mne takové řešení nenapadá (což nic neznamená), právě proto bych rád takové řešení viděl, pokud ho někdo má. Bohužel neustálé opakování, že takových řešení je samozřejmě spousta a každý to musí vidět, přitom tu je ale uvedený jediný příklad, mne úplně nepřesvědčuje o tom, že zdejší diskutéři tak jednoznačně lepší řešení nemají.

Že se budeme dohadovat o tom, jaké má které řešení přednosti a jaké nedostatky, to je možné, ale to už je holt riziko diskuse.

Mimochodem, je tu několik komentářů, jak je něco evidentně a jednoznačně špatně, ale v žádném z těch komentářů není napsáno, co přesně je špatně – a ty různé náznaky směřují každý jiným směrem. Někdo psal, že špatně je opakování (v každém kódu se toho ale opakuje spousta), vy píšete, že špatně je nutnost ošetření chyby za každým výkonným řádkem kódu – což už je mnohem lepší výtka, ale k tomu, že je to jednoznačně špatně, to má ještě daleko. Už to, že názory na to, co je vlastně špatně, jsou tak rozdílné, je celkem slušná indikace, že to s tím „jednoznačně špatně“ není až tak jednoduché, že ten kód je „jednoznačně špatně“ jen na první pohled, a když se nad tím člověk zkusí zamyslet, možná zjistí, že jednoznačně lepší řešení není až tak snadné najít.
21.11.2018 14:15 SkákalPřesOheňAžSiPropálilMokasíny | skóre: 29 | blog:
Rozbalit Rozbalit vše Re: Sysinternals také na Linuxu
Mimochodem, je tu několik komentářů, jak je něco evidentně a jednoznačně špatně, ale v žádném z těch komentářů není napsáno, co přesně je špatně – a ty různé náznaky směřují každý jiným směrem.
Protože je toho špatně vícero a každému vadí něco trochu jiného? A taky protože je možné se o tom bavit na různých úrovních, tj. parsování /proc/pid/stat konkrétně nebo nějakého podobného textu obecně nebo obecně error handling, atd., je to potenciálně velmi široké téma.

Začal bych dokumentací, která specifikuje scanf flagy pro parsování jednotlivých sloupců a dokonce už tady i někdo poslal celkem rozumně vypadající nástin kódu, což jsi nezaznamenal nebo vyignoroval, nevim.

Jinak to, že spousta lidí má čas napsat "to je ale ošklivý kód", ale už nemá čas/chuť vymýšlet řešení problému, který 1. se jich netýká, 2. je už dávno vyřešen někde jinde a 3. chce ho po nich Filip Jirsák se svým přístupem k diskutujícím, mi nepřijde naprosto nijak divné a nijak to neimplikuje, že to řešení neexistuje nebo že tady je nějaká záhada/detektivka, jakou z toho děláš.

Jestli tě to fakt tak zajímá, tak si projdi tu dokumentaci a třeba zdroják jiných utilit, které tohle řeší, třeba najdeš něco zajímavého. Mně se během psaní komentáře dokompiluje projekt, což je jediný důvod, proč tady teď komentuju a víc tomu nedám ani sekundu a ostatním doporučuju to samé.
21.11.2018 15:33 Filip Jirsák | skóre: 67 | blog: Fa & Bi
Rozbalit Rozbalit vše Re: Sysinternals také na Linuxu
Protože je toho špatně vícero a každému vadí něco trochu jiného?
Pokud každému vadí něco jiného, není náhodou možné, že jiné věci zase považuje za správné – a kdyby je někdo jiný opravil, považoval by to za zhoršení? Neměl by si toho náhodou být programátor vědom, že často je to jen otázka vkusu – a že tedy psát obecné komentáře „to musí každý vidět, jak je to špatně“, je poněkud hloupé?
je to potenciálně velmi široké téma
Souhlasím. Je to široké téma, každý může vidět problémy někde jinde, tudíž obecně ten kód odsoudit, jak je to špatně napsané, je póza ale ne konstruktivní příspěvek do debaty.
Začal bych dokumentací, která specifikuje scanf flagy pro parsování jednotlivých sloupců
Pokud vám scanf vyhovuje pro parsování těch dat. Co když je ve vedlejším souboru parser jiného formátu, na který už scanf nestačí? Je pak lepší jednou použít scanf a podruhé strto* funkce, nebo je lepší to sjednotit a všude použít stejný princip?
dokonce už tady i někdo poslal celkem rozumně vypadající nástin kódu, což jsi nezaznamenal nebo vyignoroval, nevim
Ano jedno, ani druhé, ale tohle:
Já tady vidím jediný příspěvek s kódem, a autora toho kódu oceňuji, že jako jediný našel odvahu jít s kůží na trh. Přestože si nemyslím, že by jeho kód byl lepší nebo horší – je prostě jen jiný, má jiné nedostatky a jiné přednosti.
že tady je nějaká záhada/detektivka, jakou z toho děláš
Já tu z toho žádnou záhadu nebo detektivku nedělám. Pouze mi připadalo zajímavé, kolik lidí si musí kopnout do autora kódu, kterému vůbec nerozumí, vůbec netuší, jak by měl vypadat, jenom někde zaslechli, že je prý chyba, když se ve zdrojovém kódu něco opakuje.
21.11.2018 17:52 Michal Kubeček | skóre: 71 | Luštěnice
Rozbalit Rozbalit vše Re: Sysinternals také na Linuxu
Pokud každému vadí něco jiného, není náhodou možné, že jiné věci zase považuje za správné – a kdyby je někdo jiný opravil, považoval by to za zhoršení?

Tak se schválně zeptám: kdo další si ještě myslí, že parsovat řádek s 49 čísly oddělenými mezerami tímto rukodělným způsobem je v pořádku?

Přestože si nemyslím, že by jeho kód byl lepší nebo horší – je prostě jen jiný, má jiné nedostatky a jiné přednosti.

Jestli to opravdu vidíte takhle, tak se asi opravdu nemáme o čem bavit, protože každý žijeme v jiné realitě.

Pouze mi připadalo zajímavé, kolik lidí si musí kopnout do autora kódu, kterému vůbec nerozumí

1. Kromě asi dvou přitroublých výkřiků, které nikdo nebral vážně, nikdo nekopal do autora, ale to toho, jak je ta funkce napsaná. To je dost zásadní rozdíl. 2. Jak jste přišel na to, že tomu kódu "vůbec nerozumíme"?

21.11.2018 18:13 Filip Jirsák | skóre: 67 | blog: Fa & Bi
Rozbalit Rozbalit vše Re: Sysinternals také na Linuxu
Tak se schválně zeptám: kdo další si ještě myslí, že parsovat řádek s 49 čísly oddělenými mezerami tímto rukodělným způsobem je v pořádku?
Neřekl bych, že jediný účel té aplikace je parsovat řádek se 49 čísly. Díval se někdo na další zdrojáky? Jestli se v nich třeba nevyskytují parsery napsané stejným způsobem?
Jak jste přišel na to, že tomu kódu "vůbec nerozumíme"?
Nějak vás nevidím mezi autory komentářů, které zde byly před tím, než jsem napsal svůj první komentář v této diskusi. Komentáře, na které jsem reagoval, převážně opakovaly „nevím, co co tam jde, ale vidím tam opakující se podobné bloky kódu, a někde jsem zaslechl, že je to prý prasárna“.
21.11.2018 18:40 Michal Kubeček | skóre: 71 | Luštěnice
Rozbalit Rozbalit vše Re: Sysinternals také na Linuxu
Díval se někdo na další zdrojáky? Jestli se v nich třeba nevyskytují parsery napsané stejným způsobem?

V čem by to pomohlo? Vždyť to by bylo ještě horší, než kdyby tohle byl jediný náhodný úlet.

Podívat se vedle by dávalo smysl, kdyby se tu implementovala zdánlivě zbytečně obecná parsovací funkce, když zrovna tady by stačila jednodušší. Pak by mělo smysl zkontrolovat, jestli se někde jinde využívají i ty další možnosti. Ale tohle není ten případ. Tady je neprakticky, nepřehledně a neudržovatelně napsaný kus kódu, který je izolovaný a na nic jiného nenavazuje a ani navazovat nemůže.

21.11.2018 19:34 Filip Jirsák | skóre: 67 | blog: Fa & Bi
Rozbalit Rozbalit vše Re: Sysinternals také na Linuxu
Představte si, že máte vedle sebe třeba osm parserů, které by pro parsování vstupu používaly sérii strto* funkcí, protože by ty formáty byly sice jednoduché, ale už dost složité na to, aby se daly rozparsovat jedním voláním sscanf. A teď vám k tomu přibyde devátý formát, který se shodou náhod zrovna dá rozparsovat jením voláním sscanf. Čemu dáte přednost – tomu, aby ten jeden parser vypadal úplně jinak než ty ostatní, ale byl hezčí, a nebo tomu, aby všechny ty parsery používaly stejné konstrukce?
21.11.2018 20:41 Michal Kubeček | skóre: 71 | Luštěnice
Rozbalit Rozbalit vše Re: Sysinternals také na Linuxu
To je zcela hypotetická otázka. Mít vedle sebe osm takhle zbastlených parserů je prostě od základu špatně (on i ten jeden je špatně), takže nemá smysl bádat nad tím, jestli bych i devátý zbastlil stejně nebo trochu jinak.
22.11.2018 08:56 SkákalPřesOheňAžSiPropálilMokasíny | skóre: 29 | blog:
Rozbalit Rozbalit vše Re: Sysinternals také na Linuxu
Pokud vám scanf vyhovuje pro parsování těch dat. Co když je ve vedlejším souboru parser jiného formátu, na který už scanf nestačí? Je pak lepší jednou použít scanf a podruhé strto* funkce, nebo je lepší to sjednotit a všude použít stejný princip?

(...)

Přestože si nemyslím, že by jeho kód byl lepší nebo horší – je prostě jen jiný, má jiné nedostatky a jiné přednosti.
Ano, tohle je přesně důvod, proč nemělo/nemá smysl psát ti tady jakékoli příklady alternativní verze... A pak kdo tady pózuje...
Pouze mi připadalo zajímavé, kolik lidí si musí kopnout do autora kódu, kterému vůbec nerozumí, vůbec netuší, jak by měl vypadat, jenom někde zaslechli, že je prý chyba, když se ve zdrojovém kódu něco opakuje.
Smysl toho kódu je zjevný a ano obecně kód se zbytečně nízkým SNR je chyba, na tom nění co řešit, není to detektivka.
22.11.2018 13:16 Filip Jirsák | skóre: 67 | blog: Fa & Bi
Rozbalit Rozbalit vše Re: Sysinternals také na Linuxu
Jasně, patent na to, který kód je dobrý a který špatný, máte vy, a napsat do diskuse jiný názor nemá smysl.

Opakující se podobný kód obecně obvykle bývá chybou. Klíčové je ovšem to slovíčko „obvykle“, ze kterého plyne, že to tak není vždy. Je hloupé něco odsuzovat jen na základě poučky, která neplatí vždy. To byl důvod té mé první reakce. Ale nebojte, už s tou drzostí, že píšu něco, s čím nesouhlasíte, končím.
22.11.2018 13:34 SkákalPřesOheňAžSiPropálilMokasíny | skóre: 29 | blog:
Rozbalit Rozbalit vše Re: Sysinternals také na Linuxu
To sis ale vymyslel ty, že tady někdo něco odsuzuje jen na základě poučky.
Josef Kufner avatar 22.11.2018 16:47 Josef Kufner | skóre: 69
Rozbalit Rozbalit vše Re: Sysinternals také na Linuxu
Řešíš ptákoviny. Že je/bude vedle možná nějaký jiný soubor ještě neznamená, že je špatné mít jednoduchý a jednoúčelový parser na tenhle soubor. Zbytečně obecným přístupem komplikuješ a prodražuješ jednoduché řešení aktuálního problému. Zjevně je scanf dokumentací doporučeným způsobem parsování a z pohledu dopředné kompatibility bych to napřed nasekal na řádky a ujistil se, že přebývající čísla budu ignorovat a na chybějících to nepadne na hubu. Že takový parser bude nutné psát pro každý soubor znovu není nijak špatné, neboť to zas bude primitivní obal na scanf a možná se u třetího parseru povede extrahovat společné části a zadefinovat jednoduchý framework.

Obava, že použití maker špatné, protože by tam někde mohlo být datum, je stejně špatný přístup. Viz YAGNI. Prostě se to udělá s jedním makrem pro aktuální problém a když se tam možná někdy objeví něco nepasujícího, udělá se druhé makro, které se na vhodném místě zavolá místo toho prvního. Efektivně se tím definuje primitivní DSL. Tak jako tak je to lepší než hromada opakujícího se kódu, který se blbě kontroluje.
Hello world ! Segmentation fault (core dumped)
8.11.2018 16:20 AlYoSHA
Rozbalit Rozbalit vše Re: Sysinternals také na Linuxu
Asi outsourcing v Kazachstane. :-)
8.11.2018 14:47 lazywriter
Rozbalit Rozbalit vše Re: Sysinternals také na Linuxu
Koukám, že to Microsoft s tím "Embrace, extend, and extinguish" myslí vážně.
8.11.2018 13:21 Zdenek 'Mst. Spider' Sedlak | skóre: 38 | blog: xMstSpider
Rozbalit Rozbalit vše Re: Sysinternals také na Linuxu
:-D

sounds like nmon http://nmon.sourceforge.net/pmwiki.php

#1 thing to remember when coding for linux / unix : ==> it was probably already done. <==
9.11.2018 11:37 Onanym
Rozbalit Rozbalit vše Re: Sysinternals také na Linuxu
Tak ještě chvíli a přerod GNU/Linux v SystemD/Windows bude dokonán

Založit nové vláknoNahoru


ISSN 1214-1267   www.czech-server.cz
© 1999-2015 Nitemedia s. r. o. Všechna práva vyhrazena.