Programovací jazyk Python byl vydán v nové major verzi 3.15.0. Podrobný přehled novinek v aktualizované dokumentaci.
BIGWORDS.PAGE je open-source webová aplikace, která po otevření odkazu v prohlížeči vykreslí přes celou obrazovku jednoduché informační sdělení. Zpráva i její nastavení jsou uložené v části URL za znakem #, například odkaz https://bigwords.page/#abclinuxu zobrazí jako velký bílý nápis 'abclinuxu' na černém pozadí. Obsah odkazu lze upravovat i vestavěným editorem, ten umožňuje nastavovat formátování a vizuální efekty textu, časovače, QR kódy a obrázky. Zdrojový kód je dostupný pod licencí MIT na GitHubu.
V neděli 11. října proběhne rotace klíče kořenové zóny. Podruhé v historii. Ondřej Filip na blogu CZ.NIC: "Pokud je pro Vás DNS protokol spíše výzva, ale přesto spravujete nějakou síť či DNS resolver, zkuste si jednoduchý test, který připravila firma Cloudflare na této adrese. Obzvláště zbystřit byste měli, pokud uvidíte nějaká červená políčka."
Vláda Spojených států se rozhodla vyřadit americkou softwarovou společnost Microsoft a několik dalších velkých technologických podniků z programu, který umožňuje kvalifikovaným zahraničním pracovníkům získat povolení k trvalému pobytu. Oznámila to včera administrativa amerického prezidenta Donalda Trumpa. Opatření zdůvodnila rozsáhlým zneužíváním programu, který je dlouhodobě terčem kritiky ze strany Trumpových příznivců, neboť prý znevýhodňuje americké pracovníky.
Datové centrum největší ruské technologické společnosti Jandex v Rjazaňské oblasti se stalo cílem dronového útoku a zastavilo provoz. Jandexu se někdy přezdívá „ruský Google“. Provozuje nejoblíbenější internetový vyhledávač v Rusku nebo aplikace pro objednávky jídla a taxi. Využívají jej desítky milionů lidí v rusky mluvících zemích.
Francouzská společnost Mistral AI představila Mistral Large 4 (interně přezdívaný 'le Chonk', volně přeloženo 'pořádný macek'), 'open-weight multimodální hybridní instruct-and-reasoning model s architekturou granulárního MoE, nativně podporující více jak 160 jazyků'. Model má přes jeden bilión parametrů, z nichž při práci využívá 49 miliard, kontextové okno o délce milion tokenů a obrazový enkodér o 1,6 miliardách parametrů.
… více »Svobodný multiplatformní herní engine Bevy napsaný v Rustu byl vydán ve verzi 0.20. Díky 227 přispěvatelům.
Simon Long oznámil Raspberry Pi Desktop pro PC a Mac s Intelem postavený na aktualizovaném Debianu 13 Trixie. S klientem Raspberry Pi Connect pro vzdálenou správu. Ke stažení je vedle Raspberry Pi OS pro Raspberry Pi.
ESP32-C3 adblock přemění lacinou vývojovou desku ESP32‑C3 na samostatný DNS blokovač nejenom reklamních domén, minimalistickou alternativu k populárnímu Pi-hole. ESP32-C3 adblock místo objemných názvů domén ukládá jejich 40-bitové FNV-1a hashe do flash paměti, které pak binárně prohledává, kontrola jedné domény trvá přibližně 10 milisekund. Blocklist pojme až 537 tisíc domén a lze jej spravovat přes webové rozhraní. Projekt zatím
… více »ArtCraft je sada open source aplikací pro práci s obrázky a videi "inspirovaných" aplikacemi od Adobe. Napsaných v Rustu. Pro MacOS, Windows i Linux. Běží také ve webovém prohlížeči. Aktuálně se jedná o 7 aplikací: PhotoCraft (Photoshop), VectorCraft (Illustrator), FilmCraft (Premiere Pro), LightCraft (Lightroom), PdfCraft (Acrobat), EffectCraft (After Effects) a DesignCraft (InDesign). Zdrojové kódy jsou k dispozici na GitHubu.
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: 33
| 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: 33
| blog: mirecove_dristy
| Poprad
10.5.2011 19:11