Lidi dělají divné věci. Například spouští Linux v Excelu. Využít je emulátor RISC-V mini-rv32ima sestavený jako knihovna DLL, která je volaná z makra VBA (Visual Basic for Applications).
Revolut nabídne neomezený mobilní tarif za 12,50 eur (312 Kč). Aktuálně startuje ve Velké Británii a Německu.
Společnost Amazon miliardáře Jeffa Bezose vypustila na oběžnou dráhu první várku družic svého projektu Kuiper, který má z vesmíru poskytovat vysokorychlostní internetové připojení po celém světě a snažit se konkurovat nyní dominantnímu Starlinku nejbohatšího muže planety Elona Muska.
Poslední aktualizací začal model GPT-4o uživatelům příliš podlézat. OpenAI jej tak vrátila k předchozí verzi.
Google Chrome 136 byl prohlášen za stabilní. Nejnovější stabilní verze 136.0.7103.59 přináší řadu novinek z hlediska uživatelů i vývojářů. Podrobný přehled v poznámkách k vydání. Opraveno bylo 8 bezpečnostních chyb. Vylepšeny byly také nástroje pro vývojáře.
Homebrew (Wikipedie), správce balíčků pro macOS a od verze 2.0.0 také pro Linux, byl vydán ve verzi 4.5.0. Na stránce Homebrew Formulae lze procházet seznamem balíčků. K dispozici jsou také různé statistiky.
Byl vydán Mozilla Firefox 138.0. Přehled novinek v poznámkách k vydání a poznámkách k vydání pro vývojáře. Řešeny jsou rovněž bezpečnostní chyby. Nový Firefox 138 je již k dispozici také na Flathubu a Snapcraftu.
Šestnáctý ročník ne-konference jOpenSpace se koná 3. – 5. října 2025 v Hotelu Antoň v Telči. Pro účast je potřeba vyplnit registrační formulář. Ne-konference neznamená, že se organizátorům nechce připravovat program, ale naopak dává prostor všem pozvaným, aby si program sami složili z toho nejzajímavějšího, čím se v poslední době zabývají nebo co je oslovilo. Obsah, který vytvářejí všichni účastníci, se skládá z desetiminutových
… více »Richard Stallman přednáší ve středu 7. května od 16:30 na Technické univerzitě v Liberci o vlivu technologií na svobodu. Přednáška je určená jak odborné tak laické veřejnosti.
14.12.2014 00:35
Josef Kufner | skóre: 70
14.12.2014 12:12
pavlix | skóre: 54
| blog: pavlix
Je to docela nezvyk, vidět vše nahňácané v jednom souboru.Ono to tak asi nezůstane, ten soubor nejspíše rozdělím ve chvíli, kdy se ukáže, že je důvod používat funkcionalitu nejen ve formě skriptu, ale i ve formě knihovny.
Jak velkou podmnožinu systemd to zvládne?Je to work in progress, takže takovou, jaká se naimplementuje, v tomto ohledu se chystám přistupovat k RFE jako k bugreportům, takže dopíšu, co komu bude chybět. Spouštění simple a oneshot služeb je implementovatelné bez problémů včetně všech těch hovadin okolo. Forking jde řešit specifikací pidfile vytvářeného službou (současný stav) nebo možná i nějakým wrapperem. Zatím jsem neřešil notify. Problém je se závislostmi a pořadím, které typicky nejdou přímočaře přeložit, takže očekávám, že je bude muset volající často specifikovat na příkazové řádce, což ještě není implementováno. Zajímá tě ještě něco konkrétního?
14.12.2014 19:34
pavlix | skóre: 54
| blog: pavlix
14.12.2014 23:13
Josef Kufner | skóre: 70
15.12.2014 00:30
pavlix | skóre: 54
| blog: pavlix
15.12.2014 01:02
Josef Kufner | skóre: 70
15.12.2014 01:10
pavlix | skóre: 54
| blog: pavlix
Je to docela nezvyk, vidět vše nahňácané v jednom souboru.Mne naopak prijde v dnesni dobe nelogicky opak. Puvodne vzniklo rozdelovani programu na souboru kvuli modularite (absenci verzovani) a omezeni kompilatoru (ktere mohly zpracovat najednou jen maly soubor). Ale striktne vzato to neni potreba.
15.12.2014 17:31
pavlix | skóre: 54
| blog: pavlix
15.12.2014 17:50
pavlix | skóre: 54
| blog: pavlix
Tak to co jsem napsal je trochu provokativni, protoze vim, ze Franta ma rad Javu.A Pepa má taky rád javu?
i kdyz u konverzniho skriptu se to hodi, ze se nemusi slozite instalovatTak já už mám přidaný
AbcLinuxu.cz
ITBiz.cz
HDmag.cz
AbcPráce.czsetup.py a je fakt, že Python je v tomhle vcelku flexibilní a hledá jak v aktuálním adresáři, tak v systémovém, takže rozdělení nepřinese zásadní komplikace.
Myslel jsem, ze to napsal Franta.. No nevadi, odpovedet muze taky.
Nejsem obhajce toho mit vsechno v jednom souboru (i kdyz u konverzniho skriptu se to hodi, ze se nemusi slozite instalovat), ale javovsky zpusob deleni mi pripada sileny. Jsem zastance toho, ze dobry program by mel byt citelny tak trochu jako knizka, tedy od obalky k obalce (mozna s vynechanim nekterych casti).Tak já si tu tradičně přihřeju polívku s Rustem - viz Crates and Modules. Hlavně ty moduly se mi docela líbí...
15.12.2014 21:24
pavlix | skóre: 54
| blog: pavlix
use) cyklicky, s tím v zásadě nesouvisí. Moduly jsou pouze k tomu, aby sis mohl 1) zdrojáky rozstrkat do hierarchie a 2) řídit viditelnost (ta se v Rustu řeší pouze právě mezi moduly).
Jestli mohou být cyklické závislosti i mezi crates, to už nevim přesně, ale jsem si skoro jistý, že ne.
16.12.2014 00:16
pavlix | skóre: 54
| blog: pavlix
16.12.2014 09:23
pavlix | skóre: 54
| blog: pavlix
V Rustu ve zdrojácích ani nikde nejsou explicitně specifikovány závislosti mezi moduly/soubory.Já jsem to chápal tak, že crate je soubor a modul se vytváří explicitně, takže ve skutečnosti jsou crate, soubor a modul tři různé pojmy. To potom znamená, že Rust neumí postupnou kompilaci jako céčko, že.
Crate je pak celá binárka (program nebo knihovna), takže tam už cyklické závislosti afaik nemůžou bejt.Zajímavé.
takže ve skutečnosti jsou crate, soubor a modul tři různé pojmyPřesně tak. V praxi samozřejmě mít co soubor, to modul, nicméně u větších modulů bude mít smysl je roztáhnout do více souborů...
To potom znamená, že Rust neumí postupnou kompilaci jako céčko, že.To, co jsem popsal, je výchozí chování, kdy ti rustí kompilátor v podstatě poskytne jednoduchý build systém. Jinak má hafo konfigurace, může generovat všechno možné od celých binárek přes jednotlivé .o soubory až po asm nebo ir, takže afaik by to mělo jít použít v nějakém build systému á la C. Koneckonců backendem je LLVM.
16.12.2014 12:39
pavlix | skóre: 54
| blog: pavlix
Popravdě dosud považuju kombinaci make, shellu a autotools za nepřekonanou a rychlost kompilace za naprosto zásadníPopravdě považuju autotools za dílo ďáblovo
jenže jestli to dobře chápu, nemá Rust hlavičkové soubory a tudíž je potřeba při kompilaci vždy parsovat všechny závislosti, aby měl kompilátor k dispozici informace o datových strukturách.To ano, ale vzhledem k tomu, že ten kompilátor je beztak pomalej a žere dost paměti, je to asi celkem detail
Rovněž mi tak chybí rozumné oddělení API, ABI a implementaceTomu moc nerozumim... Ale celkově mi přijde, že se diskuse posunula do roviny "Rust není C", s čímž se nedá než souhlasit...
16.12.2014 16:21
pavlix | skóre: 54
| blog: pavlix
Popravdě považuju autotools za dílo ďáblovoJá za velmi podařené dílo ďáblovo, které není ani v nejmenším, čím nahradit.
To ano, ale vzhledem k tomu, že ten kompilátor je beztak pomalej a žere dost paměti, je to asi celkem detailPrávě naopak, jestliže kompilátor nesází výsledky bleskově, hodí se postupná kompilace jako sůl. Navíc někteří z nás používají ccache, takže umíme využít výsledků kompilace opakovaně i při formálních změnách nebo naopak při kompilaci z čistých zdrojů, což vývojář potřebuje dost často. Na Gentoo navíc výsledek takto optimalizované kompilace můžeš dostat rovnou do systému.
Tomu moc nerozumim... Ale celkově mi přijde, že se diskuse posunula do roviny "Rust není C", s čímž se nedá než souhlasit...Uznávám, že C je na Linuxu co do toolingu a zvyklostí natolik kvalitní ekosystém, že je těžké se mu i kdyby jen přiblížit. Na druhou stranu jsem slyšel Rust prezentovaný jako jazyk pro systémové programování, což v kontextu, kde se pohybuju zastává C, maximálně ještě prokládané Pythonem, který se ovšem prakticky za všech okolností používá právě jako nadstavba nad C. Můžeš mi tedy říct, do jaké oblasti je Rust vhodný, když to podle tebe není ta, kde se používá C?
Já za velmi podařené dílo ďáblovo, které není ani v nejmenším, čím nahradit.CMake, jednoznačně. Ale i některé jiné systémy považuju za furt lepší než autotools...
Právě naopak, jestliže kompilátor nesází výsledky bleskově, hodí se postupná kompilace jako sůl. Navíc někteří z nás používají ccache, takže umíme využít výsledků kompilace opakovaně i při formálních změnách nebo naopak při kompilaci z čistých zdrojů, což vývojář potřebuje dost často.Nevim přesně, co myslíš tou "postupnou kompilací", každopádně použitelný build systém by imho měl umět ccache-like funkcionalitu bez externí berličky. Build systém v rustc (Rust compiler) v základu takovouhle funkcionalitu nemá, je jen jednoduchý. Jinak rustc jako takový používá pro sestavování autotools (z čehož nejsem moc nadšen a taky to buhvíjak dobře nefunguje) a je možné použít ccache, ale jak to přesně mají pořešeno, to nevím. rustc umí na žádost vyplivnout dependency info, takže možná že to je tam použito. Osobně se těším na něco rozumnějšího, např. podpora rustu v CMake by byla fajn (někde na githubu jsem viděl takové pokusy, uvidíme, co z toho bude...).
Můžeš mi tedy říct, do jaké oblasti je Rust vhodný, když to podle tebe není ta, kde se používá C?To jsem neřekl, určitě to je ta, kde se používá C/C++ (víceméně), akorát nemá moc cenu se na něj snažit napasovat věci specifické pro C, jako třeba header files.
16.12.2014 22:58
pavlix | skóre: 54
| blog: pavlix
CMake, jednoznačně.Zkoušel jsem a jednoznačně ne. Je to sice zajímavá alternativa, ale i když odhlédnu od toho, že je v mnoha ohledech zcela zbytečně nekompatibilní, plnohodnotná náhrada to rozhodně není. Ale pokud budeš chtít zdůvodnění, tak to je na delší povídání. S autotools jsem natolik sžitý, že mnohou funkcionalitu používám
Nevim přesně, co myslíš tou "postupnou kompilací", každopádně použitelný build systém by imho měl umět ccache-like funkcionalitu bez externí berličky.To není berlička, ale nástroj, a navíc má mnohem blíž ke kompilátoru než k build systému. Nejjednodušší způsob, jak může build systém něco takového podporovat je právě použít kompilátor přes ccache wrapper.
Jinak rustc jako takový používá pro sestavování autotools (z čehož nejsem moc nadšen a taky to buhvíjak dobře nefunguje)Což ovšem asi nebude chyba autotools, že. Autotools rozhodně mají své rezervy, na které narážím celkem často, a za build systém, který by byl plnohodnotnou náhradou autotools, byl by srozumitelnější, a ještě by řešil ty věci, na které jsem narazil, bych velice ocenil.
a je možné použít ccache, ale jak to přesně mají pořešeno, to nevímJsou dva základní způsoby, jak použít ccache s autotools. Jeden je
./configure CC="ccache gcc", druhý je PATH=$PATH:/usr/lib64/ccache/bin.
To jsem neřekl, určitě to je ta, kde se používá C/C++ (víceméně), akorát nemá moc cenu se na něj snažit napasovat věci specifické pro C, jako třeba header files.Já jsem zase neřekl, že se na něj mají napasovat header files, ale ptal jsem se jak se tam řeší ty věci, které se v C řeší přes header files. Shodit můj dotaz s odkazem, že mi na Rustu vadí, že není C, je dost laciné, vzhledem k tomu, že jsem nic takového ani nenaznačil. Jen na C kromě vlastností samotného jazyka oceňuj to, že kolem něj je tolik nástrojů, zkušeností a best practices, že nenarážíš na nové problémy, které ještě nikomu nestály za řešení. To, že se u Rustu nemám koho zeptat na základní otázky, abych dostal smysluplnou odpověď, tuto výhodu C jenom podtrhuje.
Nejjednodušší způsob, jak může build systém něco takového podporovat je právě použít kompilátor přes ccache wrapper.Pro build systém to určitě jednodušší je, uživatel toho build systému musí nainstalovat si a pochopit další nástroj...
Já jsem zase neřekl, že se na něj mají napasovat header files, ale ptal jsem se jak se tam řeší ty věci, které se v C řeší přes header files.Což je konkrétně co?
Jen na C kromě vlastností samotného jazyka oceňuj to, že kolem něj je tolik nástrojů, zkušeností a best practices, že nenarážíš na nové problémy, které ještě nikomu nestály za řešení. To, že se u Rustu nemám koho zeptat na základní otázky, abych dostal smysluplnou odpověď, tuto výhodu C jenom podtrhuje.Tak na to se celkem nedá moc říct, těch >40 let se jentak nedožene... Nicméně ironie je, že na začátku jsme se bavili o modulech, což je oblast, ve které C nenabízí vůbec nic...
17.12.2014 10:41
pavlix | skóre: 54
| blog: pavlix
Pro build systém to určitě jednodušší je, uživatel toho build systému musí nainstalovat si a pochopit další nástroj...No jeje, tak si vývojář nainstaluje jeden balíček a pokud se nenastaví na cestu sám, tak to udělá.
Což je konkrétně co?A to se mi zase teď vysvětlovat nechce, je to základní znalost stávajícího ekosystému, to se radši časem zeptám někoho, kdo trochu tuší.
Tak na to se celkem nedá moc říct, těch >40 let se jentak nedožene... Nicméně ironie je, že na začátku jsme se bavili o modulech, což je oblast, ve které C nenabízí vůbec nic...A to je tak špatné chtít po novém nástroji, aby kromě nových vlastností zastával dobře i to, co se starým už umíme (a to není jen o nástroji, ale i o dostupnosti informací)? Na céčku je samozřejmě spousta věcí na hovno a člověk by tak rád ocenil alternativu, které je řeší. Ale u programovacího jazyka je to ještě horší než u těch autotools. Jejich vlastnosti člověk vždycky nějak naskriptuje, když má na takové věci dost času, ale základní věci prostě rozumně jako uživatel nenahradíš.
A to se mi zase teď vysvětlovat nechce, je to základní znalost stávajícího ekosystému, to se radši časem zeptám někoho, kdo trochu tuší.
Neboj, vím co jsou headery, spíš mě zajímalo, v čem vidíš takovej přínos. Imho jsou spíš důsledkem způsobu, jak se C/C++ kompiluje (viz třeba nutnost psát include guards). Mít skupinu funkcí, struktury nebo třídy (když jde o C++) přehledně definované v headeru odděleně od implementace je celkem fajn, to zcela uznávám, nicméně stejně musí člověk používat všelijaké triky, aby implementaci skutečně důsledně oddělil, tj. různé opaque pointery ve strukturách, PIMPL v C++ a některé věci ani oddělit z headerů nemůžeš, např. generika implementovaná preprocesorovou magií v C a templaty v C++ ...
A to je tak špatné chtít po novém nástroji, aby kromě nových vlastností zastával dobře i to, co se starým už umíme (a to není jen o nástroji, ale i o dostupnosti informací)?V zásadě ne, podle toho, co po tom nástroji vlastně chceš. Zatím jsme zaznamenal požadavek na možnost použití ccache, který s použitím vestavěného build systému splněn není, s použitím externího (autotools) ano.
17.12.2014 23:36
pavlix | skóre: 54
| blog: pavlix
Neboj, vím co jsou headery, spíš mě zajímalo, v čem vidíš takovej přínosAha. Ty totiž stále ještě předpokládáš, že požaduju po Rustu, aby fungoval v ohledu struktury zdrojáků jako C, ale to je nesmysl. Když se začal trochu víc propagovat Git jako náhrada Subversion, tak si člověk na každém rohu mohl přečíst, jak dělat věci, které dělal se stávajícím systémem, které věci nejdou, proč nejdou, a co s tím. Pokud mám vůbec chápat Rust jako možnou náhradu C, tak k tomu potřebuju mít v ruce něco podobného.
nicméně stejně musí člověk používat všelijaké triky, aby implementaci skutečně důsledně oddělilNejpraktičtější je chápat céčko jako nadstavbu nad assemblerem a bez dalších nástrojů (ať už knihoven nebo různých generátorů) od něj neočekávat zázraky. Na druhou stranu je údržba ABI v čistém C strašně jednoduchá díky tomu, že ten jazyk dělá v podstatě jenom to, co se mu řekne. Exportovat pointer na nedefinovanou strukturu a poskytnout k němu sadu funkcí je tak easy jak si to jenom umím představit :).
V zásadě ne, podle toho, co po tom nástroji vlastně chceš.Zatím si chci pouze udělat představu, co umí a k čemu je vhodný.
Zatím jsme zaznamenal požadavek na možnost použití ccacheTo je nesmysl. Jediný požadavek, který by s tím mohl souviset je rychlá kompilace, přičemž rád slevím z nároků u první kompilace daného projektu, ale rád bych, aby byla rychlá alespoň každá další kompilace, a to i v případě, že udělám změnu. To se v C zajišťuje především pomocí oddělené kompilace za použití hlavičkových souborů a někdy se hodí to spojit s ccache. Použít ccache je ale prostředek, nikoliv cíl, a pokud se ten prostředek použije špatně (například se cachuje po příliš velkých jednotkách), tak nemusí k naplnění cíle vůbec dojít.
s použitím vestavěného build systémuPopravdě řečeno jako céčkař nevidím důvod, aby měl kompilátor jazyka vestavěný build systém.
Pokud mám vůbec chápat Rust jako možnou náhradu C, tak k tomu potřebuju mít v ruce něco podobného.Úrovní abstrakce je Rust mnohem blíž k C++, D apod. než k C. Jinak nějaké takové informace existují, zejména co se jazyka jako takového týče. Viděl jsem různé tutoriály typu "Rust for C++ programmers", "Rust for Rubyists" (nevim, proč zrovna Ruby, které má úplně jiné zaměření, ale w/e) a podobně. Informací týkajících se build systémů, toolingu a vůbec ekosystému okolo je zatím spíš míň a rychle zastarávají, což je dané hlavně tím, že tyhle věci teprve vznikají, takže bych je čekal spíš až s vydáním stabilní* verze jazyka a kompilátoru. Nicméně na ML a IRC jsou i teď obvkle ochotni vysvětlit/poradit. *) stabilní ve smyslu že nepadá už je, mám na mysli stabilní ve smyslu zachovávající kompatibilitu (ABI, jazyka, atd.)
Na druhou stranu je údržba ABI v čistém C strašně jednoduchá díky tomu, že ten jazyk dělá v podstatě jenom to, co se mu řekne. Exportovat pointer na nedefinovanou strukturu a poskytnout k němu sadu funkcí je tak easy jak si to jenom umím představit :)To je zásluha unixového ekosystému a taky téměř univerzálního rozšíření GCC nebo kompatibilních kompilátorů, rozhodně ne jazyka C, který pro ABI prakticky nehne prstem. Určitě to je fajn, to souhlas, ale jinak moc nevim, proč to píšeš
Jediný požadavek, který by s tím mohl souviset je rychlá kompilace, přičemž rád slevím z nároků u první kompilace daného projektu, ale rád bych, aby byla rychlá alespoň každá další kompilace, a to i v případě, že udělám změnu.Aha, hmm, tak na to aktuálně odpovím dost těžko, protože to závisí na X věcech (ja je kód rozdělen, jak/čim ho sestavuješ,...) a za chvíli se situace stejně změní. Jediný, co můžu říct celkem s jistotou, je, že výchozí build většího crate pomocí rustc je v současné době relativně pomalý a žere relativně dost RAM.
Popravdě řečeno jako céčkař nevidím důvod, aby měl kompilátor jazyka vestavěný build systém.Já taky moc ne, ale někdy se to hodí, když potřebuješ rychle něco zkusit...
18.12.2014 09:02
pavlix | skóre: 54
| blog: pavlix
Úrovní abstrakce je Rust mnohem blíž k C++, D apod. než k C.To může být i fajn v závislosti na tom, jak je to celé postavené. Já jsem si třeba kdysi myslel, jak je C++ super, než jsem narazil na hromadu drobností, které si radši v C udělám jinak. Třeba v Pythonu se mi zdaleka tolik nestává, že bych narážel na to, že mi ten jazyk překáží, i když má taky své nevýhody třeba i oproti tomu C a teď nemám namysli neefektivní běh programů ve VM, kde je vše v hashovacích tabulkách.
To je zásluha unixového ekosystému a taky téměř univerzálního rozšíření GCC nebo kompatibilních kompilátorů, rozhodně ne jazyka CTo, že je to jednoduché je právě vlastností programovacího jazyka C. Proto to taky píšu. To, že je kolem toho tooling, je samozřejmě dobře, ale o tom až tak nemluvím.
Aha, hmm, tak na to aktuálně odpovím dost těžko, protože to závisí na X věcech (ja je kód rozdělen, jak/čim ho sestavuješ,...)Tak třeba v C ho můžu rozdělit, jak uznám za vhodné a sestavuje se tak, že největší zpomalené způsobí změna hlavičkového souboru, který se používá ve velké části projektu. zase na druhou stranu není potřeba vícekrát zpracovávat celý zdroják, který za tím hlavičkovým souborem leží a který je násobně větší. Ke kompilaci přichází v ůvahu GCC nebo LLVM, přičemž co vím, tak LLVM má být podstatně rychlejší, ale ještě jsem se nedostal k tomu ho trochu víc používat. Tady se už skutečně nebavíme ani tak o jazyce jako o existujících nástrojích a jejich dalším směřování. Ono totiž asi není problém vzít zdroják, který popisuje jak API, tak ABI, tak implementaci, a první dvě z nich vygenerovat a uložit jakožto (třeba i binární) obdobu hlavičkového souboru pro další zpracování. Nebo použít nějakou úplně jinou techniku, která mě třeba ani nenapadne.
14.12.2014 12:29
pavlix | skóre: 54
| blog: pavlix
os.path.basename ? Nebo modulu argparse ? Doporucuju nahlednout do dokumentace ke standardni knihovne, at se zase nevymysli kolo
Pokud se uvazuje do budoucna o jakesi serioznosti, bylo by asi vhodne nasadit nektery z dostupnych parseru. Uvedene manualni parsovani ktere nepocita s nestandardnimi situacemi(format, znakova sada) a rozsiritelnosti, neni dostatecne.
Dal mi neni jasne proc je to napsane pro porad min rozsireny Python 3. Pouziti subgeneratoru tu je spis jako manyra nez nutnost. Jiny duvod ?
Btw. je po necem takovem vubec poptavka v Gentoo komunite ? Zatim jsem nezaznamenal ze by upstream zesilel a vetsina uz dodavala systemd unity.
16.12.2014 16:43
pavlix | skóre: 54
| blog: pavlix
Slysel autor o funkci os.path.basename?Patches welcome.
Nebo modulu argparse?Slyšel a nevidí důvod ho použít. Na jednoduché věci je zbytečný, na středně složité ho autor čas od času použije a na cokoli komplikovanějšího je úplně na hovno. Autor čas od času uvažuje, že si napíše vlastní parser na parametry příkazové řádky, který bude trochu lépe ovladatelný. Navíc je tu možnost, že bude program portován na nějakou ze starších verzí Pythonu.
Uvedene manualni parsovani ktere nepocita s nestandardnimi situacemi(format, znakova sada) a rozsiritelnosti, neni dostatecne.Konkrétně?
Dal mi neni jasne proc je to napsane pro porad min rozsireny Python 3.Python 3 považuju za skvělý jazyk na psaní prototypů podobných věcí, jakmile budu rámcově spokojený s funkcionalitou, nevidím problém to portovat na Python ≥ 2.6, ve chvíli, kdy se ukáže, že je k tomu důvod.
Btw. je po necem takovem vubec poptavka v Gentoo komunite?Vím minimálně o jednom člověku z Gentoo komunity, který to chce využívat, a to jsem já. Vivat open source!
Zatim jsem nezaznamenal ze by upstream zesilel a vetsina uz dodavala systemd unity.Považuju naopak za velice rozumné, když tak upstream učiní a do několika projektů už jsem je sám poslal a byly přijaty. Je to nejen krok k lepší podpoře systemd, kdy maintaineři distribuce můžou odškrtnout další položku jako vyřešenou upstreamem, ale i ukázka, jak se má služba používat. To ve výsledku slouží nejen jako příklad lidem, ale lze z toho při troše snahy generovat hotové skripty, jako to dělám já. Jako maintainer balíků pro více než jednu distribuci to dokážu ocenit.
Slyšel a nevidí důvod ho použít. Na jednoduché věci je zbytečný, na středně složité ho autor čas od času použije a na cokoli komplikovanějšího je úplně na hovno. Autor čas od času uvažuje, že si napíše vlastní parser na parametry příkazové řádky, který bude trochu lépe ovladatelný. Navíc je tu možnost, že bude program portován na nějakou ze starších verzí Pythonu.
Nejaky priklad, co take zasadne tam chyba? Samozrejme nejde spravit uplne vsetko, ale to vidim skor ako vyhodu -- vyzaduje si to isty navrh UI a je tam ista konzistencia medzi tym ako vyzera vstup python scriptov, co pouzivaju argparse.
btw: Pre starsi python (2.3+) je argparse dostupny vo forme externej kniznice.
16.12.2014 23:35
pavlix | skóre: 54
| blog: pavlix
Nejaky priklad, co take zasadne tam chyba?Je to takové celkově neovladatelné. Přijde mi, že od toho nemůžeš chtít nic víc než chtěl autor. Vyžaduje to primitivní návrh UI, což vyhovuje u běžných příkazů, která max implementují nějakou tu volbu. Zrovna na nástroj typu systemd2rc by to stačilo. Ale tuším, že jsem měl problém tam implementovat i něco, co by fungovalo aspoň trochu ve stylu iproute2 nebo git.
btw: Pre starsi python (2.3+) je argparse dostupny vo forme externej kniznice.Externí závislosti bych zrovna v případě systemd2rc rád omezil na minimum, ale dobrá poznámka.
17.12.2014 00:03
Josef Kufner | skóre: 70
17.12.2014 10:42
pavlix | skóre: 54
| blog: pavlix
18.12.2014 11:55
Jakub Lucký | skóre: 40
| Praha
18.12.2014 12:31
Josef Kufner | skóre: 70
A havně se mi líbí, že napíšeš dokumentaci a už není třeba psát implementaci takto zdokumentovaného API.
18.12.2014 12:49
pavlix | skóre: 54
| blog: pavlix
18.12.2014 17:53
Jakub Lucký | skóre: 40
| Praha
No, ono by to z toho Clicku asi šlo taky generovat, ani nevím, možná to umí...
23.12.2014 15:09
Bystroushaak | skóre: 36
| blog: Bystroushaakův blog
| Praha
Velice pěkný je docopt, který byl přepsán i pro PHP. Nástroje ve stylu Gitu to umí. Programátor napíše nápovědu a ono ji to rozparsuje a použije ke zpracování parametrů na příkazové řádce.Docopt imho nemůže plně konkurovat argparse. Je to dobré na různé jednodušší interface, ale selhává tam kde chceš validaci, defaultní hodnoty a všelijaké vymoženosti, které jsem si už zvykl považovat za standard.
Hm, nemylis si to s getopt? Ten git-like UI (iproute2 UI nepoznam) skutocne nedaval a mal aj par dalsich nevyhod (napr. nedokazal rozparsovat len zname argumenty a pod.), ale s argparse sa git-like UI da implementovat celkom pohodlne (cca len staci pridat subparsere) + vdaka ciastocnemu rozparsovaniu je mozne celkom lahko poskladat viacero parserov, pripadne doplnit nejaku nestandardnu funkcionalitu.
18.12.2014 00:01
pavlix | skóre: 54
| blog: pavlix
Default command v zaklade nie je, ale to nie je az tak velky problem pri argparse. Hlavna vyhoda argparse je snad v tom, ze je dost benevolentne k jeho vstupu a dovoluje robit s nim dalej (prave na rozdiel od optparse), takze mozes kludne implementovat veci nad argparse, ktore argparse nezvlada na par riadkov...
V tomto pripade teda pred volanim parse_args staci nieco ako
if sys.argv[0] not in allowed_commands:
sys.argv = [default_command] + sys.argv
btw: Mne pride, ze subparsere su mozno az prilis malo oddelene, napr. zapisuju argumenty do jednej namespace.
19.12.2014 22:04
pavlix | skóre: 54
| blog: pavlix
V tomto pripade teda pred volanim parse_args staci nieco ako1) To něco bude muset být značně odlišné. 2) Nevím proč by v mém software přímý přístup k argv měl vadit, zatímco u software s argparse by měl být v pořádku.
zapisuju argumenty do jednej namespace.Sám si to už ani nepamatuju, ale to mi teda taky přijde úchylné, i když funkčně to asi není až tak zásadní.
1) To něco bude muset být značně odlišné.
Ci to bude musiet byt znacne odlisne zalezi od designu programu, ale pokial argumenty beru az podprikazy, tak to alebo nieco velmi podobne dostacuje.
2) Nevím proč by v mém software přímý přístup k argv měl vadit, zatímco u software s argparse by měl být v pořádku.
Nevadi, chcel som prave povedat len to, ze argparse je proste lahko rozsiretelne a da sa nan pozerat len ako na pomocny nastroj, pouzivat ho v pripadoch, ked dava nejaku pridanu hodnotu zadarmo a o zvysok parsovania argumentov sa moze clovek starat rucne.
22.12.2014 13:33
pavlix | skóre: 54
| blog: pavlix
Nevadi, chcel som prave povedat len to, ze argparse je proste lahko rozsiretelne a da sa nan pozerat len ako na pomocny nastroj, pouzivat ho v pripadoch, ked dava nejaku pridanu hodnotu zadarmo a o zvysok parsovania argumentov sa moze clovek starat rucne.Až budu mít čas, vyzkouším to.
23.12.2014 15:08
Bystroushaak | skóre: 36
| blog: Bystroushaakův blog
| Praha
23.12.2014 16:43
pavlix | skóre: 54
| blog: pavlix
Tiskni
Sdílej:
