Bitwig Studio (Wikipedie) bylo vydáno ve verzi 6. Jedná se o proprietární multiplatformní (macOS, Windows, Linux) digitální pracovní stanici pro práci s audiem (DAW).
Společnost Igalia představila novou linuxovou distribuci (framework) s názvem Moonforge. Jedná se o distribuci určenou pro vestavěné systémy. Vychází z projektů Yocto a OpenEmbedded.
Google Chrome 146 byl prohlášen za stabilní. Nejnovější stabilní verze 146.0.7680.71 přináší řadu novinek z hlediska uživatelů i vývojářů. Podrobný přehled v poznámkách k vydání. Opraveno bylo 29 bezpečnostních chyb. Vylepšeny byly také nástroje pro vývojáře.
D7VK byl vydán ve verzi 1.5. Jedná se o fork DXVK implementující překlad volání Direct3D 3 (novinka), 5, 6 a 7 na Vulkan. DXVK zvládá Direct3D 8, 9, 10 a 11.
Bylo vydáno Eclipse IDE 2026-03 aneb Eclipse 4.39. Představení novinek tohoto integrovaného vývojového prostředí také na YouTube.
Ze systému Slavia pojišťovny uniklo přibližně 150 gigabajtů citlivých dat. Jedná se například o pojistné dokumenty, lékařské záznamy nebo přímou komunikaci s klienty. Za únik může chyba dodavatelské společnosti.
Sněmovna propustila do dalšího kola projednávání vládní návrh zákona o digitální ekonomice, který má přinést bezpečnější on-line prostředí. Reaguje na evropské nařízení DSA o digitálních službách a upravuje třeba pravidla pro on-line tržiště nebo sociální sítě a má i víc chránit děti.
Meta převezme sociální síť pro umělou inteligenci (AI) Moltbook. Tvůrci Moltbooku – Matt Schlicht a Ben Parr – se díky dohodě stanou součástí Meta Superintelligence Labs (MSL). Meta MSL založila s cílem sjednotit své aktivity na poli AI a vyvinout takovou umělou inteligenci, která překoná lidské schopnosti v mnoha oblastech. Fungovat by měla ne jako centralizovaný nástroj, ale jako osobní asistent pro každého uživatele.
Byla vydána betaverze Fedora Linuxu 44 (ChangeSet), tj. poslední zastávka před vydáním finální verze, která je naplánována na úterý 14. dubna.
Open source router Turris Omnia NG Wired je v prodeji. Jedná se o Turris Omnia NG bez Wi-Fi. Je připraven pro zamontování do racku.
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