Zobrazit příspěvky

Tato sekce Vám umožňuje zobrazit všechny příspěvky tohoto uživatele. Prosím uvědomte si, že můžete vidět příspěvky pouze z oblastí Vám přístupných.


Příspěvky - Pavel Stěhule

Stran: [1] 2 3 ... 36
1
Vývoj / Re:Je jazyk C skutočne ťažký?
« kdy: 08. 06. 2025, 08:56:42 »
Konkrétně signed integer overflow zkoumají pod AO3 (vypnuli to pomocí -fwrapv) a rozdíly ve výkonu jsou zanedbatelné.

Ono je otázkou, co je dneska implementovatelné v překladači z pohledu zpětné kompatibility a očekávání uživatelů.

V každém případě moderní překladač důrazně upozorní, že je něco jinak, a je na vývojáři aby napsal kód bez warningu. V Postgresu kód s warningem nemá šanci se dostat do upstreamu, a co jsem se jako vývojář naučil, že warning v Cčku není něco, nad čím by se dalo mávnout rukou.

2
Vývoj / Re:Je jazyk C skutočne ťažký?
« kdy: 08. 06. 2025, 05:49:20 »
Zkus tohle chování vysvětlit. Pokud možno _jednoduše_, když je C jednoduchý jazyk.  8)

Když to přeložím bez optimalizací - na gcc 15.1, vypíše to 4 čísla. Když to zkusím s optimalizací

dostanu zřetelný warning:

<code>
    test.c: In function ‘main’:
    test.c:7:9: warning: iteration 3 invokes undefined behavior [-Waggressive-loop-optimizations]
        7 |         printf( "%d\n", i*1000000000 );
          |         ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    test.c:6:20: note: within this loop
        6 |  for (int i = 0; i < 4; ++i)
          |                  ~~^~~
</code>

Je to docela dobře vysvětlené https://stackoverflow.com/questions/24296571/why-does-this-loop-produce-warning-iteration-3u-invokes-undefined-behavior-an .

Holt optimalizace v C jsou opravdu agresivní - a opravdu se v Cčku nevyplatí ignorovat warningy

3
Vývoj / Re:Je jazyk C skutočne ťažký?
« kdy: 08. 06. 2025, 05:36:03 »
Zkus tohle chování vysvětlit. Pokud možno _jednoduše_, když je C jednoduchý jazyk.  8)

Když to přeložím bez optimalizací - na gcc 15.1, vypíše to 4 čísla. Když to zkusím s optimalizací

dostanu zřetelný warning:

<code>
    test.c: In function ‘main’:
    test.c:7:9: warning: iteration 3 invokes undefined behavior [-Waggressive-loop-optimizations]
        7 |         printf( "%d\n", i*1000000000 );
          |         ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    test.c:6:20: note: within this loop
        6 |  for (int i = 0; i < 4; ++i)
          |                  ~~^~~
</code>

4
Vývoj / Re:Programovací jazyk Ada v České republice
« kdy: 29. 04. 2025, 08:17:17 »
Zajímal jsem se o to, proč Ada dopadla tak jak dopadla, reálně působí informace, že dlouho nebyl k dispozici zadarmózní kompilátor narozdíl od C/C++ a pokud školy přestaly Adu vyučovat, situace nemohla dopadnout jinak. Proto je hlavní procento knížek do roku 1995 (Ada 95 Problem Solving Program Design, Ada 95 from the Beginning, Ada 95 The Craft of OOP), z novějších už jen Beginning Ada programming from novice to professional 2020 nebo nesmrtelný Barnes se svojí nejnovější Programming in Ada 2022. Co se dá dělat, takový je vývoj.

Podle mne to zazdila licence, a možná příliš velké ambice, možná načasování. Wirth v 90 letech propagoval dost minimalistické jazyky - např. Oberon. Možná tam svoji roli hrála skutečnost, že v C byly psané Unixy, později Windows byly napsané v C++, a v druhé polovině 90 let přišla Java, které měla moderní knihovny pro práci s TCP - a pro experimenty s internetem byla vhodnější. V 80 letech ještě nebylo tolik výkonu nazbyt, a přeci jen C je tomu assambleru blíž, a je jednoduší v něm psát rychlé aplikace. O tom jestli nějaký programovací jazyk se rozšíří nebo ne rozhoduje dost možná náhoda, třeba i v tom jestli nějaká významná a velká firma podporuje a používá daný jazyk -  a zbytek se opičí. To, co se děje na univerzitách (a co se tam učí) zas až tak velkou váhu nemá (spíš pak některé koncepty se díky tomu dostanou do mainstreamového jazyka). Většina firem, managmentu se dost nerado odchyluje od aktuálního mainstreamu.

5
Vývoj / Re:Programovací jazyk Ada v České republice
« kdy: 28. 04. 2025, 21:16:30 »
Algolské jazyky však v programátorském světě nemají štěstí, což potvrzuje mnoho reakcí diskutérů u článků o tomto jazyce zde na Rootu.


Proto bych se rád touto cestou optal, zda se některý ze čtenářů nesetkal s tímto jazykem ve firemní praxi nebo nezná někoho, kdo ano.

Asi záleží na generaci a škole. U nás (začátek 90 let - ČVUT) byl Pascal dost preferovaný, při výuce, při psaní aplikací. Naopak C nebo C++ měl příchuť punku. Na Matfyzu prý jelo C++. Osobně mám Wirthovy jazyky rád - i když už jsem je nikdy nepoužil - Modula, Oberon nebo Visual Basic (upravená Modula).

Dost lidí stále používá variantu ADY aniž by o tom vědělo. PL/SQL (Oracle) je docela věrná implementace ADY. A v PL/SQL jsou stále napsané milióny řádků procedur běžících v apkách v korporátech. PL/pgSQL (Postgres) je osekaná kopie PL/SQL - takže je to taky trošku ADA.

6
Server / Re:Používá se ještě databáze Firebird?
« kdy: 27. 04. 2025, 08:28:00 »
Jestli nedošlo ke změně, tak nad Firebirdem běží Pražská Městská knihovna. Osobně Firebird nepoužívám, a zrovna tak neznám nikoho, kdo by ho používal, ale po očku sleduji vývoj. Je to databáze, která má relativně stabilní letitý vývoj, který je stále živý, a má to svojí niku. Je to databáze vhodná pro embedding - nakopírujete 2 soubory a jedete, má to vlastnosti, které zjednodušují vývoj v embeddingu. V tom je to stejná databáze, jako je SQLite. Oproti ní je to ale databáze - s plnohodnotným SQL, s vestavěným skriptovacím jazykem, monitoringem. SQLite (i podle vlastního vyjádření jejího autora) je spíš transakční filesystém s SQL API. SQLite je primitivní (ale pro řadu použití dostačující) jednouživatelská velice malá databáze. Oproti tomu je Firebird úplná více uživatelská databáze (i když se spíš jen výjimečně používá pro větší počet uživatelů), která je ale stále velmi malá a kompaktní (vhodná pro embedding), což Postgres nebo MySQL třeba určitě není.   Pokud bych předpokládal, že s nějakým hw budu distribuovat i databázi, tak pravděpodobně bych šel do Firebirdu (zvlášť pokud bych měl někoho, kdo s ním umí).

7
Server / Re:Nevýhody InnoDB oproti MyISAM v MariaDB
« kdy: 18. 04. 2025, 20:34:05 »
Citace
MyRocks (MariaDB only)   Designed for write-heavy workloads, MyRocks is optimized for crash resilience but might not be suitable for all use cases.

Jestli má MyRocks a Aria stejné nedokumentované nedostatky jako MyIsam co se týče paralelního čtení a zápisů se nelze nikde dočíst.

MyRocks by mělo být postavené nad RocksDB - https://github.com/facebook/mysql-5.6/wiki/Getting-Started-with-MyRocks

rockdb podporuje neblokujici snapshoty - tudiz by cteni nemelo blokovat zapis https://github.com/facebook/rocksdb/wiki/rocksdb-faq

8
Ahoj vsichni,
jak vidite aktualni perspektivu VS studia oboru IT (napr. VUT FIT) ve svetle soucasneho velmi rychleho zvysovani vykonu AI, na to navazanych ruznych copilotu a dalsich vyvojarskych prostredku jako je napr. Claude Sonnet + Cursor AI IDE, atd...atd.... a proste celkoveho rustu analytickych schopnosti AI?
Jaka je podle vaseho mineni ve vyhledu nasledujicich par let perspektiva vyvojaru, coderu, databazovych specialistu, ale treba take i adminu, protoze i prace admina je zalezitost, kterou AI nepochybne v kratkodobem vyhledu bude zvladat levou zadni.
Pred par dny byl vydan ChatGPT 4.1. Priznam se, ze jeho schopnosti me docela ohromily. Pripada mi evidentni, ze AI bude schopna nahradit nejen rutinni prace, ale take samostane vyvijet i slozite algoritmy.
 
Jen mi to tak pripada a nebo se o teto zalezitosti hovori naprosto nedostatecne?
Jak se na tohle tema divate vy? Ktere obory IT zatim i v dlouhodobejsim vyhledu dle vaseho nazoru zustanou lidskou domenou?

AI neumí nic vytvořit - umí jen kombinovat. Nicméně drtivá IT není o programování složitých algoritmů.

I bez AI se v posledních 10 letech do IT dostalo mraky lidí, což vede k tomu, že juniorní mzdy v IT budou spíš dolů nebo stagnovat. Navíc je na obzoru docela velká ekonomická krize. Vždy záleží na kvalitě - velice dobrý junior si práci najde, možná ne tak snadno jako před 5 roky, ale najde. Průměrný junior si práci nenajde. Věřím tomu, že platy se trochu srovnají - už teď šikovný klempíř si rukama vydělá víc než průměrný ajťák, a nevidím důvod proč by se to mělo měnit - školy teď chrlí ajťáky ne klempíře.

9
Server / Re:Nevýhody InnoDB oproti MyISAM v MariaDB
« kdy: 17. 04. 2025, 22:03:28 »
Mám ZFS, takže některé ochranné prvky, které dělá innoDB jsou zbytečné, protože jsou dělány na úrovni souborového systému.

ZFS je dost pomalý filesystém - a při velké zátěži jsou s ním s databázemi problémy. MyISAM neřeší konzistenci - zápisy končí ve filesystémové cache - a v případě havárie můžete příjít o data z filesystémové cache - což vzhledem k primitivnímu formátu nemusí být problém - můžete mít ale nakopnutý index, a to už problém být může. InnoDB má mnohem složitější formát a pokud by došlo ke ztrátě konzistence, tak to není jen o ztrátě pár záznamů. ZFS vám pomůže jen v tom, že si můžete udělat snapshot a vrátit se k nějakému snapshotu. Pokud by se ale rozbila konzistence v MySQL, tak je vám ZFS na dvě věci. InnoDB má na rozdíl od MyISAM vlastní write cache - o kterou v případě havárie můžete přijít, a tak musíte mít konzistentní transakční logy. Pokud byste je neměl, tak to, že přijdete o pár záznamů je to nejmenší - můžete mít nakopnutý index, což rozbije vyhledávání - unikátní index nemusí být unikátní, atd atd. MyISAM je do jisté míry "inmemory db", takže některé operace mohou být velice rychlé. Má velice primitivní formát - který je relativně odolný vůči chybám. InnoDB funguje už úplně jinak, a případné chyby konzistence v InnoDB mají mnohem horší dopad.

10
Bazar / Re:Nabízím instalačky MS-DOS 3.3 a antiviru Tři psi
« kdy: 04. 04. 2025, 12:00:03 »
Mimochodem, neví někdo z pamětníků, kteří si na Tři psy ještě vzpomínají, v čem byli naprogramováni? Na obrázcích to vypadá trochu jako Turbo Vision, ale barevnostně je to jiné. Snad nějaký Basic...

V zásadě to mohou být Turbo Vision. Ty třídy se dají upravit.
Ale silně to připomíná interface, který měly utility od Nortona. Takže by to mohla být nějaká knihovna, která byla součástí Zortech aka  Symantec C++.

Myslím si, že 602 měla vlastní GUI knihovnu, kterou používala v 90 letech ještě před přechodem na Win. Byl v tom napsaný i calc602 https://lukas.faltynek.com/2007/03/05/c602_ceskoslovenska_konkurence_ms_excel/. V těch dobách skoro každý povinně si podobnou okýnkovací knihovnu napsal - případně se daly sehnat jako freeware. V čem to bylo napsané, netuším - autoři ale měli sklon k Pascalu - i interní skriptovací jazyk byl Pascal.

11
Server / Re:Zvažuji přechod z Linuxu na FreeBSD
« kdy: 24. 03. 2025, 20:32:37 »
Takže každá část má být ideálně One-man-Show?  Dej do kopie Torvaldse, že to všechno dělá blbě a měl to celé dělat sám :-)

Lenoch jeden líná ...komunita mu musí pomáhat. Zajeď za ním, že bys mu radil :-)

Sledujem vyvoj programovacieho jazyka jai alebo aj odin a sledoval som rozne podcasty o nich a okolo nich a ineho sw a otazka open source prisla na debatu dost casto a generalny konsenzus je taky ze open source(tym nemam na mysli verejny kod ale skor verejne pull / merge requesty) su praveze na skodu a je to zly system. Osobne to vidim totozne. Cim viac ludi sa do niecoho babre, tym viac to stoji, tym viac sa debatuje, tym menej roboty sa urobi. Kazdu cast kodu by mal mat na starosti jeden clovek ktory to cele vedie a komunia by sa do kodu vobec nemala starat, len davat namietky, rady, a podobne. Diskusia je fajn ale kod by mal mat gatekeepera. Ono aj ani do linuxoveho kernelu si nemoze hocikto len tak commitnut zmeny.

Pochybuji, že se to dá generalizovat - znám vývoj databází - a když bych se podíval na MySQL, SQLite, Firebird a Postgres, tak každá z těch databází má úplně jiný typ vývoje, jinou komunitu, a v podstatě platí, že to, co je někdy výhoda, je v jiné chvíli nevýhodou. V 90 měl MySQL nebo Firebird výrazně větší progres než Postgres, právě díky relativně malému týmu. Dneska do Firebirdu skoro nikdo nejde, právě kvůli jeho malému týmu. SQLite je skoro one man show, ale zas jak je to výrazně menší projekt, tak to zase tolik nevadí, a nikdo ani nečeká větší progres. Postgres je tou komunitou, kde každý kecá do všeho, a vývoj jde pomalu - ale "každý si jede za své" a není až tak velký problém s financováním projektu - což třeba u MySQL nebo MariaDB problém je. Navíc s vývojem Postgresu se setkalo mnohem víc lidí, takže je větší šance najít talenty. Vývoj programovacího jazyka (navíc, který jede nad llwm) je relativně "jednoduchá" omezená záležitost. A souhlasím, že je pro konzistenci programovacího jazyka lepší menší vývojový tým než větší. Ale je to možné, že velkou část těžké a špinavé práce se udělá v týmu llwm.

12
Server / Re:Upgrade PostGIS extension z dev verze
« kdy: 18. 03. 2025, 16:59:00 »
Ahoj!
Na serveru se mi do Docker image nejakou nestastnou shodou okolnosti dostala extension PostGIS ve verzi 3.2.0.dev, nad kterou se nasledne postavila kupa uzivatelskych objektu.
Pri patchovani jsem narazil na to, ze dostupna verze extension uz je novejsi (3.5.0), bohuzel se mi nedari prijit na zadny zpusob, jak stavajici extension updatovat. Vzdy skoncim na informaci, ze z dane verze neni k dispozici zadna cesta pro update na novou verzi. Rad bych se vyhnul odstavce spojene s exportem/importem dat (instance neni uplne mala a zabere to cas) a tak bych se jeste rad zkusil zeptat zkusenejsich. Existuje nejaka moznost, jak provest update extension nebo me dump zkratka nemine?
Diky moc za pripadne napady!

Podle dokumentace by měl jít update z 3.1 na 3.4 https://www.enterprisedb.com/docs/postgis/latest/installing/upgrading/
a předpokládám, že upgrade z 3.4 na 3.5 bude určitě také. Bacha, tam je velká zrada. PostGIS se upgraduje skrz nějaký skript, který vygeneruje potřebná SQL (si myslím). Není to běžná extenze. Je to svět sám pro sebe. Doporučoval bych se zeptat na dedikovaném fóru nebo na https://groups.google.com/g/postgresql-cz?hl=cs kde je určitě pár lidí s dobrou znalostí jak PostGISu tak Postgresu.

13
Server / Re:Upgrade PostGIS extension z dev verze
« kdy: 18. 03. 2025, 16:43:47 »
Určitě jde mít víc extenzí různých verzí v různých DB. Minimálně u partman-a mě to potkalo několikrát. Osobně tohle vnímám jako problematické, protože právěto přetahání znamená, že pokud mi v mezičase někdo zapíše, tak mám rozjetá data. Tohle replika elegantně řeší.

Tohle neplatí univerzálně. partman je čistě plpgsql (jestli se nepletu). Hodně extenzí je napsaných v C, a pro jednoduchost buildu nemají verzi v názvu knihovny. Tudíž nepodporují souběžný běh různých verzí extenzí. U některých knihoven se řeší alespoň kompatibilní ABI, aby byl možný upgrade, ale pochybuji, že by někdo psal C extenze, tak aby plně fungoval s různými verzemi extenze. Nikde nemám nainstalovaný PostGIS, takže si to nemohu ověřit, ale vypadá to, že PostGIS je výjimka, a má verzi zadrátovanou v názvu knihovny. V mnoha ohledech je PostGIS dost specifická extenze - velikostí, komplexitou a způsobem implementace upgrade.

14
Server / Re:SQL: Ako na problematicky right join?
« kdy: 23. 02. 2025, 21:18:11 »
Podmínky s OR mohou mít problémy s výkonem - záleží jaká jsou data, jak máte indexy i jakou máte databázi (a jakou verzi). Samozřejmě, že záleží i na velikosti dat a intenzitě provozu. V některých (dnes spíš hraničních) případech je nutné dotaz přepsat na UNION.

To se ještě dneska vážně používají databáze, které tyto sémanticky shodné zápisy (s OR nebo s UNION) nedokáží převádět automaticky (podle toho co je pro ně výhodnější na provedení) a nutí k tomu programátora?

Jsou takové databáze a hodně se používají. PostgreSQL to nedělá 100%, MySQL a MariaDB pravděpodobně také ne. U Postgresu není problém v transformaci (transformace by se ani dělat nemusela, jde o podobu finálního plánu) - takový patch už byl vytvořený, a měl pár stovek řádek, ale v rozhodnutí, kterou cestu preferovat - jestli bitmap indexscan nebo merge index scanu nebo ještě něco jiného. U výrazů s OR jsou větší problémy s odhady, a kvalita odhadu je základ.

15
Server / Re:SQL: Ako na problematicky right join?
« kdy: 23. 02. 2025, 07:01:22 »
Kód: [Vybrat]
SELECT co.id FROM content co
LEFT JOIN categories ca ON co.categoryId = ca.id
WHERE ca.id IS NOT NULL
  OR co.type = 'stranka'

Tohle by mělo zachovat všechny záznamy content, co mají typ 'stranka' bez ohledu na cokoliv dalšího + záznamy content, co mají jiný typ než 'stranka' a mají categoryId vyskytující se v category.
Nebo jsem špatně pochopil požadavek?

Diky, mal som uz funkcnu verziu, ale toto ma inspirovalo ju znacne zjednodusit.

Podmínky s OR mohou mít problémy s výkonem - záleží jaká jsou data, jak máte indexy i jakou máte databázi (a jakou verzi). Samozřejmě, že záleží i na velikosti dat a intenzitě provozu. V některých (dnes spíš hraničních) případech je nutné dotaz přepsat na UNION.

Stran: [1] 2 3 ... 36