Byla vydána nová verze 19 integrovaného vývojového prostředí (IDE) Qt Creator. Podrobný přehled novinek v changelogu.
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.
Dobrý den,
Sanžím se (pomocí Pythonu) zprovoznit komunikaci s jistým HW zařízením, pomocí seriového portu. Jsem ve stavu, kdy dokáži na port zapisovat a HW bezproblému příjímá, ale potřeboval bych také, ale by program v Pythonu dokázal reagovat, když dostane od HW nějakou informaci.
Ke komunikaci používám pySerial. Mám takové malé GUI, kterým posílám informace HW a ten je přijímá, ale chtěl bych pro testovací účely, aby je HW poslal zpět. Ze strany HW to mám ošetřeno, ale nevím jak zachytávat zprávy v Pythonu, protože informace může přijít kdykoliv a jí na ni potřebuji reagovat.
Hledal jsem dlouho, ale našel jsem pouze nějaké řešení pomocí vícevláknové aplikace, což však neumím implementovat. Nenapadá prosím někoho nějaké jiné řešení jak odchytávat vstup? Popřípadě jak tedy využít více vláken a kde se o tom dozvědět nějaké informace?
Děkuji za každou odpověď...
A nebyl byste (popřípadě kdokoliv jiný) tak laskav a naznačil, jak by ta komunikace probíhala? Nedovedu si moc představit to probouzení. Kdybych měl hlavní proces s GUI a vytvořil vlákno, které by třeba čekalo na nějaký impuls na seriovém portu. Jak dát vědět tomu druhému, že se něco stalo a on na to má reagovat? Nebo si to špatně představuji?
Děkuji
GUI je v Tkinteru, nicméně se mi podařilo na webu najít nějakou ukázku terminálu ve wxPythonu a díky ní jsem to pochopil a zdárně implementoval. Jediné, co mě ještě trápí, jsou problémy s bufferem, respektive s posíláním zpráv z hardwaru (konkrétně jde o kit Arduino Decimilia). Zprávy jsou občas náhodně zalomeny na další řádek. Například pošlu-li číslo 123, tak ho přijmu jednou jako 123, jednou jako 12\n3 nebo 1\n23. Netuším čím to může být, ale zřejmě není problém na straně GUI.
Tak kdyby někdo řešil podobný problém:
Chyba byla ve špatné implementaci. Data jsem četl ve smyčce
while 1:
n = serial.read(1)
if n:
n = n + serial.read(n)
print n
a problém byl pravděpodobně způsoben tím, že jsem reagoval na stav bufferu dřív, než v něm byla všechna data. Tzn smyčka začínala a když se prováděl řádek n = serial.read(1), tak v bufferu byla uložena jen část řetězce.
Teď by mě ještě zajímalo jak vše zesynchronizovat. Napadlo mě použití nějakého odělovače (např.: dvojtečka, tečka, čárka nebo nějaký jiný málo používaný ASCII znak) a potom, když bude něco v bufferu, tak se bude číst, dokud nenarazím na daný znak. Napadá někoho lepší řešení?
No záleží na tom, jestli z toho HW chodí ASCII text, nebo nějaký binární svinstvo. Já jsem řešil podobný problém s bufferem na data, která jsem odesílal z jednočipu a coby ukončovací/oddělovací znak jsem používal 0x00.
Moc tomu tvému problému nerozumím. Možná by pomohlo sem hodit ukázku dat, která do toho portu tečou. Možná by taky nebylo od věci použít readline(), místo read(1) a pak to spojovat.
Pokud tomu ale rozumím správně, že ještě nemáš hotový protokol, kterým se bude komunikovat, pak bych doporučil jako oddělovač zpráv zvolit \n a pomocí toho readline() z toho portu číst po celých řádcích. Potom budeš moci třeba pomocí regulárních výrazů parsovat hodnoty v každé zprávě.
Tiskni
Sdílej: