kozziho wxDVDShrink

28.8.2006 14:43 | Přečteno: 1390× | Linux | poslední úprava: 28.8.2006 14:45

Daniel Kozák nereaguje na mé e-maily, takže jsem se rozhodl napsat mu to do blogu.

V této diskusi jsem mu napsal chybu, kterou dostávám při kompilaci. Po sdělení, že mám ArchLinux mi napsal, že má bugovou verzi dvdread a wxgtk. Problém s dvdread opravdu je a dá se vyřešit přepsáním souborů v /usr/include/dvdread soubory z adresáře /usr/include/dvdnav. wxGTK ale bugové není. V ArchLinuxu je wxGTK zkompilováno s podporou unicode (parametr --enable-unicode skriptu configure). Daniel pravděpodobně s wxGTK nikdy neprogramoval (já teda také ne), jinak by věděl, že pokud pracuje s tímto toolkitem, má používat makro wxT pro textové konstanty. To však nečiní. Dále v kódu používá funkci wxString::c_str() která ale vrací const wchar_t* nebo const char* v závislosti na použití unicode. A on ji prostě použije nějak takto: const char *janevimco = janevimco2.c_str(). Správné užití je ale const char *janevimco = janevimco2.mb_str(wxConvLocal) kde wxConvLocal je globální konvertor wxGTK.

Takže kozzi, pohrál jsem si za tebe. Nečiním si žádné nároky na spoluautorsví a přidaný kód můžeš klidně vydávat za svůj.

       

Komentáře

[pasmen]

Po vcerejsku jsem cekal neco stavnatejsiho :( A ono je to suchy programko...

[Tomáš Honzák]

Aniž bych chtěl nějak extra rejpat, slyšel jste někdy o programech diff a patch?

[Jardík]

Ano, slyšel. Ale podle mě je nemá cenu používat na sedmnácti kilobytový projekt.

[Tomáš Honzák]

Dovolil bych si nesouhlasit

• Vytvoření diffu není pomalejší než vytvoření tar{b,bz}allu
  
• Maximální velikost diffu je (odhlédneme-li od nějaké režie) rovna velikosti všech souborů původní verze + velikosti všech souborů nové verze (v případě, že z původního kódu nezůstane kámen na kameni), typicky jde ale o zlomky
  
• DIFF se podstatně lépe čte, analyzuje, aplikuje, distribuuje
  

Mimo to zastávám názor, že používat best practices a scm tooly vůbec je potřeba od začátku, a ne až v okamžiku, kdy to v lepším případě "přestane jít dělat ručně", v horším autor zjistí, že to, co spáchal za posledních X hodin je "úplně na nic" a začne zoufale hledat, která z kopií zdrojáků na disku je ta poslední ještě fungující

[Michal Kubeček]

Za nejdůležitější ale považuji skutečnost, že většinou lze snadno a rychle aplikovat dva různé patche, skládat dohromady dvě různé modifikace téhož projektu není legrace a IMHO je nejjednodušší si z jedné udělat patch proti původním zdrojákům a aplikovat ho jako patch na druhou…

[Jardík]

No, jestli chcete diff, nikdo vám v jeho vytvoření nebrání. Zde si stáhněte původní tarball, stáhněte ten můj, rozbalte je a vytvořte si diff. Pak ho pro dobrý pocit aplikujte na původní verzi. Ovšem v mém tarballu jsem provedl menší přeuspořádání souborů do adresářů. Tj., diff nepůjde vytvořit tak jednoduše jako tarball. Já ho vytvořím tak, že pravým myšítkem kliknu na adresář, vyberu vytvořit archiv, vyberu tar.bz2, dám OK a je hotovo. Než bych napsal příkaz, trvalo by mi to déle. A ještě déle by mi trvalo nastudování vytváření diffů.

[Tomáš Honzák]

Tady ale nejde o mně nebo o to, co bych já chtěl :) Vidím tu ale krásnou modelovou situaci.

Malý opensource projekt, prozatím spravovaný jedním člověkem, ale to není podstatné. Stejně tak dobře se může jednat o malý tým.

A jeden aktivní vývojář, který si kód stáhne, prozkoumá, odhalí chyby, opraví je, a do toho ještě podle svého nejlepšího vědomí a svědomí zlepší vnitřní organizaci software (přeuspořádá soubory v podadresářích apod). To celé zabalí do úhledného balíčku a pošle správci projektu: "tu máš můj kód, nežádám slávy! Ber, nebo nech ležet."

A co teď s tím chudák správce projektu?

Určitě má radost z opravených chyb. Ale co s tou reorganizací? Možná náš přítel vývojář skutečně udeřil hřebíček na hlavičku, možná úplně nepochopil, jaké má správce záměry, ale hlavně má problém. Dostal všechno "na jedné hromadě".

Jak teď rychle a jednoduše pozná, jaké změny byly provedeny jakožto opravy chyb, jaké z důvodů reorganizace, co jsou případné nové vylepšení... ?

Má tak asi dvě možnosti: buď přijmout celý balíček "za svý", přeplácnout s ním aktuální zdrojový strom a modlit se , nebo se pokusit "provést diff", a nad diffem pak hádat, co z těch změn jsou fixy, co reorganizace... mnohem pravděpodobnější je, že s povzdychnutím celý balík od vývojáře prostě zahodí, protože nebude mít nervy na to, hrabat se paralelní verzí svého balíku, a zkoumat, proč, co, kde a jak.

Přitom kdyby dostal několik diffů, jeden pro každý bugfix, jeden pro každý set nových funkcí či reorganizací, je pro něj prozkoumání změn mnohem pohodlnější a jednodušší, a hlavně na první pohled vidí, co patří k čemu, a může si vybrat -- triviální opravy commituje obratem, o složitějších může přemýšlet o každém zvlášť a stejně tak může mnohem pohodlněji rozhodnout o začlenění navrhovaných vzlepšení či změn ve struktuře ...

Nehledě k tomu, že může mít mezi tím u sebe rozděláno několik nových featur, které zatím nereleasoval, nebo zrovna teď dostal mailem podobný balík od jiného vývojáře. Viz příspěvek Michala Kubečka níže.

Vývoj open-source software, má-li k něčemu vést, musí podléhat určitým pravidlům, stejně jako cokoliv, na čem se podílí více lidí, a jakkoliv z vlastní zkušenosti velmi dobře vím, jak se vývojáři téměř štítí sáhnout na cokoliv, co jen trochu zavání scm ( ano, jsem configuration manager ), trvám na tom, že zasílání změn v podobě dobře komentovaných patchů je pro open source základ.

[jm]

No, podle me hlavne nema smysl psat 17kB projekt ve wxGTK...

[...............23]

no keby to nepoužívalo wxGTK, asi by to nemalo 17kB

[Michal Čihař]

<rejp>wxWidgets je hodně bugové, ale zrovna toto je vlastnost a ne bug.</rejp>

[kozzi]

no nevím čím to je ale žadná mail mi nepřišel. No jinak dík za ůpravy já jsem to ted smoll a uz to mam skorem hotovy. No a ted jsem zjistil že jsi je udělal za mě.

[kozzi]

no ale stejne si to radeji udelam sam protoze tento projekt delam pro to abych se neco naucil takze by to nemelo smysl sprach proste okopirovat i kdyby to bylo lepsi. Jinak vyuziji akorat toho zpusobu instalace.

[Jardík]

E-mail jsem posílal z webového rozhraní tady na abclinuxu.cz. Nevím, co jsi sem dal za e-mail, nebo jestli to správně funguje.

[kozzi]

jo uz vim vcem je chyba ja tam mam starej mail ale on je nastavenej aby mi vse preposlal na muj novej ucet. no nevim proc to nefunguje ale to uz je jedno opravil jsem to dal jsem tam ten novej mail.

[David Watzke]

dave amd64 ~/compile/wxDVDShrink $ ./configure
Running configure script for wxDVDShrink ...
Checking depencies ...
        wxGTK (required) ... found.
Depencies test OK.
Generating install and uninstall scripts ... done.
Generating Makefile ... done.

dave amd64 ~/compile/wxDVDShrink $ make
g++ -Wall -c -o output/objs/src/analyze.o  -I/usr/lib64/wx/include/gtk2-unicode-release-2.6
-I/usr/include/wx-2.6 -DGTK_NO_CHECK_CASTS -D__WXGTK__ -D_FILE_OFFSET_BITS=64
-D_LARGE_FILES -DNO_GCC_PRAGMA  src/analyze.cpp
In file included from /usr/include/dvdread/ifo_read.h:24,
                 from src/analyze.cpp:24:
/usr/include/dvdread/ifo_types.h:32:2: error: #error "Must include
<inttypes.h> or <stdint.h> before any libdvdread header."
make: *** [output/objs/src/analyze.o] Error 1

[kozzi]

podívej se sem:http://www.abclinuxu.cz/zpravicky/wxdvdshrink

[David Watzke]

Co tam mám najít?

[kozzi]

no problem je v libdvdread jinak toto resi nova verze na http://kozzi.php5.cz/wxDVDShrink-0.0.2.tar.gz