Názory k článku
Linus přidal tabulátory do Kconfig

Faktický monopol je to tak jako tak. Ale ten druhý případ není problém do té doby, pokud to není problém pro další věci a pokud není problém, aby někdo další vstoupil na trh. Ostatně často je větší problém zneužití dominantního postavení na trhu, nikoliv monopol, což lidé často pletou dohromady.

Jakákoliv specifikace, kde záleží na počtu nebo druhu netisknutelných znaků, je špatná. Mezera má být mezera bez ohledu na to, čím a kolika znaky je vycpaná. Indentování nemá mít žádný jiný význam než pohledový.

Python vas miluje :D

A my ostatní milujeme Python. :D Fakt nejhorší je když si přes nano potřebuju něco upravit v py scriptu a pak už dostávám jen "Inconsistent use of Tabs and Spaces".

To je hezká teorie, ale třeba u YAMLu nebo Markdownu ta významovost počtu bílých znaků dává smysl. Pokud chceme uživateli umožnit něco editovat jako čistý text a zároveň ho nechceme nutit párovat otevírací a uzavírací závorky, je použití bílých znaků rozumné řešení.

Já bych dal přednost XML a jeho podpoře všude, ale svět se (celkem pochopitelně) vydal jinou cestou a ty významové bílé znaky jsou druhé nejlepší řešení.

U Pythonu jsem se s tím nesmířil, myslím si, že program/skript má psát někdo a v něčem, kde to párování závorek zvládne. Když se špatně zformátuje YAML nebo Markdown, změní to význam, ale nic vážného se nestane. Když se špatně zformátuje Python, změní se význam kódu, vůbec se na to nemusí přijít a může to mít vážné dopady.

Nepotrebuji aby se menili zdrojaky - ale aby bylo jasno, ze jak se chovat k WS v danem formatu. Uplne by stacilo zminit napr tohle:

Whitespace is composed from SPACEs and TABs and can appear before, in or after any line, yet we advice to adhere to code styling rules defined in docs/neco.txt

A ted dotaz pro seniory: je LF v KConfigu tedy whitespace, anebo neni - podle me jak kde (coz je zas nedostatecna dokumentace v kconfig-language.rst ), protoze uvadi ze radek je uvozen keywordem, takze se implikuje ze na radku se nachazi jen jeden semanticky element, byt by jich tam mohlo byt vice kdyz se LF vypusti. Vice LF za sebou je nejspis akceptovatelne, ale neuvadi se zda mezi elementy muze byt extra LF.

Tohle je nejvetsi potiz - proste specifikace NENI UPLNA, at si rika kdo chce. Jedna strana udelala urcite predpoklady a nic nerekla, druha strana to podle toho parsuje protoze to interpretuje jednim zpusobem.

Takova ticha domacnost, to fakt chces.. u neceho, co pohani pulku ekonomie sveta :D

Může být.

A teď si shrňme co se stalo:
- specifikace nebyla úplná
- nějaké předpoklady blablabla
- Steven Rostedt chybně předpokládal, že tam mají být mezery
- Linus mu tam svérázným způsobem naznačil, že opravuje chybu na špatném místě

Dotaz jedna: opravdu máte problém chápat tak nějak implicitně, že space a tab jsou whitespace v každém případě už hodně dlouho? Autor té specifikace holt předpokládal, že ji nepíše pro malé děti.

Dotaz dva: opravdu máte pocit, že konkrétně KConfig pohání půlku ekonomiky (ne ekonomie, btw, tu pohání spíš Microsoft Word a Excel, ale to je jedno) světa?

Pri psani specifikace nemate neco "predpokladat", ale specifikovat.

Aktualni specifikace neobsahuje jediny vyskyt slova whitespace, proste to neresi.

A dalsi vec co neresi - je kodovani. Mame predpokladat, ze je to UTF-8 (jako kazdy "normalni" soubor, nebo je to omezeno na US-ASCII ?

Ohledne TABu je zde nejasnost, zda v textovych polich se ma zachovat ci nikoliv - pokud by to bylo jedno, tak at si kazdy prevede WS+ na 1 mezeru, ale mozna by nektere help vysvetlivky radi zachovali formatovani.

Ad UTF jsem myslel že proto existuje BOM jinak to beru jako ANSI

BOM jsem videl naposledy u UTF-16 pod windows (protoze vsechno je ascii, az na .inf a jeho .inx zdrojak, kdyz pisete ovladace).

Dalo to zabrat aby to git bral jako text a delal nad tim diff spravne.. ale dnes uz to je resitelne.

U UTF-8 ten BOM neni vyzadovan ani doporucovan:

The Unicode Standard permits the BOM in UTF-8, but does not require or recommend its use.

Je to z duvodu zpetne kompatibility s ascii, protoze par divnoznaku v prubehu textu je lepsi, nez par divnoznaku na zacatku souboru :)

BOM slouží pro specifikaci endianity. Pro UTF-8 už to naštěstí skoro nikdo nepoužívá. Není mi jasné, k čemu je dobré o něčem předpokládat, že je to ANSI kódování – předpokládat UTF-8 dává daleko větší smysl.

Pri psani specifikace nemate neco "predpokladat", ale specifikovat.
Z takovýchto nepochopení základních věcí pak vznikají ty nepřesné specifikace. Každá specifikace předpokládá velkou spoustu věcí. Jinak by to nešlo. Důležité je si to uvědomit, uvědomit si, co předpokládáte, a co naopak není vhodné předpokládat a je dobré to napsat do specifikace.

Mylite se. Predpokladani je cesta do pekel a existuje na to mnoho dukazu z praxe.

Viz problem binarnich predpon ve Windowsu vs dekadickych na discich (nebo kombinaci na disketach). Zde evidentne chybuje Windows, ktery neni schopen se prizpusobit modernimu standardu, ktery by uvedl spor na prave misto.

Zatimco vyrobci disku jako mentalove musi psat na kazdy disk, ze Si predpona M, znamena 1000000, coz snad vi i decka na zakladce.

Nebo takove drazsi predpokladani, kdy si spletete stopy a metry, a druzice se vam roztristi o povrch.

Jooo.. jen si predpokladejte dale.. a budte to delat do doby, nez se vam neco nestane.

Jasně, takže ve specifikaci nebudete předpokládat, že se používá dvojková soustava, nebudete předpokládat osmibitový bajt, nebudete předpokládat znalost významu anglických slov, nebudete předpokládat znalost booleovské algebry. To byste nikdy žádnou specifikaci nenapsal.

Cesta do pekel je něco předpokládat a nebýt si toho vědom.

Binární předpony Windows ani popletení stop a metrů nebyl problém předpokladů.

Já, stejně jako všichni ostatní, kdo reálně nějaké specifikace dělají, budeme dál předpokládat. Cesta do pekel je váš přístup, kdy se tváříte, že nic nepředpokládáte – jenže ve skutečnosti máte spoustu skrytých předpokldaů, a do těch skrytých předpokladů se vám pak schovají i ty předpoklady, které by neměly být skryté.

Tak nam pane chytrej reknete, je Kconfig v UTF8 nebo v ASCII - co predpokladate v roce 2024 ?

Vzhledem k tomu, že každý patch musí projít scripts/checkpat­ch.pl, tak předpokládám https://github.com/torvalds/linux/blob/ed30a4a51bb196781c8058073ea720133a65596f/scripts/checkpatch.pl#L558-L571

Nerozporovaný názor z r. 2007 https://lkml.indiana.edu/hypermail/linux/kernel/0706.0/1402.html

Realita je, ze UTF8 funguje v Kconfigu velice spatne:

- config SYMBOL ... symbol nemuze byt utf8, parser z jadra haze chybu unsupported character na kazdy ne-ascii byte, tahle cast mozna jde do kompilace jako define, ale GCC mi unicode defines skrze -D a #if zpracuje v poradku.

- ve zbytku textu (pojmenovani polozky a napovedneho textu) parser z jadra akceptuje UTF8, ale tento text nefunguje spravne v make nconfig a menuconfig, funguje v make config a xconfig

Navic ty proklete TABy jako whitespace zde fakt nefunguji konzistentne - propisuji se verbatim do vystupu v nconfig/menuconfig, naopak se v xconfig redukuji na jednu mezeru.

Hosi to maj slusne rozbity... pritom by stacilo mit tu specifikaci uplnou :-)

pritom by stacilo mit tu specifikaci uplnou :-)
Vy jste stále nepochopil, že nelze mít úplnou specifikaci?

Tak byste tam napsal, že je to v kódování ASCII. Byla by taková specifikace úplná? No nebyla, protože tam nemáte definované, co je to kódování ASCII. Tak byste odkázal na definici ASCII. Bylo by to pak úplné? Opět nebylo, protože byste neměl definován ten odkaz (třeba instituci, která definici vydala; ani rok, ve kterém to vydala). Neměl byste ani úplnou definici ASCII.

Tím, že požadujete úplnou specifikaci, ukazujete, že jste na tom co do schopnosti něco specifikovat nejméně stejně špatně, jako ten, kdo nenapsal, zda se používají mezery, tabulátory nebo oboje a jaké se používá kódování.

Ale jde, ale vy zas delate blbce ze sebe, ze odmitate porozumet tomu, co se vlastne pozaduje od specifikace. Nikdo by nerozporoval US-ASCII a ani UTF-8 (kor kdyby bylo definovano uplne - tj. with/without/op­tional BOM).

Zacneme tim, ze se tam doplni kodovani, a pokud je "kodovani" kontextove specificke, coz podle mych testu je, tak by bylo vhodne doplnit regularni vyrazy pro omezujici sadu. Napr pro onen zastupny vyraz "symbol", nachazejici se po klicovem slove "config".

Specifikace, jak je momentalne sepsana je opravdu velice marna. Pokud si myslite ze neni, tak sem s regexem, pro config symbol - idealne ze specifikace. Ukazte ze jste chlap, a ne tluchuba internetova.

Uz jenom to, ze pochybujete o necem, jako ze kdo a jak definoval US-ASCII, vypovida o vasi neprofesionalite a jako ajtak by jste letel z jakehokoliv projektu v tom momente co vypustite takovou cicovinu.

Takze znova - jestli nekdo definuje vlastni format/jazyk - tak to ma udelat standardnim zpusobem jak se textove zapsane jazyky definuji (EBNF), a ne nejakym obskurnim free-form markup dokumentem, kde se ebnf vyraziva objevuji jenom sporadicky.

OK, takže specifikace je úplná, pokud RDa prohlásí, že je úplná.

US-ASCII je nestandardní název pro ASCII. Hlavně že lpíte na přesných definicích. Nepsal jsem kdo a jak, ale kdo a kdy. A když napíšu, že byl ASCII standard v poslední verzi vydán v roce 1986, předpokládám, že každý ví, že je to letopočet gregoriánského kalendáře. Jenže vy jste psal, že specifikace nemůže nic předpokládat. Takže budu muset nadefinovat i ten gregoriánský kalendář.

Mimochodem, když píšete, že by nikdo nerozporoval ASCII nebo UTF-8 – to byste ale měl rozporovat. Pokud chcete úplnou specifikaci, musíte specifikovat, jak naložit s verzemi ASCII a UTF-8. Má to být nějaká konkrétní verze? Nebo vždy nejnovější verze?

Ale vy jste zjevně stále nepochopil, že já neobhajuji nedostatečnou specifikaci formátu Kconfig, jenom se vám marně snažím vysvětlit, že váš požadavek na specifikaci, která nebude mít žádné předpoklady, je úplně mimo mísu. To není přehnaný požadavek, to je úplné nepochopení specifikací.

Jste porad vedle a jenom se placate ve stejnych mentalnich s*ackach. Proberte se clovece a vyhledejte mozna i lekare, jestli na necem jedete. Bavime se o KConfigu - ze vy nedokazete udrzet myslenku a fantazirujete pate pres devate je zcela vas osobni problem a deviace. Ostatni se dokazou bavit k veci. A tou veci je zde KConfig.

Pry nestandardni... to si vyrikejte s IANA, proc to takhle vede. Asi maji malinkou potrebu se odlisit od ITU/ISO odvozenin, kterym lidem taky rikaj "ascii", ale nejsou jimi - napr. ty, ktere nahrazuji dolar.. a dolar = amerika = US.. chapete tu souvislost? :D

Pokud se vydani normy nezminuje, ma se za to, ze se bere platna v dobe definice dila ktere na nej odkazuje/je-navazano, neni-li uvedeno jinak. Takze pokud Kconfig vznikl s linuxem v 1991, melo se jednat o US-ASCII podle IANA = ANSI X3.4-1986, pokud pozdeji, existuje revize ANSI X3.4-1986 R1992, nebo R1997 Nicmene konkretni revize zde nebude hrat vyznamovou roli protoze se upresnovali jenom ridici kody, ktere KConfig nevyuziva. Ale tim, ze nikdo nerika ze je to jakykoliv ASCII, je tato otazka bezpredmetna.

A taky ze existuje jedina verze UTF-8 specikace, ktera ma pouze implementacni podvarianty podle pritomnosti BOM, a tohle jsem jiz zminoval ze je potreba uvest take. Nevidel jsem v zivote dva utf8 nastroje, ktere by si nerozumeli a jejich opakovane pouziti by ztracelo ci poskozovalo data. Proste UTF8 ma nespornou a uplnou specifikaci v tomto ohledu.

To, ze vice norem definuje to same, je bezne - a zde to delaji vsichni stejne, pokud se to jmenuje stejne, tak to je jenom k prospechu veci. Dava vam vybrat si, ktere zneni standardu si poridite - prosta moznost konkurence v standardizaci - proste si vyberete zdroj, ktery popisuje veci uplneji a beze spornych bodu. Coz je primarni ucel standardizace - ze se chcete vyhnout nedorozumenim, ze nekdo myslel a nedomyslel, co se stane, kdyz to nebude cerne na bilem.

Napsal jste tohle:

Pri psani specifikace nemate neco "predpokladat", ale specifikovat.
To je obecné tvrzení. Pokud jste chtěl napsat „Při psaní specifikace Kconfig nemáte něco ‚předpokládat‘, ale specifikovat,“ měl jste to napsat.

Pry nestandardni... to si vyrikejte s IANA, proc to takhle vede.
Spíš je otázka, proč jste si vybrala IANA.

protoze se upresnovali jenom ridici kody, ktere KConfig nevyuziva
Ale, další předpoklad.

A taky ze existuje jedina verze UTF-8 specikace, ktera ma pouze implementacni podvarianty podle pritomnosti BOM, a tohle jsem jiz zminoval ze je potreba uvest take. Nevidel jsem v zivote dva utf8 nastroje, ktere by si nerozumeli a jejich opakovane pouziti by ztracelo ci poskozovalo data. Proste UTF8 ma nespornou a uplnou specifikaci v tomto ohledu.
Holt jste toho v životě ještě viděl málo. Unicode se v čase vyvíjí, aktuálně máme verzi 15.1. To, co je v jedné verzi neplatná sekvence bajtů, je v další verzi platný znak. Takže můžete jedním programem vygenerovat platný text v kódování UTF-8, který ovšem jiný program načítající správně UTF-8 odmítne zpracovat kvůli neplatné sekvenci bajtů, která nereprezentuje žádný Unicode znak.

Evidentně jste ale stále nepochopil, že problém je v tom vašem úvodním tvrzení, že při psaní specifikace nemáte nic předpokládat – které je prostě nesmyslné. Samotný lidský jazyk je založen na předpokladech. Původně to vypadalo, že jste to jen napsal nepřesně, že jste příliš zevšeobecnil. Ale ukázalo se, že vůbec nechápete, co to standardy normy a specifikace jsou.

1/ trvam na tom, ze se maji veci definovat dostatecne, napr. pomoci EBNF, ktera ve specifikaci chybi a krome WS by ujasnila mnoho spornych bodu. Dale chybi kodovani souboru - a o tom se tady uz zminuji ponekolikate. Mate to cist cely a nevytrhavat veci z kontextu.

2/ ja si vybral iana -> ansi -> ascii, protoze to do sebe zapada a jeden odkazuje na druhy. A vy jste si vybral ktery standard a proc? Jenom trousite nesmyslne reakce, ale NIC jste krome sve hlouposti nepredvedl. Porad cekam na upresneni, nekolika dotazu ke KConfigu - co je "symbol"? Jake kodovani? Jaky vyznam ma WS?

3/ Jestli mate problem rozlisovat mezi UTF-8 (jakozto mechanizmem pro mapovani vice nez 7-bitovych hodnot na byte sekvenci), a Unicode (jakozto definici znaku vsech abeced, ktere se prubezne doplnuje), tak je zcela marne se s vami bavit.

Muzete odpovedet neco konkretne, bez meta-onanie? Anebo to uzavreme s tim, ze zadny hmatatelny prinos vase prispevky uz roky neprinasi.

Nastesti pocitace nepracuji s lidskym jazykem a predpoklady (tedy az na to lamersky GPT), ale maji pevne definovanou strukturu - takze Filipku, jakkoliv se snazis tady exhibovat nad vhodnosti specifikaci pofidernich kvalit, tak to fakt neni ta spravna cesta. Takove rozjimani si nech na pivo v hospode - pro nas, co s pocitaci pracujeme, jsou jednoznacne specifikace nutnym zakladem. Tecka.

Ad 1) Já vám to neberu. Akorát že tohle není předmětem naší diskuse.

Ad 2) Žádné iana, ansi, ascii neexistuje. K dostatečnému definování patří i to používat správné názvy, zkratky apod. A to včetně velikosti písmen. „ascii“ není totéž jako „ASCII“.

Ad 3) Pořád máte nějaké špatné předpoklady. Já nemám problém to rozlišovat. Akorát vím, že UTF-8 kóduje Unicode znaky, takže to, zda něco je či není platná UTF-8 sekvence závisí na verzi Unicode. Zkuste si to představit třeba na ASCII. Když budete číst soubor, který má být v ASCII, a narazíte tam na bajt s nastaveným nejvyšším bitem, bude to podle vás v pohodě a správně ten bajt zpracujete?

Nastesti pocitace nepracuji s lidskym jazykem
My se ale bavíme o specifikacích. A ty jsou psány lidským jazykem.

Ale chápu, proč se snažíte od lidských jazyků dostat co nejdál. Protože porozumění lidským jazykům není vaše silná stránka.

pro nas, co s pocitaci pracujeme, jsou jednoznacne specifikace nutnym zakladem
Jenomže „jednoznačná specifikace“ je něco jiného, než „specifikace bez jakýchkoli předpokladů“.

Jestli je soubor v US-ASCII, tak zadny nejvyssi bit v bajtu nastaven nebude.
Je to 7-bitove kodovani a do sedmi bitu ulozite hodnotu 0-127, nic jineho.

Vas pozadavek nastavovani osmeho bitu kdyz jich existuje sedum, je jako chtit po integer bajtu aby enkodoval 0..255 s nejakou desetinnou presnosti (0,1 ^ n; n>=1)

UTF-8 koduje cisla 0..0x10FFFF - nezavisle na verzi Unicode, do 1 az 4 bajtu.

Vse co neni definovany znak je obligatni ctverecek, ale neznamena to, ze takove znaky se napr pri copy/paste zahodi v compliant sw. A taky to neznamena, ze dokument ulozeny v novsi verzi unicode by nesel otevrit nebo snad shazoval starsi sw.

Zda je neco platna, neplatna nebo nevhodna sekvence, urcuje samotna definice UTF-8. A neplatne sekvence (ktere vubec nesouvisi s tim, ze do unicode se pridavaji dalsi znaky) se mapuji na error placeholdery podle doporuceni ve standardu.. ne dle libovule tvurce parseru.

Pokud se vam neco rozbilo, tak to byva treba spatnym prepokladem podobneho amatera jako jste vy, co bral ze relevantni Unicode pro ne ma pouze 64K znaku a dekodoval pouze 1-3 byte UTF-8 sekvence na unsigned short (16bit). Ale 4-byte kodovani na >64K tam bylo od pocatku. Na tohle trpi treba uzivatele mysql, co zvolili utf8mb3.

Doporučuju někdy si nějaký soubor otevřít a podívat se, kolik bitů tam má bajt. UTF-8 nekóduje čísla, ale validní Unicode code pointy. Nastavený nejvyšší (osmý) bit v ASCII kódovaném souboru je stejný případ, jako neexistující code point zakódovaný v UTF-8.

RDa: Vaše otázka nijak nesouvisí s mým komentářem.