Byl publikován aktuální přehled vývoje renderovacího jádra webového prohlížeče Servo (Wikipedie).
V programovacím jazyce Go naprogramovaná webová aplikace pro spolupráci na zdrojových kódech pomocí gitu Forgejo byla vydána ve verzi 12.0 (Mastodon). Forgejo je fork Gitei.
Nová čísla časopisů od nakladatelství Raspberry Pi zdarma ke čtení: Raspberry Pi Official Magazine 155 (pdf) a Hello World 27 (pdf).
Hyprland, tj. kompozitor pro Wayland zaměřený na dláždění okny a zároveň grafické efekty, byl vydán ve verzi 0.50.0. Podrobný přehled novinek na GitHubu.
Patrick Volkerding oznámil před dvaatřiceti lety vydání Slackware Linuxu 1.00. Slackware Linux byl tenkrát k dispozici na 3,5 palcových disketách. Základní systém byl na 13 disketách. Kdo chtěl grafiku, potřeboval dalších 11 disket. Slackware Linux 1.00 byl postaven na Linuxu .99pl11 Alpha, libc 4.4.1, g++ 2.4.5 a XFree86 1.3.
Ministerstvo pro místní rozvoj (MMR) jako první orgán státní správy v Česku spustilo takzvaný „bug bounty“ program pro odhalování bezpečnostních rizik a zranitelných míst ve svých informačních systémech. Za nalezení kritické zranitelnosti nabízí veřejnosti odměnu 1000 eur, v případě vysoké závažnosti je to 500 eur. Program se inspiruje přístupy běžnými v komerčním sektoru nebo ve veřejné sféře v zahraničí.
Vláda dne 16. července 2025 schválila návrh nového jednotného vizuálního stylu státní správy. Vytvořilo jej na základě veřejné soutěže studio Najbrt. Náklady na přípravu návrhu a metodiky činily tři miliony korun. Modernizovaný dvouocasý lev vychází z malého státního znaku. Vizuální styl doprovází originální písmo Czechia Sans.
Vyhledávač DuckDuckGo je podle webu DownDetector od 2:15 SELČ nedostupný. Opět fungovat začal na několik minut zhruba v 15:15. Další služby nesouvisející přímo s vyhledáváním, jako mapy a AI asistent jsou dostupné. Pro některé dotazy během výpadku stále funguje zobrazování například textu z Wikipedie.
Více než 600 aplikací postavených na PHP frameworku Laravel je zranitelných vůči vzdálenému spuštění libovolného kódu. Útočníci mohou zneužít veřejně uniklé konfigurační klíče APP_KEY (např. z GitHubu). Z více než 260 000 APP_KEY získaných z GitHubu bylo ověřeno, že přes 600 aplikací je zranitelných. Zhruba 63 % úniků pochází z .env souborů, které často obsahují i další citlivé údaje (např. přístupové údaje k databázím nebo cloudovým službám).
Open source modální textový editor Helix, inspirovaný editory Vim, Neovim či Kakoune, byl vydán ve verzi 25.07. Přehled novinek se záznamy terminálových sezení v asciinema v oznámení na webu. Detailně v CHANGELOGu na GitHubu.
Sám jsem člověkem více než cokoli jiného rozporuplným, a bohužel i mé texty jsou začasté plny rozporů. Když si jich někdy všimnu a snažím se o vysvětlování, čitelnost obvykle povážlivě klesá. Celé to je jen snaha zdokonalovat svoje vyjadřování, snaha vměstnat notně zkurvenou poezii do schémat hovorové řeči. A snad i já mohu věřit, že hledat krásná slova je lepší než zabíjet a vraždit.
Tiskni
Sdílej:
A nie je? Ak tomu dobre rozumiem, tak tam spadajú aj Lispovské makrá. A to určite DSL je.
Aha možno som to zle pochopil. Ak je ten zoznam jazykov v 3. vyčerpávajúci, tak sorry. Ale v tom prípade žiadam o pridanie Lispu do zoznamu A možno tiež Haskellu, ten je na DSL viac než vhodný. Samozrejme, len ak Ladíček tieto jazyky ovláda, inak by to asi nemalo zmysel
Na mňa sa nepozeraj, ja som na Haskell úplný amatér Ale mám vo feedoch pár moc zaujímavých blogov a tam sa DSL z času na čas objavujú. Čo si teraz spomínam, tak DSL pre 3D grafiku, DSL pre skriptovanie hier a naposledy ma zaujal pojem FRP (functional reactive programming), ktorému síce vôbec nerozumiem, ale videl som to niekde spomenuté pri DSL
Takže rozhodne by ma potešilo keby sa tu niečo také vyskytlo. Možno sa toho chytí niektorý ábičkovský haskellista (prádza množina?).
Nemyslím si, že je potrebné ovládať Lisp. Práve naopak, prvé kapitoly sú v podstate úvod do Lispu, tie v prostriedku sa zasa až príliš do hĺbky sa tam preberajú problémy spojené s makrami. Až na konci sú zaujímavejšie príklady. Takže drvivá väčšina kapitol je neprenositeľná na iné jazyky.
Inak, nič proti tej knihe. Čisto ako literatúra o Lispe je skvelá.
Určite? Pokiaľ viem, tak metaprogramovanie (pomocou metatried, ktoré sú ale spracované úplne iným spôsobom než v Smalltalku) dáva dosť veľké možnosti.
Trochu ma sklamalo, že sa nebudeš venovať LR. To je momentálne téma, ktorá ma najviac zaujíma. Aspoň spomenúť by si ich mohol. Ale aj tak je tam kopa viac než zaujímavých oblastí, takže jedného verného čitateľa máš istého
Takto: mne sa LL páči podstatne viac než LR. Konceptuálne je to oveľa jednoduchšie (LL človek v podstate vymyslí aj na kolene) a viem o nich už dlho. Ale mal som za to, že za a) vymyslel to Knuth b) LR(1) > LL(1) v zmysle inklúzie gramatík, c) LR je algoritmicky efektívnejšie ako LL, d) pri LL treba riešiť kopu vecí (left-recursion napr.), ktoré pri LR nie sú. Preto som sa v poslednej dobe začal trochu učiť LR. Ale súčasný vývoj v parsovaní nepoznám a ak je to tak ako hovoríš, tak mám radosť a pokojne LR oželiem (ale aj tak si myslím, že by bola škoda aspoň ich nespomenúť).
Ok, to mi stačí.
Btw, netušíš náhodou ktorý z nich (LL/LR) produkujú PCT v Parrote? mj41 tu totiž nedávno spomenul zaujímavý tutoriál na implementáciu kompilátora do Parrotovského bytekódu (PASM?). Spravil som si z toho pár kapitoliek a bolo to fakt fajn. A mimochodom som dospel k tomu, že Perl 6 je fakt fajn jazyk. Parrot používa jeho podmnožinu ako na špecifikáciu gramatiky, tak parsing actions nad AST. Jazyky pre Parrot sa píšu fakt jedna báseň, možno ďalší tip, ktorý by si mohol spomenúť v článku? Ale aby som sa vrátil k téme, tak celý čas rozmýšľam nad tým, čo za kompilátor tam vlastne vzniká. Nejak sa mi to nepodarilo dogoogliť, takže možno aspoň tu mi niekto dá odpoveď
Grammars, typically files with a ".pg" file extension, are compiled using the Parrot Grammar Engine (PGE). PGE is an implementation of the Perl 6 rules engine for Parrot. PGE uses a Recursive Descent parser, although certain components such as expressions can be parsed using a bottom-up parser for efficiency.
netušíš náhodou ktorý z nich (LL/LR) produkujú PCT v Parrote?To netusim, ale anekdota rika, ze na parsovani Perlu 7 bude treba pouzit Chart parser nebo Viterbi parser.
Mno, momentálne mám pocit, že ak bude vývoj podobný ako Perl 5 -> Perl 6, tak z Perlu 7 bude úplne minimalistický jazyk
Je z toho snad zřejmé, že se nehodlám pouštět moc hluboko do teorie formálních jazykůOsobne si myslim, ze k tomu v podstate teorie formalnich jazyku neni treba (nebo jen naproste zaklady) a ze se celkove parsovani v literature o DSL nebo o prekladacich dost precenuje. LL(1) parser napise schopnejsi programator aniz by potreboval cokoliv vedet o teorii a vic v podstate neni treba :–) . Na DSL (a programovacich jazycich ci prekladacich) je preci mnohem zajimavejsi semantika nez syntax. Tedy v prve rade jak vhodne navrhnout DSL v navaznosti na konkretni problem a v druhe rade jak to rozumne implementovat (kdyz uz mame nejak zparsovany vstup do AST). Tipuju, ze ta prvni vec je ale spis umeni nez ze by na to byla vhodna teorie (coz je asi taky duvod, proc se to bezne pri vyuce odbyva). Mozna by to bylo nejvhodnejsi vylozit formou prikladu takovych jazyku a rozborem jejich silnych a slabych stranek.
Asi tiež neuškodí spomenúť, že úplne najjednoduchšie veci sa dajú riešiť už regulárnymi výrazmi. Pochopiteľne sa jedná o primitívne šablónovacie jazyky pre HTML
a na žádný AST ani nedojdeSamozrejme, ten AST tam muze byt jen implicitne mysleny.
+1
Teóriu jazykov som neabsolvoval (viem čo je gramatika a približne aj ako to súvisí s automatmi a regulárnymi výrazmi, ale to je tak všetko), ale malý LL kompilátorček Lispu, som si napísal už dávno
Osobne si myslim, ze k tomu v podstate teorie formalnich jazyku neni treba (nebo jen naproste zaklady) a ze se celkove parsovani v literature o DSL nebo o prekladacich dost precenuje.souhlasim. osobne mi prijde problematika parsovani, jako asi nejnudnejsi pasaz z oblasti navrhu prog. jazyku.
A ktoré sú zaujímavejšie oblasti? Typový systém?
Parsovanie je podľa mňa základ. S tým by si mal asi začať (teda modulo texty, ktoré uvádzajú do problematiky). Kam sa vydáš ďalej, to už je na tebe. Garbage collector je užitočná vec, ale dnes už je jeden v každom virtuálnom stroji (a to zrejme kvalitnejší, než človek vyrobí na kolene), takže mi pripadá trochu zbytočné sa mu venovať. Typové systémy vyzerajú užitočnejšie, ale asi je to fakt trochu hard-core. Ešte by sa dali spomenúť optimalizácie, ale to mi pripadá zasa zbytočné, lebo to "len" zlepšuje už hotovú vec. Takže neviem, nechám sa prekvapiť s čím prídeš
rozeberete ruzne typy gramatik v jednom souboru a poslete je do ruznych streamu.Je to trochu porno, ale dá se vyjít třeba odtud: http://www.antlr.org/wiki/display/ANTLR3/Island+Grammars+Under+Parser+Control. Nikdy jsem to nedělal, ale musí to jít. Řeší to v každém lepším IDE (kombinace PHP+HTML+CSS+JavaScript+regexpy v jednom souboru musí být peklo).
stringtemplateHodně minimalistickej šablonovací jazyk, ale líbí se mi, že docela dobře zvládá bílé znaky. Ale není to nic než šablonovací jazyk, stejně dobře může posloužit třeba FreeMarker.
napisete gramatiku, vyjde Vam z toho AST strom. Chcete potom z tohoto stromu neco filtrovat (jen urcite elementy) a co nejmene psat.Stromové gramatiky v ANTLR jsou docela mocné, od ANTLR 3.2 se dají přepisovat i stromy na stromy. Stačí popsat jen tu část stromu, která je zajímavá. Zase, nedělal jsem to, ale musí to jít.
nahrazovani v AST stromu, prevod jednoho jazyka na druhy. Vcelku by se mi hodilo nejake klikadlo, kde naklikate na kazde strane jednu gramatiku a resite vztahy mezi nimi (mapovani).To musí být obecně docela šílený problém (ne-li nerozhodnutelný). Ale mám pocit, že grafické návrháře existují třeba pro XSLT
nadefinujete gramatiku. Presneji nadefinujete pouze typy elementu a jejich relace mezi nimi. Ale dany typ elementu musite overit pres nejakou databasi "treba" slov. To, co znate jsou ty relace mezi danymi typy elementu. Zda to je a jak ?A to už jsem ani nepochopil