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í
×
    včera 22:22 | Komunita

    Na čem pracují vývojáři webového prohlížeče Ladybird (GitHub)? Byl publikován přehled vývoje za duben (YouTube).

    Ladislav Hagara | Komentářů: 0
    včera 19:11 | IT novinky

    Provozovatel čínské sociální sítě TikTok dostal v Evropské unii pokutu 530 milionů eur (13,2 miliardy Kč) za nedostatky při ochraně osobních údajů. Ve svém oznámení to dnes uvedla irská Komise pro ochranu údajů (DPC), která jedná jménem EU. Zároveň TikToku nařídila, že pokud správu dat neuvede do šesti měsíců do souladu s požadavky, musí přestat posílat data o unijních uživatelích do Číny. TikTok uvedl, že se proti rozhodnutí odvolá.

    Ladislav Hagara | Komentářů: 2
    včera 11:22 | Zajímavý projekt

    Společnost JetBrains uvolnila Mellum, tj. svůj velký jazykový model (LLM) pro vývojáře, jako open source. Mellum podporuje programovací jazyky Java, Kotlin, Python, Go, PHP, C, C++, C#, JavaScript, TypeScript, CSS, HTML, Rust a Ruby.

    Ladislav Hagara | Komentářů: 0
    včera 09:11 | Bezpečnostní upozornění

    Vývojáři Kali Linuxu upozorňují na nový klíč pro podepisování balíčků. K původnímu klíči ztratili přístup.

    Ladislav Hagara | Komentářů: 0
    1.5. 20:00 | Komunita

    V březnu loňského roku přestal být Redis svobodný. Společnost Redis Labs jej přelicencovala z licence BSD na nesvobodné licence Redis Source Available License (RSALv2) a Server Side Public License (SSPLv1). Hned o pár dní později vznikly svobodné forky Redisu s názvy Valkey a Redict. Dnes bylo oznámeno, že Redis je opět svobodný. S nejnovější verzí 8 je k dispozici také pod licencí AGPLv3.

    Ladislav Hagara | Komentářů: 1
    1.5. 19:22 | IT novinky

    Oficiální ceny Raspberry Pi Compute Modulů 4 klesly o 5 dolarů (4 GB varianty), respektive o 10 dolarů (8 GB varianty).

    Ladislav Hagara | Komentářů: 0
    30.4. 22:33 | Nová verze

    Byla vydána beta verze openSUSE Leap 16. Ve výchozím nastavení s novým instalátorem Agama.

    Ladislav Hagara | Komentářů: 0
    30.4. 17:44 | Zajímavý článek

    Devadesátková hra Brány Skeldalu prošla portací a je dostupná na platformě Steam. Vyšel i parádní blog autora o portaci na moderní systémy a platformy včetně Linuxu.

    karkar | Komentářů: 0
    30.4. 12:11 | Humor

    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).

    Ladislav Hagara | Komentářů: 7
    30.4. 10:44 | IT novinky

    Revolut nabídne neomezený mobilní tarif za 12,50 eur (312 Kč). Aktuálně startuje ve Velké Británii a Německu.

    Ladislav Hagara | Komentářů: 36
    Jaký filesystém primárně používáte?
     (58%)
     (1%)
     (9%)
     (21%)
     (4%)
     (1%)
     (2%)
     (0%)
     (1%)
     (3%)
    Celkem 506 hlasů
     Komentářů: 19, poslední 30.4. 11:32
    Rozcestník

    ESR: Emacs by měl opustit bzr a přejít ke Gitu

    Eric S. Raymond se nechal slyšet, že bzr (Bazaar), systém pro správu zdrojových kódů vyvíjený Canonicalem, je mrtvý a Emacs by proto měl přejít k něčemu jinému. Doporučuje Git, a to i ze "sociálních" aspektů.

    3.1.2014 12:53 | Luboš Doležel (Doli) | Komunita


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

    Komentáře

    Vložit další komentář

    pavlix avatar 3.1.2014 13:13 pavlix | skóre: 54 | blog: pavlix
    Rozbalit Rozbalit vše Re: ESR: Emacs by měl opustit bzr a přejít ke Gitu
    Kéž by k tomu došlo víc projektů. Na druhou stranu vůbec nemám problém s tím, aby nad Gitem vznikaly různé nadstavby. Jediný problém je v tom, že už základní vlastnosti Gitu jsou širší než budou někteří chtít přijmout. Větvená historie s merge commity je asi nejkontroverznější.
    Já už tu vlastně ani nejsem. Abclinuxu umřelo.
    xkucf03 avatar 3.1.2014 13:39 xkucf03 | skóre: 49 | blog: xkucf03
    Rozbalit Rozbalit vše Re: ESR: Emacs by měl opustit bzr a přejít ke Gitu

    Nechci teď hodnotit Bazaar, ale představa gitovské monokultury je mi proti srsti…

    A tohle je taková definice kruhem:

    Sticking to a moribund version-control system will compound and exacerbate the project's difficulty in attracting new talent.

    Když se bude všude používat jen Git, tak budou mít nováčci problém s jinými systémy, na které nejsou zvyklí a nikdy je neviděli → proto bychom všude měli používat Git.

    Mám rád, když se lidé přou, znamená to, že vědí, co dělají, a že mají směr. Frantovo.cz, SQL-DK, Relational pipes
    3.1.2014 17:00 s
    Rozbalit Rozbalit vše Re: ESR: Emacs by měl opustit bzr a přejít ke Gitu
    Zase na druhou stranu, myslenka - "nebudu to pouzivat proto, ze to pouzivaji vsichni" je snad jeste ujetejsi :-) Napadlo te treba, ze to, ze vsichni pouzivaji git, nemusi byt jen davova psychoza, ze to muze byt proste tim, ze je git tak dobry? Co myslis?

    xkucf03 avatar 3.1.2014 17:33 xkucf03 | skóre: 49 | blog: xkucf03
    Rozbalit Rozbalit vše Re: ESR: Emacs by měl opustit bzr a přejít ke Gitu

    Někdy mi právě přijde, že to davová psychóza je. Už jen v této diskusi několikrát padlo něco ve smyslu:

    I would have preferred Mercurial …

    I can understand hating git; the UI is pretty nasty …

    Agreed, from my experience. Mercurial's UI is better, too.

    Naopak výhodou Gitu je, že ho spousta lidí zná – takže pokud už se Gitem někdo prokousal, bude se mu lépe přispívat. Což je celkem relevantní argument, to nepopírám.

    Na druhou stranu přílišná uniformita je taky na škodu a přijde mi lepší žít s tím, že existuje více (D)VCS a dá se pracovat se všemi, než očekávat, že všude bude jediný správný verzovací systém. Řešení vidím spíš v abstrakci – pak se nebude stávat to, že někdo investuje obrovské úsilí do vytvoření nadstavby nad nějakým VCS – a ta bude nepoužitelná s jiným VCS, i když většina je stejná a bude se to programovat pořád znova a znova. Např. u relačních databází jsme už před mnoha lety dospěli k tomu, že máme abstraktní vrstvy jako JDBC nebo PDO a pod nimi ovladače pro konkrétní DBMS1.

    [1] SŘBD :-)

    Mám rád, když se lidé přou, znamená to, že vědí, co dělají, a že mají směr. Frantovo.cz, SQL-DK, Relational pipes
    mirec avatar 3.1.2014 18:39 mirec | skóre: 32 | blog: mirecove_dristy | Poprad
    Rozbalit Rozbalit vše Re: ESR: Emacs by měl opustit bzr a přejít ke Gitu

    Abstrakcia má jednu zásadnú nevýhodu: limituje aj tie najlepšie systémy na možnosti toho najhoršieho. GIT podporuje rôzne šialenosti (priama práca s objektmi ...) ktoré sa v iných VCS nedajú dosiahnuť.

    LinuxOS.sk | USE="-fotak -zbytocnosti -farebne_lcd +vydrz +odolnost +java" emerge telefon
    xkucf03 avatar 3.1.2014 19:34 xkucf03 | skóre: 49 | blog: xkucf03
    Rozbalit Rozbalit vše Re: ESR: Emacs by měl opustit bzr a přejít ke Gitu

    To není pravda, abstrakce buď může podporovat maximální možnou funkcionalitu (s tím, že ne každý ji musí podporovat) nebo jen část, ale na ten zbytek použiješ speciální rozšíření. Např. na většinu věcí můžeš použít stejné abtraktní rozhraní, ať je pod tím sqlite nebo PostgreSQL. Případně to může být modulární, můžou být různé úrovně podpory standardu.

    U těch verzovacích systémů chceš v IDE např. vidět, které soubory/řádky se změnily (nejsou commitnuté), vypsat si historii, vypsat si u každého řádku souboru, z jaké verze pochází a kdo je autorem, udělat commit vybraných souborů do aktuální větve atd. To je pro všechny systémy společné. A nějaké speciality si můžeš udělat na příkazové řádce bez abstrakce nebo pomocí nějakého rozšíření.

    Máš vlastně tři skupiny funkcionality:

    • obsažené v abstrakci i VSC – ideální stav
    • obsažené jen v abstrakci → implementace vyhodí výjimku nebo budeš mít nějaký mechanismus na signalizaci, která funkcionalita je podporovaná
    • obsažené jen ve VSC → použiješ rozšíření/modul nebo komunikuješ s VCS na přímo bez abstrakce

    Čím větší je ta první skupina, tím lépe, ale v zásadě jakákoli nenulová množina je plus, protože to umožní znovupoužitelnost, ušetří práci – někdo napíše ovladač pro nový VCS a rázem ho můžou všichni používat skrze svůj software, aniž by museli něco doprogramovávat; nebo někdo napíše novou GUI aplikaci a rázem ji mohou používat uživatelé všech VCS, pro které jsou ovladače (aniž by autor té GUI aplikace musel vůbec tušit, že tyto VCS existují).

    Mám rád, když se lidé přou, znamená to, že vědí, co dělají, a že mají směr. Frantovo.cz, SQL-DK, Relational pipes
    3.1.2014 20:05 s
    Rozbalit Rozbalit vše Re: ESR: Emacs by měl opustit bzr a přejít ke Gitu
    nikdy sem u gitu necitil potrebu pouzivat UI a nikdy sem ani zadne nepouzival. Krev se mi peni, kdyz s nekym neco probiram, on chce commitnout jeden soubor a misto aby napsal git add, git commit, spusti jakesi UI a zacne klikat... Podobnou mam averzi treba i k mc, ale toto tema je trochu offtopic ;-), a to, ze nekdo nema rad git, protoze ma rad mercurial, to imo neni argument.

    pro mne teda furt git +1 pro svou rychlost a jednoduchost a taky asi proto, ze s nim umim a lepsi neznam. Zato horsich znam hned nekolik ;-)
    xkucf03 avatar 3.1.2014 20:13 xkucf03 | skóre: 49 | blog: xkucf03
    Rozbalit Rozbalit vše Re: ESR: Emacs by měl opustit bzr a přejít ke Gitu
    Krev se mi peni, kdyz s nekym neco probiram, on chce commitnout jeden soubor a misto aby napsal git add, git commit, spusti jakesi UI a zacne klikat...

    Vtip je v tom, že nemusíš spouštět jakési UI – máš už otevřené IDE (případně editor) a v něm ten konkrétní soubor (soubory), tam jednou dvakrát klikneš nebo zmáčkneš klávesovou zkratku, napíšeš zprávu a odentruješ – je to rychlejší, než se přepínat do konsole, psát příkaz a vybírat znova soubory…

    Osobně používám Mercurial, něco (asi většinu) dělám na příkazové řádce a něco v IDE, podle toho, co je v tu chvíli víc po ruce a pohodlnější. Jsem rád za obě možnosti. Ale takový diff v IDE/editoru (podbarvené změněné řádky) je k nenahraditelný.

    Mám rád, když se lidé přou, znamená to, že vědí, co dělají, a že mají směr. Frantovo.cz, SQL-DK, Relational pipes
    Jakub Lucký avatar 3.1.2014 20:15 Jakub Lucký | skóre: 40 | Praha
    Rozbalit Rozbalit vše Re: ESR: Emacs by měl opustit bzr a přejít ke Gitu
    Ale takový diff v IDE/editoru (podbarvené změněné řádky) je k nenahraditelný.
    Na tohle je skvělá Idea/PHPStorm/Pycharm...
    If you understand, things are just as they are; if you do not understand, things are just as they are.
    xkucf03 avatar 3.1.2014 20:16 xkucf03 | skóre: 49 | blog: xkucf03
    Rozbalit Rozbalit vše Re: ESR: Emacs by měl opustit bzr a přejít ke Gitu

    Já to mám v Netbeans :-)

    Mám rád, když se lidé přou, znamená to, že vědí, co dělají, a že mají směr. Frantovo.cz, SQL-DK, Relational pipes
    mess avatar 4.1.2014 12:19 mess | skóre: 43 | blog: bordel | Háj ve Slezsku - Smolkov
    Rozbalit Rozbalit vše Re: ESR: Emacs by měl opustit bzr a přejít ke Gitu
    Já zase v KDevelop, QtCreatoru, Eclipse ... ;-)
    Cez párne mesiace zošíváš vaginy, cez neparne montuješ hajzle.
    Jakub Lucký avatar 3.1.2014 20:16 Jakub Lucký | skóre: 40 | Praha
    Rozbalit Rozbalit vše Re: ESR: Emacs by měl opustit bzr a přejít ke Gitu
    Ano, takhle se používá SVN na Windows... za poslední měsíce jsem si s tím v práci užil své...
    If you understand, things are just as they are; if you do not understand, things are just as they are.
    3.1.2014 23:48 ---- | skóre: 33 | blog:
    Rozbalit Rozbalit vše Re: ESR: Emacs by měl opustit bzr a přejít ke Gitu
    Další výhoda Gitu je, že je mocnější než mercurial; má lepší branches, má interaktivní rebase, ...

    a interface k gitu mi přijde v pohodě (teda ten konzolový, s GUI nemám žádné zkušenosti) - hlavně pro běžné věci je to triviální.
    stativ avatar 4.1.2014 13:44 stativ | skóre: 54 | blog: SlaNé roury
    Rozbalit Rozbalit vše Re: ESR: Emacs by měl opustit bzr a přejít ke Gitu
    V čem má git lepší branche? Používám obojí, i když preferuju mercurial, a branche mi přijdou nastejno. Jinak interaktivní rebase se v mercurialu jmenuje histedit.
    Ať sežeru elfa i s chlupama!!! ljirkovsky.wordpress.com stativ.tk
    stativ avatar 4.1.2014 13:58 stativ | skóre: 54 | blog: SlaNé roury
    Rozbalit Rozbalit vše Re: ESR: Emacs by měl opustit bzr a přejít ke Gitu
    Jen dodám, že tím nevyvracím, že git nemá nějakou funkcionalitu navíc, ale to se dá říct i naopak. Např. u gitu mi schází podpora largefiles, naopak u mercurialu bych uvítal něco jako "git clone --depth" (IIRC se ale vývojáři vyjádřili, že tohle v mercurialu nechtějí) a možnost editoru hunku při commitu jako je u "git add -p".
    Ať sežeru elfa i s chlupama!!! ljirkovsky.wordpress.com stativ.tk
    pavlix avatar 4.1.2014 20:43 pavlix | skóre: 54 | blog: pavlix
    Rozbalit Rozbalit vše Re: ESR: Emacs by měl opustit bzr a přejít ke Gitu
    u gitu mi schází podpora largefiles
    Co si pod tím má laik představit?
    Já už tu vlastně ani nejsem. Abclinuxu umřelo.
    stativ avatar 5.1.2014 11:00 stativ | skóre: 54 | blog: SlaNé roury
    Rozbalit Rozbalit vše Re: ESR: Emacs by měl opustit bzr a přejít ke Gitu
    Je to něco jako centralizovaný VCS uvnitř decentralizovaného. Snaží se to řešit klasický problém asi všech DVCS, kterým je ukládání velkých binárních souborů, kde moc dobře nefunguje komprese.

    V mercurialu lze označit soubor jako largefile. Mercurial pak pro takový soubor funguje jako centralizovaný systém, kde na vybraném serveru jsou všechny revize a na klientovi je jen cache s verzemi, které klient potřebuje (a kterou je možné smazat). Je to dost užitečné pro různé artworky, které se moc často nemění, ale které zaberou spoustu místa.
    Ať sežeru elfa i s chlupama!!! ljirkovsky.wordpress.com stativ.tk
    pavlix avatar 5.1.2014 15:36 pavlix | skóre: 54 | blog: pavlix
    Rozbalit Rozbalit vše Re: ESR: Emacs by měl opustit bzr a přejít ke Gitu
    Musím ti dát bod za snahu, ale ten tvůj popis je opravdu strašný. Jestli to správně chápu, tak jde o to, že si stáhneš jen mělkou historii (což Git částečně umí), akorát selektivně dle atributu nějakého souboru.

    Mně osobně takhle možnost moc užitečná nepřijde a řešil bych to buď pomocí archivu nebo pomocí Git submodule, který bych klonoval jen mělce. Na druhou stranu implementovat takový atribut pro konkrétní soubory by v gitu bylo vcelku triviální, takže v tom nevidím problém, pokud to někdo za užitečné považuje.
    Je to dost užitečné pro různé artworky
    Nemyslím si. Pokud má být pro ty artworky výhodný Git, tak nejspíš s plnou historií. Pokud pro ně výhodný není, tak se dají distribuovat jako archiv. Není problém v Gitu udržovat buď verzi toho archivu nebo rovnou hash.
    Je to dost užitečné pro různé artworky, které se moc často nemění, ale které zaberou spoustu místa.
    Asi záleží o jak velké soubory jde a kolikrát za život projektu se změní. Ale pokud už takové soubory mají být v Gitu i kdyby jen na serveru, není důvod, aby zabírali místo ve stejné větvi (ve stejném repozitáři) jako kód. Ve chvíli, kdy se jedná o Git submodule, není problém tato data jako celek klonovat bez historie.

    Neříkám, že je v Gitu práce s mělkými kopiemi a se submoduly úplný med, ale spíš bych se soustředil na zlepšování tohoto než přesouvání granularity na jednotlivé soubory. Ale rád si poslechnu i jiný pohled.
    Já už tu vlastně ani nejsem. Abclinuxu umřelo.
    stativ avatar 5.1.2014 17:04 stativ | skóre: 54 | blog: SlaNé roury
    Rozbalit Rozbalit vše Re: ESR: Emacs by měl opustit bzr a přejít ke Gitu
    Musím ti dát bod za snahu, ale ten tvůj popis je opravdu strašný.
    Díky za bod, mě se můj popis docela líbil :-)
    Jestli to správně chápu, tak jde o to, že si stáhneš jen mělkou historii (což Git částečně umí), akorát selektivně dle atributu nějakého souboru.
    Historie, pokud jde o commity, se stáhne celá, akorát data ne. Dalo by se taky říct, že pro largefiles mercurial verzuje metada, kdežto data jsou zvlášť.
    Mně osobně takhle možnost moc užitečná nepřijde a řešil bych to buď pomocí archivu nebo pomocí Git submodule, který bych klonoval jen mělce.
    Ten názor ti neberu. Já třeba submoduly v oblibě zrovna nemám a k archivu nemám hezkou historii.
    Pokud má být pro ty artworky výhodný Git, tak nejspíš s plnou historií. Pokud pro ně výhodný není, tak se dají distribuovat jako archiv. Není problém v Gitu udržovat buď verzi toho archivu nebo rovnou hash.
    Largefiles právě kombinují do jisté míry obojí. Oproti shallow clone nebo separátnímu archivu v logu vidím všechny commity. Zároveň ale nemusím na disku mít i stará data, která nejspíš nikdy potřebovat nebudu. A když už bych je náhodou potřeboval, tak se stáhnou ze serveru (tady je výhoda oproti archivu, protože k nim mám historii).
    Ať sežeru elfa i s chlupama!!! ljirkovsky.wordpress.com stativ.tk
    pavlix avatar 5.1.2014 17:28 pavlix | skóre: 54 | blog: pavlix
    Rozbalit Rozbalit vše Re: ESR: Emacs by měl opustit bzr a přejít ke Gitu
    Historie, pokud jde o commity, se stáhne celá, akorát data ne.
    Já osobně se na Git rád dívám jako na objektovou databázi. Stažení celé historie commitů bez samotných adresářů a souborů je v celku triviální. Takže celá ta legrace bude především o tom, aby nad tím dobře fungovaly nástroje, které v tuto chvíli s takovou situací nepočítají.
    Dalo by se taky říct, že pro largefiles mercurial verzuje metada, kdežto data jsou zvlášť.
    Git udržuje o souborech jen minimum informací a ty jsou součástí tree objektů, tedy adresářů. Pokud jsou potřeba nějaká další metadata, typicky se ukládají jako obyčejné textové soubory a můžou se vázat i na cesty, na kterých žádný objekt není (.gitignore). Takový nástroj by byl vhodný i pro označení toho, čemu říkáš large files, protože by mohl předvídat i soubory, které zatím nebyly přidány.

    Podle mě by nebyl problém ani stahovat si celý strom, pouze vynechávat vybrané či všechny datové soubory. Ale opět se naráží na to, že by bylo potřeba uzpůsobit nástroje na práci s neúplnou informací.
    Já třeba submoduly v oblibě zrovna nemám
    Tak artwork reálně submodulem je. Starají se o něj často jiní lidé. Lze upravovat do jisté míry samostatně. Podle mě je škoda ho slévat s kódem. Implementace submodulů v Gitu by jistě zasloužila vyšperkovat, ale jejich nepoužití v takových případech podle mě vede k tomu, že se člověk dříve nebo později spálí.
    Largefiles právě kombinují do jisté míry obojí.
    Tak to ani v nejmenším. Funkce submodulu nelze nahradit tím, že si označím soubor a nestahuju jeho historii.
    Oproti shallow clone nebo separátnímu archivu v logu vidím všechny commity.
    V případě submodulu si dokonce můžeš vybrat, zda tě zajímá jeho historie samotná nebo v kontextu celého projektu. Navíc mi pak přijde užitečné si pro celý submodul stáhnout jen metadata a k nim aktuální data, očemž už jsem psal výše a člověk by ani nemusel řešit nějaké značkování souborů.
    A když už bych je náhodou potřeboval, tak se stáhnou ze serveru (tady je výhoda oproti archivu, protože k nim mám historii).
    To by pro submodul s metadaty a aktuálními daty platilo úplně stejně. Já v tom vidím dva rozdílné pohledy na stejný problém, přičemž bych ale stále preferoval ten s granularitou submodulů, nikoliv jednotlivých souborů, ale jinak jsou si velmi podobné a je to prostor, ve kterém by se mohl Git dále zlepšovat.
    Já už tu vlastně ani nejsem. Abclinuxu umřelo.
    xkucf03 avatar 5.1.2014 17:50 xkucf03 | skóre: 49 | blog: xkucf03
    Rozbalit Rozbalit vše Re: ESR: Emacs by měl opustit bzr a přejít ke Gitu
    Tak artwork reálně submodulem je. Starají se o něj často jiní lidé.

    To je pak podobná situace jako u knihoven – a tam mi přijde lepší necpat cizí binární knihovny do mého úložiště, ale verzování nechat na autorech té knihovny a mít nějaký systém, jak si dotáhnout potřebné závislosti (od distribučního balíčkovacího systému .deb/.rpm přes Maven, Ivy, CPAN, CTAN a další až po vlastní skript, který nakopíruje potřebné knihovny ze sdíleného disku). Cpát tyhle věci do verzovacího systému je mi proti srsti, mám radši minimalistická úložiště, kde je jen to nejcennější, ale je fakt, že Largefiles tuhle moji nechuť trochu snižují.

    Mám rád, když se lidé přou, znamená to, že vědí, co dělají, a že mají směr. Frantovo.cz, SQL-DK, Relational pipes
    6.1.2014 11:08 Ed
    Rozbalit Rozbalit vše Re: ESR: Emacs by měl opustit bzr a přejít ke Gitu
    Pokud chces konkretni pripad:

    Git repozitar dat pro Flightgear flight simulator (hlavne modely letadel) ma asi 11GB. Klon trva i na rychle lince mnoho hodin. Pritom drtive vetsine lidi (vcetne tvurcu tech modelu) staci jen aktualni nebo posledni tagovana verze). Ale zase pokud se hleda, proc treba nefunguje autopilot, je dobre mit kompletni historii zmen pro nektere (XML) soubory.

    Na submodulech me stve, ze git archive je tise ignoruje.
    pavlix avatar 6.1.2014 11:32 pavlix | skóre: 54 | blog: pavlix
    Rozbalit Rozbalit vše Re: ESR: Emacs by měl opustit bzr a přejít ke Gitu
    To zní jako docela běžný příklad. No je to jak jsem říkal, Git potřebuje v této oblasti vylepšit toolset. Ale nemít tyhle data v submodulu považuju za zločin, i kdyby motivovaný nedostatky gitovských nástrojů.

    Pokud jde o git archive, náprava by nemusela být až tak složitá.
    Já už tu vlastně ani nejsem. Abclinuxu umřelo.
    5.1.2014 20:19 Martin Mareš
    Rozbalit Rozbalit vše Re: ESR: Emacs by měl opustit bzr a přejít ke Gitu
    Co třeba git-annex?
    pavlix avatar 5.1.2014 20:52 pavlix | skóre: 54 | blog: pavlix
    Rozbalit Rozbalit vše Re: ESR: Emacs by měl opustit bzr a přejít ke Gitu
    To vypadá zajímavě.
    Já už tu vlastně ani nejsem. Abclinuxu umřelo.
    stativ avatar 5.1.2014 21:22 stativ | skóre: 54 | blog: SlaNé roury
    Rozbalit Rozbalit vše Re: ESR: Emacs by měl opustit bzr a přejít ke Gitu
    Tak o tom jsem nevěděl. Díky.
    Ať sežeru elfa i s chlupama!!! ljirkovsky.wordpress.com stativ.tk
    6.1.2014 11:35 JS1 | skóre: 2 | blog: intuition_pump
    Rozbalit Rozbalit vše Re: ESR: Emacs by měl opustit bzr a přejít ke Gitu
    Ahh, diky moc, to jsem dlouho hledal, takovy software!
    Lidstvo čelí v tomto století hrozbě civilizačního kolapsu. Podpořte hnutí klimatickakoalice.cz!
    pavlix avatar 6.1.2014 13:42 pavlix | skóre: 54 | blog: pavlix
    Rozbalit Rozbalit vše Re: ESR: Emacs by měl opustit bzr a přejít ke Gitu
    Mimochodem, zdrojem zajímavých informací je i toto. Jsou tam odkazy na několik dalších projektů, které můžou být pro některý konkrétní účel vhodnější.
    Já už tu vlastně ani nejsem. Abclinuxu umřelo.
    7.1.2014 13:56 kolcon | skóre: 15 | blog: kolcon
    Rozbalit Rozbalit vše Re: ESR: Emacs by měl opustit bzr a přejít ke Gitu
    vypada to zajimave, az na jednu vec.

    Jestli to spravne chapu, tak mi to ty soubory presune do sveho .git adresare a nahradi je symlinky.

    Nejsem si uplne jisty, ze chci mit v adresarich kupu symlinku kamsi, misto dat.

    Co se stane, kdyz se rozhodnu, ze git-annex prestanu pouzivat? Jak jednoduse z tech symlinku dostanu zpatky ty soubory?
    xkucf03 avatar 7.1.2014 14:01 xkucf03 | skóre: 49 | blog: xkucf03
    Rozbalit Rozbalit vše Re: ESR: Emacs by měl opustit bzr a přejít ke Gitu

    Na to bude stačit krátký skriptík. Horší je, když uvnitř těch souborů (nebo vůči nim) budou nějaké relativní odkazy – pak je dost možné, že software, který s tím pracuje bude brát jako výchozí cestu místo, kam symlink odkazuje, ne to, kde se nachází.

    Mám rád, když se lidé přou, znamená to, že vědí, co dělají, a že mají směr. Frantovo.cz, SQL-DK, Relational pipes
    7.1.2014 14:26 JS1 | skóre: 2 | blog: intuition_pump
    Rozbalit Rozbalit vše Re: ESR: Emacs by měl opustit bzr a přejít ke Gitu
    Bohuzel, lepsi system asi neexistuje, aspon dokud filesystemy nepodporuji neco jako "odkaz na vzdalene uloziste". Coz je v podstate ten symlink...
    Lidstvo čelí v tomto století hrozbě civilizačního kolapsu. Podpořte hnutí klimatickakoalice.cz!
    xkucf03 avatar 7.1.2014 14:40 xkucf03 | skóre: 49 | blog: xkucf03
    Rozbalit Rozbalit vše Re: ESR: Emacs by měl opustit bzr a přejít ke Gitu

    To by šlo udělat přes FUSE – některé soubory by byly lokálně a některé by se tahaly až v případě potřeby ze serveru. Pro aplikace by to bylo transparentní.

    BTW: proč by to nemohly být pevné odkazy? Nebo mít ty soubory jen v pracovní kopii, ale verzovací systém by věděl, že to nejsou běžné verzované soubory a jak se k nim má chovat.

    Mám rád, když se lidé přou, znamená to, že vědí, co dělají, a že mají směr. Frantovo.cz, SQL-DK, Relational pipes
    pavlix avatar 7.1.2014 14:45 pavlix | skóre: 54 | blog: pavlix
    Rozbalit Rozbalit vše Re: ESR: Emacs by měl opustit bzr a přejít ke Gitu
    ShareBox je postavený nad git annex.
    Já už tu vlastně ani nejsem. Abclinuxu umřelo.
    7.1.2014 15:07 JS1 | skóre: 2 | blog: intuition_pump
    Rozbalit Rozbalit vše Re: ESR: Emacs by měl opustit bzr a přejít ke Gitu
    Toho jsem si vedom, ale stejne si myslim, ze (desktopove) aplikace s tim, ze soubor muze byt docasne nedostupny (pro vysokou hodnotu casu - zvlast kdyz se musi treba cekat na lidskeho operatora, aby pripojil disk) obecne prilis nepocitaji.
    Lidstvo čelí v tomto století hrozbě civilizačního kolapsu. Podpořte hnutí klimatickakoalice.cz!
    7.1.2014 15:14 JS1 | skóre: 2 | blog: intuition_pump
    Rozbalit Rozbalit vše Re: ESR: Emacs by měl opustit bzr a přejít ke Gitu
    Idealne bych si predstavoval: Chci si prehrat film, otevru si ho v prehravaci (nebo kliknu na ikonu), a napise mi to:

    "Soubor .. (s filmem) je ulozen na offline mediu XYZ. Pokud ho chcete prehrat, pripojte prosim to medium. OK Zrusit"

    Jenze na neco takoveho musi byt (IMHO) podpora jak na urovni aplikace, tak na urovni FS. Mozna by to slo udelat i pres ruzne KIO Slave nebo podobne, nevim.
    Lidstvo čelí v tomto století hrozbě civilizačního kolapsu. Podpořte hnutí klimatickakoalice.cz!
    6.1.2014 12:53 Vlad
    Rozbalit Rozbalit vše Re: ESR: Emacs by měl opustit bzr a přejít ke Gitu
    ... a možnost editoru hunku při commitu jako je u "git add -p".
    hg record ?
    stativ avatar 6.1.2014 17:59 stativ | skóre: 54 | blog: SlaNé roury
    Rozbalit Rozbalit vše Re: ESR: Emacs by měl opustit bzr a přejít ke Gitu
    Ten samozřejmě znám a možnost upravit hunk nemá. Ve wiki je na to i feature request.
    Ať sežeru elfa i s chlupama!!! ljirkovsky.wordpress.com stativ.tk
    3.1.2014 17:27 David Jaša | skóre: 44 | blog: Dejvův blog
    Rozbalit Rozbalit vše Re: ESR: Emacs by měl opustit bzr a přejít ke Gitu
    Jeden z původních autorů bzr psal už před rokem, že je to efektivně mrtvá věc, takže se spíš divím, že akutální článek na podobné téma někoho překvapí.
    pavlix avatar 3.1.2014 20:02 pavlix | skóre: 54 | blog: pavlix
    Rozbalit Rozbalit vše Re: ESR: Emacs by měl opustit bzr a přejít ke Gitu
    +1

    Dokonce mám dojem, že jsem zaslechl něco o možnosti reimplementovat bzr CLI jako nadstavbu nad gitem.
    Já už tu vlastně ani nejsem. Abclinuxu umřelo.
    xkucf03 avatar 3.1.2014 20:15 xkucf03 | skóre: 49 | blog: xkucf03
    Rozbalit Rozbalit vše Re: ESR: Emacs by měl opustit bzr a přejít ke Gitu

    Že by pak Git měl konečně použitelné UI? To by bylo fajn. (ale stejně bych radši emulaci rozhraní Mercurialu)

    Mám rád, když se lidé přou, znamená to, že vědí, co dělají, a že mají směr. Frantovo.cz, SQL-DK, Relational pipes
    pavlix avatar 3.1.2014 21:26 pavlix | skóre: 54 | blog: pavlix
    Rozbalit Rozbalit vše Re: ESR: Emacs by měl opustit bzr a přejít ke Gitu
    Tož používat se to dá, jen je to trochu kostrbaté. Nejsem si jistý, jestli emulace nějakého stávajícího rozhraní je ta nejlepší cesta, ale pokud by nad gitovskými repozitáři umělo pracovat více různých nástrojů, tak by to určitě dobře posloužilo poznání různých přístupů.
    Já už tu vlastně ani nejsem. Abclinuxu umřelo.
    xkucf03 avatar 3.1.2014 21:49 xkucf03 | skóre: 49 | blog: xkucf03
    Rozbalit Rozbalit vše Re: ESR: Emacs by měl opustit bzr a přejít ke Gitu

    Jak jsem psal, bylo by to fajn. Ono je to hlavně o tom, že Git je spíš nízkoúrovňová databáze než systém pro správu verzí (který by sám o sobě nějak podporoval workflow při vývoji softwaru).

    Mám rád, když se lidé přou, znamená to, že vědí, co dělají, a že mají směr. Frantovo.cz, SQL-DK, Relational pipes
    pavlix avatar 3.1.2014 22:11 pavlix | skóre: 54 | blog: pavlix
    Rozbalit Rozbalit vše Re: ESR: Emacs by měl opustit bzr a přejít ke Gitu
    Jen pokud ignoruješ jeho vysokoúrovňové příkazy.
    Já už tu vlastně ani nejsem. Abclinuxu umřelo.
    6.1.2014 12:21 podlesh
    Rozbalit Rozbalit vše Re: ESR: Emacs by měl opustit bzr a přejít ke Gitu
    On asi naráží na to, že nad těmito vysokoúrovňovými příkazy je ještě celá další velká úroveň: workflow. Většina rozšířených VCS workflow neřeší, git dokonce myslím záměrně a je to jeden z důvodů popularity, protože různé projekty používají velmi odlišná workflow.
    pavlix avatar 6.1.2014 12:28 pavlix | skóre: 54 | blog: pavlix
    Rozbalit Rozbalit vše Re: ESR: Emacs by měl opustit bzr a přejít ke Gitu
    Psal o nízkoúrovňové databázi, což jsou podle mě typicky nízkoúrovňové příkazy pro manipulaci s objekty v databázi. Vysokoúrovňové příkazy už tvoří systém na správu verzí, ač nevynucuje konkrétní workflow.
    Já už tu vlastně ani nejsem. Abclinuxu umřelo.
    3.1.2014 20:17 David Jaša | skóre: 44 | blog: Dejvův blog
    Rozbalit Rozbalit vše Re: ESR: Emacs by měl opustit bzr a přejít ke Gitu
    přímo v článku:
    Could bzr have a second life as another UI for the Git file format, becoming part of the Git world rather than competing with it? Sure, I guess. Several people, including myself, have suggested this in the past. It would however still require a fair amount of work - bzr-git is unfinished. If it's just the UI you're after then it is probably easier to simply build a bzr-like Git UI from scratch, directly on top of something like libgit2 or Dulwich.
    pavlix avatar 3.1.2014 21:27 pavlix | skóre: 54 | blog: pavlix
    Rozbalit Rozbalit vše Re: ESR: Emacs by měl opustit bzr a přejít ke Gitu
    Díky.
    Já už tu vlastně ani nejsem. Abclinuxu umřelo.
    3.1.2014 21:12 Radim Kolář | skóre: 11
    Rozbalit Rozbalit vše Re: ESR: Emacs by měl opustit bzr a přejít ke Gitu
    Jeste se na bzr trochu dela.

    Bzr pouzivam a vyhovuje mi, s rychlosti nemam pri praktickem nasazeni problem. Pokud pouzivam git tak jen proto abych mohl posilat veci pres github.

    Jediny co mi u bzr chybi je cherry-pick
    3.1.2014 14:03 OldFrog {Ondra Nemecek} | skóre: 36 | blog: Žabákův notes | Praha
    Rozbalit Rozbalit vše Re: ESR: Emacs by měl opustit bzr a přejít ke Gitu
    Chápu to dobře, že hlavní problém bzr je špatný výkon u opravdu rozsáhlých projektů?
    -- OldFrog
    3.1.2014 14:12 OldFrog {Ondra Nemecek} | skóre: 36 | blog: Žabákův notes | Praha
    Rozbalit Rozbalit vše Re: ESR: Emacs by měl opustit bzr a přejít ke Gitu
    Protože jinak podle mě na verzovacím systému zas tolik nezáleží a současné distrubuované systému se používají všechny podobně a není problém se naučit pár nových příkazů, ne? Osobně bych systém neměnil, pokud neklade opravdové technologické překážky (např. tu limitující rychlost).

    Možná je to ale takových projektů jako je emacs jinak (nemám zkušenost).
    -- OldFrog
    GeoRW avatar 4.1.2014 11:30 GeoRW | skóre: 13 | blog: GeoRW | Bratislava
    Rozbalit Rozbalit vše Re: ESR: Emacs by měl opustit bzr a přejít ke Gitu
    Skor obava toho, ze vyvoj Bazaaru stagnuje a kedze Git vyhrava suboj o developerov a projekty, tak je lepsie prejst nanho, aby prip. mohol Emacs motivovat vyvojarov prispievat aj do neho :-) Inak Git je rychly a ma niektore navyse featury, ale pre 99.9% projektov (vratane Emacsu) ten rozdiel nehra ziadnu ulohu. BTW, Emacs uz aj tak skoro nikto nepuziva :-D
    "This is to be taken with a grain of salt." ACBF - Advanced Comic Book Format
    pavlix avatar 4.1.2014 11:34 pavlix | skóre: 54 | blog: pavlix
    Rozbalit Rozbalit vše Re: ESR: Emacs by měl opustit bzr a přejít ke Gitu
    Popravdě řečeno se při balíčkaření starám snad jen o jeden projekt v bzr a než se jím zabývat, tak radši nad stromem pustím quilt a spravuju si patche s ním. Takže tenhle argument vidím jako velmi silný.
    Já už tu vlastně ani nejsem. Abclinuxu umřelo.
    stativ avatar 4.1.2014 13:49 stativ | skóre: 54 | blog: SlaNé roury
    Rozbalit Rozbalit vše Re: ESR: Emacs by měl opustit bzr a přejít ke Gitu
    +1
    Ať sežeru elfa i s chlupama!!! ljirkovsky.wordpress.com stativ.tk
    4.1.2014 11:35 JS1 | skóre: 2 | blog: intuition_pump
    Rozbalit Rozbalit vše Re: ESR: Emacs by měl opustit bzr a přejít ke Gitu
    BTW, Emacs uz aj tak skoro nikto nepuziva :-D
    Nejsem si tak jisty, rekl bych, ze v posledni dobe Emacs zaziva urcity navrat, asi diky Lispovym (a dalsim) jazykum, a take diky zlepseni funkcionality, treba integraci systemu balicku, lepsi praci s fonty, atd.
    Lidstvo čelí v tomto století hrozbě civilizačního kolapsu. Podpořte hnutí klimatickakoalice.cz!
    pavlix avatar 4.1.2014 11:46 pavlix | skóre: 54 | blog: pavlix
    Rozbalit Rozbalit vše Re: ESR: Emacs by měl opustit bzr a přejít ke Gitu
    Emacs už má balíčkovací systém jako ostatní OS?
    Já už tu vlastně ani nejsem. Abclinuxu umřelo.
    4.1.2014 13:58 Martix. | skóre: 15
    Rozbalit Rozbalit vše Re: ESR: Emacs by měl opustit bzr a přejít ke Gitu
    +1 ELPA, Emacs už jen chybí ten kernel... :-D
    stativ avatar 4.1.2014 14:05 stativ | skóre: 54 | blog: SlaNé roury
    Rozbalit Rozbalit vše Re: ESR: Emacs by měl opustit bzr a přejít ke Gitu
    Však čekají na GNU Hurd.
    Ať sežeru elfa i s chlupama!!! ljirkovsky.wordpress.com stativ.tk
    Bedňa avatar 4.1.2014 17:32 Bedňa | skóre: 34 | blog: Žumpa | Horňany
    Rozbalit Rozbalit vše Re: ESR: Emacs by měl opustit bzr a přejít ke Gitu
    Nečakajú, však sa doň dá nabútovať z Linuxu a je to celkom sranda, hral som sa tým hodinku. Len tie skratky mi pripadajú na hlavu :-)
    KERNEL ULTRAS video channel >>>
    Conscript89 avatar 5.1.2014 15:17 Conscript89 | Brno
    Rozbalit Rozbalit vše Re: ESR: Emacs by měl opustit bzr a přejít ke Gitu
    No, myslim ze horsi nez VCS je pro novacka v projektu samotny elisp :)
    I can only show you the door. You're the one that has to walk through it.
    6.1.2014 11:28 JS1 | skóre: 2 | blog: intuition_pump
    Rozbalit Rozbalit vše Re: ESR: Emacs by měl opustit bzr a přejít ke Gitu
    :-) Co vy o tom muzete vedet..

    Je to prave naopak. Tim, ze se Elisp pouziva jak na konfiguraci, tak na rozsirovani, je ta "learning curve" daleko nizsi, nez u modernich IDE.

    Vim to z vlastni zkusenosti. Par rozsirujicich funkci jsem si do Emacsu uz napsal, ale studovat nejake zbesile Javove API pro rozsirovani treba Eclipse se mi opravdu nechce..

    Takze prave proto, ze je Emacs tak *snadne* rozsirit, ho ma kazdy nastaveny po svem. Uvazujte o tom.

    "Those who don't understand Lisp are condemned to reinvent it, poorly."

    (Jinak Emacs umi barevne odlisovani diffu samozrejme take, dokonce bych rekl, ze to je vec starsi nez ona IDE.)
    Lidstvo čelí v tomto století hrozbě civilizačního kolapsu. Podpořte hnutí klimatickakoalice.cz!
    xkucf03 avatar 6.1.2014 11:52 xkucf03 | skóre: 49 | blog: xkucf03
    Rozbalit Rozbalit vše Re: ESR: Emacs by měl opustit bzr a přejít ke Gitu
    ale studovat nejake zbesile Javove API pro rozsirovani treba Eclipse se mi opravdu nechce.

    Jakkoli může být API Eclipse zběsilé (neznám), výhoda je v tom, že máš k dispozici online dokumentaci (JavaDoc) tříd a metod a napovídání v IDE – víš jaké metody která třída nabízí, jakých typů mají být argumenty, jakých typů jsou návratové hodnoty a v důsledku toho zase víš, jaké metody na těch objektech můžeš volat – díky tomu se dá dobře učit za chodu.

    Mám rád, když se lidé přou, znamená to, že vědí, co dělají, a že mají směr. Frantovo.cz, SQL-DK, Relational pipes
    6.1.2014 12:34 JS1 | skóre: 2 | blog: intuition_pump
    Rozbalit Rozbalit vše Re: ESR: Emacs by měl opustit bzr a přejít ke Gitu
    Elisp a Emacs je take vyborne zdokumentovany.. Nejenom ze ma Emacs dokumentaci primo v sobe, dokonce je mozne primo skocit na zdrojak prislusne funkce. A napovidani to umi taky.
    Lidstvo čelí v tomto století hrozbě civilizačního kolapsu. Podpořte hnutí klimatickakoalice.cz!
    6.1.2014 13:28 Ivan
    Rozbalit Rozbalit vše Re: ESR: Emacs by měl opustit bzr a přejít ke Gitu
    Mensi plugin jsem napsal jak pro Emacs tak i pro Eclipse. U Emacsu jsem mel problem vybavit si po 10ti letech zaklady Lispu, ale nakonec jsem to dal. U Eclipse jsem mel problem, ze se vsechno hrozne rychle vyviji a vetsina navodu na internetu je neaktualni. Javadoc v tomhle pripade moc nepomuze, je potreba vedet jak presne poskladat ruzne tridy dohromady a hlavne co napsat do ruznych zbesilych XML formatu. Navic u Eclipse musite vyvijet plugin v jedne instanci a ladit a debugovat ve druhe. Celkove bych rekl, ze vyvoj pluginu pro Eclipse ma mnohem plossi learning curve. Uz jenom zprovozneni prostredi pro vyvoj pluginu mu zabralo cely den.
    6.1.2014 13:48 JS1 | skóre: 2 | blog: intuition_pump
    Rozbalit Rozbalit vše Re: ESR: Emacs by měl opustit bzr a přejít ke Gitu
    Celkove bych rekl, ze vyvoj pluginu pro Eclipse ma mnohem plossi learning curve.
    Asi jsi chtel napsat strmejsi, jestli jsem spravne pochopil ten komentar.
    Lidstvo čelí v tomto století hrozbě civilizačního kolapsu. Podpořte hnutí klimatickakoalice.cz!
    6.1.2014 16:46 David Jaša | skóre: 44 | blog: Dejvův blog
    Rozbalit Rozbalit vše Re: ESR: Emacs by měl opustit bzr a přejít ke Gitu
    Až nedávno jsem pochopil, že termit "učící křivka" má dva významy a zrovna v angličtině se používá častěji (výhradně?) ten druhý.
    6.1.2014 18:08 JS1 | skóre: 2 | blog: intuition_pump
    Rozbalit Rozbalit vše Re: ESR: Emacs by měl opustit bzr a přejít ke Gitu
    Vida, to mas pravdu. Me vyhovuje ten vyznam, ktery odpovida analogii vystupu na horu. Strmejsi -> clovek se vic nadre.
    Lidstvo čelí v tomto století hrozbě civilizačního kolapsu. Podpořte hnutí klimatickakoalice.cz!
    7.1.2014 09:15 Ivan
    Rozbalit Rozbalit vše Offtopic: Re: ESR: Emacs by měl opustit bzr a přejít ke Gitu
    Aha. Me utkvel v pameti obrazek z nejakyho XKCD komixu kde byl na horizontalni ose cas(resp. usili) a na vertikalni ose uzitek. Svym postem jsem chtel rict ze u Eclipse prekvapive dlouho trva nez storite neco uzitecneho (v mym pripade to byl patch pro plugin zalozeny na XTEXTu).

    7.1.2014 09:45 JS1 | skóre: 2 | blog: intuition_pump
    Rozbalit Rozbalit vše Re: Offtopic: Re: ESR: Emacs by měl opustit bzr a přejít ke Gitu
    No hlavne, ze si rozumime. :-) Ja jsem zadny Eclipse plugin nedelal, ale prave hlavne ty XML konfiguraky me desi. Je to asi vec, ktera mi nejvic vadi na Javovem ekosystemu - oni delaji DSL a nechteji si to proste priznat.
    Lidstvo čelí v tomto století hrozbě civilizačního kolapsu. Podpořte hnutí klimatickakoalice.cz!
    xkucf03 avatar 7.1.2014 10:40 xkucf03 | skóre: 49 | blog: xkucf03
    Rozbalit Rozbalit vše Re: Offtopic: Re: ESR: Emacs by měl opustit bzr a přejít ke Gitu

    Co je na tom XML tak děsivého? Copak tolik záleží na tom, jestli ty závorky kolem dat jsou špičaté, kulaté nebo složené? Nevím, jak u Eclipse, ale obvykle ke XML dostaneš schéma, takže víš, co tam máš psát.

    Je fakt, že někdy je to XML jen formálně a ve skutečnosti je v něm zapsaný procedurální program, ve kterém voláš konstruktory tříd, metody, předáváš parametry… to mi přijde trochu zbytečné, ale není to chyba XML, ale toho, kdo ho takhle použil. Radši mám, když konfigurace jsou neživá data (ne program), ale opačný přístup může mít taky něco do sebe. Např. logování v Javě můžeš nakonfigurovat přes properties soubor (klíč=hodnota), což znamená nastudovat si dokumentaci, zjistit, jaké klíče tam můžou být, jak se zapisují zanořené struktury a pak to vyzkoušíš, jestli jsi to pochopil správně a loguje to, jak má. Nebo můžeš místo properties souboru poskytnout název třídy – tzn. napíšeš jednoduchý program, který inicializuje logovací subsystém – píšeš to v jazyce, který znáš, IDE ti napovídá názvy metod a datové typy a během psaní se ti to pod rukama kompiluje, takže máš hned kontrolu chyb. To mi přijde celkem dobré. Jako druhou dobrou možnost vidím XML s dobře udělaným schématem – tam máš taky online nápovědu a okamžitou kontrolu.

    Mám rád, když se lidé přou, znamená to, že vědí, co dělají, a že mají směr. Frantovo.cz, SQL-DK, Relational pipes
    7.1.2014 13:38 Martin Mareš
    Rozbalit Rozbalit vše Re: Offtopic: Re: ESR: Emacs by měl opustit bzr a přejít ke Gitu
    Co je na tom XML tak děsivého?
    Že je to věc na první pohled jednoduchá, ale ve skutečnosti nebývale komplikovaná a obskurní. Zkoušel jste si někdy pečlivě přečíst specifikaci?
    xkucf03 avatar 7.1.2014 13:59 xkucf03 | skóre: 49 | blog: xkucf03
    Rozbalit Rozbalit vše Re: Offtopic: Re: ESR: Emacs by měl opustit bzr a přejít ke Gitu

    Celou ne, ale občas si v tom čtu, když si potřebuji něco ujasnit – přijde mi to stejně srozumitelné jako běžné specifikace :-)

    Mám rád, když se lidé přou, znamená to, že vědí, co dělají, a že mají směr. Frantovo.cz, SQL-DK, Relational pipes
    7.1.2014 17:39 Martin Mareš
    Rozbalit Rozbalit vše Re: Offtopic: Re: ESR: Emacs by měl opustit bzr a přejít ke Gitu
    Především mi přijde zásadní otázka, proč pro tak jednoduchý cíl (zápis stromů) zvolit něco takhle složitého. XML neumí oproti lispovským S-expressions nic zajímavého navíc, a přesto je jeho specifikace (i implementace) o několik řádů složitější.
    7.1.2014 18:10 JS1 | skóre: 2 | blog: intuition_pump
    Rozbalit Rozbalit vše Re: Offtopic: Re: ESR: Emacs by měl opustit bzr a přejít ke Gitu
    Ja bych byl optimista, dneska uz hodne lidi preferuje JSON, treba se nakonec k tem s-expressions nejak dokonverguje.. :-)
    Lidstvo čelí v tomto století hrozbě civilizačního kolapsu. Podpořte hnutí klimatickakoalice.cz!
    7.1.2014 14:48 JS1 | skóre: 2 | blog: intuition_pump
    Rozbalit Rozbalit vše Re: Offtopic: Re: ESR: Emacs by měl opustit bzr a přejít ke Gitu
    Narozdil od Martina si nemyslim, ze zrovna syntaxe je ten nejvetsi problem (i kdyz zrovna v pripade XML to je dost hrozne).

    Problem je prave v te myslence, ze konfigurace (chces-li to tak nazvat, neni to uplne vhodne) maji byt data. U uzivatelskeho konfiguraku se to da pochopit (ale i tam to u vetsich systemu narazi), kvuli bezpecnosti.

    Ale u programu samotneho, treba u statickych dat, jak ma vypadat layout? Zazivam tohle ted na Androidu, a je to hruza. Potiz je totiz v tom, ze obcas je potreba neco vytvaret dynamicky (napr. ja chci udelat paletu tlacitek). Takze se podpore pro tu konfiguraci primo v jazyce stejne nevyhnes. To co vznikne bude hybrid - kus bude v XML, druhy kus bude v Jave.

    Coz ma mnoho nepraktickych dusledku. Napr. chci neco statickeho predelat na dynamicke, nebo jenom malinko "zdynamicnit". Dusledek je, ze ted mam definici rozkouskovanou na dvou mistech, v ruznych zapisech. (Podobnym problemem trpi Javascriptove aplikace, kdy se cast HTML/CSS vytvari dynamicky..)

    Ve skutecnosti by ale stacil jen jeden jazyk, dostatecne silny na to, aby se v nem daly ty DSL vytvaret. V nem by se pak dalo zapsat oboji, v unifikovane syntaxi, a bylo by to krasne prehledne.

    Tohle neni nova myslenka - uz ji objevil Lisp, Forth, do jiste miry i Haskell.. (o tom poslednim ti asi rekne vic Martin, ale myslim, ze to ukazuje, ze to jde realizovat i s typovou kontrolou, pokud je to tvoje uchylka.. ;-))

    Proste, Javiste by si IMHO meli priznat, ze domenove specifickym jazykum se v programovani nelze vyhnout. Vykaslat se na XML a rozsirit si Javu tak, aby to slo napsat primo v ni.
    Lidstvo čelí v tomto století hrozbě civilizačního kolapsu. Podpořte hnutí klimatickakoalice.cz!
    xkucf03 avatar 7.1.2014 15:32 xkucf03 | skóre: 49 | blog: xkucf03
    Rozbalit Rozbalit vše Re: Offtopic: Re: ESR: Emacs by měl opustit bzr a přejít ke Gitu

    Zní to dobře, ale obávám se, že to není pro každého. Pro běžného uživatele je to příliš mocný nástroj a hrozí, že si to rozvrtá. Taky to dost odhaluje vnitřní implementaci – to může být problém, když ji chceš změnit → staré konfiguráky (ve kterých může být zapsané cokoli) pak přestanou fungovat (nebo tě to omezuje v možnostech měnit vnitřní uspořádání programu). Neživá data (ať už XML nebo něco jiného) můžeš taky snadno vygenerovat, převést na něco jiného, napsat k nim GUI editor nebo aspoň zobrazovač – protože je to uzavřená množina kombinací, které lze vytvořit. Jakmile je to jednou program, tak ta složitost je neomezená a musíš se k tomu už vždy chovat jako k programu.

    To co vznikne bude hybrid - kus bude v XML, druhy kus bude v Jave.

    Zrovna na takovém programu pracuji – výchozí konfiguraci1 mám v Javě2 a uživatel si ji může překrýt svojí konfigurací v XML – tam má celkem omezené možnosti, ale zase je to jednoduché a snadno pochopitelné – a kdyby mu to nestačilo, tak si napíše vlastní třídu v Javě a odkáže se na ní z té konfigurace.

    Vykaslat se na XML a rozsirit si Javu tak, aby to slo napsat primo v ni.

    Ono není potřeba rozšiřovat Javu jako takovou – součástí Javy je JSR 223: Scripting for the Java Platform – konfigurace může být třeba v Groovy a z něj se budou volat javovské metody, které nějak zkonfigurují tu aplikaci. Myslím, že nástroje celkem jsou – otázka je, jestli by se uživateli chtělo „programovat konfiguraci“ – tady mi právě přijde, že pro něj bude stravitelnější napsat nějaké to XML, kde mu editor poradí, jaké elementy/atributy tam má psát. Jak by to bylo v případě skriptu? Dejme tomu, že zná ten jazyk – ale určitě nezná metody/funkce/konstrukce, které ten konfigurační DSL tvoří – to by si musel nastudovat v nějaké dokumentaci.

    V případě toho mého XML si otevřeš konfigurák v Emacsu a začneš psát – a editor ti na základě Relax NG schématu říká, jestli to píšeš dobře nebo ne. Dole hned vidíš (nXML Valid) nebo naopak konkrétní chybu. V případě nějakého skriptu/DSL by Emacs (nebo jiný editor) tuhle informaci vzal kde?

    Něco jiného by bylo, kdyby konfigurákem byla Javovská třída – tu by si uživatel otevřel v IDE a všechny tyhle informace, nápovědy a kontroly by tam měl. Jenže to by jednak uživatelé remcali, že pro pohodlnou konfiguraci potřebují IDE a nestačí jim jejich oblíbený XML editor, a jednak by to byl asi až příliš mocný nástroj v rukou uživatele (viz výše).

    [1] ono je to na hraně mezi konfigurací a součástí samotného programu
    [2] tzn. typová kontrola a kontrola syntaxe zadarmo, používání společných konstant (nemám tam nějaké magické textové řetězce, které by na sebe musely pasovat a musel se mezi nimi udržovat soulad)

    Mám rád, když se lidé přou, znamená to, že vědí, co dělají, a že mají směr. Frantovo.cz, SQL-DK, Relational pipes
    7.1.2014 15:58 JS1 | skóre: 2 | blog: intuition_pump
    Rozbalit Rozbalit vše Re: Offtopic: Re: ESR: Emacs by měl opustit bzr a přejít ke Gitu
    Samozrejme, ten argument s konfiguraci je trochu mimo, protoze uz na zacatku jasne rikam, ze nemluvim o konfiguraci, ale o vecech, ktere se zapisuji v XML a pritom nejsou soucasti konfigurace (jako treba layouty na Androidu, Ant build "skripty", ruzne DI..).

    To programovani konfigurace ma hlavni vyhodu - muzes si vybrat vlastni parametrizaci. O tom to cele je.

    Ale zapomen na to, vidim, ze jsi ztraceny pripad..
    Lidstvo čelí v tomto století hrozbě civilizačního kolapsu. Podpořte hnutí klimatickakoalice.cz!
    xkucf03 avatar 7.1.2014 17:51 xkucf03 | skóre: 49 | blog: xkucf03
    Rozbalit Rozbalit vše Re: Offtopic: Re: ESR: Emacs by měl opustit bzr a přejít ke Gitu
    treba layouty

    Zrovna tohle je dobrý příklad. Když to budou data, tak může existovat nějaký vizuální návrhář, kde si člověk to GUI nakliká. Dokonce to ani nemusí dělat programátor, ale někdo přes GUI – a programátor to už „jen“ oživí.

    Jenže když to bude program, tak žádná taková editace není možná.

    Totéž platí pro uživatelskou konfiguraci – dejme tomu, že uživatel si chce nastavit nové databázové připojení. V případě XML k tomu může existovat přívětivý editor, kde si všechno nakliká, aniž by přišel do styku se zdrojákem. Na druhou stranu v případě programu si může udělat konfiguraci třeba takovou, že každý den v týdnu uvidí jiná databázová spojení. Každé má svoje.

    Rozumné mi přijde oba přístupy kombinovat – co jde udělat deklarativně, to udělat tak, a co nejde, pro to mít nějaký dodatečný skript/program, který to doladí.

    Ale zapomen na to, vidim, ze jsi ztraceny pripad..

    To bych nerad :-) ale chci dát uživatelům nějakou úroveň pohodlí a možností. Dejme tomu, že pro konfiguraci použiji nějaké DSL nebo prostě něco jiného než XML. Jak se mám dostat na stejnou úroveň přívětivosti, kterou mi teď nabízí XML a základní1 instalace Emacsu? Tzn. editor napovídá, kontroluje syntaxi a hlásí chyby. Uživatel nemusí vědět, že ta struktura je zrovna takováhle:

    <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
    <configuration xmlns="…">
    
        <database>
            <name>…</name>
            <url>…</url>
            <userName>…</userName>
            <password>…</password>
        </database>
    
        <database>
            …
        </database>
    
    </configuration>

    Prostě otevře konfigurák v editoru a všechno potřebné se dozví tam. Rád se přiučím, jak podobného výsledku dosáhnout pomocí něčeho jiného než XML.

    [1] v Debianu/Ubuntu, ale to bude asi všude stejné

    Mám rád, když se lidé přou, znamená to, že vědí, co dělají, a že mají směr. Frantovo.cz, SQL-DK, Relational pipes
    7.1.2014 18:16 JS1 | skóre: 2 | blog: intuition_pump
    Rozbalit Rozbalit vše Re: Offtopic: Re: ESR: Emacs by měl opustit bzr a přejít ke Gitu
    Ale tobe porad unika ta pointa - nic z toho co rikas se navzajem nevylucuje s tim mit to jako DSL v ramci skutecneho programovaciho jazyka.

    Dokonce i Eclipse me pri vyvoji na Androidu prekvapil, kdyz ve skutecnosti ten layout zobrazuje i z toho, co se definuje v Jave. To uz mohli interpretovat tu Javu rovnou.. Proste si to tim XML formatem jenom zbytecne komplikuji.
    Lidstvo čelí v tomto století hrozbě civilizačního kolapsu. Podpořte hnutí klimatickakoalice.cz!
    xkucf03 avatar 7.1.2014 19:25 xkucf03 | skóre: 49 | blog: xkucf03
    Rozbalit Rozbalit vše Re: Offtopic: Re: ESR: Emacs by měl opustit bzr a přejít ke Gitu
    nic z toho co rikas se navzajem nevylucuje s tim mit to jako DSL v ramci skutecneho programovaciho jazyka

    Jedna věc je, jestli se to teoreticky nevylučuje a druhá věc: jsou na to běžně v praxi dostupné nástroje?

    • XML: běžný editor + schéma → uživatel ví, co tam může psát a jestli tam nemá chyby
    • DSL: jak dosáhnout srovnatelného výsledku??

    Přijde mi to, jako bys mi radil psát programy pro mainframy – sice to může být teoreticky lepší, ale většina lidí doma mainframe nemá a takový program jim bude na nic. Ale XML lidi znají. I když na něj třeba občas nadávají, snad každý ví, jaké závorky a uvozovky tam má psát. Běžné editory, které ty lidi už mají, jim umí zvýraznit syntaxi, načít schéma, napovídat, validovat. V distribucích jsou nástroje jako xpath, xmllint nebo xsltproc.

    Chápu tu myšlenku, co tu padla, že uživatel se naučí psát konfiguraci a pak už mu zbývá jen málo a už si píše rozšíření, plynule přechází od konfigurování k programování. Ano, líbí se mi to… Na druhou stranu: programy se píší v mnoha různých jazycích – copak má uživatel umět jazyk každého programu, který používá? V tomhle je XML docela dobrý jednotící prvek – píšu konfiguraci pořád stejně a můžu abstrahovat od toho, v jakém jazyce je ten který program napsaný – jednou to může být C++ jednou Java jindy Perl… pro základní konfiguraci a použití programu ani nemusím vědět, v jakém jazyce je. Stejně tak můžu používat pořád ten samý editor pro úpravy konfiguráků.

    Možná je cesta psát programy jako hromadu modulů/funkcí, které se poslepují pomocí Guile, a tím dostanou výslednou formu programu, a současně se v Guile bude psát i konfigurace… ale stále tomu v praxi chybí některé nástroje a stále platí některé moje připomínky: deklarativní (data) vs. procedurální (program) a z toho vyplývající výhody/nevýhody.

    To uz mohli interpretovat tu Javu rovnou.

    Interpretovat kód programu není tak složité, horší je opačný postup: mám výsledek, ten nějak upravím (ať už vizuálně klikáním nebo jinak) a pak z toho chci dostat opět zdrojový kód – a ne ledajaký kód, ale ten původní, ve kterém budou provedené jen minimální nutné změny. Když ten DSL bude dostatečně omezený a deklarativní, tak by to jít mělo – ale když bude plnohodnotným programovacím jazykem a bude procedurálním, tak to je asi úkol pro umělou inteligenci.

    Mám rád, když se lidé přou, znamená to, že vědí, co dělají, a že mají směr. Frantovo.cz, SQL-DK, Relational pipes
    8.1.2014 11:16 JS1 | skóre: 2 | blog: intuition_pump
    Rozbalit Rozbalit vše Re: Offtopic: Re: ESR: Emacs by měl opustit bzr a přejít ke Gitu
    Jedna věc je, jestli se to teoreticky nevylučuje a druhá věc: jsou na to běžně v praxi dostupné nástroje?
    Kdyby navrhari nebyli idioti a netravili cas implementaci XML rozhrani, mohli by ty nastroje davno mit. Mozna se pletu, ale komercni Lispova prostredi nebo Smalltalk takove nastroje maji take, adaptovane pro jejich konkretni jazyk.
    Ale XML lidi znají. I když na něj třeba občas nadávají, snad každý ví, jaké závorky a uvozovky tam má psát. Běžné editory, které ty lidi už mají, jim umí zvýraznit syntaxi, načít schéma, napovídat, validovat.
    Tohle je myslim jadro toho problemu (a odpovida to na Martinovu neprimou otazku, proc tolik lidi vidi v XML kladivo). Ty hodnotis veci prilis povrchne, podle syntaxe. Jenze o syntaxi to vubec neni! Podstatna je semantika.
    V tomhle je XML docela dobrý jednotící prvek – píšu konfiguraci pořád stejně a můžu abstrahovat od toho, v jakém jazyce je ten který program napsaný – jednou to může být C++ jednou Java jindy Perl… pro základní konfiguraci a použití programu ani nemusím vědět, v jakém jazyce je. Stejně tak můžu používat pořád ten samý editor pro úpravy konfiguráků.
    A to je prave ten omyl, ktery souvisi s tim povrchnim pohledem. Ve skutecnosti to nemuzes takto delat, protoze je podstatna semantika toho XML, nikoli syntax - jak pise Ivan. Jestli se to zapisuje jako XML nebo sexpy nebo Java, je naprosto nepodstatne. A prave proto je idealni pouzit stejnou syntaxi, jako ma programovaci jazyk, ktery pouzivas (a proto je dulezite, aby ten jazyk umel snadno definovat a kombinovat jak deklarativni, tak proceduralni zapisy).
    deklarativní (data) vs. procedurální (program) a z toho vyplývající výhody/nevýhody.
    Ale ja nejsem proti deklarativnimu zapisu! Jen jsem proti tomu omezit se jen na deklarativni zapis, a to je trochu rozdil. Protoze mnohokrat je moznost proceduralniho generovani deklarativniho zapisu velice uzitecna.
    Interpretovat kód programu není tak složité, horší je opačný postup: mám výsledek, ten nějak upravím (ať už vizuálně klikáním nebo jinak) a pak z toho chci dostat opět zdrojový kód – a ne ledajaký kód, ale ten původní, ve kterém budou provedené jen minimální nutné změny. Když ten DSL bude dostatečně omezený a deklarativní, tak by to jít mělo – ale když bude plnohodnotným programovacím jazykem a bude procedurálním, tak to je asi úkol pro umělou inteligenci.
    Vzdyt to delat nemusis. GUI generator proste vygeneruje deklarativni zapis. Pokud ho zmenis tak, ze pouzijes nejake proceduralni procesy, rekne ti to proste - sorry, nemuzu to znovu zobrazit, nerozumim tomu. Porad ti to ale dava vic moznosti nez to zakazat uplne.

    Prikladem muze byt treba editor nastaveni v Emacsu. Ten generuje ciste deklarativni sexpy. Pokud je zmenis tak, ze budou proceduralni, holt to nebude schopen zpetne zpracovat. Coz ti nemusi vadit - predpoklada se, ze kdyz uz to menis rucne, tak vis co delas.
    Lidstvo čelí v tomto století hrozbě civilizačního kolapsu. Podpořte hnutí klimatickakoalice.cz!
    xkucf03 avatar 8.1.2014 12:24 xkucf03 | skóre: 49 | blog: xkucf03
    Rozbalit Rozbalit vše Re: Offtopic: Re: ESR: Emacs by měl opustit bzr a přejít ke Gitu
    Ty hodnotis veci prilis povrchne, podle syntaxe. Jenze o syntaxi to vubec neni! Podstatna je semantika.

    Zrovna o té syntaxi a sémantice jsem už jednou něco psal: Jak (ne)používat XML – při popisovaném použití je to XML opravdu na nic, bereš si z něj jen syntaxi a o sémantice nevíš nic, tu si musíš vycucat z prstu nebo nastudovat někde bokem. Ale když to XML použiješ správně, tak tam máš jak syntaxi (vychází ze samotného XML), tak sémantiku (vychází ze schématu, které jsi k tomu formátu dodal).

    Jestli se to zapisuje jako XML nebo sexpy nebo Java, je naprosto nepodstatne. A prave proto je idealni pouzit stejnou syntaxi, jako ma programovaci jazyk, ktery pouzivas

    Může být. Netrvám na konkrétní syntaxi plné ostrých závorek a uvozovek, klidně se ten strom objektů může zapisovat jinak a klidně stejnou syntaxí jako zbytek programu, s tím fakt nemám problém a asi by se mi to i líbilo. Ale potřebuji k tomu odpovídající nástroje – takové, které poskytnou srovnatelné pohodlí jako u toho XML. Tzn. např. textový editor, který si načte javovské třídy (nebo jiné definice) a bude schopný uživateli radit, jaké položky tam může vyplnit, poskytovat k nim online dokumentaci a hlásit mu případné chyby (jak v syntaxi tak sémantice).

    Ještě k té abstrakci a nezávislosti na jazyku: dejme tomu, že jsem admin a na serveru mám aplikace psané ve třech různých jazycích – asi nebude moc praktické mít tři různé editory nebo si instalovat tři různé moduly do editoru, pro ty různé syntaxe (což je způsobené tím, že autor aplikace chtěl mít konfiguraci ve stejném jazyce jako program). Naopak by se mi líbilo, kdyby všechny konfiguráky byly v jedné syntaxi (ať už jakékoli, nemusí to být XML), já měl jen jeden editor a vždy si pouze načetl schéma pro danou sémantiku.

    Ty se na to díváš z pohledu programátora a chceš používat jeden jazyk – ale když se na to podíváš z pohledu uživatele/administrátora, tak ten by taky rád používat stejný jazyk pro konfiguraci aplikací (naprogramovaných v různých jazycích). To je neřešitelný rozpor – buď by bylo potřeba psát všechny aplikace v jednom jazyce (kterém?) nebo se prostě jedna strana (programátor nebo uživatel) musí přizpůsobit.

    Vzdyt to delat nemusis. GUI generator proste vygeneruje deklarativni zapis. Pokud ho zmenis tak, ze pouzijes nejake proceduralni procesy, rekne ti to proste - sorry, nemuzu to znovu zobrazit, nerozumim tomu. Porad ti to ale dava vic moznosti nez to zakazat uplne.

    Tam se ale snadno dostaneš do pasti – lehce si vygeneruješ spoustu kódu, dokud je deklarativní, tak se to dá ukočírovat1, ale jakmile to jednou překlopíš do procedurální roviny, tak už není cesty zpět a máš hromadu kódu, se kterou se už musíš nějak vypořádat sám.

    Líbí se mi, jak tohle řeší Netbeans – GUI si tam můžeš naklikat, jeho deklarativní popis je uložený v nějakém XML a z něj se generuje procedurální tvar v Javě – a některé jeho části jsou needitovatelné – právě proto, aby bylo možné je kdykoli přegenerovat z toho deklarativního popisu. Ty pak píšeš vnitřky těch vygenerovaných metod (např. obsluha událostí tlačítek), kde máš typovou kontrolu a všechno pohodlí tvého programovacího jazyka, ale nemůžeš editovat signaturu té metody, protože pak by nepasovala na ten zbytek (můžeš ji leda smazat). Ty needitovatelné části kódu ti ale nebrání v tom, aby sis tam dopsat inicializační metodu, která už procedurálně doladí to GUI, třeba tam dynamicky vygeneruje tlačítka do deklarativně připraveného panelu nebo naplní texty a popisy.

    Jak jsem psal, netrvám na konkrétní syntaxi a klidně bych i uvítal, kdyby ta syntaxe deklarativních a procedurálních částí byla podobná, vycházela ze stejného jazyka, ale zatím jsem nic takového (s vhodným ekosystémem nástrojů kolem toho) prostě neviděl.

    Prikladem muze byt treba editor nastaveni v Emacsu. Ten generuje ciste deklarativni sexpy. Pokud je zmenis tak, ze budou proceduralni, holt to nebude schopen zpetne zpracovat. Coz ti nemusi vadit - predpoklada se, ze kdyz uz to menis rucne, tak vis co delas.

    Ale to, že uživatel je schopný psát procedurálně, ještě neznamená, že to tak chce dělat vždycky – já např. taky umím dělat procedurálně GUI ve Swingu, ale pokud to jde, tak si ho radši naklikám (tzn. leze z toho nějaké deklarativní XML a z něj se teprve generuje procedurální kód) a procedurálně napíšu jen to nezbytně nutné – a ty deklarativní části můžu kdykoli editovat v GUI editoru.

    [1] slušný nástroj, který ti umožnil snadno něco naklikat, ti to umožní i snadno smazat nebo nějak hromadně změnit

    Mám rád, když se lidé přou, znamená to, že vědí, co dělají, a že mají směr. Frantovo.cz, SQL-DK, Relational pipes
    8.1.2014 13:50 kralyk z abclinuxu | skóre: 29 | blog:
    Rozbalit Rozbalit vše Re: Offtopic: Re: ESR: Emacs by měl opustit bzr a přejít ke Gitu
    Zatímco syntaxi XML zná prakticky každý, XML schémata, XSLT a tyhle věci už zná podstatně méně lidí...
    pavlix avatar 8.1.2014 13:52 pavlix | skóre: 54 | blog: pavlix
    Rozbalit Rozbalit vše Re: Offtopic: Re: ESR: Emacs by měl opustit bzr a přejít ke Gitu
    A z těch co znají, má z nich ještě podstatně méně radost.
    Já už tu vlastně ani nejsem. Abclinuxu umřelo.
    xkucf03 avatar 8.1.2014 14:07 xkucf03 | skóre: 49 | blog: xkucf03
    Rozbalit Rozbalit vše Re: Offtopic: Re: ESR: Emacs by měl opustit bzr a přejít ke Gitu

    A kolik lidí ovládá Lisp nebo jiný programovací jazyk?

    Navíc nemusíš umět psát schémata nebo XSLT na to, aby sis pustil xsltproc a podíval se třeba na výsledné XHTML v prohlížeči, nebo aby sis do editoru načetl XSD a věděl, že máš XML dokument správně, nebo kde je v něm chyba.

    Mám rád, když se lidé přou, znamená to, že vědí, co dělají, a že mají směr. Frantovo.cz, SQL-DK, Relational pipes
    8.1.2014 14:32 kralyk z abclinuxu | skóre: 29 | blog:
    Rozbalit Rozbalit vše Re: Offtopic: Re: ESR: Emacs by měl opustit bzr a přejít ke Gitu
    A kolik lidí ovládá Lisp nebo jiný programovací jazyk?
    Když už bych si musel vybrat mezi naučit se základy Lispu, nebo naučit se XML schémata, bral bych osobně to první. No ale máme i rozšířenější jazyky, např. JS+JSON, kde je velmi snadné psát jak deklarativní, tak ale i procedurální kód (používá Grunt), dále třeba Lua (používá premake), dál taky lidi často píšou build v pythonu (třeba botan, boost,...). Taky se používají různé DSL, např. CMake má imho docela pěkný a velmi snadno zvládnutelný DSL.
    Navíc nemusíš umět psát schémata nebo XSLT na to, aby sis pustil xsltproc a podíval se třeba na výsledné XHTML v prohlížeči, nebo aby sis do editoru načetl XSD a věděl, že máš XML dokument správně, nebo kde je v něm chyba.
    Vůbec nevim co je xsltproc, neznám XSLT a naučit se ho by byla v zásadě stejná práce, jako naučit se některé z výše jmenovaných řešení.
    xkucf03 avatar 8.1.2014 15:45 xkucf03 | skóre: 49 | blog: xkucf03
    Rozbalit Rozbalit vše Re: Offtopic: Re: ESR: Emacs by měl opustit bzr a přejít ke Gitu
    No ale máme i rozšířenější jazyky, např. JS+JSON, kde je velmi snadné psát jak deklarativní, tak ale i procedurální kód (používá Grunt), dále třeba Lua (používá premake), dál taky lidi často píšou build v pythonu (třeba botan, boost,...). Taky se používají různé DSL, např. CMake má imho docela pěkný a velmi snadno zvládnutelný DSL.

    1) Ano, máme mnoho různých jazyků, ale který z nich vybrat? Nakonec se dostaneš k tomu rozporu popsanému v #131 – programátor by chtěl používat jeden jazyk pro programování i konfiguraci vs. uživatel/administrátor by chtěl používat stejnou syntaxi pro konfiguráky programů psaných v různých jazycích.

    2) Kde jsou ty nástroje? Konkrétní SW, který by se dal použít teď hned v praxi – ne nějaké teoretické spekulace o tom, co by všechno bylo možné.

    Chci, aby si uživatel otevřel můj konfigurák ve svém oblíbeném editoru (např. Emacs) a ten mu kontroloval validitu, hlásil chyby a napovídal možné konfigurační položky – aby nemusel lovit tu sémantiku v nějakých tutoriálech na webu. Aby to byla nějaká známá syntaxe, ne nějaká miliontá první obskurní „jednoduchá“ syntaxe, kde sice stačí napsat méně písmenek, ale uživatel bude znova a znova dumat nad tím, jestli mezi klíčem a hodnotou má být = nebo :, jestli na koncích řádků musí být středníky, a jak se proboha zapisují seznamy.

    JS+JSON

    JavaScript by možná použít šel, zná ho spousta lidí od webu… a taky se pro procedurální konfiguraci/skriptování někdy používá (resp. používá se ECMAScript). Ale JSON je zabitý tím, že neumí ani ty pitomé komentáře, a i v té jednoduchosti je takový polovičatý – např. nutnost psát názvy klíčů do uvozovek – to už rovnou můžu psát XML atributy název="hodnota".

    neznám XSLT a naučit se ho by byla v zásadě stejná práce, jako naučit se některé z výše jmenovaných řešení.

    Vtip je v tom, že XSLT se ani moc učit nemusíš. Transformace jde navrhnout tak, že XSL z velké části odráží strukturu výsledného dokumentu (třeba XHTML nebo nějaký XML formát, který uživatel zná a chce ho transformací získat) a sem tam v ní jsou nějaké IFy a cykly… Je to poměrně intuitivní a můžeš to bát jako jednoduchou šablonu – příklad: generuje se XHTML výstup a v něm jsou nečíslované seznamy, ty bys ale radši tabulky, tak otevřeš tu šablonu a předěláš to na tabulky – jediné, co k tomu potřebuješ znát, jsou základy HTML. A to díky tomu, že ta šablona kopíruje strukturu a syntaxi výsledného dokumentu, kterému rozumíš. Případně to může být XSLT, které generuje prostý text, pak je to ještě jednodušší.

    Kdyby to bylo třeba v Lispu nebo Pythonu, tak možná budeš umět přepsat <ul> na <ol>1, ale budeš umět předělat seznam na tabulku? Zjistit, jak přidat další úroveň elementů nebo třeba atributy… to bude o dost složitější než v tom XSLT.

    [1] pokud se tam nepoužije nějaká abstrakce, která by před tebou skryla řetězce "ol" a "ul"

    Mám rád, když se lidé přou, znamená to, že vědí, co dělají, a že mají směr. Frantovo.cz, SQL-DK, Relational pipes
    8.1.2014 17:10 kralyk z abclinuxu | skóre: 29 | blog:
    Rozbalit Rozbalit vše Re: Offtopic: Re: ESR: Emacs by měl opustit bzr a přejít ke Gitu
    Ano, máme mnoho různých jazyků, ale který z nich vybrat?
    Zejména podle okolností - jaký nástroj na jakou platformu chci podporovat...
    Kde jsou ty nástroje? Konkrétní SW, který by se dal použít teď hned v praxi – ne nějaké teoretické spekulace o tom, co by všechno bylo možné.
    Snažil jsem se u každého uvést konkrétní nástroj.

    JSON má v absenci komentářů určitě nevýhodu (proto si např. sublime komentáře do JSONu neoficiálně přidal, otázka je, jestli to je dobře), ale imho to vyváží snadnost té integrace s JS (resp. ECMAScript).
    Vtip je v tom, že XSLT se ani moc učit nemusíš. Transformace jde navrhnout tak, že XSL z velké části odráží strukturu výsledného dokumentu (třeba XHTML nebo nějaký XML formát, který uživatel zná a chce ho transformací získat) a sem tam v ní jsou nějaké IFy a cykly…
    Úplně stejný argument platí pro ty ostatní technologie - prakticky všechny z nich se člověk snadno naučí, pokud už je nezná, navíc u nich je imho lepší šance, že budou užitečné i jinde.
    Kdyby to bylo třeba v Lispu nebo Pythonu, tak možná budeš umět přepsat <ul> na <ol>1, ale budeš umět předělat seznam na tabulku? Zjistit, jak přidat další úroveň elementů nebo třeba atributy… to bude o dost složitější než v tom XSLT.
    Nebude, protože python podporuje XML (nevim jak Lisp, ale počítám, že taky). Onehdná jsem přesně něco takového potřeboval udělat - přečíst jedno XML, udělat v nějaký změny dat a roztřídit do množiny jiných XML podle určitých podmínek... V pythonu to bylo celkem triviální a nemusel jsem se učit další jazyk+toolset.

    Navíc to zdrojové XML bylo potřeba načíst z něčeho obskurního (nějakej vlastní formát jednoho softwaru, kterej si kdosi v jedný firmě ubastlil). V pythonu to bylo celkem triviální (pár řádek), v XSLT by něco takovýho nebylo možný, musel bys stejně použít nějakej jinej jazyk/nástroj a k němu XSLT, a náhle jsme opět u toho samého problému jako na začátku diskuse: XML se v tý chvíli stává pátým kolem u vozu.
    9.1.2014 14:59 kralyk z abclinuxu | skóre: 29 | blog:
    Rozbalit Rozbalit vše Re: Offtopic: Re: ESR: Emacs by měl opustit bzr a přejít ke Gitu
    JSON má v absenci komentářů určitě nevýhodu
    Tady by ještě chtělo dodat, že komentáře v XML sice jsou, ale jsou dost debilně řešený (7 znaků na komentář - wtf? Nefunguje nesting, v komentu nesmí být '--').
    xkucf03 avatar 9.1.2014 15:54 xkucf03 | skóre: 49 | blog: xkucf03
    Rozbalit Rozbalit vše Re: Offtopic: Re: ESR: Emacs by měl opustit bzr a přejít ke Gitu

    V céčku taky nemůžeš zanořit komentáře – tohle se ti nepřeloží:

    /**
     * komentář /** omg */
     */

    A v komentáři nemůžeš mít */.

    Na jednu stranu lidi nadávají, že psát parser dá moc práce a na druhou by chtěli mít možnost zapisovat kdejaké obskurnosti. Tohle nejde dohromady a je potřeba si vybrat nějakou úroveň jednoduchosti/složitosti.

    Spíš by ti mohlo chybět, že XML nemá jednořádkové komentáře, ale to by zase znamenalo vyhradit pro komentáře nějaký znak (např. #), který by se pak ale zase nesměl vyskytovat v textovém obsahu a musel by se nějak escapovat – tzn. zase další složitost pro parser a opruz pro uživatele. Tady je rozdíl oproti programovacím jazykům – v nich totiž nepíšeš libovolný obsah, ale píšeš klíčová slova i identifikátory (libovolný obsah píšeš leda do uvozovek), a tak ti nemusí vadit, že nějaký znak je vyhrazený pro komentáře a nemůžeš ho použít v klíčových slovech nebo identifikátorech.

    Mám rád, když se lidé přou, znamená to, že vědí, co dělají, a že mají směr. Frantovo.cz, SQL-DK, Relational pipes
    9.1.2014 16:15 kralyk z abclinuxu | skóre: 29 | blog:
    Rozbalit Rozbalit vše Re: Offtopic: Re: ESR: Emacs by měl opustit bzr a přejít ke Gitu
    A v komentáři nemůžeš mít */.
    Protože tím se ukončuje komentář, takže je logické, že to v komentáři být nemůže. Zatímco v XML by '--' v komentářích klidně být mohlo, nevidím důvod proč ne (vzhledem k tomu, že komentář je ukončen sekvencí '-->').

    Jinak v céčku můžeš zanořené komentáře udělat pomocí preprocesoru (#if 0), ale není to zrovna čísté.
    Spíš by ti mohlo chybět, že XML nemá jednořádkové komentáře, ale to by zase znamenalo vyhradit pro komentáře nějaký znak (např. #), který by se pak ale zase nesměl vyskytovat v textovém obsahu a musel by se nějak escapovat
    Takhle to má YAML, s tím, že # uvozuje komentář kdekoli kromě stringu. Imho docela dobré.
    xkucf03 avatar 9.1.2014 16:23 xkucf03 | skóre: 49 | blog: xkucf03
    Rozbalit Rozbalit vše Re: Offtopic: Re: ESR: Emacs by měl opustit bzr a přejít ke Gitu
    kdekoli kromě stringu. Imho docela dobré.
    To ano, ale v XML máš ten string kdekoli :-) (kromě názvů elementů/atributů a pár dalších míst)
    Mám rád, když se lidé přou, znamená to, že vědí, co dělají, a že mají směr. Frantovo.cz, SQL-DK, Relational pipes
    xkucf03 avatar 9.1.2014 14:01 xkucf03 | skóre: 49 | blog: xkucf03
    Rozbalit Rozbalit vše Re: Offtopic: Re: ESR: Emacs by měl opustit bzr a přejít ke Gitu

    BTW: The Art of Unix Programming:

    XML is a very simple syntax resembling HTML — angle-bracketed tags and ampersand-led literal sequences. It is about as simple as a plain-text markup can be and yet express recursively nested data structures. XML is just a low-level syntax; it requires a document type definition (such as XHTML) and associated application logic to give it semantics.

    Among the hardest things to get right in designing any text file format are issues of quoting, whitespace and other low-level syntax details. Custom file formats often suffer from slightly broken syntax that doesn't quite match other similar formats. Using a standard format such as XML, which is verifiable and parsed by a standard library, eliminates most of these issues.

    Mám rád, když se lidé přou, znamená to, že vědí, co dělají, a že mají směr. Frantovo.cz, SQL-DK, Relational pipes
    xkucf03 avatar 7.1.2014 17:56 xkucf03 | skóre: 49 | blog: xkucf03
    Rozbalit Rozbalit vše Re: Offtopic: Re: ESR: Emacs by měl opustit bzr a přejít ke Gitu

    P.S. Ještě k těm layoutům a GUI: v Netbeans si třeba naklikám nějaký panel, hned vidím, jak jsou vedle sebe tlačítka, popisky, textová pole… což prostě při psaní kódu nevidím – a při tvorbě GUI mi to přijde celkem důležité. Ale hlavní okno aplikace vytvářím ručně v kódu, do něj přidávám ten panel. Jiný panel mám zase ručně a přidávám do něj komponenty dynamicky. A jiný je zase naklikaný, podle toho, jak co je lepší. Dokonce můžu nějaký panel naklikat (tzn. základ je deklarativní) a v inicializační metodě ho doladím, něco přidám, změním texty, hodnoty atd.

    Mám rád, když se lidé přou, znamená to, že vědí, co dělají, a že mají směr. Frantovo.cz, SQL-DK, Relational pipes
    8.1.2014 10:41 Ivan
    Rozbalit Rozbalit vše Re: Offtopic: Re: ESR: Emacs by měl opustit bzr a přejít ke Gitu
    staré konfiguráky (ve kterých může být zapsané cokoli) pak přestanou fungovat (nebo tě to omezuje v možnostech měnit vnitřní uspořádání programu).
    A to je presne problem na ktery jsem narazil. XML je pry self-documenting format, takze se nikdo nezabyva nejakou semantikou XML elementu. Nova verze Eclipse vychazi cca 1x za rok a kazda ma trosku jine formaty XML konfiguraku. Navod pro vytvoreni deployment descriptoru pluginu pro Juno uz nefunguje na Kepleru. Resp. to XML je porad "validni" akorat to zjevne nestaci a je potreba jeste neco pripsat aby se vsechny JARy spravne zabalily.

    Problem pro me neni ani tak XML format jako takovy. Vadi mi, ze je az prilis snadne ho zmenit a diff nad XSD schematy neni zrovna efektivni reseni.
    7.1.2014 16:22 kralyk z abclinuxu | skóre: 29 | blog:
    Rozbalit Rozbalit vše Re: Offtopic: Re: ESR: Emacs by měl opustit bzr a přejít ke Gitu
    Naprostý souhlas, XML je imho na build systém naprosto nevhodné.

    Vzhledem k tomu, že je k dispozici celá paleta dobře známých a snadno použitelných skriptovacích jazyků, tak opravdu nevidím jediný důvod použít XML - není vhodný ani návrhem ani syntaxí.
    7.1.2014 17:40 Martin Mareš
    Rozbalit Rozbalit vše Re: Offtopic: Re: ESR: Emacs by měl opustit bzr a přejít ke Gitu
    Narozdil od Martina si nemyslim, ze zrovna syntaxe je ten nejvetsi problem
    Mně to nepřijde jako největší problém, ale jako největší hrůza :-)

    Největší problém je samozřejmě, že XML je pro většinu lidí tím velkým kladivem, které když uchopí, cokoliv jim připadá jako hřebík ;)
    7.1.2014 18:21 JS1 | skóre: 2 | blog: intuition_pump
    Rozbalit Rozbalit vše Re: Offtopic: Re: ESR: Emacs by měl opustit bzr a přejít ke Gitu
    Nemyslim, ze to je pro vetsinu lidi kladivo - ale proste takova je Javova kultura, tak to delaji.

    Ale ja bych mel problem i kdyby Java pouzivala misto mnoha XML (napriklad u tech layoutu) s-vyrazy (jako data). Radu veci lze totiz krasne programove parametrizovat, tak proc se s tim zbytecne psat? Navic to ten jazyk i zjednodusi - ty "jen datove" reprezentace maji casto ruzne ad hoc parametrizace, jako dedicnost apod., ktere by takto zcela odpadly.
    Lidstvo čelí v tomto století hrozbě civilizačního kolapsu. Podpořte hnutí klimatickakoalice.cz!
    xkucf03 avatar 7.1.2014 19:28 xkucf03 | skóre: 49 | blog: xkucf03
    Rozbalit Rozbalit vše Re: Offtopic: Re: ESR: Emacs by měl opustit bzr a přejít ke Gitu

    A brání ti něco to psát čistě procedurálně? Vždyť ten deklarativní konfigurák se přece někde načte, vzniknou z něj objekty a ty se někam dál předávají. Copak nejde tuhle část přeskočit a vytvořit si rovnou ty objekty a pokračovat až od tohoto bodu dál?

    Mám rád, když se lidé přou, znamená to, že vědí, co dělají, a že mají směr. Frantovo.cz, SQL-DK, Relational pipes
    7.1.2014 19:34 JS1 | skóre: 2 | blog: intuition_pump
    Rozbalit Rozbalit vše Re: Offtopic: Re: ESR: Emacs by měl opustit bzr a přejít ke Gitu
    Ano, brani mi v tom hloupa syntaxe Javy, ktera neumoznuje vytvaret vlastni DSL. Jeste neco?
    Lidstvo čelí v tomto století hrozbě civilizačního kolapsu. Podpořte hnutí klimatickakoalice.cz!
    xkucf03 avatar 7.1.2014 22:39 xkucf03 | skóre: 49 | blog: xkucf03
    Rozbalit Rozbalit vše Re: Offtopic: Re: ESR: Emacs by měl opustit bzr a přejít ke Gitu

    Můžeš si napsat pomocné metody/funkce nebo si navrhnout nějaké fluent interface – sice to není jazyk, máš tam mezi tím tečky a závorky, ale výsledek je podobný.

    Pokud to pořád nestačí, tak můžeš sáhnout po JSR 223 a tu konfiguraci napsat v nějakém jiném jazyce (případně si dokonce navrhnout jazyk vlastní).

    Mám rád, když se lidé přou, znamená to, že vědí, co dělají, a že mají směr. Frantovo.cz, SQL-DK, Relational pipes
    8.1.2014 10:53 JS1 | skóre: 2 | blog: intuition_pump
    Rozbalit Rozbalit vše Re: Offtopic: Re: ESR: Emacs by měl opustit bzr a přejít ke Gitu
    Ano, muzu treba pouzit Clojure a napsat to v nem. Ale to tu "learning curve" nezlepsi, jenom prida dalsi vrstvu problemu. Proste rict "muzes pouzit jiny jazyk, da se to na to napasovat" neni omluva pro spatny design.
    Lidstvo čelí v tomto století hrozbě civilizačního kolapsu. Podpořte hnutí klimatickakoalice.cz!
    8.1.2014 14:36 kralyk z abclinuxu | skóre: 29 | blog:
    Rozbalit Rozbalit vše Re: Offtopic: Re: ESR: Emacs by měl opustit bzr a přejít ke Gitu
    Proste, Javiste by si IMHO meli priznat, ze domenove specifickym jazykum se v programovani nelze vyhnout. Vykaslat se na XML a rozsirit si Javu tak, aby to slo napsat primo v ni.
    "Java is a DSL to transform big XML documents into long exception stack traces." — Scott Bellware
    6.1.2014 12:25 kralyk z abclinuxu | skóre: 29 | blog:
    Rozbalit Rozbalit vše Re: ESR: Emacs by měl opustit bzr a přejít ke Gitu
    Tak u IDE typu Eclipse (QtC,...) mají pluginy jinou úlohu.

    Tomu, co ty popisuješ, je imho podobný například Sublime se svými pluginy/skripty v pythonu...
    xkucf03 avatar 6.1.2014 12:34 xkucf03 | skóre: 49 | blog: xkucf03
    Rozbalit Rozbalit vše Re: ESR: Emacs by měl opustit bzr a přejít ke Gitu

    Nebo jEdit, který má jak „makra“ (jednoduché skripty), tak „plug-iny“ (složitější kompilované moduly).

    Mám rád, když se lidé přou, znamená to, že vědí, co dělají, a že mají směr. Frantovo.cz, SQL-DK, Relational pipes
    6.1.2014 12:43 JS1 | skóre: 2 | blog: intuition_pump
    Rozbalit Rozbalit vše Re: ESR: Emacs by měl opustit bzr a přejít ke Gitu
    Nevim, co myslis tou jinou ulohou..

    Sublime neznam, ale v podstate mi to pripada jako o hodne chudsi Emacs, i filozofii.

    Pokud je rozsirovaci jazyk jiny nez ten, v kterem se delaji jednoduche veci, tak to znamena znacny schod na te "learning curve". A o tom to je - nekdo kdo si dnes konfiguruje Emacs mozna zitra napise plugin, protoze to proste prijde samo, jako prirozena vec. U IDE se mu mozna do studia toho API nebude chtit. Proste Emacs svoje vnitrnosti zamerne odkryva pri te konfiguraci, jako pozvanku ho modifikovat; IDE delaji opak.
    Lidstvo čelí v tomto století hrozbě civilizačního kolapsu. Podpořte hnutí klimatickakoalice.cz!
    6.1.2014 13:48 kralyk z abclinuxu | skóre: 29 | blog:
    Rozbalit Rozbalit vše Re: ESR: Emacs by měl opustit bzr a přejít ke Gitu
    Nevim, co myslis tou jinou ulohou..
    U těch zmíňovaných IDE se nepočítá s tím, že by si každý psal plugin, spíš je to výjimečná záležitost. Píšeš, že ostatní IDE neodkrývají vnitřnosti, jako kdyby to bylo špatně. Není to to samé, co umí Emacs, nemá to tu bezbřehou flexibilitu ;-) ale to neznamená, že to je nutně špatně (osobně mi to naopak vyhovuje víc - opravdu nevím, proč bych se měl hrabat ve střevech IDE).
    Proste Emacs svoje vnitrnosti zamerne odkryva pri te konfiguraci, jako pozvanku ho modifikovat
    Zrovna ten Sublime nebo jiné editory dělají to samé.
    6.1.2014 14:25 JS1 | skóre: 2 | blog: intuition_pump
    Rozbalit Rozbalit vše Re: ESR: Emacs by měl opustit bzr a přejít ke Gitu
    U těch zmíňovaných IDE se nepočítá s tím, že by si každý psal plugin, spíš je to výjimečná záležitost.
    Mne to prijde prave jako skoda. Jinak na tohle tema existuje klasicky clanek.

    A taky tento. Zvlast se mi libi citat:
    Multics Emacs proved to be a great success — programming new editing commands was so convenient that even the secretaries in his office started learning how to use it. They used a manual someone had written which showed how to extend Emacs, but didn't say it was a programming. So the secretaries, who believed they couldn't do programming, weren't scared off. They read the manual, discovered they could do useful things and they learned to program.
    Osobne si myslim, ze myslenka, ze by pocitacove programy mely mit dve tvare, jednu primitivni GUI pro normalni lidi a druhou slozitou pro "ty prave programatory", co chteji delat "velke veci", je scestna (ale bohuzel to ma sve komercni duvody). Mel by proste existovat plynuly prechod.
    Lidstvo čelí v tomto století hrozbě civilizačního kolapsu. Podpořte hnutí klimatickakoalice.cz!
    Conscript89 avatar 7.1.2014 10:30 Conscript89 | Brno
    Rozbalit Rozbalit vše Re: ESR: Emacs by měl opustit bzr a přejít ke Gitu
    No vidis, a me nedela problem udelat zakladni operace VCS a lisp (asi protoze jsem se ucil Haskell) mi nejak porad nejde. Chci tim rict ze naucit se jazyk je narocnejsi, nez se naucit par prikazu a co znamenaji (bez hlubsich znalosti).
    I can only show you the door. You're the one that has to walk through it.
    7.1.2014 12:40 JS1 | skóre: 2 | blog: intuition_pump
    Rozbalit Rozbalit vše Re: ESR: Emacs by měl opustit bzr a přejít ke Gitu
    Vzdyt na zakladni konfiguraci Emacsu se nemusis ucit Elisp.. Na zacatku to muzes brat proste jako syntax, pozdeji pridat pochopeni, ze se tak zapisuji operatory, atd. Je to tak pozvolne, ze uz to snad ani pozvolneji udelat nejde.
    Lidstvo čelí v tomto století hrozbě civilizačního kolapsu. Podpořte hnutí klimatickakoalice.cz!
    3.1.2014 14:40 Lol Phirae | skóre: 23
    Rozbalit Rozbalit vše Re: ESR: Emacs by měl opustit bzr a přejít ke Gitu
    U emacsu si to vůbec neumím představit; bzr má naprosto příšerný výkon i u projektů o dva řády menších.
    xkucf03 avatar 3.1.2014 14:50 xkucf03 | skóre: 49 | blog: xkucf03
    Rozbalit Rozbalit vše Re: ESR: Emacs by měl opustit bzr a přejít ke Gitu
    BTW: velice podnětná diskuse, doporučuji přečíst.
    Mám rád, když se lidé přou, znamená to, že vědí, co dělají, a že mají směr. Frantovo.cz, SQL-DK, Relational pipes
    3.1.2014 18:46 Pepe
    Rozbalit Rozbalit vše Re: ESR: Emacs by měl opustit bzr a přejít ke Gitu
    umel by tu nekdo shrnout hlavni prednosti i nedostatky pro bzr, git, hg a darcs? dekuju!
    Jakub Lucký avatar 3.1.2014 19:02 Jakub Lucký | skóre: 40 | Praha
    Rozbalit Rozbalit vše Re: ESR: Emacs by měl opustit bzr a přejít ke Gitu
    Dva různé názory

    A něco o Darcs
    If you understand, things are just as they are; if you do not understand, things are just as they are.
    3.1.2014 20:36 mimi.vx | skóre: 37 | blog: Mimi.VX | Praha
    Rozbalit Rozbalit vše Re: ESR: Emacs by měl opustit bzr a přejít ke Gitu

    ten článek o Darcs má pěkný závěr ..

    Where git rocks:

    Git's performance rocks

    Git is very fast. Nuff said.

    If you need to create a really huge repo, just use git.

    The only haskell thing that works good is xmonad. I used it for years and still very happy with it. 
    The only haskell things that works fast are qsort and shootout tests.
    The other haskell soft is full of shit and I can't understand why.

    Gits' branches rock

    The same. If you really need to use branches, use git.

    Git vs CVS vs SVN vs Mercurial vs Bazaar

    And don't think what CVS, SVN, mercurial or bazaar is better than git. It's not truth, these version control systems are much worse

    USE="-gnome -kde";turris
    pavlix avatar 3.1.2014 21:21 pavlix | skóre: 54 | blog: pavlix
    Rozbalit Rozbalit vše Re: ESR: Emacs by měl opustit bzr a přejít ke Gitu
    Používám Git denně, takže asi nemá smysl řešit první odkaz.

    Druhý odkaz mi dává smysl. Ale popravdě řečeno snad všechno, co se v tom článku píše, lze řešit čistě na klientské straně (uživatelský repozitář s pracovním stromem) a z velké části se jedná o UI. Tady bych docela preferoval ponechat si Git jako low-level backend a pokud to workflow daného projektu umožňuje, vybrat si frontend dle vlastních preferencí.

    Třetí odkaz a vyznačené pozdější úpravy naznačují, že se Git od jeho napsání zlepšil a stále se zlepšuje. V částech, které vyzdvihují darcs nacházím především poznámky ohledně UI a různých operací, což je technicky řešitelné nad Gitovským objektovým úložištěm a tím pádem zcela jistě i se vzdálenými Gitovskými repozitáři. Mimo to tam vidím jasně napsáno, že pokud chci používat větve, mám použít Git.

    A popravdě řečeno, na údržbu změn v software větve používat chci. A chci je používat rychle a jednoduše. Git to umožňuje, Mercurial pokud jsem správně pochopil též a Darcs pokud jsem správně pochopil, nikoliv. Bazaar je mrtvý.

    Znamená to, že pro mě v open source světě existují dva verzovací systémy. Franta pokud vím používá a preferuje Mercurial, stejně jako mnozí jiní.

    Pokud dobře chápu, rozdíl mezi Git a Hg začíná už v identifikaci uložených dat, kde se mi Git zdá funkčně podstatně jednodušší, což beru jako výhodu. Gitovská implementace větví jakožto jednoduchých pointerů na stav projektu s historií mi připadá nepřekonatelná, ale to už Mercurial dohnal. Bezpečnost Gitovských operací pokud jde o existující commity je něco, čeho bych se vzdával dost těžko.

    Když tohle všechno sečtu dohromady, ano, občas se kvůli gitovskému CLI koušu do rtu, občas by se mi hodil nějaký nástroj, který v Gitu není, občas si ho třeba i dodělám nebo nějak poskládám pomocí jiných nástrojů, ale nic z toho nevidím jako důvod přejít na Hg.

    Pokud by mě to hodně štvalo, napíšu si nad Gitem vlastní nadstavbu, která bude odpovídat mému stylu práce. K tomu už jen zbývá dodat, že mezi projekty, které mě zajímají má Git majoritu,

    Tím neříkám, že je Git všespásný, ale pokud jde o jiné VCS, tak mě zajímají jen z pohledu takových případů užití, kde Git nějakým způsobem selhává. Ve většině takových případů bych dal přednost jeho nadstavbě či doplňku.

    Jediné, kde bych skutečně rád použil jiný základ je údržba změn jednotlivých souborů. Typicky by to bylo hlídání celého /etc a podobné úlohy, kde bych dal přednost tomu, že bych mohl od začátku trackovat všechny soubory včetně nově vzniklých, ale kdykoli zavádět výjimky a především pracovat s historií nezávisle na tom, které změny přišly ve stejném období.
    Já už tu vlastně ani nejsem. Abclinuxu umřelo.
    Jakub Lucký avatar 3.1.2014 21:37 Jakub Lucký | skóre: 40 | Praha
    Rozbalit Rozbalit vše Re: ESR: Emacs by měl opustit bzr a přejít ke Gitu
    Z toho, co jsem o Darcs přečetl mi přišlo nejzajímavější to nelineární chápání commitů... Viz video v odkaze 3
    If you understand, things are just as they are; if you do not understand, things are just as they are.
    pavlix avatar 3.1.2014 21:45 pavlix | skóre: 54 | blog: pavlix
    Rozbalit Rozbalit vše Re: ESR: Emacs by měl opustit bzr a přejít ke Gitu
    Video už jsem viděl, a přišlo mi značně pomýlené. Denně pracuju se závislostmi, které nejsou detekovatelné ze strany VCS.
    Já už tu vlastně ani nejsem. Abclinuxu umřelo.
    3.1.2014 23:17 Radek Miček | skóre: 23 | blog: radekm_blog
    Rozbalit Rozbalit vše Re: ESR: Emacs by měl opustit bzr a přejít ke Gitu
    +1

    Hezké by bylo, kdyby VCS rozuměly významu programů a patche obsahovaly například popis provedených refaktoringů. Takové patche by šlo použít i napříč různymi jazyky.
    4.1.2014 00:05 OldFrog {Ondra Nemecek} | skóre: 36 | blog: Žabákův notes | Praha
    Rozbalit Rozbalit vše Re: ESR: Emacs by měl opustit bzr a přejít ke Gitu
    No, mě se líbí fossil http://www.fossil-scm.org/

    Nevím, jak by si poradil s emacsem a je to minorita, nicméně má hezké vlastnosti:
    • repositář je sqlite databáze
    • fossil spočívá v jediné dobře portovatelné binárce
    • zabudovaný webserver, bugtracking systém, wiki
    • údajně vysoký výkon a afektivita (nemohu porovnat), vývoj od r. 2007 - dodnes aktivní
    -- OldFrog
    xkucf03 avatar 4.1.2014 00:11 xkucf03 | skóre: 49 | blog: xkucf03
    Rozbalit Rozbalit vše Re: ESR: Emacs by měl opustit bzr a přejít ke Gitu

    +1 Fossil má něco do sebe. A v Monotone jsou taky některé zajímavé koncepty.

    Mám rád, když se lidé přou, znamená to, že vědí, co dělají, a že mají směr. Frantovo.cz, SQL-DK, Relational pipes
    4.1.2014 13:48 Michal Vyskočil | skóre: 60 | blog: miblog | Praha
    Rozbalit Rozbalit vše Re: ESR: Emacs by měl opustit bzr a přejít ke Gitu
    No, mě se líbí fossil http://www.fossil-scm.org/

    Nevím, jak by si poradil s emacsem a je to minorita, nicméně má hezké vlastnosti:
    • repositář je sqlite databáze
    • údajně vysoký výkon a afektivita (nemohu porovnat), vývoj od r. 2007 - dodnes aktivní
    Vysoký výkon s sqlite databází? Někde v dokumentaci ke gitu je schovaný Linusův email na toto téma.
    When your hammer is C++, everything begins to look like a thumb.
    5.1.2014 23:07 OldFrog {Ondra Nemecek} | skóre: 36 | blog: Žabákův notes | Praha
    Rozbalit Rozbalit vše Re: ESR: Emacs by měl opustit bzr a přejít ke Gitu
    Co to je za argument? Sqlite přeci nemusí být úzké hrdlo.

    Výkon by šel otestovat mirací nějakého projektu z git do fossilu (což nějak lze).
    -- OldFrog
    7.1.2014 09:28 Kareves
    Rozbalit Rozbalit vše Re: ESR: Emacs by měl opustit bzr a přejít ke Gitu
    Existuje skript nazvaný fossil2git, který slouží k opačné věci - zrcadlí z fossilu do gitu. V praxi ho používají vývojáři jazyka TCL, který zrcadlí své repozitáře z fossilu na github.
    7.1.2014 12:53 OldFrog {Ondra Nemecek} | skóre: 36 | blog: Žabákův notes | Praha
    Rozbalit Rozbalit vše Re: ESR: Emacs by měl opustit bzr a přejít ke Gitu
    Díky za tip, to se může hodit, protože tohle: http://www.fossil-scm.org/index.html/doc/tip/www/inout.wiki funguje - pokud tomu dobře rozumím - pouze jednorázově.
    -- OldFrog
    4.1.2014 12:10 dustin | skóre: 63 | blog: dustin
    Rozbalit Rozbalit vše Re: ESR: Emacs by měl opustit bzr a přejít ke Gitu
    Umí nějaké IDE do gitu commitovat (tedy přidávat do indexu) jen chunky diffů v jednotlivých souborech, tj. necommitovat celé soubory? Je to velice užitečná vlastnost třeba pro commit refaktoringu názvu třídy, když soubory volající třídu (tedy změna) obsahují i jiné změny, které však patří do jiného commitu. Jasně, že by šlo commitovat hned po tom refaktoringu, ale změny si vždy chvíli sedají a dolaďují, než se to commitne.

    IntelliJ Idea to myslím zatím neumí.

    Obecně rozpad složitější změny do více commitů, aby každý obsahoval jen sobě odpovídající změny a výsledek byl kompilovatelný, je docela složité. V CLI i v mně známých IDEch. Platí to i třeba pro vývoj jádra, kde se na obsah commitů kouká ještě daleko důsledněji, než při uzavřeném proprietárním vývoji.
    4.1.2014 12:13 dustin | skóre: 63 | blog: dustin
    Rozbalit Rozbalit vše Re: ESR: Emacs by měl opustit bzr a přejít ke Gitu
    Jde mi o implementaci git add -i a pak rozpad na patche a chunky.
    4.1.2014 15:53 xhaakon
    Rozbalit Rozbalit vše Re: ESR: Emacs by měl opustit bzr a přejít ke Gitu
    Eclipse EGit toto zvládá. Lze si vedle sebe graficky porovnat soubor ve workspace s jeho podobou v git indexu a libovolně mezi nimi přesouvat chunky změn i ručně editovat. Nakonec commitnout pouze to co je v indexu přes view Git Staging.

    http://luksza.org/2011/egit-iteractive-adding/
    4.1.2014 15:58 dustin | skóre: 63 | blog: dustin
    Rozbalit Rozbalit vše Re: ESR: Emacs by měl opustit bzr a přejít ke Gitu
    Paráda, to je přesně ono, díky moc. Teď už jen přesvědčit JetBrains, aby se inspirovali :-)
    5.1.2014 12:32 Michal Kubeček | skóre: 72 | Luštěnice
    Rozbalit Rozbalit vše Re: ESR: Emacs by měl opustit bzr a přejít ke Gitu
    O IDE nevím, ale rozhraní git gui mi připadá dostatečně praktické na to, abych IDE neřešil.
    xkucf03 avatar 4.1.2014 12:20 xkucf03 | skóre: 49 | blog: xkucf03
    Rozbalit Rozbalit vše Re: ESR: Emacs by měl opustit bzr a přejít ke Gitu

    Přijde mi to jako chybný postup – ne nadarmo jsou v mnoha týmech pravidla, že by se měl commitovat jen kód, který jde zkompilovat a který prošel testy – což u nějaké ručně vybrané podmnožiny změněných řádků zaručené nemáš.

    Mám rád, když se lidé přou, znamená to, že vědí, co dělají, a že mají směr. Frantovo.cz, SQL-DK, Relational pipes
    pavlix avatar 4.1.2014 13:17 pavlix | skóre: 54 | blog: pavlix
    Rozbalit Rozbalit vše Re: ESR: Emacs by měl opustit bzr a přejít ke Gitu
    Mně to přijde jako zcela správný postup a záruka za správnost je stejná jako u jakýchkoliv jiných úprav, tedy žádná. Před odesláním sady změn je tak jako tak nutné všechny změny otestovat. To se v CLI dělá triviálně.
    git rebase -i master --exec 'make && make check'
    
    V mnohých projektech je naopak zakázáno commitovat nesouvisející změny, který si člověk někdy jen tak narychlo splácá, aby něco vyzkoušel a pak je rozloží na nějaké funkční celky, které jsou vhodné k review.
    Já už tu vlastně ani nejsem. Abclinuxu umřelo.
    xkucf03 avatar 4.1.2014 13:45 xkucf03 | skóre: 49 | blog: xkucf03
    Rozbalit Rozbalit vše Re: ESR: Emacs by měl opustit bzr a přejít ke Gitu

    Já ale neříkám, že by se měly dohromady commitovat nesovisející věci. Správný postup je podle mého tento:

    1. přejmenuji třídu nebo udělám jiný refaktoring
    2. udělám clean & build a ideálně pustím testy
    3. commit
    4. dělám další změny

    Případně pokud mám nějakou rozdělanou práci a přijde urgentní požadavek na přejmenování/refaktoring

    1. odložím rozdělanou práci (MQ v Mercurialu, staging area v Gitu nebo použití jiné pracovní kopie…)
    2. přejmenuji třídu nebo udělám jiný refaktoring
    3. udělám clean & build a ideálně pustím testy
    4. commit
    5. vrátím se k původní práci

    Je dobré ten projekt držet v nějakém konzistentním stavu jako celek a nevytrhávat ty změny z kontextu. Protože když to děláš, tak si musíš dávat práci s ruční kontrolou a nesmíš na nic zapomenout, nic nepřehlídnout – zatímco v opačném případě ti velký kus téhle práce ušetří kompilátor a testy.

    Mám rád, když se lidé přou, znamená to, že vědí, co dělají, a že mají směr. Frantovo.cz, SQL-DK, Relational pipes
    4.1.2014 13:59 dustin | skóre: 63 | blog: dustin
    Rozbalit Rozbalit vše Re: ESR: Emacs by měl opustit bzr a přejít ke Gitu
    Správný postup to je teoreticky, ale v praxi po tom refaktoringu ještě řešíš, zda je to provedené správně, zda se s tím dá pracovat dále, zda to nemělo být ještě trochu jinak, Těch commitů by bylo několikanásobně více, z nichž by velká část byla rovnou předělaná na něco jiného. Běžně měním názvy tříd několikrát (triviální úkon), než je dle finální funcionality správně.

    Jasně že to můžeš nakonec interaktivně rebasovat a "duplicitní" commity sloučit, ale strávíš s tím spoustu času, navíc ani tohle není silná stránka IDE.

    Stačil by mi alespoň staging po chuncích, ani by si to nemuselo pamatovat refaktorovací changeset (i když to by bylo daleko lepší).
    pavlix avatar 4.1.2014 20:54 pavlix | skóre: 54 | blog: pavlix
    Rozbalit Rozbalit vše Re: ESR: Emacs by měl opustit bzr a přejít ke Gitu
    Z praktických zkušeností jsem rád za to, že Git umožňuje změny narychlo naprasit, testnout, jestli to vůbec funguje, a následně změny kousek po kousku rozložit na tebou popsaný ideální patchset. Jestliže to některý systém nepodporuje a člověk to musí řešit ručně, jen těžko to budu považovat za výhodu.
    zatímco v opačném případě ti velký kus téhle práce ušetří kompilátor a testy.
    Vzhledem k tomu, že mnou popsaný workflow stojí a padá na úspěšné kompilaci a automatizovaných testech, je tato poznámka značně redundantní.
    Já už tu vlastně ani nejsem. Abclinuxu umřelo.
    xkucf03 avatar 4.1.2014 21:39 xkucf03 | skóre: 49 | blog: xkucf03
    Rozbalit Rozbalit vše Re: ESR: Emacs by měl opustit bzr a přejít ke Gitu
    Jestliže to některý systém nepodporuje a člověk to musí řešit ručně, jen těžko to budu považovat za výhodu.

    Některé systémy to podporují a dokonce i lépe než Git, ale když o to nestojíš, tvoje škoda :-P

    Mám rád, když se lidé přou, znamená to, že vědí, co dělají, a že mají směr. Frantovo.cz, SQL-DK, Relational pipes
    pavlix avatar 5.1.2014 15:39 pavlix | skóre: 54 | blog: pavlix
    Rozbalit Rozbalit vše Re: ESR: Emacs by měl opustit bzr a přejít ke Gitu
    Pak je škoda, že se o takových vlastnostech takových systémů v diskuzi nepsalo. Moc rád bych se o něčem takovém něco dozvěděl, ale zatím nebylo od koho. V praxi bych ovšem uvítal, kdyby nástroj pracoval s gitovským formátem dat, což ovšem není zase takový problém.
    Já už tu vlastně ani nejsem. Abclinuxu umřelo.
    5.1.2014 02:31 Martin Mareš
    Rozbalit Rozbalit vše Re: ESR: Emacs by měl opustit bzr a přejít ke Gitu
    Běžně se mi stává, že při práci na nových kusech zdrojáku narážím na drobné chyby na jiných místech (často třeba jen překlepy v komentářích). Rovnou je opravím, ale testovat a commitovat je chci až časem.
    5.1.2014 11:01 kralyk z abclinuxu | skóre: 29 | blog:
    Rozbalit Rozbalit vše Re: ESR: Emacs by měl opustit bzr a přejít ke Gitu

    Případně pokud mám nějakou rozdělanou práci a přijde urgentní požadavek na přejmenování/refaktoring

    1. odložím rozdělanou práci (MQ v Mercurialu, staging area v Gitu nebo použití jiné pracovní kopie…)
    Jestli správně rozumím tomu, o co v příkladu jde, tak staging area by nepomohl, spíš stash a/nebo branch...
    4.1.2014 14:14 dustin | skóre: 63 | blog: dustin
    Rozbalit Rozbalit vše Re: ESR: Emacs by měl opustit bzr a přejít ke Gitu
    Záleží podle situace. Pokud je projekt velký, testů hodně a "make check" trvá 10 minut, k tomu vyprodukuješ 10 commitů za hodinu (z nichž polovina je "pridani/oprava komentare", moc se toho za den nenapíšeš. Mimochodem typický příklad, když po někom převezmeš kód, který se ti moc nelíbí.

    Samozřejmě třeba u jádra nic jiného nezbývá a sláva bohu za to :-)
    pavlix avatar 4.1.2014 20:57 pavlix | skóre: 54 | blog: pavlix
    Rozbalit Rozbalit vše Re: ESR: Emacs by měl opustit bzr a přejít ke Gitu
    Záleží podle situace. Pokud je projekt velký, testů hodně a "make check" trvá 10 minut, k tomu vyprodukuješ 10 commitů za hodinu (z nichž polovina je "pridani/oprava komentare", moc se toho za den nenapíšeš.
    Právě naopak. Při popsaném workflow lze celou sérii testovat třeba i v samostatném adresáři nebo na samostatném stroji a tím pádem snížit časové dopady prakticky na nulu.
    Já už tu vlastně ani nejsem. Abclinuxu umřelo.
    4.1.2014 13:52 dustin | skóre: 63 | blog: dustin
    Rozbalit Rozbalit vše Re: ESR: Emacs by měl opustit bzr a přejít ke Gitu
    ?? commit má být co nejmenší množina změn, která spolu souvisí, aby jej šlo snadno revertnout, prozkoumat, atd. Popis commitu má vyjadřovat, co commit obsahuje. Samozřejmě by měl kód po něm fungovat, aby šel použít třeba bisect. Ne vždy je správná funkčnost splnitelná, ale minimálně zkompilovat by to mělo jít vždy.

    Velké commity jsou spíše vyjímečné, když se nevyplatí ( = nechce) to rozpadávat na malé - právě třeba kvůli nedostačující podpoře v IDE. Tedy přesně to, na co jsem se ptal.

    Kontroly nad commity provádíme až při pushnutí skupiny commitů na server, kdy integrační server (teamcity) kontroluje více commitů najednou. Kdyby měl kontrolovat každý commit odděleně, nestíhal by, kontrola trvá docela dlouho. Ale samozřejmě je také možnost dělat kontroly lokálně, ale nám se osvědčilo centrální řešení, vývojářské stroje nejsou tak výkonné, aby vše stíhaly najednou.
    xkucf03 avatar 4.1.2014 13:55 xkucf03 | skóre: 49 | blog: xkucf03
    Rozbalit Rozbalit vše Re: ESR: Emacs by měl opustit bzr a přejít ke Gitu

    V zásadě nic, s čím bych nesouhlasil, ale jak to souvisí s komentářem, na který reaguješ? Četl jsi #45?

    Mám rád, když se lidé přou, znamená to, že vědí, co dělají, a že mají směr. Frantovo.cz, SQL-DK, Relational pipes
    5.1.2014 02:31 frdrx | skóre: 29 | blog: frdrx
    Rozbalit Rozbalit vše Re: ESR: Emacs by měl opustit bzr a přejít ke Gitu
    No blik...
    Patička mi slouží k tomu, abych si lépe poznal svoje příspěvky.

    Založit nové vláknoNahoru


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