OpenJS Foundation, oficiální projekt konsorcia Linux Foundation, oznámila vydání verze 22 otevřeného multiplatformního prostředí pro vývoj a běh síťových aplikací napsaných v JavaScriptu Node.js (Wikipedie). V říjnu se verze 22 stane novou aktivní LTS verzí. Podpora je plánována do dubna 2027.
Byla vydána verze 8.2 open source virtualizační platformy Proxmox VE (Proxmox Virtual Environment, Wikipedie) založené na Debianu. Přehled novinek v poznámkách k vydání a v informačním videu. Zdůrazněn je průvodce migrací hostů z VMware ESXi do Proxmoxu.
R (Wikipedie), programovací jazyk a prostředí určené pro statistickou analýzu dat a jejich grafické zobrazení, bylo vydáno ve verzi 4.4.0. Její kódové jméno je Puppy Cup.
IBM kupuje společnost HashiCorp (Terraform, Packer, Vault, Boundary, Consul, Nomad, Waypoint, Vagrant, …) za 6,4 miliardy dolarů, tj. 35 dolarů za akcii.
Byl vydán TrueNAS SCALE 24.04 “Dragonfish”. Přehled novinek této open source storage platformy postavené na Debianu v poznámkách k vydání.
Oznámeny byly nové Raspberry Pi Compute Module 4S. Vedle původní 1 GB varianty jsou nově k dispozici také varianty s 2 GB, 4 GB a 8 GB paměti. Compute Modules 4S mají na rozdíl od Compute Module 4 tvar a velikost Compute Module 3+ a předchozích. Lze tak provést snadný upgrade.
Po roce vývoje od vydání verze 1.24.0 byla vydána nová stabilní verze 1.26.0 webového serveru a reverzní proxy nginx (Wikipedie). Nová verze přináší řadu novinek. Podrobný přehled v souboru CHANGES-1.26.
Byla vydána nová verze 6.2 živé linuxové distribuce Tails (The Amnesic Incognito Live System), jež klade důraz na ochranu soukromí uživatelů a anonymitu. Přehled změn v příslušném seznamu. Tor Browser byl povýšen na verzi 13.0.14.
Byla vydána nová verze 30.0.0 frameworku pro vývoj multiplatformních desktopových aplikací pomocí JavaScriptu, HTML a CSS Electron (Wikipedie, GitHub). Chromium bylo aktualizováno na verzi 124.0.6367.49, V8 na verzi 12.4 a Node.js na verzi 20.11.1. Electron byl původně vyvíjen pro editor Atom pod názvem Atom Shell. Dnes je na Electronu postavena celá řada dalších aplikací.
Byla vydána nová verze 9.0.0 otevřeného emulátoru procesorů a virtualizačního nástroje QEMU (Wikipedie). Přispělo 220 vývojářů. Provedeno bylo více než 2 700 commitů. Přehled úprav a nových vlastností v seznamu změn.
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 
AbcLinuxu.cz
ITBiz.cz
HDmag.cz
AbcPráce.cz.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.
Tiskni
Sdílej:
