Fedora 40 release party v Praze proběhne v pátek 17. května od 18:30 v prostorách společnosti Etnetera Core na adrese Jankovcova 1037/49, Praha 7. Součástí bude program kratších přednášek o novinkách ve Fedoře.
Stack Overflow se dohodl s OpenAI o zpřístupnění obsahu Stack Overflow pro vylepšení OpenAI AI modelů.
AlmaLinux byl vydán v nové stabilní verzi 9.4 (Mastodon, 𝕏). S kódovým názvem Seafoam Ocelot. Přehled novinek v příspěvku na blogu a v poznámkách k vydání.
Před 50 lety, 5. května 1974 v žurnálu IEEE Transactions on Communications, Vint Cerf a Bob Kahn popsali protokol TCP (pdf).
Bylo vydáno do češtiny přeložené číslo 717 týdeníku WeeklyOSM přinášející zprávy ze světa OpenStreetMap.
Byla vydána (Mastodon, 𝕏) nová stabilní verze 2.10.38 svobodné aplikace pro úpravu a vytváření rastrové grafiky GIMP (GNU Image Manipulation Program). Přehled novinek v oznámení o vydání a v souboru NEWS na GitLabu. Nový GIMP je již k dispozici také na Flathubu.
Google zveřejnil seznam 1220 projektů od 195 organizací (Debian, GNU, openSUSE, Linux Foundation, Haiku, Python, …) přijatých do letošního, již dvacátého, Google Summer of Code.
Na základě DMCA požadavku bylo na konci dubna z GitHubu odstraněno 8535 repozitářů se zdrojovými kódy open source emulátoru přenosné herní konzole Nintendo Switch yuzu.
Webový prohlížeč Dillo (Wikipedie) byl vydán ve verzi 3.1.0. Po devíti letech od vydání předchozí verze 3.0.5. Doména dillo.org již nepatří vývojářům Dilla.
O víkendu probíhá v Bostonu, a také virtuálně, konference LibrePlanet 2024 organizovaná nadací Free Software Foundation (FSF).
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.