How crazy can I get? part 1 (diskuse)

[pc2005]

Aneb jak si Bedňa přál ...

[Bedňa]

Kurňa kuknem na to a hovorím si je to ono, si pán, dík kámo.

[debian]

Can you give on and article/blog your full example code? I wanna try that.

Thx.

[pc2005]

Not yet, I don't wanna spoil blogposts, maybe in 4-5 part, definitely on the end of the series. These version are not even able to run on PC and they would randomly wrote to a random memory locations.

[debian]

Ok. Then u give on too on github or here. ... I like what i studying, can testing.

[xkucf03]

s/github/gitlab/g

nebo jinam…

• Git != GitLab
• verzovací systém != Git

[vlastikroot]

Proboha proc? Na grafiku nejsou potreba Xka, staci framebuffer (ktery musi fungovat, kdyz funguje konzole na displayi).

[pc2005]

Právě pro takovéhle komentáře . A to tohle je ještě nuda >. BTW tohle není grafika, to jsou znaky v terminálu.

[vlastikroot]

Je to grafika, to vidim Me jde prave o to, proc to delat takhle oklikou (bash -> fbcon -> framebuffer) a ne rovnou (c/c++ -> framebuffer).

Protože to jde? Nebuď takovej suchar

[pc2005]

No primárně protože ten daný den mě nešel zkompilovat ncurses a binárka byla moc velká do initramdisku, pak jsem se ho nechtěl učit a nakonec to bylo because we can . V céčku bych to samozřejmě napsat mohl a možná to přepíšu. Z bashe to bude triviální .

[Bedňa]

Tak a teraz k EN. Fakt sranda, že roky som bol len na písanej angličtine "pls fix my bug" a teraz som sa na dlhšiu dobu ocitol za hranicami a emajly robím v pohode. Potom mi volá fakt pekná Alexia a bla, bla bla, pretože je moc ukecaná a nejde k veci, takže to nechytám a poviem jej prepáč, dáme kávu ja si idem prečítať email na ktorý som sa vysral :)

Kurwa si borec vo veciach ktorým som kedysi venoval kopec času, tak tebe fandím, ako to háčkuješ.

"more stable than Xorg*" alebo tak niečo tam píšeš, nechce sa mi k tomu vracať :) Sorry ja som zástanca Xorgov a nemám rád kecy bez riešenia čo je na nich zlé :)

[pc2005]

"more stable than Xorg*" alebo tak niečo tam píšeš, nechce sa mi k tomu vracať :) Sorry ja som zástanca Xorgov a nemám rád kecy bez riešenia čo je na nich zlé :)

To se přímo netýka bashe, ale spíš intel Xscale SoC architektury. V té době nefungoval pořádně touchscreen, Xka sežerou značnou část RAM a nevejdou se do 30MB ramdisku (takže je nelze spouštět bez SD karty), fluxbox má dost neefektivní stavový automat na obsluhu klikání, takže se špatně fungujícím touchscreen driverem to bylo nepoužitelné. Když umře nějakej driver, tak potřebuju vidět dmesg puštěnej ve smyčce, v tty konzoli to je přece jen robustnější. GTK se nedá použít na rozlišení menší než 640x480 (mám dojem, že to mají dokonce ve specifikaci UI layoutu, minimálně jsem musel ty layouty ručně upravovat, protože jsem jinak viděl jen výpis adresářů). Současně používaný matchbox ještě v té době pořádně nefungoval (je málo vyvíjenej) a občas segfaultoval. Stejně tak nefungovala virtuální klikací klávesnice (jsem musel najít až minulej rok, že se před x lety změnil server repa).

Dále zapnutí Xek začne víc žrát baterku, takže je vyšší šance, že systém selže nadproudem (ani bych neměl v xkách aplikaci na sledování odběru z baterky). Intenzivní používání "grafického" "řadiče" ho může zablokovat.

A finálně největší problém. GCC pro xscale negenerovalo validní instrukce a tak občas dostal ARM buď random kód a nebo instrukci z novější generace architektury (protože ARMv5TE nemá pořádnou podporu debuggingu, tak to vypadalo tak, že kód skáče náhodně po paměti a on nejspíš i občas skákal). Taky to znemožňovalo používat 16bpp xkový aplikace (ty instrukce se používají pro zoomování pixmap).

[vlastikroot]

Xka se na embedded vubec nehodi. Nejlepsi je kreslit primo na framebuffer. Qt ma moduly linuxfb (legacy FB) a eglfs (openGL KMS), takze jde pouzivat i bez X. Ale to PXA270 je asi moc slaby i na Qt, ja delam s Freescale iMX 5 a 6 a ani tam to neni zadna slava.

[vlastikroot]

BTW, ja pouzivam Qt/QML i na miniaturnim monochromatickem displayi 128x64 OLED s radicem SSD1305. Mam tam dost podobne GUI, jako jsou screenshoty v zapisku (program slouzi k flashovani a otestovani zarizeni ve vyrobe, takova ozivovaci SD karta).

Vyhoda je, ze mam tim padem stejne vyvojove prostredi, at uz jsem na PC, dotykovem embedded zarizeni, i na tech nejjednodusich tlacitkovych zarizenich.

[pc2005]

Čistý xka s vlastním layoutem by jely, akorát teda by bylo málo paměti. Matchbox docela sedí i když je dost natvrdo naprogramovanej (divná nabídka a občas něco segfaultuje).

[xkucf03]

Přijde mi to dost nečitelné. Nepřemýšlel jsi o rozdělení na vrstvy bitmap (resp. spíš znakových map)?

text = "
 ╭──────╮
 │ Ahoj │ 
 │ 123  │
 │ ...  │
 ╰──────╯
";

barvaPisma = "
 xxxxxxxx
 x      x 
 x aaaa x
 x bbbb x
 xxxxxxxx
";

barvaPozadi = "
 dddddddd
 d cccc d 
 d      d
 d      d
 dddddddd
";

akce = "
 dddddddd
 daaaaaad 
 daaaaaad
 daaaaaad
 dddddddd
";

A pak mít funkci, která ti to poskládá dohromady a vygeneruje ANSI sekvence. Ve zdrojáku by bylo na první pohled vidět, co bude na obrazovce. Dynamické hodnoty by se daly doplňovat prostým nahrazením textu (+x kontrola délky), např. bys tam měl {ppp} a za to bys doplňoval hodnotu nabití baterie v procentech.

Další funkce by pak podle souřadnic zjistila akci a vrátila např. akci "a".

[debian]

A naprogramoval by a la ncurses ....

[pc2005]

Co vlastně všechno ncurses umí, můžu si definovat kompletní okenní paradigma, nebo jsou závislosti mezi oknama součástí knihovny?

[Josef Kufner]

Okna v ncurses jsou dost low-level záležitost a do oken jak je známe z grafických desktopů to má hodně daleko.

[pc2005]

Jako rozdělit to na planární grafiku? To nejde ash neumí pole a jinak nemáš jak bys dostal atribut třeba pozadí ke specifickému znaku. A bajtový copypaste by bylo ultrapomalý. Jedině že bys generoval ty ansi escape kódy z nějakého vlastního jazyka, ale to by bylo furt pomalý. Nicméně aktuální verze to má jinak (nebo spíš může mít, zatím jsem byl línej to implementovat) .

[pc2005]

Jo a pak by se to taky blbě generovalo kdyby se měly generovat jednotlivý atributový roviny.

[Josef Kufner]

Rychlost je nepodstatná. Předkompiluješ si to při překladu či před prvním použitím.

[pc2005]

před prvním použitím

Jo to je ten problém, co popíšu v dalších částech.

[RM]

Regarding printf inconsistency over diverse shells, what`s a problem?

[pc2005]

Hmm I wrote it illegibly, because I partly don't remember why I didn't switch to printf and I don't remember older configurations of my busybox. I can only try to retrace my thinking.

It's more like inconsistencies between shell implementations not directly printf, altought there are some.

The busybox implementation of ash is slow (it even calls the kernel after every keyword). But the strings in busybox ash are __very__ slow, so I always assume a string parsing will slow the graphical engine to an unusable speed. The main goal is use the strings as little as possible. The echo -e -n command should be fast enough as it contains only switches, but the printf you cannot directly use a general graphical data string in the formating part (it can contain "%"). You need to use them as a parameter. The formating string can only be "%b".

You could use stuff like this:

# printf "AAA %.5s BBB\n" "${var2}"

but it does not copy five UTF-8 characters (with 3 bytes). It copies only 5 bytes (1 and 2/3 of an three bytes UTF-8 char).

In this situation "printf" doesn't have any benefits over "echo", but it has a disadvantage with the formatting string, which has to be complexly parsed. In the bash it doesn't really matter as the implementation overhead of a program with more features is bigger than the speed differences between echo and printf (= there are equally slow). In busybox there may be speed differences.

And you can opt to disable one of the busybox ash functions to gain a space for the binary so using only a dumb echo output could be seen as a benefit.

The rest of the "echo over printf" choice was most likely in my unwillingness to deal with the printf documentation as a _much_ more difficult stuff required my attention.