Vim Classic byl vydán ve verzi 8.3. Drew DeVault oznámil tento fork editoru Vim (verze 8.2.0148, tj. těsně před zavedením Vim9 skriptování) v březnu letošního roku. Důvodem forku bylo, že vývojáři editorů Vim a Neovim začali při vývoji využívat LLM.
Open source konference DevConf.CZ 2026 proběhne 18. a 19. června v Brně na FIT VUT. Publikován byl program a spuštěna byla registrace.
Společnost JetBrains uvolnila verzi 2 svého open-source velkého jazykového modelu (LLM) pro vývojáře Mellum.
Probíhá konference Microsoft Build 2026. Microsoft představuje své novinky: kvantový čip Majorana 2, Surface Laptop Ultra a Surface RTX Spark Dev Box s NVIDIA RTX Spark, Intelligent Terminal, Coreutils for Windows (fork Rust Coreutils), AI modely MAI, AI agenta Scout, platformu pro agent-first zařízení Project Solara, …
Google Chrome 149 byl prohlášen za stabilní. Nejnovější stabilní verze 149.0.7827.53 přináší řadu novinek. Podrobný přehled v poznámkách k vydání. Vylepšeny byly také nástroje pro vývojáře.
Pluto.jl, reaktivní notebook pro programovací jazyk Julia, dospěl do verze 1.0.
Byla vydána nová verze 12.0.0 vizuálního programovacího jazyka Snap! (Wikipedie) inspirovaného jazykem Scratch (Wikipedie). Přehled novinek na GitHubu.
Počítačovou hru Gravity Circuit (ProtonDB) lze do 14. června do 19:00 získat na Steamu zdarma. Napořád.
Nejnovější X.Org X server 21.1.23 a Xwayland 24.1.12 řeší 9 bezpečnostních chyb.
npm balíčky @redhat-cloud-services byly kompromitovány.
pisi maly program v c-cku a potreboval bych vedet, jak dlouhy je double, nebo lepe jaka je jeho presna bitova struktura (kolik bitu je exponent atp.). Jak to na danem systemu zjistim? Jedna se o architekturu i386, gcc-4.1 (distro debian testing).
Dekuj za radu :)
Zdravi Michal
sizeof(). Na velikost mantisy a exponentu se zkuste podívat třeba do seriálu, který nedávno vyšel na Rootu, je to asi tak druhý nebo třetí díl.
dekuji za odpoved, upresnim svuj problem: ja dostanu z pristroje 8byte, z toho prvnich 11 jsou "exponent bits" a zbylych 52 jsou "fraction bits" podle EEE754. Kdyz ted nactu techle 8byte do promene typu double (sizeof(double)=8, alespon na mem systemu), tak dostavam hodnotu o 4 rady mensi, napriklad misto 0.2 dostanu 0.00002. Hledam pricinu problemu. Napadlo me, jestli je opravdu ulozeny double podle EEE754 i na mem systemu. Proto dotaz, jak to zkontroluji?
jeste presneji, pristroj vraci hodnotu ve tvaru :
(ascii)0(ascii)#(binary)110100....
cili prvni dva byte jsou ascii 0 a ascii #, pak nasleduje 64 bitu.
nactu tedy vsechno (celkem 10 byte) do pole typu char a pak provedu
pointer_na_double=pole + 2;
No a chova se to jak jsem uvedl vyse... :)
Jeste jednou dekuji za pomoc
Zkuste se podívat na hodnoty maker FLT_RADIX (mělo by být 2), DBL_MANT_DIG, DBL_MIN_ËXP a DBL_MAX_EXP (je potřeba includovat <float.h>), z nich by to mělo být vidět. U mne je to (na x86 i x86_64) 2, 53, 1024, -1021. Takže by to mělo být 53 bitů mantisy, 1 bit znaménko a 10 bitů exponentu.
V každém případě bych ale doporučoval nespoléhat na kompatibilitu binárního zápisu a napsat si na to konverzní funkci. Ušetříte si tím těžkou hlavu, kdybyste to někdy chtěl portovat na jinou platformu (třeba big endian).
moc dekuji, to je ono :) Na mem systemu jsou hodnoty totozne tj. 2, 53, 1024 a -1024.
Ano, kompatibilita mym resenim trpi. Mohl bych vsechna data nacist jako ascii a pak je zkonvertovat pomoci atof(), coz je z hlediska kompatibility bezproblemove. Nicmene rad bych se tomuto reseni vyhnul kvuli rychlosti. I za cenu ztraty kompatibility.
Tiskni
Sdílej: