Homebrew (Wikipedie), správce balíčků pro macOS a od verze 2.0.0 také pro Linux, byl vydán ve verzi 4.5.0. Na stránce Homebrew Formulae lze procházet seznamem balíčků. K dispozici jsou také různé statistiky.
Byl vydán Mozilla Firefox 138.0. Přehled novinek v poznámkách k vydání a poznámkách k vydání pro vývojáře. Řešeny jsou rovněž bezpečnostní chyby. Nový Firefox 138 je již k dispozici také na Flathubu a Snapcraftu.
Šestnáctý ročník ne-konference jOpenSpace se koná 3. – 5. října 2025 v Hotelu Antoň v Telči. Pro účast je potřeba vyplnit registrační formulář. Ne-konference neznamená, že se organizátorům nechce připravovat program, ale naopak dává prostor všem pozvaným, aby si program sami složili z toho nejzajímavějšího, čím se v poslední době zabývají nebo co je oslovilo. Obsah, který vytvářejí všichni účastníci, se skládá z desetiminutových
… více »Richard Stallman přednáší ve středu 7. května od 16:30 na Technické univerzitě v Liberci o vlivu technologií na svobodu. Přednáška je určená jak odborné tak laické veřejnosti.
Jean-Baptiste Mardelle se v příspěvku na blogu rozepsal o novinkám v nejnovější verzi 25.04.0 editoru videa Kdenlive (Wikipedie). Ke stažení také na Flathubu.
TmuxAI (GitHub) je AI asistent pro práci v terminálu. Vyžaduje účet na OpenRouter.
Byla vydána nová verze R14.1.4 desktopového prostředí Trinity Desktop Environment (TDE, fork KDE 3.5, Wikipedie). Přehled novinek i s náhledy v poznámkách k vydání. Podrobný přehled v Changelogu.
Bylo vydáno OpenBSD 7.7. Opět bez písničky.
V Tiraně proběhl letošní Linux App Summit (LAS) (Mastodon). Zatím nesestříhané videozáznamy přednášek jsou k dispozici na YouTube.
To co jste napsal je obyčejný FUD a plyne jedině z neznalosti.
Pokud chcete psát něco o C++, měl by jste si první prostudovat možnosti tohoto jazyka a ne šířít nesmysly typu, že C++ je vždycky pomalejší než C. Právě naopak, v C++ máte možnosti vytvořit vysoce optimalizované funkce, které by jste v C vytvořil asi tak pomocí miliónů maker a 20 hlavičkových souborů, které by jste pomocí nastavených maker includoval třeba 20x po sobě. Samozřejmě, že jsem to trošku nafoukl, jediné co k tomu můžu napsat je, že váš kód by na první pohled nikdo nepochopil ;)
Pokud vypnete v C++ vyjimky a RTTI, máte totálně ekvivalentní jazyk, co se týče generování kódu a rychlosti jako C, a navíc máte neuvěřitelné možnosti při psaní kódu, jaké v C mít nikdy nebudete.
Pokud vám vadí demanglování jmen funkcí, můžete použít extern "C".
Překladač už při překladu ví, jaký index má použít, navíc může díky znalosti virtuálních funkcí cachovat jejich počáteční adresu.
MSVC navíc používá speciální konvenci, kdy se jako parametr this používá registr ecx, může se to zdát jako banalita, ale toto je úplně perfektní věc pro vytváření delegátů. To už jsme ale trochu odbočili :)
AbcLinuxu.cz
ITBiz.cz
HDmag.cz
AbcPráce.cz
29.10.2008 01:33
29.10.2008 10:22
struct ObjectVTable
{
void (*vfunkce)(Object* self);
};
struct Object
{
ObjectVTable* vtable;
};
při volání virtuální funkce se provede úplně jednoduchá věc:
Object* o = ... o->vtable->vfunkce(o);Pokud překladač ví, že se jedná o tabulku virtuálních funkcí (což v případě C++ implementace ví), tak si hodnotu vtable může uchovat v registru a vygenerovat lepší kód než v C implementaci. Index vfunkce() je v našem případě 0. Je to věc známá při překladu o žádné prohledávání tabulky se nejedná.
29.10.2008 21:37
Stanislav Brabec | skóre: 45
| Praha
this. To se však často nestává, a navíc i tato výhoda je dána pouze kvalitou optimalizátoru.
Jak už bylo výše řečeno, toto platí za předpokladu, že nepoužijete RTTI a k volbě instance použijete přetížení. Pokud kód větvíte podle toho, zda je argument int nebo float, je to něco jiného.
Tedy přesně totéž, co udělá programátor v C nebo v assembleru, pokud potřebuje proměnný odkaz na funkciÁno, toto jsou virtuální funkce. Ale já bych dodal ještě to, že v C++ překladač ví, že se jedná o vtable a ta by se neměla změnit při volání její funkce, takže optimizér si klidně může uložit vtable do registru a při volání více funkcí se ta dereference udělá jen 1x.
Jediná teoretické výhoda C spočívá ve virtuální funkci samotné, pokud by nebylo potřeba předávat implicitní this. To se však často nestává, a navíc i tato výhoda je dána pouze kvalitou optimalizátoru.Pokud se toto stane, můžeme si přeci i v C++ udělat strukturu funkcí a tu používat pro tento účel - toto se používá v grafických knihovnách.
Pokud kód větvíte podle toho, zda je argument int nebo float, je to něco jinéhoTady se neshodnem. Je to stejné. Pořadí přetížených funkcí v tabulce virtuálních funkcí má taky logiku, takže se jedná opět o věc známou z překladu.
29.10.2008 22:10
Stanislav Brabec | skóre: 45
| Praha
Ale já bych dodal ještě to, že v C++ překladač ví, že se jedná o vtable a ta by se neměla změnit při volání její funkce, takže optimizér si klidně může uložit vtable do registru a při volání více funkcí se ta dereference udělá jen 1x.K tomu lze v moderním C použít
-fstrict-aliasing.
Měl jsem na mysli větvení v kódu, tedy RTTI, k němuž je třeba předávat identifikátory typu jako skryté proměnné.Pokud kód větvíte podle toho, zda je argument int nebo float, je to něco jinéhoTady se neshodnem. Je to stejné. Pořadí přetížených funkcí v tabulce virtuálních funkcí má taky logiku, takže se jedná opět o věc známou z překladu.
Zná index, nezná hodnotu na tomto indexu uloženou.Jo presne tak.
Jediná teoretické výhoda C spočívá ve virtuální funkci samotné, pokud by nebylo potřeba předávat implicitní this. To se však často nestává, a navíc i tato výhoda je dána pouze kvalitou optimalizátoru.Intel i MSVC garantuji, ze this bude vzdy ulozen v registru, nicmene GCC ho (pokud neni potreba) vubec nepreda. Intel by zase mel umet provadet devirtualizaci (mozna uz i GCC, nevim, uz je to docela dlouho co jsem zkoumal jake optimalizace umi), diky cemu je pak mozne virtualni funkce, ktere nejsou zakryte pouzivat s casnou vazbou a diky tomu i inlinovat.
Jak už bylo výše řečeno, toto platí za předpokladu, že nepoužijete RTTI a k volbě instance použijete přetížení. Pokud kód větvíte podle toho, zda je argument int nebo float, je to něco jiného.Smysl tehle vety mi dost unika. Mam pocit ze pletete dohromady zakryti metody pri dedicnosti a pretezovani metod/funkci.
30.10.2008 10:02
Stanislav Brabec | skóre: 45
| Praha
To, že zatímco přetěžování lze plně vyhodnotit během kompilace, konstrukce typuJak už bylo výše řečeno, toto platí za předpokladu, že nepoužijete RTTI a k volbě instance použijete přetížení. Pokud kód větvíte podle toho, zda je argument int nebo float, je to něco jiného.Smysl tehle vety mi dost unika. Mam pocit ze pletete dohromady zakryti metody pri dedicnosti a pretezovani metod/funkci.
if (typeid(argument1) == int) mají režii i v době běhu programu.
cudna logika - kedze C nema objektove rozsirenia je asi logicke ze vysledna struktura programu bude inaPokud v C naprogramuju to, co C++ udělá za mě, tak bude struktura programu úplně stejná. Pokud C++ překladač navíc uplatní nativní možnosti C++, bude výsledná binárka lepší ta z C++.
ci aj v asemblere budete brutalne OBJEKTOVYJá dokážu zvážit to, na co použiju asm a na co ne. Pokud chcete být objektový v asm, klidně můžete, ale budete psát podobné věci, jaké vám lezou z překladu C++.
v linuxe sa nepouziva c++ jednoducho preto ze jeho rezia je vacsia ako v CVídím, že existuje opravdu hodně lidí, co takovému nesmyslu věří. Otázka je, co berete jako C++. Jestli jazyk, nebo STL, nebo rozšíření o výjimky a RTTI. Já beru C++ jako jazyk a STL jako knihovnu, kterou nemusím použít. Je jasné, že pokud to s STL přeženu, tak bude program větší, ale nikdy nebude pomalejší. Pokud chci malé binárky, tak jednoduše nepoužiju STL ale hlavně výjimky. Pokud tedy tvrdíte, že C++ je pomalejší než C, tak řekněce, co konkrétně ? Podle vaší reakce mám totiž pocit, že o C++ nevíte skoro nic.
btw na vyslednu rychlost to ci sa nieco inkluduje raz alebo 100x nema vplyv ci mate inu skusenostToto není debata o překladu z C/C++ do asm.
PRECO by mal niekto programovat v C rovnako ako v C++??? uvedomte si ze C++ a C su dva rozdielne jazykyProc by mel nekdo pouzit druhy jazyk? Jenom proto ze to rikate? Samozrejme ze to jsou rozdilene jazyky, nicmene C++ je vybudovano nad Ceckem a oba standardy se snazi drzet maximalni moznou vzajemnou kompatibilitu.
"Pokud chci malé binárky, tak jednoduše nepoužiju STL ale hlavně výjimky" - co viac povedat - vieto o com pisete? mam pocit ze ste si len cosi precital na webe, tomu co tam pisali ste neporozumel a teraz z toho gulasu co mate v hlave tu hlasate podobne veci.Zakladni problem C++ pri kompilaci je, ze do binarnich souboru cpe obrovske mnozstvi symbolu. Po stripnuti techto symbolu jsou obvykle datove objemy binarek v jazycich C a C++ velmi podobne. Btw. kdo dnes proboha optimalizuje na velikost binarky? To se dela jedine u embeded zarizeni, kam bych C++ v dnesni dobe nedoporucil (nedostatek kvalitnich kompilatoru).
inac pre vase info pouzivam C++ od doby co vysiel vobec prvy prekladac Borlandu pre toto prostredie.Tak si obcas zkuste zjistit co vam ten kompilator s kodem dela.
Uvedomte si ze ludia co robia na kerneli a su postaveny v hierarchii vyssie urcite nemaju ziadny problem so zvladnutim C++,Java,...,...Coz nema vubec nic spolecneho s tim ze na jadre delaji tisice lidi a spousta z nich C++ neumi.
Clovek co vie programovat sa v novom jazyku behom mesiaca, dvoch orientuje absolutne pohodlne.Zacinam docela chapat proc tady placate takove kraviny.
"Pokud chci malé binárky, tak jednoduše nepoužiju STL ale hlavně výjimky" - co viac povedat - vieto o com pisete?Vím. Pokud by jste o C++ opravdu něco věděl (což jste mi ukázal pravý opak), věděl by jste, že výjimky vám způsobí nárust binární velikosti kódu asi o 10%. Toto je jediná věc na C++, která vám opravdu zvětší binárky, proto ji hodně projektů nepoužívá (Qt, Kde, aplikace od Google, wxWidgets, ...). PS: Já znám překladač od Borlandu, doma mám dokonce orig. verzi 3.1, kde jsem za dávných dob používál TurboVision.
akych objektov v CMěl by jste se někdy podívat do zdrojových kódu projektů, které jsou napsané v C. Mám totiž pocit, že C programátoři jsou mnohdy více objektově založení než C++ programátoři.
C++ je asi tak 7x pomalsieJenže to nebyl identický kód. Od začátku se tu vede flame o tom, že v C++ je pomalejší stejný kód jako v C, což se vám tady pár lidí snaží vyvrátit, ale marně.
chcete povedat ze vytvorenie objektu v C++ je casovo obdobne narocne ako alokacia pamate v C pre dany typ
class A
{
int x;
int y;
public:
A() { kod1; }
~A() { kod2; }
};
int main()
{ A a; }
Je zcela ekvivalentni (dokonce jde o implementaci, ktera se pouziva pri kompilaci C++ kodu) s:
struct A
{
int x;
int y;
};
void Init(struct A const * a) { kod1; }
void DeInit(struct A const * a) { kod2; }
int main()
{ struct A a; Init(&a); DeInit(&a); }
Ukazte mi ten vas overhead objektu.
.
OK mam dost dlouhou zkusenost z obojiho, mam prekladac, ktery by mel byt optimalizovany (dle vyrobce jak pro C tak pro C++), Metrowerks CodeWarrior. Pokud pouziju C++ tak mi stoupne pametova naroznost o polovinu a beh SW se viditelne zpomali, vzhledem k tomu, ze chvilemi je pro me nutna okamzita reakce, je kobinace C a Asembleru idealni. Nebudu tam cpat C++ ktere jenom ze tam je spolkne nejaky 3,5 kByte Flash z 128kByte a skoro 2kByte RAM z 8k. Navic kazda funkce je vice narocna , protoze sice kon je mensi, ale prilinkovane knihovny vetsi.
A to programuju malo objemove ridici jednotky, kde pro me neni cena tim nedulezitejsim, tedy se mohu rozhodnout, co pouziji.
29.10.2008 07:45
zoul | skóre: 43
| blog: ☂
| Boskovice
29.10.2008 07:55
zoul | skóre: 43
| blog: ☂
| Boskovice
Skoro mi to prijde, ze mas na mysli nejaky jiny jazyk, v cemz me utvrzuje i to, ze v tom shootoutu Objective-C je.
Tomas
30.10.2008 11:15
zoul | skóre: 43
| blog: ☂
| Boskovice
Na desktopove aplikace staci, ale to je vsechno v uvozovkach.Píšou se v něm i hry pro iPhone, bez jakýchkoliv výkonnostních problémů ze strany jazyka. Ono je sice hezký říct, že zasílání zpráv je ve srovnání s voláním funkcí brutálně pomalé, ale doby, kdy pár instrukčních cyklů znamenalo rozdíl mezi pomalým a rychlým programem, jsou dávno pryč. Dneska jsou podobné rozdíly podstatné jen u několika málo procent programů.
29.10.2008 14:22
Algi | skóre: 1
| blog: Sinner
29.10.2008 13:25
Stanislav Brabec | skóre: 45
| Praha
struct) v právě definované struct („třídě“).
Virtuální dědičnost v C = vložení „zděděné“ „třídy“ (struct) do právě definované struct („třídy“).
Šablony jsou věc na úrovni zdrojového kódu, makra jsou, pravda, jen částečnou náhražkou. Metaprogramování v něm neuděláte.
Metoda = funkce (nejspíš začínající jménem „třídy“), v jejíž dokumentaci je uvedeno, k čemu slouží
Virtuální metoda = ukazatel na funkci v definici struct („třídy“).
Konstruktor/destruktor = funkce s _new a _destroy na konci názvu.
40znakový prefix znamená sice nepříjemnost při psaní kódu. Při čtení nebo ladění je rozhodně příjemnější, než dohledávání mezi desítkami definic přetíženého jména v C++.
No a díky GObject máte možnosti, kterými C++ objekdy nedisponují – posílání zpráv, nastavování vlastností objektu, čítač referencí.
Obliba C asi spočívá v tom, že:
Většina toho v C také jde, jen se to jinak píše a jinak nazývá: ...Já to znám, vím že to jde, ale otázka je, jestli vám přijde přehledné to takto dělat ?
Virtuální metoda = ukazatel na funkci v definici struct („třídy“).Takže:
struct A {
void (*method0)(A* self, int param0, int param1);
void (*method1)(A* self, int param0, int param1);
...
void (*method100)(A* self, int param0, int param1);
}
a v kódu:
A* A_new()
{
A* self = (A*)malloc(sizeof(A));
if (!self) return NULL;
...
self->method0 = A_method0;
...
self->method100 = A_method100;
}
Toto je podle vás dědičnost ? Toto jsou obyčejné ukazatele na funkce. V C se dá udělat dědičnost tak, že by se vytvořila další struktura, která by byla podobná té z C++ (virtuální tabulka funkcí), předpokládám, že jste to myslel spíš tak.
40znakový prefix znamená sice nepříjemnost při psaní kódu. Při čtení nebo ladění je rozhodně příjemnější, než dohledávání mezi desítkami definic přetíženého jména v C++.Já ladím pomocí nástrojů IDE, takže tento argument je úplně mimo. Nevšiml jsem si rozdílů mezi laděním C kódu a C++ kódu.
No a díky GObject máte možnosti, kterými C++ objekdy nedisponují – posílání zpráv, nastavování vlastností objektu, čítač referencí.Já mám na GObject jiný názor. Nastavování properties a události je věc, která není nativně v C/C++ a člověk si ji musí naprogramovat. GObject je řešení pro C, ale otázka je, jak moc kvalitní. A nemusím chodit ani daleko. Ukažte mi nějaký nástroj (code assist), který umí GObject, který je vám schopný ukázat, jaké máte možnosti. To samé pro vaši dědičnost v C a virtuální funkce v C ? jako nezlobte se, ale jestli vám přijde přehlednější toto:
GJmenoKnihovnyNazevObjektu *o = neco...; int x = g_nazev_zdedeneho_objektu_x_get(G_NAZEV_ZDEDENEHO_OBJEKTU(o)); int y = g_nazev_zdedeneho_objektu_y_get(G_NAZEV_ZDEDENEHO_OBJEKTU(o));než toto:
JmenoKnihovny::NazevObjektu *o = neco...; int x = o->x(); int y = o->y();Tak jsme asi oba někde jinde
Obliba C asi spočívá v tom, že:Jak jsem psal výše, to už není o oblibě, ale o držení se zajetých kolejí.
29.10.2008 17:44
Stanislav Brabec | skóre: 45
| Praha
Toto je podle vás dědičnost ? Toto jsou obyčejné ukazatele na funkce. V C se dá udělat dědičnost tak, že by se vytvořila další struktura, která by byla podobná té z C++ (virtuální tabulka funkcí), předpokládám, že jste to myslel spíš tak.Struktura, v ní virtuální tabulkou funkcí, a ukazatel na ní z nadřazené třídy. Prostě to, co udělá překladač jazyka C++ při kompilaci.
Já ladím pomocí nástrojů IDE, takže tento argument je úplně mimo. Nevšiml jsem si rozdílů mezi laděním C kódu a C++ kódu.Občas jen čtu kód a hledám, kde je definovaná funkce, která se vykoná. A to jde v C++ hůř, zatímco v C stačí
grep na hlavičkové soubory.
Já mám na GObject jiný názor. Nastavování properties a události je věc, která není nativně v C/C++ a člověk si ji musí naprogramovat. GObject je řešení pro C, ale otázka je, jak moc kvalitní.Třeba se dá se diskutovat, zda třeba řetězcové identifikátory vlastností jsou z hlediska efektivity ideální. A nemusím chodit ani daleko. Ukažte mi nějaký nástroj (code assist), který umí GObject, který je vám schopný ukázat, jaké máte možnosti. To samé pro vaši dědičnost v C a virtuální funkce v C ?
jako nezlobte se, ale jestli vám přijde přehlednější toto:Asi ano. První forma mi připadá přehlednější – myšlenkové úsilí potřebné na představení výsledné podoby kódu je nižší. Programování jsem se začal učit ve strojním kódu, později jsem se naučil assembler, teprve mnohem později C. C mi tehdy připadalo jako příliš vysokoúrovňový jazyk, ve kterém některé věci nejdou popsat přesně. C++ mi ve většině případů připadá jako zbytečná úroveň abstrakce dodnes (s výjimkou maticové algebry, komplexních čísel a podobných věcí).GJmenoKnihovnyNazevObjektu *o = neco...; int x = g_nazev_zdedeneho_objektu_x_get(G_NAZEV_ZDEDENEHO_OBJEKTU(o)); int y = g_nazev_zdedeneho_objektu_y_get(G_NAZEV_ZDEDENEHO_OBJEKTU(o));než toto:JmenoKnihovny::NazevObjektu *o = neco...; int x = o->x(); int y = o->y();Tak jsme asi oba někde jinde
Struktura, v ní virtuální tabulkou funkcí, a ukazatel na ní z nadřazené třídy. Prostě to, co udělá překladač jazyka C++ při kompilaci.Rozdíl mezi náma je ten, že já nechám překladač vyrobit tu tabulku a naplnit. Vy ji musíte definovat, napsat prototypy funkcí a pak při inicializaci knihovny naplnit pro každou třídu (strukturu) zvlášť.
Občas jen čtu kód a hledám, kde je definovaná funkce, která se vykoná. A to jde v C++ hůř, zatímco v C stačí grep na hlavičkové soubory.Já jsem zvyklý na "goto declaration" nebo "goto definition". Nemusím nic hledat, code assist to dělá za mě.
Třeba se dá se diskutovat, zda třeba řetězcové identifikátory vlastností jsou z hlediska efektivity ideální.Když se to udělá hash, tak jo :)
Asi ano...Vidíte, mi to přijde jako zbytečná redundance. Blbé je to, že jsem v tomto vlákně chtěl srovnávat jazyk C a C++ hlavně kvůli novým projektům. Nastolit otázku, zda se opravdu vývojářům zdá výhodné použít tento jazyk na dlouhodobé projekty. Nemusí to být ani otázka personálních preferencí, ale třeba otázka typu, zda je dostatek vývojářu pro konkrétní jazyk. O rychlosti vývoje ani nemluvím :)
29.10.2008 20:59
Stanislav Brabec | skóre: 45
| Praha
I tak je to stále komplikovanější, než unikátní identifikátor typu int. Ovšem v jeho případě by zase byl problém se zajištěním jeho unikátnosti, zvlášť v takových případech, kdy např. widget zdědí nějakou vlastnost specifickou pro určité grafické téma.Třeba se dá se diskutovat, zda třeba řetězcové identifikátory vlastností jsou z hlediska efektivity ideální.Když se to udělá hash, tak jo :)
Blbé je to, že jsem v tomto vlákně chtěl srovnávat jazyk C a C++ hlavně kvůli novým projektům. Nastolit otázku, zda se opravdu vývojářům zdá výhodné použít tento jazyk na dlouhodobé projekty. Nemusí to být ani otázka personálních preferencí, ale třeba otázka typu, zda je dostatek vývojářu pro konkrétní jazyk. O rychlosti vývoje ani nemluvím :)Podobné srovnání jsem sám pro sebe dělal před pár týdny při kursu C++. A došel jsem k závěru, že efektivní používání C++ (ale platí to skoro pro jakýkoliv jazyk) znamená nejen se daný jazyk naučit, ale také se naučit myslet v prostředcích, které ten jazyk nabízí. Druhý krok je výrazně těžší. Tomu, kdo umí C a učí se C++, připadají vymoženosti C++ vykoupené komplikovaností jazyka.
I tak je to stále komplikovanější, než unikátní identifikátor typu int. Ovšem v jeho případě by zase byl problém se zajištěním jeho unikátnosti, zvlášť v takových případech, kdy např. widget zdědí nějakou vlastnost specifickou pro určité grafické téma.Mnohdy je těžké zajistit i unikátnost řetězců, pokud se tedy unikátnost nezajistí stylem "prostorJmen-objekt-signal" (stylem dbus).
Podobné srovnání jsem sám pro sebe dělal před pár týdny při kursu C++. A došel jsem k závěru, že efektivní používání C++ (ale platí to skoro pro jakýkoliv jazyk) znamená nejen se daný jazyk naučit, ale také se naučit myslet v prostředcích, které ten jazyk nabízí. Druhý krok je výrazně těžší.Každý jazyk je potřeba se naučit
Já vidím problém hlavně v tom, že někteří lidi píšou o C++ nesmysly a ty se pak šíří mezi ostatní. Viz například FUD typu "C je rychlejší než C++". Když už tato věta odradí někoho od C++ a začne to šířit aniž by si vyzkoušel, co je na tom žvástu pravdy, tak je to těžké. Já si třeba myslím, že rychlost aplikace závisí hlavně na kvalitě ostatních komponent a na algoritmech v aplikaci, ale to sem pletu něco na co jsem odpovídal výše -- ale mám to pořád v hlavě
29.10.2008 22:01
Stanislav Brabec | skóre: 45
| Praha
Já si třeba myslím, že rychlost aplikace závisí hlavně na kvalitě ostatních komponent a na algoritmech v aplikaciTo je pravda. Stačí zevrubnější pohled do zdrojáku leckterého projektu (nebo jen do dokumentace API), aby člověku začaly vstávat vlasy hrůzou na hlavě. I v GNOME najdeme příkladů dost: Dialog pro výběr souboru ve starých verzích GTK+ četl aktuální adresář 6×. GTK Tree View Column nelze jednoduše učinit necitlivý na aktivaci řádku po kliknutí. Evolution ve svém původním návrhu u některých funkcí nepočítala, že by mohly selhat nebo nikdy neskončit. Při implementaci POP3 šlo o lokální operace, tak se to neřešilo. Problémy nastaly až při implementaci IMAP a trvají dodnes. Pidgin nadefinoval obecné API pro přenos souborů. Existující implementace se na to nějak nabastlily, a máme z toho pěkné CVE.
29.10.2008 11:49
Ilfirin | skóre: 32
| blog: ilfblog
| Liberec
Bez zajímavosti není ani pohled na programovací jazyky, které nové aplikace používají. Empathy je napsáno v jazyce C (stejně jako Vinagre a Cheese), Hamster používá Python. Nezdá se tedy, že by se v GNOME dostávalo většího prostoru jazyku C# (a technologii Mono obecně), jak by to mohlo vypadat z různých komentářů.Takhle bych na to nekoukal. Jak jsem různě četl, Gnome je otevřený všemu zajímavému, ať je to napsané v čemkoli. Kdyby byl Hamster v C#, tak by byl v C# a nic by se nezměnilo. Různí komentátoři v tom hledají politiku, ale ona tam žádná není.
30.10.2008 08:43
Ilfirin | skóre: 32
| blog: ilfblog
| Liberec
jen reaguji na názory, že GNOME migruje (stávající aplikace) do C#Tak to se mi opět vybavuje Miguelova odpoveď na to, jestli budou migrovat Evolution do C#, kde odpověděl, že ani náhodou, že ten kód trvalo vyvinout a odladit několik let, tak ho nehoděj přece jen tak přes palubu. To dává logiku a myslím, že podobné to bude i jinde. Migrace stávajících ne, ale nové aplikace, to je věc jiná.
29.10.2008 15:39
Grunt | skóre: 23
| blog: Expresivní zabručení
| Lanžhot
BTW:Screenshoty se mají vybírat
BTW2:Funguje někomu Ekiga či jiný SIP klient na VIPhone?
A zjistil jsem, že jsem nejproduktivnější ve středu v podvečer.Na tom něco určitě bude.
BTW:Screenshoty se mají vybíratNelíbil se mi ten stín...
29.10.2008 16:33
Grunt | skóre: 23
| blog: Expresivní zabručení
| Lanžhot
GIMP prý ale také vyšel v nové verzi. No, kdo ví…
29.10.2008 16:39
Grunt | skóre: 23
| blog: Expresivní zabručení
| Lanžhot
BTW2:Funguje někomu Ekiga či jiný SIP klient na VIPhone?Mně fungoval Twinkle, ale co jsem koupil HW telefon, tak jsem ho s tímto operátorem nepoužil (momentálně jsem u 802.cz a účet u Viphone si nechávám jen proto, že ho tam má i bratr a můžu mu tak volat zadarmo). Ekigu se mi kdysi taky podařilo rozběhnout, ale při provozu to porůznu padalo, takže jsem u ní nezůstal. Ovšem to je už tak dva - tři roky.
29.10.2008 21:00
Grunt | skóre: 23
| blog: Expresivní zabručení
| Lanžhot
Od jiného operátora jsem to ovšem nezkoušel, takže nevím.
Nemůže to být tím, že se snažíte použít nějaký kodek, který Vifouni neumí?
30.10.2008 22:55
Grunt | skóre: 23
| blog: Expresivní zabručení
| Lanžhot
... osobně by mě zajímalo, kolik lidí hodnotí samotný článek, a kdo mě, Ubuntu atd.
A ani to moc neřeším, napsal jsem: "jen jsem zvědavý". Fakt mě to zajímá.
31.10.2008 14:16
Grunt | skóre: 23
| blog: Expresivní zabručení
| Lanžhot
Tiskni
Sdílej:
29.10.2008 22:59
