VASA-1, výzkumný projekt Microsoftu. Na vstupu stačí jediná fotka a zvukový záznam. Na výstupu je dokonalá mluvící nebo zpívající hlava. Prý si technologii nechá jenom pro sebe. Žádné demo, API nebo placená služba. Zatím.
Nová čísla časopisů od nakladatelství Raspberry Pi: MagPi 140 (pdf) a HackSpace 77 (pdf).
ESPHome, tj. open source systém umožňující nastavovat zařízení s čipy ESP (i dalšími) pomocí konfiguračních souborů a připojit je do domácí automatizace, například do Home Assistantu, byl vydán ve verzi 2024.4.0.
LF AI & Data Foundation patřící pod Linux Foundation spustila Open Platform for Enterprise AI (OPEA).
Neziskové průmyslové konsorcium Khronos Group vydalo verzi 1.1 specifikace OpenXR (Wikipedie), tj. standardu specifikujícího přístup k platformám a zařízením pro XR, tj. platformám a zařízením pro AR (rozšířenou realitu) a VR (virtuální realitu). Do základu se z rozšíření dostalo XR_EXT_local_floor. Společnost Collabora implementuje novou verzi specifikace do platformy Monado, tj. open source implementace OpenXR.
Byla vydána nová verze 0.38.0 multimediálního přehrávače mpv (Wikipedie) vycházejícího z přehrávačů MPlayer a mplayer2. Přehled novinek, změn a oprav na GitHubu. Požadován je FFmpeg 4.4 nebo novější a také libplacebo 6.338.2 nebo novější.
ClamAV (Wikipedie), tj. multiplatformní antivirový engine s otevřeným zdrojovým kódem pro detekci trojských koní, virů, malwaru a dalších škodlivých hrozeb, byl vydán ve verzích 1.3.1, 1.2.3 a 1.0.6. Ve verzi 1.3.1 je mimo jiné řešena bezpečnostní chyba CVE-2024-20380.
Digitální a informační agentura (DIA) oznámila (PDF, X a Facebook), že mobilní aplikace Portál občana je ode dneška oficiálně venku.
#HACKUJBRNO 2024, byly zveřejněny výsledky a výstupy hackathonu města Brna nad otevřenými městskými daty, který se konal 13. a 14. dubna 2024.
Společnost Volla Systeme stojící za telefony Volla spustila na Kickstarteru kampaň na podporu tabletu Volla Tablet s Volla OS nebo Ubuntu Touch.
Když jsem se tak minulý týden připravoval na přijímačky na Molekulární biologii, tak jsem si řekl, že si během učení zkusím po kouscích pro odreagování napsat nějakou malou zásobníkovou mašinku v Pythonu 3. Python jsem se stejně chtěl naučit už delší dobu a o assemblerech, zásobníkových počítačích a podobných obskurnostech vím úplné kulové, tak proč nespojit příjemné s užitečným? Mimochodem, pro lidi, kteří ví, co jsem zač: nebojte se, na matfyzu ani zdaleka nehodlám skončit. Jen mi tam začalo být trochu těsno, tak jsem si podal přihlášku ještě i na tu molekulárku.
Malé upozornění pro odborníky v oboru: následující text a program psal naprostý amatér co se těchto nízkoúrovňových věcí týče. Jeho znalosti problematiky virtuálních strojů jsou téměr nulové a svůj úplně první program v assembleru (viz níže) vytvořil v tom, který si sám napsal, na mašince, kterou si sám napsal. :) Nemůže být tedy divu, že to podle toho i vypadá. :D Ale teď už k věci.
Mašinka používá pro výpočty jediný zásobník a dva "registry". V prvním registru je uložen ukazatel na právě prováděnou instrukci programu (instruction pointer), v druhém registru je pak uložen ukazatel na pozici právě zpracovávaného rámce v zásobníku (frame pointer). Rámec je něco jako "pracovní prostor" právě prováděné subrutiny. Více vysvětlí malý příklad, jak může situace během provádění programu vypadat.
^ | ... | | | ... | | | previous frame | | |-----------------| | ^ | arg 1 | s | | | arg 2 | t | | | ... | a | f | | arg n | c | r | | return addr | k | a | | old frame ptr | <----- frame_ptr | m | | local 1 | | e | | local 2 | | | | ... | v v | local m |
Frame pointer je možné chápat jako takový "pevný bod" v daném pracovním prostoru subrutiny. Počítač jej používá jak pro získávání kopií argumentů funkce (ty jsou volajícím kódem vloženy na zásobník ještě před předáním řízení programu dané funkci – na pozici (frame_ptr - 1) - 1 v zásobníku leží poslední argument, na pozici (frame_ptr - 1) - 2 předposlední atd.), tak pro vyskakování z ní (na pozici frame_ptr - 1 je uložen ukazatel na instrukci, která se začne provádět po vyskočení z funkce a na pozici frame_ptr je uložena hodnota původního ukazatele na rámec předchozí volající funkce). Všechno tohle čarování je velmi důležité hlavně pro možnost rekurze (nebo obecně pro volání funkcí z funkcí). Není totiž možné ukládat data o návratových adresách, o ukazatelích na aktuální rámec funkce a jejích prametrech do pevně daných registrů, protože by se při dalším případném volání původní hodnoty přepsaly. Jediné, co máme k dispozici a s čím si musíme vystačit, je zásobník.
Ale dost řečí! Podrobnější komentáře o práci interpretu jsou v samotném zdrojáku a já nerad něco říkám dvakrát. :) Následuje velmi jednoduchá ukázka programu, který simuluje for cyklus:
AbcLinuxu.cz
ITBiz.cz
HDmag.cz
AbcPráce.cz
; i = 0
push 0
jmp cycle
cycle:
; if i is not less than 10 then end the cycle
dup
push 10
cmpl
jmpf end
; print the value of i
dup
write
; increment i
push 1
add
; jump to the beginning of the cycle
jmp cycle
end:
Dále tady máme ukázku trošku složitějšího programu pro výpočet faktoriálu rekurzí:
read
call fact
write
fact:
; get the argument n of the subroutine
argv 1
; return 1 if n is less than 2
dup
push 2
cmpl
jmpt end_fact
; else compute (n - 1)! by recursion
dup
push 1
sub
call fact
; return n * (n - 1)!
mul
retv 1
end_fact:
push 1
retv 1
Pokud byste si chtěli interpret vyzkoušet v akci na výše uvedených programech, nebo si pro něj chtěli dokonce i něco napsat (co takhle třeba přepsat faktoriál do iterativní podoby? zkuste si to!), směle do toho! Stačí si stáhnout program z odkazu výše, napsat chmod +x masinka.py a jakýkoli program v assembleru Mašinky jí pak předložíte pomocí ./masinka.py <název souboru s assemblerem>. Zdůrazňuji, že je potřeba mít nainstalován Python verze 3.
Instrukční sada je zatím omezená (stejně jsem neměl čas interpret zkoušet na nějakých složitějších příkladech), ale pro jednodušší prográmky stačí. Mašinka taky zatím pracuje jenom s celými čísly. Rozšířit ji na další typy snad ale nebude problém.
push X | vloží X na zásobník |
pop | vyjme hodnotu ze zásobníku |
dup | zduplikuje hodnotu na vrcholu zásobníku |
swp | prohodí dvě hodnoty na vrcholu zásobníku |
add, sub, mul, div | klasické základní aritmetické operace |
abs | vyjme hodnotu ze zásobníku a vloží zpět na zásobník její absolutní hodnotu |
cmp, cmpl, cmple | vyjme dvě hodnoty X, Y ze zásobníku, otestuje, zda X = Y, resp. X < Y, resp. Y <= Y a podle výsledku porovnání vloží na zásobník buď 0 nebo 1 (pravda nebo nepravda) |
read | načte hodnotu od uživatele a vloží ji na zásobník |
write | vyjme hodnotu ze zásobníku a vypíše ji na obrazovku |
call F | zavolá subrutinu F |
ret X | vyskočí z právě prováděné subrutiny a odejme ze zásobníku X parametrů, se kterými byla volána |
retv X | vyskočí z právě prováděné subrutiny, odejme ze zásobníku X parametrů, se kterými byla volána a vloží zpět na zásobník její návratovou hodnotu (poslední hodnotu, který byla vložena na vrchol zásobníku před zavoláním retv) |
jmp L, jmpt L, jmpf L | přesune běh programu k labelu L vždy, resp. pokud je na vrcholu zásobníku 1 (jump-if-true), resp. pokud je na vrcholu zásobníku 0 (jump-if-false) |
argv X | načte parametr funkce ze zásobníku a vloží jej na vrchol zásobníku, aby s ním funkce mohla lokálně pracovat (jak jsem napsal výše v odstavci o rámcích, X = 1 znamená poslední argument funkce, X = 2 předposlední argument a podobně) |
No, to by bylo asi tak všechno. Na závěr bych vás rád poprosil, abyste se do mě nemilosrdně pustili. Nebo teda raději do mého výtvoru, protože rozhodně netvrdím, že jsem zplodil nějaký zázrak. :) Musím přiznat, že i když jsem o těchto věcech věděl (a stále vím) kulové, tak mě to začalo docela bavit. Určitě mám tedy v plánu program vylepšit jak na základě vašich připomínek, tak i mých vlastních nápadů. Pusťte se klidně do návrhu programu (naprasil jsem to opravdu rychle bez nějakého velkého přemýšlení), do mé implementace v Pythonu (použil jsem jenom naprosté základy, takže se jistě dá spousta věcí napsat elegantněji) nebo (a to asi hlavně) do samotných záležitostí kolem zásobníkových počítačů, assemblerů a podobně. Budu jenom rád. Díky!
Mimochodem, přijímačky byly hodně drsné. Hlavně teda pro člověka, který měl biologii naposled před čtyřmi lety na gymplu, a který měl čas se učit jen pár dní během zkouškového z čerstvě zakoupené učebnice "Odmaturuj z biologie". :D Přípravu to nepochybně chtělo o dost větší, bohužel na matfyzu se mi pár věcí zkomplikovalo, tak jsem neměl času tolik, kolik jsem plánoval. Ale myslím si, že jsem se s tím v rámci možností popral statečně jako správný chlap. :) Pokud se na tu školu nedostanu, tak příští rok už se mi to rozhodně podaří. Ale držte mi palce! Rozhodně jsem snad nedopadl nějak tragicky a kdo ví? Třeba budu mít i trochu štěstí.
S tím souvisí takový dotaz pro zdejší studenty Univerzity Karlovy: je možné si normálně zapisovat předměty mezi fakultami? Říkal jsem si, že i když se nedostanu, tak bych si jen tak pro zajímavost i jako matfyzák zapsal nějaké úvodní předměty. Věci kolem molekulárky, genetiky, imunologie a podobně mě hodně zajímají a nerad bych čekal celý rok do dalších přijímaček, abych se o nich mohl konečně dozvědět trochu víc, než co si sám sem tam načtu z anglické Wikipedie.
Tiskni
Sdílej:
Já odpovídám: k ničemu!
Doufám, že to tady nikdo nebude brát moc vážně, možná jsem to do toho zápisku měl napsat. Vyrobil jsem Mašinku jen tak pro zábavu a pro odreagování a podělil jsem se s ní proto, protože jsem měl dojem, že by někoho mohla možná taky zajímat.
), tak už se to tady i celkem dá. :-P
Hlavně se teď proboha nic neuč, nic nedělej, flákej se, chlastej a užívej si života, dokud ti nezačne semestr, dobře ti radím (a tuhle ufolog amigapower se mnou určitě bude souhlasit ). V semestru tohle všechno sice můžeš taky, ale už to prostě není vončo.
já se ten Python chtěl naučit a vždycky upřednostňuju učení se tím, že si rovnou zašpiním rucetaky jsem se vzdycky chtel naucit python... do te doby nez jsem v nem musel naprogramovat par veci... a teda abych pravdu rekl, radsi se bez nej obejdu.
) díky Schemikovi, tak se ptám: co pro tyhle účely používáš ty? Píšeš všechny tyhle věci ve Scheme?
Nerad bych se tu pouštěl do dalšího nekonečného flamu o Pythonu, jako odpověď mi bude stačit jméno jazyka.
co pro tyhle účely používáš ty?velice casto na takove to domaci programovani pouzivam Bash... protoze to casto zacne jako jeden nevinny prikaz treba v sedu, ktery casem nabobtna o par rour a nejaky ten for cyklus az je z toho program. ;-] jako to se musi shellu nechat moznosti kompozice funkci jsou fakt slusne... horsi je to s vykonem... to pak nekdy sahnu i po tom pythonu... ale v posledni dobe hlavne po schemiku ;-] no a pokud potrebuju vykon, tak pouzivam spis SBCL nebo stare dobre Cecko... a priznam se bez muceni, ze obcas neco narychlo sbastlim i v PHP nebo Jave... imho, kazdy z jmenovanych jazyku se hodi na neco jineho a u kazdeho jsem narazil na nejaky problem, ktery me dokaze vytocit do bela... tak taky doufam, ze se to nezvrhne do flamu... ale porad lepsi flame o programovacich jazycich, nez politice...
Škoda, že do téhle problematiky moc nevidím....to obcas nemusi byt na skodu. ono neni nad to, kdyz clovek zjisti sam, jak se veci ve skutecnosti maji. treba ty vecne spory o tom jestli ma byt procesor zasobnikovy nebo registrovy...
Mimochodem, vybičovat mou zlenivělou vysokoúrovňovou mysl k napsání a odladění toho trapného faktoriálu v assembleru o kus výše mě stálo skoro stejně mnoho intelektuálního úsilí, jako napsat celou Mašinku dohromady v Pythonu. Člověku, který je zvyklý psát v "normálních" jazycích, se to skoro ani nezdá. Ty kompilátory a všelijaké další černé skříňky oddřou fakt hodně práce. A co teprv lidi, kteří je tvoří. Klobouk dolů.
Asi proto, že je to nesmysl.
Python nemá assembler žádný, je to čirý interpretr – tedy pokud hovoříme o defaultním C Pythonu
JVM, stejně tak .NET VM (IL) mají zásobníkový automat – jejich asm je tak jednoduchý, že snadno pochopíte z pohledu, o co se jedná.
virtuální assemblery Javy a .NETu mají navíc metadata, bez kterých to nejde – tedy řadu dalších přídavných dat, názvů, proměnných, objektů atd., které musí vurtuální mašina dostat, jinak to nefachá. a metadata jsou dost vysokoúrovňává data. navíc samotný asm má některé vysokoúrovňové instrukce zejména z řad práce s třídami. plus garbage collector – asm ví, co má kde za data, jakého typu, jakých názvů, zná třídy, metody, parametry, atd..
i386 je naproti tomu čistý asm – prostě sekvenčně vykonává instrukce. nepotřebuje žádná metadata, ani znát datové high level typy toho co vykonává.
jak vidíte, porovnávat se to rozumně nedá
Python má bytekód, tedy zparsovaný kód Pythonu. Nazývat to assemblerem je poněkud hodně moc silné kafe. Ale opravdu silné kafe.
Python nemá assembler žádný, je to čirý interpretr – tedy pokud hovoříme o defaultním C Pythonu.No, pokud si mám vybrat mezi panem Ponkrácem a dokumentací modulu disassembleru (C)Pythonu, hádejte, komu budu věřit
Takže pro původního tazatele - Python má svůj bytecode i virtuální stroj, který je uložený v těch .pyc a .pyo souborech (ty druhé by měly být optimalizované, ale prakticky jsou jenom stripnuté). Jedná se o zásobníkově orientovaný assebler/bytecode*, který má hromadu vysokoúrovňových operací - prakticky jakákoli vlastnost Pythonu má svoji instrukci.
* pro virtuální stroje je lepší používat termín bytecode, ale vzhledem k tomu, že ten javový umí některé ARM mašinky provádět nativně, asi je tohle rozdělení spíše akademické.
Jen v té dokumentaci Pythonu je psáno: „Since there is no Python assembler, this module defines the Python assembly language.“ (Ačkoli neexistuje žádný Python assembler, … atd.) ale pan Vyskočil je chytřejší.
Python má bytekód, tedy zparsovaný zdroják Pythonu. Dokonce opravdu jenom zparsovaný, nemá fakticky ani žádnou optimalizaci. Marketinkoví, P.R. a jiní mlžící a lži vydávající odborníci by to nazvali „vysokoúrovňovým assembler“, nebo „assemblerem s vysokoúrovňovými operacemi“, ale fakticky je to jenom mírně přechroustaný zdroják. To také mohu říci, že „Linux je jen jinak koncipované Windows“, nebo „linuxová komunita je komunita příznivců Microsoftu s menší loajalitou k Microsoftu“ a budou to stejně pravdivé věty se stejně překroucenými political corectness výrazu jako mluvit o Pythonovském (velmi neforemném a hrubém, neoptimalizaovaném parsingu zdrojáku) jako o „assembleru“.
Jen v té dokumentaci Pythonu je psáno: „Since there is no Python assembler, this module defines the Python assembly language.“ (Ačkoli neexistuje žádný Python assembler, … atd.) ale pan Vyskočil je chytřejší.pan ponkrac by v diskuzi mohl laskave zacit rozlisovat terminy -- assembly language a assembler, do cestiny se to preklada tusim jako, jazyk symbolicky adres a assembler (se nepreklada).
Python má bytekód, tedy zparsovaný zdroják Pythonu.doporucuji dostudovat pojem bytecode, abyste zjistil, ze bytecode != zparsovany zdrojak.
pan ponkrac by v diskuzi mohl laskave zacit rozlisovat terminy -- assembly language a assembler, do cestiny se to preklada tusim jako, jazyk symbolicky adres a assembler (se nepreklada).
Mohl byste si laskavě ještě jednou přečíst co píšu?
doporucuji dostudovat pojem bytecode, abyste zjistil, ze bytecode != zparsovany zdrojak
V případě Pythonu fakticky jde o rovnost. Píšeme tu v kontextu Pythonu.
Já jsem nikde netvrdil, že bytekódu je zparsovaný zdroják, ale tvrdil jsem, že v případě Pythonu jde o fakticky zparsovaný zdroják.
,,Since there is no Python assembler, this module defines the Python assembly language..'' (Ačkoli neexistuje žádný Python assembler, … atd.)to ze neexistuje ,,assembler'' neznamena, ze neexistuje ,,assembly language'', ktery tento modul definuje.... i.e., tento ,,assembly langauge'' je izomorfni vzhledem k bytecodu, stejne tak jak je izomorfni jazyk symbolickych adres vuci jazyku stroje.
Já jsem nikde netvrdil, že bytekódu je zparsovaný zdroják, ale tvrdil jsem, že v případě Pythonu jde o fakticky zparsovaný zdroják.ale tvrdil: Python má bytekód, tedy zparsovaný kód Pythonu.
Jestli chcete, já Vám nadefinuje deset různých assemblerů pro Python. Teoreticky. Akorát nebudou v základním interpreteru.
Jakákoli snaha o to udělat z byte kódu něco jiného, než přechroustaný zdroják narazí z druhé strany na to, že Python nehodlá nic stabilizovat. Ba dokonce nějaká snaha neměnit syntaxi, byte kód, či cokoli jiného velmi rychle narazí na odpor samotného autora Pythonu a jeho stejnou myšlenkou nakažených příznivců.
Když do toho budeme šťourat najdeme leccos, akorát je to v praxi k (autocenzura). Python mimo jiné běží i na JVM, stejně tak jako na .NET mašině, kde běží mnohem rychleji právě z toho důvodu, že běží na solidním byte kódu / assembleru, a ne na přechroustaném zdrojáku tak jak to standardní Python předvádí.
ale tvrdil: Python má bytekód, tedy zparsovaný kód Pythonu.
Kontext! Já se fakt moc omlouvám, ale nepíšu právnické texty s paragrafy, citacemi a odkazy na předchozí věty. Pokud se mluví a několik příspěvků jde o Pythonu, mluvím v kontextu Pythonu. Standardní Python (tedy ne žádné zbožné přání nějakého Python modulu) nemá jiný byte kód, než fakticky plus mínus přeparsovanou syntaxi.
Ani nemůže mít nic jiného, protože když autor Pythonu neustále přeorává co se dá, a neustále se píší nové a nové parsery syntaxe a další – pak na optimalizaci, nebo tvorbu nějakého slušného byte kódu nezbývá čas a Python to pak musí dělat jen velmi povrchně.
Dále už odmítám odpovídat na hnidopišské rýpání do slov od lidí, kteří neumí dát do kontextu několik vět a nejsou s to pochopit význam textu, pokud je nutné si dát dohromady sdělení ve dvou následujících větách po sobě.
pro virtuální stroje je lepší používat termín bytecode, ale vzhledem k tomu, že ten javový umí některé ARM mašinky provádět nativně, asi je tohle rozdělení spíše akademické.
Spíše pro JVM se dá použít i výraz assembler, stejně tak jako pro řadu dalších jazyků. Java má stabilní byte kód / aassembler, který je standardizzovaný a relativně neměnný.
Python nic takového nemá, v každé verzi Pythonu je to jinak. Byte kód z verze x.y nepoužijete dost dobře ve verzi x.z (za předpokladu y <> z pro matematické šťouraly).
Python se totálně brání ustálit a standardizovat i syntaxi jazyka, natož teprve svůj byte kód. Python má filozofii „strašně nás baví všechno měnit a často to děláme jen proto, že je to príma, a bavíme se tím“, takže nic stabilního tam fakticky nenajdete. Pokud byste dnes rozlouskli byte kód (tedy pro Ty co to nadneseně nazývají assemblerem), bude to stejně každou chvíli překopáváno.