Vývojáři svobodného 3D softwaru Blender představili (𝕏, Mastodon, Bluesky) nejnovějšího firemního sponzora Blenderu. Je ním společnost Anthropic stojící za AI Claude a úroveň sponzoringu je Patron, tj. minimálně 240 tisíc eur ročně. Anthropic oznámil sponzorství v tiskové zprávě Claude for Creative Work.
VNC server wayvnc pro Wayland kompozitory postavené nad wlroots - ne GNOME, KDE nebo Weston - byl vydán ve verzi 0.10.0. Vydána byla také verze 1.0.0 související knihovny neatvnc.
Bylo oznámeno vydání Fedora Linuxu 44. Ve finální verzi vychází šest oficiálních edic: Fedora Workstation a Fedora KDE Plasma Desktop pro desktopové, Fedora Server pro serverové, Fedora IoT pro internet věcí, Fedora Cloud pro cloudové nasazení a Fedora CoreOS pro ty, kteří preferují neměnné systémy. Vedle nich jsou k dispozici také další atomické desktopy, spiny a laby. Podrobný přehled novinek v samostatných článcích na stránkách
… více »David Malcolm se na blogu vývojářů Red Hatu rozepsal o vybraných novinkách v GCC 16, jež by mělo vyjít v nejbližších dnech. Vypíchnuta jsou vylepšení čitelnosti chybových zpráv v C++, aktualizovaný SARIF (Static Analysis Results Interchange Format) výstup a nová volba experimental-html v HTML výstupu.
Byla vydána verze R14.1.6 desktopového prostředí Trinity Desktop Environment (TDE, fork KDE 3.5, Wikipedie). Přehled novinek v poznámkách k vydání, podrobnosti v seznamu změn.
Jon Seager z Canonicalu včera na Ubuntu Community Hubu popsal budoucnost AI v Ubuntu. Dnes upřesnil: AI nástroje budou k dispozici jako Snap balíčky, vždy je může uživatel odinstalovat. Ve výchozím nastavení budou všechny AI nástroje používat lokální AI modely.
Nový ovladač Steam Controller jde do prodeje 4. května. Cena je 99 eur.
Greg Kroah-Hartman začal používat AI asistenta pojmenovaného gkh_clanker_t1000. V commitech se objevuje "Assisted-by: gkh_clanker_t1000". Na social.kernel.org publikoval jeho fotografii. Jedná se o Framework Desktop s AMD Ryzen AI Max a lokální LLM.
Ubuntu 26.10 bude Stonking Stingray (úžasný rejnok).
Webový prohlížeč Dillo (Wikipedie) byl vydán ve verzi 3.3.0. S experimentální podporou FLTK 1.4. S příkazem dilloc pro ovládání prohlížeče z příkazové řádky. Vývoj prohlížeče se přesunul z GitHubu na vlastní doménu dillo-browser.org (Git).
V Qt Labs se začalo uvažovat o Qt 5. Qt 4 vyšlo poprvé v červnu 2005 a ačkoliv jsou s ním vývojáři spokojení, je třeba uvažovat o některých nekompatibilních změnách. Qt 5 má nabídnout vyšší využívání GPU, usnadnit tvorbu uživatelského rozhraní s QML a JavaScriptem, usnadnit propojování s webem a webovými službami a zredukovat množství kódu nutného pro přípravu portu Qt na jinou platformu. Přechod by ale neměl být bolestivý, jako tomu bylo mezi Qt 3 a 4.
Tiskni
Sdílej:
Utf-16 prakticky má taky všechny znaky stejně dlouhý.Právě to slovo „prakticky“ dělá z utf-16 ten největší průser. Sám jsi tím dokázal, že obyčejný programátor si může myslet, že utf-16 je fixed-size a na zákadě toho ho implementovat špatně. V případě utf-8 se to může stát taky (viz třeba špatný návrh pythonu 2 ohledně unicode). Hlavní rozdíl je v tom, že u utf-8 se na to velmi rychle přijde a chyba se odhalí. V případě utf-16 ta chyba může zůstat neodhalená roky. A protože jde o disproporci mezi délkou řetězce ve znacích a délkou řetězce v dvoubajtech, může to vést na špatnou velikost bufferu, a tím až hrubou bezpečnostní chybu, která by se v utf-8 dřív a snáze odhalila.
Sám jsi tím dokázal, že obyčejný programátor si může myslet, že utf-16 je fixed-size a na zákadě toho ho implementovat špatně.No to může, co s tím můžu dělat
Že utf-8 je "blbuvzdornější", to asi je... ale za určitou (výkonnostní) cenu.
A protože jde o disproporci mezi délkou řetězce ve znacích a délkou řetězce v dvoubajtech, může to vést na špatnou velikost bufferu, a tím až hrubou bezpečnostní chybuNo, pokud si někdo špatně naimplementuje utf-16 - ie bude si myslet, že je fixed-sized, pak když mu přijde na vstup string se surrogate pairs, bude ten string považovat za delší co do počtu znaků a správně dlouhý co do počtu bajtů, takže se imho nestane, že by naalokoval menší buffer, než je třeba.
o to může, co s tím můžu dělatNemám v ruce reálná data, ale to ty nejspíš taky ne. Výkonový rozdíl utf-8 si dovolím odhadovat jako naprosto bezvýznamný.
No, pokud si někdo špatně naimplementuje utf-16 - ie bude si myslet, že je fixed-sized, pak když mu přijde na vstup string se surrogate pairs, bude ten string považovat za delší co do počtu znaků a správně dlouhý co do počtu bajtů, takže se imho nestane, že by naalokoval menší buffer, než je třeba.To je dost krátkozraký pohled. Ony se totiž při tvorbě software někdy používají knihovny nebo dokonce na jednom software pracuje více lidí. Nikdo ti nezaručí, že se programátoři budou plést konzistentně.
Výkonový rozdíl utf-8 si dovolím odhadovat jako naprosto bezvýznamný.Bezvýznamný pravědpodobně nebude. Validace utf-16 je algoritmicky o hodně jednodušší (jeden snadno předvídatelnej if) a narozdíl od utf-8 máš v ~95% případů konstatní přístup k prvku stringu, kdežto v utf-8 lineární vždy/velmi často.
"If the programming environment is not an issue, UTF-16 is recommended as a good compromise between elegance, performance, and storage."[odtud]
Ony se totiž při tvorbě software někdy používají knihovny nebo dokonce na jednom software pracuje více lidí. Nikdo ti nezaručí, že se programátoři budou plést konzistentně.Heh, neber to tak doslova, pochopitelně nepředpokládám, že by programátoři dělali chyby konzistentně. Mně se stejně opravdu nechce diskutovat na téma "standard X je špatný, protože programátor by ho mohl špatně pochopit."
Bezvýznamný pravědpodobně nebude. Validace utf-16 je algoritmicky o hodně jednodušší (jeden snadno předvídatelnej if) a narozdíl od utf-8 máš v ~95% případů konstatní přístup k prvku stringu, kdežto v utf-8 lineární vždy/velmi často.Což nic nemění na tom, že je to podle mě bezvýznamné.
Mně se stejně opravdu nechce diskutovat na téma "standard X je špatný, protože programátor by ho mohl špatně pochopit."Standard X je horší než standard Y, pokud se už předem dá předpokládat, že povede na chybné a nebezpečné implementace, zatímco standard Y už z principu nabízí daleko rychlejší objevení chyb :). Prostě UTF-16 je pouhý hack který vznikl z šestnáctibitového Unicode, který už byl překonán.
UTF-8 je taky hack, takže bych se raději zabýval tím, jaké jsou výhody/nevýhody v praxi, která jasně ukazuje, že UTF-16 je poměrně dobrý kompromis mezi výkonem a spotřebou paměti.Nepřesvedčil jsi mě.
No tak si zkus napsat nějakou funkci na manipulaci se stringem, třeba funkci, která vrátí substring od pozice m do n nebo tak něco, a porovnej si implementaci pro utf-8 a utf-16. Chápu, že na tvém 6-jádrovém Core i7 nebude rozdíl moc vidět, na nějakém mobilním ARMu apod. už to ale je něco jinýho...Psal jsem kdysi... Běžně ale počítač používám k jiným účelům než testování rychlosti rutin pro počítání znaků v řetězcích.
Běžně ale počítač používám k jiným účelům než testování rychlosti rutin pro počítání znaků v řetězcích.Je mi to jasný
:p
Mi bohatě stačí, když mají rozum návrháři knihoven typu Qt;)
The current plans for Qt5 mean that, unlike Qt4's reinvent the world approach (which was needed, if painful), it will be evolutionary and far less disruptive. This is the good news.Nevypada to tak.
Já jsem kdysi taky měl k JavaScriptu averzi, ale pokud se jednou podíváte na jeho model a hlouběji pod pokličku, tak zjistíte, že je vlastně velice dobře navržený. Hádám, že vývojáři Qt se na něj podívali a zjistili, že se k jejich záměrům hodí.
Adaptivní optimalizace. JVMko dělá něco podobného: např. když se zjistí, že dané volání, byť je třeba na proměnné typu rozhraní, je ve skutečnosti vždycky na jedné konkrétní třídě, tak ho devirtualizuje a z vyhledání metody udělá přímé volání s jednoduchou kontrolou. Pokud se někdy později stane, že se tam dostane objekt jiné třídy, tak to volání deoptimalizuje.Na jednu stranu ano, ale na druhou stranu v JS se díky obrovské dynamičnosti strašně špatně dělá ta kategorizace (kdežto ve staticky typovaném jazyce je tato informace známá). I když si v JS udělám třídu, tak do ní můžu dynamicky narvat další členy, čímž tuto optimalizaci zruším (a nebo se dostanu do fáze, kdy VM bude stále dokola patchovat kód, ale toto je asi ošetřené podmínkou 1x a dost). Javascript se začíná používat na hodně interaktivní grafické hračky, kde bych optimalizace uvítal. Já osobně věřím, že je možné jít ještě dál, ale staticky typované jazyky prostě mají tu hranici jinde, to je to:)
Ono v zásadě JVMko je taky virtuální mašina pro dynamicky typované jazyky (invokeinterface nezná typ cílového objektu a musí příslušnou metodu vyhledat za běhu, což má dokonce na různých JVMkách různou složitost), akorát že při nahrávání kódu se provádí verifikaceNo já osobně bych byl opatrnější v takovém tvrzení. Ono JVM využívá toho, že ty metody a jejich prototypy je možné získat z kompilovaných tříd, takže je logické, že můžu zavolat metodu v objektu, jehož typ neznám v době kompilace (já jsem něco takového používal třeba pro RPC). Na druhou stranu (nevím jak nejnovější JVM) je toto zjišťování poměrně drahé, řekl bych, mnohem dražší než v případě V8, kde je ta dynamičnost built-in. Ale toto všechno jen potvrzuje to, co si myslím - občas je vhodné mít dynamické typy, občas je lepší mít typovou kontrolu na úrovni jazyka. Mít možnost kombinovat statické/dynamické typování (takže mít výhody obou) mi přijde jako ta správná cesta, která by se mohla prosadit i v korporátní sféře.
v JS se díky obrovské dynamičnosti strašně špatně dělá ta kategorizace (kdežto ve staticky typovaném jazyce je tato informace známá). I když si v JS udělám třídu, tak do ní můžu dynamicky narvat další členy, čímž tuto optimalizaci zrušímVyrobí se nová třída, zneplatní se pár callsite a jede se dál
Dobře, není to tak jednoduché, vlastně je to docela magie, ale není to žádná tragédie. IMHO javascriptové virtuální mašiny jsou s optimalizacemi teprve na začátku. C/C++ z toho nebude nikdy, ale už dneska na tom JavaScript není výkonnostně nijak špatně. Výpočetně náročná místa asi bolí (nemůžu pořádně říct), ale ta řekl bych nebudou nijak závratně dynamická. Naopak může bolet to, že JavaScript má jeden jediný (hloupý) číselný typ, takže co by stačilo udělat v celých číslech se zbytečně počítá v plovoucí řádové čárce. Takových věcí asi bude víc.
Naopak může bolet to, že JavaScript má jeden jediný (hloupý) číselný typ, takže co by stačilo udělat v celých číslech se zbytečně počítá v plovoucí řádové čárce. Takových věcí asi bude víc.Toto na x86 problém není, ale na takovém ARMu celkem i jo
), ale na věci okolo je IMHO dostatečně výkonný už dneska.
hlavně ať se co nejdřív podaří z běžných desktop aplikací vymlátit C/C++Wtf! Blábol týdne...
Je to takovy scriptovaci Cecko. Kdyz se odhodi ta prisehna obludarna, kterou je JS ovesenej v browserech, tak je to prekvapive fajn jazyk. Navic mu intitivne rozumi skoro kdokoliv.
Když odhodím to obludárium, tak dostanu jazyk, ve kterém nejde napsat ani knihovna:)No, zato v něm lze triviálně napsat systém, který knihovny implementuje. Existuje pro to poměrně široce přijímaná specifikace. To zamlčuješ proto, že o tom nevíš?
10.5.2011 17:25
mirec | skóre: 32
| blog: mirecove_dristy
| Poprad
AbcLinuxu.cz
ITBiz.cz
HDmag.cz
AbcPráce.cz
10.5.2011 12:49
11.5.2011 12:15
Row {
PushButton { width: parent.width / 2 ...}
PushButton { width: parent.width / 2 ...}
}
s layoutmi sa to dalo poriešiť jednotucho ako
QVBoxLayout *layout = new QVBoxLayout(this); layout->addWidget(btn1); layout->addWidget(btn2);Riešenie s layoutmi sa mi zdá ďaleko elegantnejšie. Na rozdiel od QML mi layouty zaručia, že okno bude mať určitú minimálnu veľkosť odvodenú od veľkosti komponentov. Nehovorím, že sa podobné správanie nedá dosiahnuť pomocou QML, ale pripadá mi to ako riešenie pre psychopatov. Robili ste niekto niečo ako layouty pre QML? Neviete, či v Qt 5 bude niečo pre automatické umiestňovanie komponentov?
10.5.2011 19:54
mirec | skóre: 32
| blog: mirecove_dristy
| Poprad
10.5.2011 19:11