V pátek 28. srpna se v Praze uskuteční již osmý Mobile Linux Hackday. Jako obvykle se potkáme v pražské pobočce SUSE v Karlíně na Křižíkově, takže kromě mobilního Linuxu je to tentokrát i příležitost přijít se podívat na nově zrekonstruované kanceláře. Začínáme v 10:00, ale dorazit můžete samozřejmě kdykoliv v průběhu dne. Setkáním vás provede David Heidelberg, vývojář GPU ovladačů v Mesa 3D a jeden z hlavních lidí české komunity kolem … více »
Představen byl Raspberry Pi Compute Module 5 Programming Jig. Jedná se o zařízení umožňující připravit Compute Module 5 do plně funkčního stavu bez nutnosti použití dalších vstupně / výstupních desek. Podporuje automatizaci pomocí nástroje rpi-sb-provisioner. Podrobnosti v dokumentaci.
Hackeři ve Francii ukradli data více než půl milionu daňových poplatníků. Je to jeden z největších hackerských útoků v dějinách země. O útoku z konce června informovala až teď daňová správa. Teprve od pondělí dotčeným občanům zasílá e-maily s instrukcemi, jak postupovat dál. Hackeři se sice nedostanou k penězům dotyčných, hrozí ale věrohodné podvody. Hackeři získali třeba celá jména, údaje o rodinných příslušnících nebo také údaje o
… více »Společnost Framework představila nový Framework Laptop 12 s Intel Core Series 3, Thunderbolt 4, Wi-Fi 7, volitelnou čtečkou otisků prstů a podsvícenou klávesnicí s open-source firmwarem ZMK. Objednat lze s předinstalovanou Fedorou 44 KDE Plasma.
Byl vydán Mozilla Firefox 154.0. Přehled novinek v poznámkách k vydání a poznámkách k vydání pro vývojáře. Řešeny jsou rovněž bezpečnostní chyby. Nový Firefox 154 bude brzy k dispozici také na Flathubu a Snapcraftu.
Nové číslo časopisu Raspberry Pi zdarma ke čtení: Raspberry Pi Official Magazine 168 (pdf).
Open-source citační manažer Zotero (Wikipedie, GitHub) byl vydán v nové major verzi 10. Přehled novinek v příspěvku na blogu.
Interaktivní editor binárních dat GNU poke byl vydán ve verzi 5.0 (seznam změn).
Byla vydána verze 0.85 telnet a ssh klienta PuTTY (Wikipedie). Řešeno je 5 zranitelností.
Byly publikovány novinky z vývoje GIMPu. Pracuje se na novém formátu souborů. Stávající binární XCF bude nahrazen "zazipovaným XML". XCF zůstane plně podporován pouze pro načítání starých souborů.
Kdysi jsem si chtěl udělat vlastní webové stránky. Hezké, čisté jednoduché. Ve své třetí verzi jsou stále ve vývoji a technologii jsem věnoval tolik času, že se příliš nedostává na obsah. Vyzkoušel jsem všechny možné jazyky, technologie, CMS, frameworky a jiné buzzwordy, bez přílišného výsledku. Přestože si rád hraju s různými technologiemi, pořád je to pro mě hlavně o obsahu a pohodlná práce s ním je pro mě klíčová. Představuji si web, který se točí kolem dokumentu, jako původní ideály prastarého HTML, jen trochu pohodlnější. Ovšem kromě lidsky zpracovatelného obsahu (nápady, zamyšlení, pohádky...) tu máme i obsah, u kterého je výhodnější, aby za nás udělal práci stroj. U projektů chci automaticky generovat sekci stažení podle souborů v download adresáři, zobrazovat changelogy, etc. Myšlenka je jednoduchá — zkombinovat krásu jednoduchých značkovacích jazyků (Markdown, Textile, RST...) se silou programovacího jazyka (v tomto případě Pythonu) vloženého do dokumentu trochu jako PHP...
0. Přirozenost — co nejvíce se přiblížit lidskému myšlení, aby stálo minimální úsilí převést myšlenku do strojem zpracovatelné podoby. Minimalizovat pomyslnou bariéru mezi rozmanitostí lidské mysli a omezeností stroje.
1. Jednoduchost — abych nemusel mít na zdi přivěšenou referenční příručku
2. Neukecanost — (X)HTML je dost "ukecané" (i když oproti Javě úplný břídil) — moc píšete a málo dostanete. Rád bych se vyjádřil za pomoci minimálního množství zbytečných znaků.
3. Univerzálnost — narozdíl od jednoduchých značkovacích jazyků bych rád plně využil plnou množinu XHTML tagů — bez přímého vkládání XHTML kódu, které většinou není řešeno příliš šťastně (např. nejde používat jednoduché značky uvnitř XHTML bloku)
4. Rozšiřitelnost — možnost vytvářet si vlastní "tagy" či příkazy, které se mohou nějakým způsobem převést na XHTML. Ne všechno se dá řešit přes CSS a ne vždy je to žádoucí. V ideálním případě obecně rozšiřitelná syntaxe (prostřednictvím nějakých regexů či gramatik), aby se vlastní příkazy daly vkládat nejen použitím jakési obecné syntaxe, ale třeba i jejich vlastní. Základ by měl obsahovat v ideálním případě jen naprosto minimální obecnou syntaxi, zbytek doplní jednotlivé moduly. Dá-li Bůh.
5. Kontextovost — plně kontextová gramatika, která např. umožní zpracování všech řádkových značek uprostřed nově vytvořeného blokového tagu, který o nich nemusí mít ani ponětí. Prostě nastaví, že chce obsah zpracovat v řádkovém kontextu.
6. Programovatelnost — podpora rozumného vkládání Pythoního
kódu (případně s rozšířením na další programovací jazyky),
blokový exec příkaz, klasická eval syntaxe $proměnná
a ${výraz}. Jednoduché vkládání řídících konstrukcí
(if, for, ...), jejihž obsahem není kód, ale kus dokumentu.
Vhodné pro generovaná data jako tabulky apod.
7. Objektovost — každý "kus dokumentu" — tedy nějaký text, prvek, nebo jejich posloupnost, i celý dokument, by měl být schopen být reprezentován nějakým objektem — nad kterým půjde udělat nějaké zpracování, a hlavně jej půjde na nějaké místo nějakého dokumentu zase vložit — tímhle by se daly řešit layout šablony a podobné
8. Sémantičnost — výsledkem by měly být výhradně sémantické značky, i při použití vlastních. Vzhled se vyřeší odděleně. Minimalizovat "režijní" tagy nutné z technických důvodů (i když to ne vždy lze).
9. Lineárnost — zpracování lineárním, ideálně jednoprůchodovým parserem, bez nutnosti přednačtení celého vstupu do paměti. Možnost zpracování dat z pajpy.
10. Strukturovanost — jasná, logická, vnořovatelná struktura. Musí být jasné co k čemu patří. Nepoužívat pevné úrovně nadpisů (kdo se s tím má přepisovat, když zjistí, že chce celou sekci zabalit do jiné?)
Jednak je třeba zachovat jednoduchou syntaxi, na kterou jsou
všichni zvyklí (prázdný řádek oddělující odstavce,
*zvýraznění*, etc.), ale druhak také vytvořit syntaktická
pravidla obecná, pro vkládání libovolných příkazů, která ovšem
nesmí být příliš složitá nebo jít na obtíž. Ideálně by si měla
vystačit s minimálním počtem speciálních znaků, aby ostatní
zbyly na "volná" syntaktická pravidla.
Následuje spíše taková sbírka hrubých nápadů, rád budu za jakékoliv připomínky:
Základem syntaxe je příkaz. Každý příkaz musí mít dopředu definováno, v jakém kontextu/režimu se může vyskytovat. Celý parser funguje jako takový state machine, svým způsobem. Žádný příkaz nemůže být současně řádkový i blokový, protože by se nepoznalo, o který případ jde, pokud by se vyskytl na začátku bloku.
Každý příkaz má parametry, nejspíše poziční i pojmenované, jako jsme zvyklí z Pythonu, a případný textový obsah, který může případně obsahovat i další prvky. U blokových příkazů jsou možné dvě základní podoby syntaxe: odsazená (nám Pythonistům dobře známá) a s explicitním ukončením (ala Ruby či Pascal). Myslím, že obě mají něco do sebe (při psaní textu by odsazení mohlo být nepříjemné, ale v dokumentu, kde převládá struktura — např. layoutu stránek — by zvýšilo přehlednost), proč tedy neimplementovat obě? Třeba takto:
:section
text
:section
podsekce
:end
pokračuje sekce
:end
a :section: Tady máme nějaký text :code: and some(code) a tak dále...
Samozřejmě případně libovolně kombinovat. Dvojtečka jako začátek
příkazu je používána z čistě estetických důvodů — pokud by se
ukázalo, že je potřeba v textu příliš často, není problém zvolit
jiný znak. Jinak se samozřejmě dá escapovat příkazem ::.
Pokud mají inline příkazy textový obsah, asi by odsazení nebylo příliš vhodné, myslím, že docela hezky by mohl vypadat například následující zápis:
Toto je odstavec s :em{zvýrazněným} písmem a odkazem na
:link http://seznam.cz;
Středník je nutný aby se poznal konec příkazu, protože narozdíl
od blokového, který můžeme uzavřít koncem řádku, za ním ještě
může následovat další text. Ovšem po ukončovací } již není
třeba, jak jistě všichni céčkaři chápou;)
S takto překvapivě jednoduchou syntaxí, která si vyžádala
obětování defacto dvou znaků (v kontextu běžného textu se mohou
objevit jen : a }) už se toho dá udělat docela hodně.
A na první pohled to vypadá i čitelně:
:header První dokument
:section
:header Úvod
V dokumentu se mohou vyskytovat různé věci. Třeba takové
:img obrazky.png Obrázky;, :link http://seznam.cz{
Odkazy}.
:if 'MSIE' not in environ['HTTP_USER_AGENT']:
:link #{:img $logo; :)}
Ony tam jdou i obrázkové odkazy, ale Exploreristům
:strong{ani muk}.
:end /*konec sekce*/
Ale jistě by se to dalo udělat ještě čitelněji s trochou syntax sugaru...
První dokument
==============
Úvod
<<<< /*nadpis začánající sekci — jen ukázka, nevím, jestli
to k něčemu bude */
:defimg logoimg $logo
:defimg obr obrazky.png Obrázky
:deflink imglink #{[logoimg]{logo} :)}
:deflink ukazka http://seznam.cz{Odkazy}
V dokumentu se mohou vyskytovat různé věci. Třeba takové
[obr], [ukazka].
:if 'MSIE' not in environ['HTTP_USER_AGENT']
[imglink]
Ony tam jdou i obrázkové odkazy, ale Exploreristům
**ani muk**
:end MSIE /*end ignoruje vše za ním — můžeme si třeba popsat co končí*/
>>> /*konec sekce; nic lepšího mě zrovna nenapadlo*/
Základní trik se jmenuje vkládané objekty a ve většině podobných věcí je dnes běžný. Prostě si definuji objekt (odkaz, obrázek, …) a později se na něj odkazuji. Jen narozdíl od jednoduchých jazyků nebude v duchu průběhu programu shora dolů možné implementovat používání objektů nad jejich definicí, třeba všechny odkazy definovat na konci odstavce, etc.
Při samotném vložení objektu se někdy hodí změnit/doplnit určité parametry,
jako např. v ukázce výše textový obsah. Měnit můžeme i jiné parametry,
např. [mujimg alt=Nějaký popisek|title=Titulek] (možná by byla
přijatelnější qouted syntaxe [mujimg alt="Nějaký popisek" title=Titulek]
...
Ukázky zmíněné víše jsou jen takovým hrubým nástinem obecné idey a rád bych slyšel také názory a náměty jiných. Zatím to vypadá, že z toho vznikne ne-zcela-texu-nepodobné monstrum se složitým syntaktickým aparátem, ale doufám, že pro člověka trochu čitelnější a hlavně zaměřené na XHTML výstup a tedy i webové prezentace...
Tiskni
Sdílej:
Co Lisp? (to bude flame...)
(header První dokument)
(section
(header Úvod)
V dokumentu se mohou vyskytovat různé věci. Třeba takové
(img obrazky.png Obrázky)(link http://seznam.cz Odkazy)
(if 'MSIE'
(link (img $logo ))
Ony tam jdou i obrázkové odkazy, ale Exploreristům
(strong ani muk).
)
)
Tohle by se mi fakt líbilo. 
No ja tedy nevim, ale mysl, ktera by se lepe pracovalo s XML nez s vyse uvedenym zapisem, ma k te moji hodne daleko.
No vida, nemyslel jsem to predtim uplne vazne, ale tohle je fakt hezke. Jeste poresit escapovani zavorek (a dalsich znaku) a je vymalovano. Mozna by bylo lepe pouzit hranate - nedavno jsem premyslel nad Lispem s hranatymi zavorkami, maji tu velkou vyhodu, ze maji na klavesnici vlastni klavesy (resp. ja jsem premyslel nad Lispem, kde by bylo jedno, jakou ze tri zavorek clovek pouzije, pokud by se matchovaly, a tedy by se lepe vizualne pocitaly).
Na originalniho autora - mel byste si podle me predevsim vyjasnit, jestli chcete pravidelnou syntaxi (jako Lisp, HTML nebo obvykle programovaci jazyky), nebo nejakou "lidsky citelnou" (jako maji treba Wiki, YAML nebo ruzne publikacni systemy).
Pravidelna syntaxe ma jasna pravidla, snadno se parsuje pomoci bezkontextove nebo LL(1) gramatiky, jasne escapovani (vetsinou), a jasne definovano, co je syntakticky spravne a spatne. Naopak lidsky citelna syntaxe miva mnohem slozitejsi pravidla a parsery, nejasne ecapovani (pokud vubec) a byva daleko volnejsi, co se tyce zpracovani chyb. Toto rozhodnuti IMHO zasadne ovlivnuje zpusob, jakym bude parser napsany.
Mozna by bylo lepe pouzit 2 jazyky - jeden na markup a druhy na logiku. Kombinovat je do jednoho je nesmyslne.
Líbí se mi myšlenka odkazování na objekty, to by mohlo být hodně užitečné a lehce propojitelné s generovaným obsahem. Ale znamená to nutnost víceprůchodového zpracování.