Alyssa Rosenzweig se v příspěvku na svém blogu Vulkan 1.3 na M1 za 1 měsíc rozepsala o novém Vulkan 1.3 ovladači Honeykrisp pro Apple M1 splňujícím specifikaci Khronosu. Vychází z ovladače NVK pro GPU od Nvidie. V plánu je dále rozchodit DXVK a vkd3d-proton a tím pádem Direct3D, aby na Apple M1 s Asahi Linuxem běžely hry pro Microsoft Windows.
Byla vydána (𝕏) květnová aktualizace aneb nová verze 1.90 editoru zdrojových kódů Visual Studio Code (Wikipedie). Přehled novinek i s náhledy a animovanými gify v poznámkách k vydání. Ve verzi 1.90 vyjde také VSCodium, tj. komunitní sestavení Visual Studia Code bez telemetrie a licenčních podmínek Microsoftu.
Byla vydána (Mastodon, 𝕏) nová verze 2024.2 linuxové distribuce navržené pro digitální forenzní analýzu a penetrační testování Kali Linux (Wikipedie). Přehled novinek se seznamem nových nástrojů v oficiálním oznámení.
Počítačová hra Tetris slaví 40 let. Alexej Pažitnov dokončil první hratelnou verzi 6. června 1984. Mezitím vznikla celá řada variant. Například Peklo nebo Nebe. Loni měl premiéru film Tetris.
MicroPython (Wikipedie), tj. implementace Pythonu 3 optimalizovaná pro jednočipové počítače, byl vydán ve verzi 1.23.0. V přehledu novinek je vypíchnuta podpora dynamických USB zařízení nebo nové moduly openamp, tls a vfs.
Canonical vydal Ubuntu Core 24. Představení na YouTube. Nová verze Ubuntu Core vychází z Ubuntu 24.04 LTS a podporována bude 12 let. Ubuntu Core je určeno pro IoT (internet věcí) a vestavěné systémy.
Databáze DuckDB (Wikipedie) dospěla po 6 letech do verze 1.0.0.
Intel na veletrhu Computex 2024 představil (YouTube) mimo jiné procesory Lunar Lake a Xeon 6.
Na blogu Raspberry Pi byl představen Raspberry Pi AI Kit určený vlastníkům Raspberry Pi 5, kteří na něm chtějí experimentovat se světem neuronových sítí, umělé inteligence a strojového učení. Jedná se o spolupráci se společností Hailo. Cena AI Kitu je 70 dolarů.
Byla vydána nová verze 14.1 svobodného unixového operačního systému FreeBSD. Podrobný přehled novinek v poznámkách k vydání.
v beznem clanku o jazycich by alespon druha kapitola urcite byla o gramatikach a takovych tech vecech. ale necham si ji zatim pro sebe. v jazycich odvozenych od lispu, je rozdil mezi hodnotou a samotnym kodem hodne tesny, tak bych napsal neco o implementaci typu. neni to nic svetoborneho a priznavam, inspirovaneho guile.
nema smysl zde budovat nejaky komplexni system datovych typu, i kdyz pravda r5rs jich definuje vicero, mj. pocita i s cisly o libovolne velikosti a presnosti. pro zacatek, z tech beznych si postacime se symboly, celymi cisly, boolovskymi hodnotami a typy pro tvorbu seznamu a neco malo pro praci s kodem. takze zavedeme vyctovy typ:
typedef enum scm_type { INT, PAIR, SYMBOL, BOOL, NIL, VOID } scm_type;
a zavedeme strukturu, ktera se bude skladat z hodnoty a jejiho typu
typedef struct scm_value { scm_type type; union { int integer; int bool; char * symbol; struct scm_pair { struct scm_value * ar; struct scm_value * dr; } pair; } value; } scm_value;
pravda, nektere hodnoty mohou byt vetsi nez by skutecne mohly byt (kvuli tem dvema pointrumu u typu "pair") na druhou stranu to velice zpohodlnuje praci s takovym typem, takze co vyplytvame na miste, usetrime rychlosti pri praci jednotlivych operaci s touto strukturou.
opravdu to neni zadny zazrak, takze pokud by nekdo lisp nebo scheme videl poprve v zivote a zarazilo ho, ze o neco vyse zminuji typ pro tvorbu seznamu a ve strukture neni. pripomel bych, jak se vlastne takovy seznam tvori. jako typ jsou zde zavedny dva prvky a to NIL (prazdny seznam) a PAIR (teckovy par -- promenna obsahuje prave dve hodnoty libovolneho typu. casto se to znaci napr. (1 . 2)
) vytvorit z nej seznam je pak docela trivialni zalezitost a to skladanim jednotlivych teckovych paru dohramady v principu (hodnota . seznam), napr. (1 . (2 . (3 . (4 . ()))))
pro bezny zapis je to, ale hodne neprakticke, proto se to zkracuje do tvaru (1 2 3 4)
na jednu stranu jsem predchvilkou mlel neco o efektivite a mistu, presto tu musim zminit jeden hezky hack, ktery dokaze prijemne zlepsit vykon. pri tvorbe hodnot se pokazde alokuje nove misto v pameti. u typu jako NIL nebo BOOL to jde osetrit zadefinovanim urcitych konstant a z nich si vybirat hodnoty. to jde udelat pokud je hodnot malo, ale co takova cisla? hodnoty 0, 1, -1 jsou docela caste, takze co tak zavest konstanty i pro ne, ale 2 muze byt taky docela caste, atd., atd.
na nekterych architekturach jde pouzit bezva finta, pomalu jak bezva finta, jeana paula belmonda z filmu bezva finta. staci drobna informace o tom, ze vetsina alokatoru alokuje pamet do bloku zarovnanych na 4 nebo 8 bytu. to znamena ze minimalne spodni dva bity jsou vzdy 0 a prakticky se nepouzivaji. cela pointa pak tkvi v tom, ze je pouzijeme jako priznak, jestli se jedna o ukazatel, nebo je v hodnote ulozena nejaka dalsiho informace. napr. pokud je spodni bit nastaven na 0 jedna se o pointer a jako s takovym s nim budeme pracovat, je-li spodni bit 1 jedna se o cele cislo a na zbylych 31 bitech mame ulozenou jeho hodnotu. v kodu to pak vypada nejak takto:
#define scm_value_new_int(__val) ((scm_value *)(1 | ((__val) << 1))) #define SCM_INT(x) (int)((long)x >> 1)
makro scm_value_new_int(x)
vytvori "ukazatel", ktery vlastne neni ukazatel, ale pouze ciselna hodnota a makro SCM_INT(x)
umi hodnotu z tohoto "ukazatele" vycist zpet.
Tiskni Sdílej:
(mapcar #'(lambda (x) (concatenate 'string "push " x)) '("true" "false" "-1" "0" "1" "2"))
jako samostatné opkódy.
size
musel ukládat na jeho začátek. Když jde do vysokých bitů pointeru ukládat velikost bloku, jde tam samozřejmě ukládat i typetag.
Bohužel nevím o žádném sysému, který by to dělal. Smalltalk?
„…a po každém pitomém inkrementu testovat, jestli 32-bit výsledek vleze do 31-bit short intu, nebo ne. Sice se šetří paměť, ale na runtime to má režii.“A u short integeru se v Pythonu netestuje, jestli se výsledek vleze zase do short integeru nebo se musí vytvořit long? Jinak, Ruby 2.0 bude po vzoru Smalltalku Symbol mít jako podtřídu Stringu (na rozdíl od současné implementace), takže je klidně možné, že se bude chovat stejně. A ten tzv. BBOP je čirou náhodou vynález Lispu z poloviny sedmdesátých let.
zones
. Co to je nevím, ale když se tomu říká jinak, tak to bude něco jiného :)
„Python 31-bit short integery nemá. Má normální 32-bit integery (signed, immutable, na heapu, často používané hodnoty zamknuté ve sdílené tabulce), a pak má long integery (signed, mutable, na heapu, bignum).“Reagoval jsem na tvrzení, že se něco musí testovat a má to režii. V Pythonu přetékají short integery do long integerů a tudíž se tam asi něco testuje, jinak by se to nemohlo chovat jinak v závislosti na tom, jestli to přeteče nebo ne. Asi mi něco ušlo.
„Není, Lisp měl zones. Co to je nevím, ale když se tomu říká jinak, tak to bude něco jiného :)“Doporučuju přečíst si Data Representations in PDP-10 MACLISP, autor Guy Steele Jr., MIT 1977. Občas je dobré vědět a ne si jen myslet. Cestu ke Googlu určitě znáš.
This idea is similar to the "zones" used in some Lisp systems (e.g. LeLisp).Protože vím že mezi "similar" a "identical" je podstatný rozdíl, nic hledat nebudu.
Mít všude výhybku na integerovou aritmetiku totiž není žádná sranda- fakticky je třeba samostatně implementovat 31-bitovou aritmetiku a 32-bitovou aritmetiku, a po každém pitomém inkrementu testovat, jestli 32-bit výsledek vleze do 31-bit short intu, nebo ne. Sice se šetří paměť, ale na runtime to má režiiNe nezbytně - nevím jak scheme (asi ne), ale některé Common Lispy jsou ochotny uvěřit deklaracím že vše je fixnum (tedy 31-bitový integer) a generovat efektovní kód - tedy pokud o tu runtime režii až tak jde....
* (declaim (optimize speed space (safety 0) (debug 0))) * (defun plus (a b) (declare (fixnum a b)) (the fixnum (+ a b))) PLUS * (disassemble #'plus) ; 0A5F1A0E: 01FA ADD EDX, EDI ; 10: 8D65F8 LEA ESP, [EBP-8] ; 13: F8 CLC ; 14: 8B6DFC MOV EBP, [EBP-4] ; 17: C20400 RET 4 ; 1A: 90 NOP ; 1B: 90 NOP ; 1C: 90 NOP ; 1D: 90 NOP ; 1E: 90 NOP ; 1F: 90 NOP ; NIL
„…nevím jak scheme (asi ne)…“Stalin by k tomu určitě šel dokopat.