Aktualizováno 23.04.16 06:28:52
******************
23.04.2016
Opravil problém s opakovaným spouštěním winwin(...).
******************
26.02.2016
Zjistil jsem, že kolem příkazu winwin cosi uhnilo, takže jsem to napravil.
Zkuste:

winwin(0,200,200,500,1000,"Prohlížení")
pro login.cmd
.remwin()
.ask u Povedlo se?

PRO naběhne v samostatném win okně nezávislém na základním okně - lze ho odsouvat
a tak vidět co je v základním okně atp. Mělo by to nahradit původní koncepci
.newwin/.oldwin.
******************
06.01.2016
Do ZIPu a UNZIPu jsem doplnil češtinu. Nicméně je třeba vzít v úvahu, že čeština
v ZIPu je stále v MSDOS češtině - u nás .codepage 3!
******************
31.12.2015
Aktuální příručka je na webu. Poslední stav wr584 již odkazuje na dok584.[xhl|chm].
V příruče věnujte pozornost nové kapitole A5.22.
******************
29.12.2015
Při aktualizaci příručky ještě dotahuji práci s thready. Snažím se o paraelní
možnost ručního (původní) a automatického řízení práce s thready. Ruční má
největší efekt na zrychlení zpracování, automatické pak minimum pracnosti a možnosti
jetí větších celků na pozadí.
******************
14.12.2015
Nikdy nechodilo viditelné označování v příruče XHL pomocí <Alt O> pokud řádek
nebyl nestandardně obarvený. Kurzor se pohyboval správně po řádcích i <Ctrl C>
pak proběhlo správně, pouze označování bylo většinou na slepo. To jsem napravil.
******************
02.12.2015
Snad se podařilo vyřešit kolizi kliknutí myši na položku - prochází se KB a
v některém je JUMP na položku - ten se provedl a nesnížil se počet přeskakovaných
položek z myši - šlo to někdy až na konec formuláře -> Zapsat?
******************
01.12.2015
Jako obvykle testuji při aktualizaci příručky jednotlivé přírustky. Konstatoval
jsem, že příkaz winwin uhnil, takže jsem ho opět uvedl do provozního stavu.
******************
29.11.2015
Zahajuji aktualizaci dokumentace. Pokud Vam neco chybělo nebo bylo v dokumentaci
nepřesné, ozvěte se!
******************
14.11.2015
Protože funkce DV(...) má poslední parametr výstupní - ostatní funkce mají pouze
vstupní parametry - činí mně odjakživa potíže. Naposledy si ing. Novák stěžoval,
že při spuštění dalšího VST přes .gsb z jiného VST u funkce DV nefunguje zbytek.
Proto jsem doplnil seznam funkcí o funkci ZB(<dělenec>,<dělitel>) - výstup je
zbytek.
******************
22.10.15
Při exportu do Excelu přes clipboard je třeba znát nastavení na uživatelově PC
desetinné tečky/čárky. Zjistíte to:

.onerr #; .getkey hodn,"HKEY_CURRENT_USER/Control Panel/International=sDecimal"
.if(error) "Neexistuje"; .else "Existuje"
;'hodn'
******************
16.10.2015
Ještě se potýkám se šifovaným PDF. Nejprve AcrobatReader 11 hlásil, že soubor je
poškozen, což se podařilo opravit. Potom i bez šifrování chtěl při ukončení soubor
znovu uložit a v tom případě vnitřek PDF zcela přepracoval. To se překvapivě
podařilo opravit změnou pouhého LF na CRLF. V důsledku toho ale přestalo zcela
fungovat šifrované PDF. Testy jsem zjistil, že zatímco u nešifrovaného PDF, CRLF
v sekci XREF nevadí, šifrované PDF vůbec nefunguje. Čtení tedy není pro nešifrované
a šifrované PDF symetrické.

V současné době nešifrované PDF lze ukočit bez dotazu na znovu uložení, šifrované
PDF nikoliv. Budu se s tím ještě zabývat.
*****************
9.10.2015
Do ZUZ a EML doplnen přepínač NU. V prvém případě způsobí, že se nulové hodnoty
přepíší ze zdroje do výstupu typu XMLRDA a ve druhém případě aktivuje u numerických
hodnot formát 0n místo dosavadního 0.

Po delší době jsem se vrátil k zašifrování PDF. Nastudoval jsem popis algoritmu
RC4, pochopil, co znamená klíč v tomto algoritmu. Opustil hash MD5 v API Windows
a použil jsem jakýsi z webu.

Na základě těchto znalostí jsem postupně pochopil, co chtěl básník říci v popisu
šifrování v příruče PDF jazyka a po delším úsilí jsem šifrování protlačil.

Z popisu PDF ovšem vyplývá, že buď širujete nebo podepisujete. nelze obojí.

Ve WR je nyní příkaz:

.encrypt_pdf "<owner>"[,"user"]

umožňující zadat heslo vlastníka a uživatele. Pokud uvedete jen jedno heslo, je
<owner>==<user>.

Pomocí

.encrypt_pdf ""

se širování zruší.

Pokud by někdo potřeboval šifrování RC4, tak teneto algoritmus není znám, ale je
publikován algoritmus aRC4, který dává stejné výsledky:

unsigned char s0[256];

void aRC4ini(unsigned char *key,int dkey)
{unsigned char j,t; int i;
for(i=0; i<256; i++) s0[i]=i;
for(j=i=0; i<256; i++)
{j=(j+s0[i]+key[i%dkey]);
t=s0[i]; s0[i]=s0[j]; s0[j]=t;
}
}

void aRC4(unsigned char *txt,int dtxt,unsigned char *stxt)
{int l; unsigned char s[256]; unsigned char i,j,b,t;
memcpy(s,s0,256);
for(i=j=l=0; l<dtxt; l++)
{i++; j=j+s[i];
t=s[i]; s[i]=s[j]; s[j]=t;
b=s[i]+s[j];
stxt[l]=s[b]^txt[l];
}
}

Podstatou tohoto algorimu je, že aplikace aRC4 zachovává délku textu, aplikace
na txt a pak na stxt se stejným klíčem, dává zase původní txt.
******************
01.10.2015
Při syntéze XML spočívající v doplňování celých uzlů chybělo doplnění nadřazených
uzlů v případě, že ve vytvářené struktuře ještě neexistovaly. Dále skupina

Aktualne\Radek

se interpretovala chybne jako Aktualne.

Připomínám ale, že v případě doplňování celých skupin musí mít doplňovaná část
totožnou strukturu jako rozšiřovaná část, protože se celý uzel přemístí beze
změny do rozšířované části. V datech jsou místo identifikátorů pouze jejich
pořadová čísla ve shodě s XMLRDF.
******************
25.09.2015
Vzhledem k tomu, že tečka je v TT fontech úzká a čísla se tisknou s pevným ofsetem,
dodělal jsem posun tečky doprava o 1/4 šířky znaku jak na tiskárnu, tak do PDF formátu.
******************
23.09.2015
Konstatuji, že příklad SPR - spreadsheet fungoval naposledy ve WR55. Dále máme ve WR příkazy
pro jetí instrukcí na WR spuštěného na serveru - viz A 5.4. Obojí bych z WR vyřadil.
Alespoň je to můj názor. Pokud to někdo používá, ať se ozve.
******************
17.09.2015
Protože formát t pro HM se interně kryl pro DD s formátem u, došlo ke kolizi. proto jsem
byl nucen místo t dát nový formát h.
******************
17.09.2015
Doplněn nový typ údaje HM (hodiny:minuty) ukládaný jako CC 4095 2. Na vstupu se pořizuje
s tečkou, na výstupu je mezi hodinami a minutami dvojtečka. Ve VST se kontroluje smyslupnost
průběžného zadání tak, aby hodiny byly menší než 24 a minuty menší než 60.

Funkce ti(hm1,hm2) dává výsledek v minutách. Pokud je hm1>hm2, předpokládá se přechod
přes půlnoc.

Formát t na údaj typu DD převede hodnotu v minutách na hodiny:minuty. Např.

15 -> 0:15
300 -> 5:00
================
315 -> 5:15
******************
09.09.2015
Dospěl jsem k názoru, že nejlepší řešení poslední otázky je označit řádky, ve kterých bylo
detekováno alespoň jedno číslo pomocí vm=1. Navíc vymezerované hodnoty nepovažuji za číslo.
******************
08.09.2015
Po importu obsahu souboru Excelu přes ODBC, stačí jedna nenumerická hodnota ve sloupci, aby byl
sloupec deklarován jako textový. V tom případě se přenese numerická hodnota s desetinnou
čárkou a v účetním formátu, kde místo mezer je znak a0 hexa. Proto jsem provedl jakousi
úpravu ARI, kde při novém přepínači DC se texty převádí nejprve do pomocné proměnné a následně
se do ní vrací. A právě to zpětné dosazení se potlačí, pokud obsah textu je nenumerický.

%ari
dc.
dd
qa:6=f5
f5=qa
//
%

Tedy jakoby místo f5=qa bylo .if(<cislo>) f5=qa;

Vymezerované pole se považuje za 0. V konkrétním případě díky hodnotě 5_2015, ODBC
deklaroval pole jako textové. Protože 5_2015 není číslo, zůstane tato hodnota beze změny.
Otázkou je, zda by nebylo vhodnější takové pole vymezerovat.
******************
07.09.2015
V nápovědném menu VST lze nyní použít ve spojovacích klíčích druhé a další složky
virtuální tabulky pomocné proměnné. Dosud to šlo pouze pro hlavní tabulku nápovědného

ucet<*KB na ucet*>
wm.
ucet[muj]>
ucet&.
koducet
ucet&,koducet!
muj.ucet,qk.
...
*****************
30.08.2015
Poměrně pracnou záležitostí bylo dosažení kompatibility stávajících příkazů /dc a /cm v PIPu
pro ZPP i pro ZIP. Pro ZIP navíc vadily mezery ve jménu i adresáři (i když byly
v uvozovkách).

Pro rozbalení ZPP a ZIP byla doplněna možnost volby cílového adresáře pomocí
příznaku

/cm:"<adresář>"

např.

pip "slozka a/a.txt","slozka b/b.txt"="moje zaloha/zaloha.zip"/dc/cd:"new"

v tomto případě se v existujícím adresáři new založí složky "slozka a" a "slozka b"
a do nich se rozbalí a.txt a b.txt.

Z důvodu existence nového /cd pro /dc není pro ZIP zrealizována možnost se zdvojeným
lomítkem.

Z důvodu kompatibility ZPP a ZIP je nyní v ZIP vypuštěn zdrojový adresář - uvádějí se
až podsložky zdrojového adresáře.
*****************
30.07.2015
V minulosti bylo místo seznamu položek připuštěno použití rovnítka s významem všechny
položky. Nyní lze tento seznam zúžit např.:

=-cnaz-nazuct.

týká se instrukcí SPO, SUM, TBN a INS.

Ještě jsem se zatím neúspěšně pokoušel podpořit zaheslování souboru PDF. Problémem
je, že dle dokumentace je zapotřebí provést desítky! šifrovacích kroků (do jisté míry
nejasných) a k dispozici mám pouze správný výsledek 32 binárních čísel. Pokud se
neshodují s mnou vypočtenými, není jasné, ve které fázi došlo k chybné interpretaci.
*****************
15.07.2015
V rámci rýpaní se v threadech se již druhý měsíc pokouším (zatím dost neúspěšně) zajistit
současný chod WR a editoru spuštěného v samostatném okně. Je to v podstatě cvičení,
jak zajistit současný výstup do aktivního a neaktivního okna a vstup pouze do aktivního
okna.
*******************
26.06.2015
Trochu jsem se porýpal v dynamické definici vytvářené z XMLRDA. Lze nyní:

_mode di:100.
%zuz
ex.
rozvaha
(&Sender\IC,
ObdobiBezneNetto\Pokladna/PN,
ObdobiBezneBrutto) ak_bru
ObdobiBezneBrutto.
.se()
.co()
%
inf ak_bru

Ačkoliv např. IC a Pokladna je odkázána plně:

Envelope\EnvelopeHeader\Sender\IC
Envelope\EnvelopeBody\Message\MessageBody\RozvahaPO\Aktiva\ObdobiBezneNetto\Pokladna

lze zadat pouze jednoznačný konec řetězce. Lze položce z XMLRDA zároveň přiřadit i
nový název - zde PN. Lze zadat i jméno uzlu (zde ObdobiBezneBrutto) - v tom případě se
místo jména uzlu převezmou všechny existující listy uzlu - pokud uzel obsahuje i uzly,
ty se ignorují. U této testovací struktury obsahoval uzel cca 80 listů.
*******************
07.05.2015
Kvůli threadům je třeba držet číslo terminálu jako násobek 16. Podobně i v .termnum.
Opravena zřejmě letitá chyba, kdy po zadání .termnum xxx (původně yyy) v programu se
na konci chybně mazal redapxxx.tmp místo redapyyy.tmp a historie se zapsala do
atpxxx.his, přestože se načetla z atpyyy.his.
*******************
29.05.2015
Protože pip uměl rozbalit celý zip nebo konkrétní soubory, dodělána základní
hvězdičková konvence:

pip abc.zip=*.rda/dc
pip abc.zip=xyz.*/dc
pip abc.zip=*.*/dc - formalní, protože je totožné s pip abc.zip/dc

Ve VST protlačena práce nad neudržovaným indexem - dosud byl připuštěn pouze
udržovaný index. Lze tedy udělat konkrétní třídění a prohlížet a opravovat
věty. Nikoliv přidávat.
*******************
25.05.2015
Kromě jiného je wr584 nyní v oblasti myši pročištěna od MSDOSu.
*******************
18.05.2015
Používá někdo ve WR .disable mouse nebo znemožnění přímo v init5w. změnou + na -
na 20. pozici v řádku pro videorežim? Ono to funguje, ale ve Windows by to byl asi nesmysl.
*******************
17.05.2015
Zdá se, že .enable mouse|mcur|mshow|mcuronly jsou ještě přežitky z DOSu, takže
jsem z nich učinil prázdné akce a úvahy s tím spojené z kódu vymazal.
*******************
28.04.2015
Pokud by měl někdo nutnost začít komunikovat přes datové schránky, tak ing. Havel
z VoSa Znojmo dává k dispozici jakýsi program pod WR, kde komunikaci řeší.

Viz www.redap.cz/schranky.zip
*******************
27.04.2015
V TBN nový přepínač TM (test místa) pro údaje typu RV a RE v případě TT fontů.
Určíte-li formát 2 a přijde text WW, tak se do zadaného místa nevejde. V případě
přepínače TM se vytiskne pouze jedno W. V opačném případě můžemé mít řetězec
délky 10 a tiskneme z něj pouze 2 znaky. V případě "iiiiiiiiii" se vytisknou dva
znaky a prostor pro text je vyplněný pouze zpoloviny. V případě TM se vytisknou
místo 2 znaků čtyři "i".
*******************
26.04.2015
Editor v samostatném okně pro některá rozlišení měl poškozené zobrazení.
*******************
21.04.2015
Pro pole v RDA nebylo řešeno .test <relace>.<pole> - doplněno $poc1 nyní obsahuje
počet prvků pole.

ZMT s přepínačem CS (výstup do CSV) zajistí výstup všech prvků pole.
*******************
20.04.2015
Zkusil jsem natvrdo rožnout editor v samostatném winwin okně. Tzn., že se s okny
WinREDAPu a editoru dá samostatně šoupat.
*******************
17.04.2015
Před léty jsem umožnil pracovat v libovolné u nás přípustné codepage. I RDA mají
v sobě příznak codepage. Nicméně se mně zdá, že se to nijak neujalo a všichni
jedou v KOI08. Otázkou je, zda např. nezrušit tuto možnost v RDA. Tím by se
zjednodušil život pro .codpage 6; ZUZ(DBF v 1250)->RDA - RDA je ve 1250. Pak
.codepage 1 a ZUZ RDA->RDA teprve nyní je RDA v KOI08.
*******************
16.04.2015
Snad se to konečně povedlo, takže stav je nyní takový:

Po _mode th. se zapne možnost threadů.

Po .begin_thread se založí thread01.bak

Pak se normálně plní CMD, ale při procházení parametrů instrukce se tato
nespustí, ale její parametry se uloží do thread01.bak.

Po .end_thread se thread01.bak uzavře, spustí se výkonný thread, který
postupně spouští nastřádaně instrukce jako další thready. Originální
CMD po .end_thread pokračuje dál.

Nicméně se zdá, že práce s thready zatěžuje více systém, takže časy
na provedení testovacího příkladu nad nevelkými RDA se 150 instrukcemi
v thread01.bak jsou spíé větší jako při normálním jetí (stačí _mode th:0.).

Takže z toho zatím zdá se zůstává jediný efekt - lze spustit cosi na pozadí
a pokračovat okamžitě v CMD dál.

Přirozeně, pokud chcete mít jistotu před nějakým krokem, že je proces na pozadí
ukončen je nutno použít příkaz .wait_thr.
*******************
10.04.2015
Změna technologie je sice potřebná, ale v prvním kole se zcela nepovedla.
Po vyřešení různých problémů s pravděpodobností 50% se mně podaří bezchybně
provést skoro 150 instrukcí, ale dál tudy cesta nevede.

Nicméně i tato slepá ulička rozšířila moje nazírání na problém, takže doufám,
že ve druhém kole řešení problému s automatickou synchronizací treadů budu
úspěšnější.
*******************
31.03.2015
Změnil jsem zcela technologii pro vytvotření threadů - prakticky nulová
pracnost pro stávající úsek programu, ale narazil jsem u RAM disku, který
jsem z pochopitelného důvodu nemusil dělat síťový. Nyní se bez toho neobejdu,
takže to musím dopracovat.
*******************
Po úspěšném absolvování 114 kroků mohu konstatovat, že je tato část asi
funkční a mohu se věnovat zjednodušení algoritmizace chodu.
*******************
29.03.2015
Dost dlouho jsem se trápil s protlačením třídění RDA s volnou délkou věty
na RAM disku. Teď jsem konečně úspěšně dokončil 83 kroků.
*******************
27.03.2015
Konečně se zadařilo protlačit 72 instrukcí mezi .begin_thr/.end_thr.
Instrukce jsou vesměs TRI, IND, ZUZ a SPO, proložené občas .testfile.
*******************
24.03.2015
Do chodu na pozadí přidáno LST a OPT

Testy, kdy mezi .begin_thr a .end_thr je více jak 100 kroků (instrukcí) ještě
nedopadly O.K. Mám též filosofický problém s interpretací .wait_thr n. Tj.
čekání na ukončení posledních n threadů. Bude nutno to předělat tak, aby se
čekalo na něco konkrétního. Např. můžete mít za sebou TRI,TRI,SPO několikrát.
Potřebujeme čekat vždy na ukončení dvou třídění a SPO pak běží na pozadí
s dalšími tříděními. Pak obecně běží dvě SPO s dvě TRI, pak tři SPO a dvě TRI.
Po dosažení osmi threadů se musí čekat, až něco skončí a indexy posunout.
V tom okamžiku je otázkou na co se má čekat.
*******************
23.03.2015
q5:11 předpokládá úpravu obyčejných textů. Ne typu HTM nebo XML!

q5:22 převádí znaky pouze v oblasti "..." a >...<

q5:33 provádí opačnou změnu k q5:11 nebo q5:22 tedy < na < ap.
*******************
Protože se množí dotazy, jak převést znaky < > & ap. do tvaru vhodného pro XML
doplnil jsem

pip txt.htm=txt.txt/q5:11

Zůstává to ale v KOI!
*****************
19.03.2015
Doplnil jsem do threadu:

.testfile "<soubor>",t1,t2,t3,t4,t5

t1 - soubor neexistuje
t2 - soubor existuje a je volný
t3 - soubor existuje a je volný na čtení
t4 - soubor existuje, ale není přístupný
t5 - soubor je adresářem

za ti můžeme dát -1 - pak se .begin_thread/.end_thread okamžitě ukončí
nebo 0 - nic se neděje nebo n>0 - pak se přeskočí n následujících instrukcí.

.wait_thr n

čeká se na ukončení posledních n threadů.

Např.

.begin_thr
.testfile "uxx.rda",-1,0,0,-1,-1
pip ux.rda=uxx.rda
.testfile "uxx.rda",-1,0,0,-1,-1
pip uy.rda=uxx.rda
.wait_thr 2
tri ux|jm.
tri uy|jm.
.wait_thr 2
%spo
!
ux
uy
ux uyy
jm.
!
!
//
%
.end_thr
*****************
18.03.2015
Má cenu se zabývat rozšířením indikace v .testfile <soubor>? V případě návratové
hodnoty 2 mohou nastat dva případy:

1. Soubor je otevřen na čtení nebo aktualizaci a je ho tedy možno též číst nebo
aktualizovat.

2. Soubor je otevřen výhradně - obvykle, když se nově vytváří.

Nyní ale .testfile tento rozdíl neindikuje.
*****************
18.03.2015
V sekci za .begin_thr jsou připuštěny i jednořádkové tvary instrukcí a PIP. Ne copy!!
*****************
17.03.2015
Protože ti upadlo pokaždé při 51. cyklu, došlo mně, že jsem zapomněl uvolňovat
hlavičky alokované thready, takže posléze došly. Po opravě procházejí stovky cyklů.
*****************
15.03.2015
Snad je téměř dobojováno. Momentálně mně na pozadí běží 30-tý cykl ARI, IND, SUM
a 2x TRI - volná délka (interně IND neudržovaný index a pak ZUZ dle tohoto indexu),
pak se čeká před SPO. Než jsem to dopsal, na pozadí končí 40-tý cykl. Teď je na Vás,
abyste to, kdy není třeba čekat na výsledek nebo když po nějakém běhu se rožlo
nějaké menu, tak teď se může objevit hned. Než se uživatel rozhodne, jak dál. Na pozadí
se běh již dokončí.

Nicméně jsem si to přechválil. Při 51. cyklu to ještě upadlo.
*****************
14.03.2015
Stále mně při souběhu 5 threadů najednou to s pravděpodobností cca 15 % upadne. Tj.
ještě existují globální proměnné, které by měly být lokální pro každý thread. Je to
ale jako hledání jehly v kupce sena. V každém chodu se to díky asynchronnímu průběhu
threadů může nebo nemusí projevit a pokud se to projeví, tak pokaždé nějak jinak.
*****************
14.03.2015
Z výčtu instrukcí v threadu vypadlo TBN. Nicméně testy při výstupu do PDF ukázaly,
že je výhodnější za každým TBN dát .wait_thr. Tj. při paraelním chodu dvou TBN
dostáváme výrazně horší čas. Ještě se pokusím přidat instrukci SUM.

Nyní mají WR584 číslo v $term modulo 16, protože thready si musí vytvářet
disjunktní jména pomocných souborů. Takže hlavní program např. 704, první tread 705
atd. Veškeré výstupy threadů jsou potlačeny. Funguje pouze _mode xm, kdy se
chyby threadů zobrazují pomocí messagboxů.
****************
09.03.2015
Zkusil jsem:

copy uxx.rda ux.rda
copy uxx.rda uy.rda
copy uxx.rda uz.rda
copy uxx.rda ua.rda
;'$dt%d21'
.begin_thr
%ari
ua
vm=0
//
%
.wait_thr
%ind
uz
uz.y00
jm.
;
%
.wait_thr
%tri
ux
jm.
%
.wait_thr
%tri
uy
jm.
%
.wait_thr
%spo
!
ux
uy
ux
jm.
!
!
//
%
.end_thr
.wait_thr
;'$dt%d21'

a trvá to 16.4 s. Když vyhodím první tři .wait_thr, tj. běží ARI, IND a 2X TRI současně, pak
to trvá 9.4 s. PC s dvoujádrovým procesorem. Zatím navrženo na maximálně 8 instrukcí
současně. Přirozeně před SPO musíme počkat, aby vstupní soubory byly dotříděny!

Vzhledem k tomu, že mám cca 800 globálních proměnných, o kterých nemám tušení, zda
si v nich paraelně běžící instrukce nekolidují, bude třeba toto experimentálně ověřit na vašich
programech. POZOR! v rámci .begin_thr/.end_thr nesmí být žádný příkaz ATP!

Z instrukcí lze zatím pouze ARI, ZUZ, SPO, TRI a IND. Interně se to nyní chová tak,
že po příkazu .begin_thr se zahájí čtení se substitucemi do interního souboru až po
.end_thr. Pak se spustí výkonný thread nad tímto souborem a ten postupně spouští
instrukce ze souboru a čeká při příkazu .wait_thr na ukončení všech paraelně běžících
threadů (maximálně 8).

Po spuštění výkonného threadu ATP pokračuje v plnění programu.
*******************
03.03.2015
Pro představu o co usiluji a je zdá se již funkční:

.;Start sestavy na pozadí
.begin_thr
%tbn
ux
ar,po,pf,lp. tbn1.pdf
!
0 60
1 0 1 1
!
.se(jm "ji")
.co(ico=qa; qa+=1)
.co()
$
ico;jm r$
$
%
.end_thr
.;Okamžitě se objeví menu
.MENU:
_mode bg.
!.bigmen(1,dp|r1|pv|mx|rm:1,-1,-1,16,1000,"aaaa","bbbb")
"Pořízení "
"Sestava "
.askn n
.;Okamžitě můžeme pořizovat
.if(n==1)
.begin
%vst
!
uziv
.pr(pc;jm r;)
/
$
%
.goto MENU
.end
.;Tady se eventuálně čeká na pořízení předchozí sestavy.
if(n==2)
.begin
.wait_thr
.begin_thr
%tbn
ux
ar,po,pf,lp. tbn2.pdf
!
0 60
1 0 1 1
!
.se(jm "ji")
.co(ico=qa; qa+=2)
.co()
$
ico;jm r$
$
%
.end_thr
.goto MENU
.end
.;Okamžitě po ESC se nemusí skončit - interně .wait_thr
******************
01.03.2015
Protože se uživatelský teploměr pral s teploměrem při čtení souborů, učinil
jsem úpravu v tom smyslu, že .disable toolbar odstřihne systémové zobrazování
polohy v souboru a umožní pouze explicitní zobrazení pomocí .show_bar.
Takže posloupnost příkazů musí být pro indikaci v okénku:

.winw(10,10,3,52,<200'fnt%2'>,<200>,"","")
.disable show_bar
.init_bar '$wpr+$wfb'#,'$wps'#,50,,<372>,0
.show_bar -max !inicializace maximální hodnotou
...
.show_bar n !nastavení teploměru na 50*n/max kostičku

fnt je font nápovědného řádku.
******************
27.02.2015
S formálními úpravami zatím končím (ubylo cca 60 kB což je cca 1.5 % ze
všech kódů WR). Pokouším se o reentranci podmínek a aritmetiky v instrukcích.
Jinak by nejelo reentrantně ani TBN a ZUZ.
******************
24.02.2015
Série drobnějšich úprav zasáhla ještě 110 modulů.
Doufám, že wr584 dělá vše, co uměla před úpravami.
******************
24.02.2015
Protože se ukázalo, že zbytečné odkazy "extern" v kódu C++ mohou u threadů
škodit, provedl jsem vyčištění zdrojů částečně ručně a částečně pomocí ATP.
Celkem to zasáhlo 270 modulů z 590 možných.
******************
23.02.2015
Ještě provedena kontrola na PC s Core 2 DUO a opět 2x normálně sestava 32 s
a 2x současně ta samá 39 s, takže skutečně má smysl uvažovat pouze o tisku
na pozadí jednotlivých sestav - omezí se čekání před dalším krokem.

Na debug wr584 (pomalejší) a PC s Atlonem to dělá současně 63 s, po sobě na
pozadí 36 s a 2x na popředí 34 s. Z toho vyplývá, že na pozadí je nutno spouštět
sestavy postupně.
******************
22.02.2015
Po několikadenním úsilí musím konstatovat, že nelze na jediném otevření
souboru číst současně ze dvou threadů i když to není nic zvláštního.
Když soubor otevřu dvakrát, jede vše O.K. I když jsem zamknul operace
"Nastav bajtovou adresu"+"+Přečti bajty od adresy", stále si thready do čtení
nějak kecají.
******************
Zatím stále paralelní tvorba sestav nic moc 2x TBN současně 64 sekund, 2x
TBN normálně za sebou 46 sekund. Tedy stále to vede spíše k dokončovacím
nebo přípravným operacím, aby se náběh nebo pokračování dalšího
kroku zbytečně nezdržoval.
******************
18.02.2015
Mám počítač s AMD Le 1300 Manila, který se dá přepnout v Biosu na
Atlon II X2 4400e - tedy dvojjádrový procesor. Nicméně po přepnutí se
mně řada věcí zpomalí. Je to ale pro dolaďování souběžných procesů
nepostradatelná věc. To co běží krásně na jednojádrovém procesoru
se pak zhroutí na dvoujádrovém procesoru a je třeba hledat, kde paralelismus
škodí. Objevit příčinu problému není jednoduchá věc.

Teď například hledám již třetí den příčinu, kdy dvě paralelní sestavy do PDF
neprojdou - jedna se vždy předčasně ukončí na chybu čtení. Pokud uzamknu
čtecí rutinu od začátku do konce čtení, je vše O.K. Nicméně na první pohled
to musí běhat paralelně bez uzamčení, takže někde nevidím jakousi globální
proměnnou, kteru si paralelní procesy vzájemně přestavují.
******************
15.02.2015
Po značném úsilí a přesunu desítek globálních proměných do lokálních
proměnných jednotlivých threadů se zadařilo spuštění současně dvou
TBN s výstupem do PDF. Aby to bylo na mém nepříliš nadupaném PC
měřitelné, každý chod TBN vytvářel sestavu 1300 stran. Solo cca 19 s.
Najednou 46 s, takže úspora žádná. Procesory dohromady jedou na 50%,
při solo úloze jeden na 100% a druhý skoro na nule.

Nicméně bude vhodné sestavy spouštět na pozadí. Teď jsem třeba zkusil
pustit jedno třídění a dvě sestavy současně na pozadí. Aby to mělo smysl,
budu musit dodat mechanismus, kdy zřetězená akce nezačne dříve, než
se dokončí předchozí akce. Pak třeba 3 třídění pro sestavu, která počká
na dokončení všech třídění. Přirozeně hlavní CMD musí pokračovat
okamžitě dál.

Po .enable cache třídění na pozadí podle očekávání zhavaruje. Subrutina
pro kešování není zatím na mutitasking upravená.

Faktem je, že ve většině případů na lokále jsou takové úvahy zbytečné. Např.
zmíněná sestava PDF při výstupu s přepínačem SP místo FP trvá i 2x na pozadí
něco přes 1 s a za tu dobu se vygeneruje 2x 900 textových stránek sestav.
******************
13.02.2015
Podařilo se nejjednodušší sestavu spustit 2x na pozadí pomocí:

atbn(1,"tbn1.cmd")
atbn(2,"tbn2.cmd")
.wait_thr
dir tbn1.lst
dir tbn2.lst

Kde tbn1.cmd a tbn2.cmd odpovídají spuštění "tbn @tbnx.cmd". Např.
tbn1.cmd je:

ux
ns,so. tbn1.lst
!
0 100
1 0 1
!
$
jm r$
$

Po protlačení složitějších sestav by TRI a TBN na pozadí mohly stačit pro
využití většiny asynchronních možností v uživatelských CMD.
******************
12.02.2015
Protože obecně jsem teoreticky připustil spuštení až 10 threadů najednou, bylo
by dost obtížné konstruovat smyčky na čekání všech threadů, které mohou
končit v nahodilém pořadí. Proto jsem ještě zavedl příkaz

.wait_thr

který zajistí pokračování CMD až po ukončení všech threadů.
******************
12.02.2015
Po postupných víceméně formálních úpravách 190 modulů z celkových 600, se zdá,
že třídění volné délky věty současně na popředí a na pozadí konečně funguje.
Obtížnost těchto úprav spočívá v tom, že TRI volné délky věty interně volá
IND na neudržovaný index a IND přirozeně třídění a pak se volá interně ZUZ,
kopírující dle neudržovaného indexu původní RDA do nové kopie RDA. Všechny
tyto akce se mohou v libovolném okamžiku paralelně protínat v závislosti na
přepínání či paralelní práci procesorů ve Windows systému.
******************
07.02.2015
Na webu atri() ve WR584 nefungovalo. Po delší době jsem zjistil, že musím dát
na jedno místo zpoždění. Po debugem nebyl předtím žádný problém.

?? mám se s tím dále zabývat. Budete mít pro to využití? Na první pohled to
vypadá, že na víceprocesorové mašině jedou dvě třídění jako jedno, a sice to
s delší dobou třídění.

Nicméně je to dosti pracné. Např. sort v prvním kole po formálních úpravách
přestal správně fungovat, takže jsem to zahodil a jel to ještě jednou s kontrolou
po každém dílčím kroku úpravy. Pro představu tam bylo cca 30 proměnných
mimo stack pro komunikaci mezi cca 10 moduly. Ty se musily přesunout v hlavním
programu do stacku a předávat tento stack všem podprogramům. Pak nahradit
všude např. ahh řetězcem s->ahh a přirozeně opravit všechny prototypy modulů.
******************
Jedou i dva thready současně:

.enable quiet
copy w.rda wx.rda
copy w.rda wy.rda
;'$dt%d21'
atri(1,"wx.rda","jm.")
atri(2,"wy.rda","jm.")
.do()
.test $thr 1
.if($filerr==0)
.begin
.test $thr 2
.if($filerr==0) .break
.end
.pause 1
.end_do
;pres thr '$dt%d21'
******************
06.02.2015
Po značně náročných a rozsáhlých úpravách se mně podařilo procpat
třídění (pouze pevné délky) na jednoprocesorovém stroji na pozadí.
Na dvouprocesorové mašině to občas padne - reentrance není ještě
zcela O.K. Nicméně třídění na pozadí tam a zpátky dá 13.8 s, normální
třídění 13.7 s a současně TRI + pozadí tam a zpátky 13.7 s a ne 27 s.
Měřeno na dvouprocesorové mašině.

Nejvíce práce dalo upravit rutinu sort na reentranci - současně vlastně
třídí dva soubory tak jak ji to taktuje operační systém - chvíli jeden
soubor a chvíli druhý - obecně to přepne na nějaké vnitřní instrukci
sortu.

Zatím to trápím takto:

u:="wy.rda"
n:="jm."
atri(1,"wy.rda","jm.") <*start pozadí*>
tri wx|jm. <*start normálního třdění*>
.do()
.test $thr 1 <*ev. čekání na ukončení pozadí po ukončení tri*>
.if($filerr==0) .break
.pause 1
.end_do
******************
05.02.2014
Tak nejen Norton, ale nyní i Kasperkyj antivirák hlásí u WR Trojského koně.
******************
03.02.2015
Pokouším se zprovoznit asynchronní třídění, tj. spustit třídění
a pokračovat v CMD. Po čase se zeptat, zda je setříděno, aby se
mohlo pokračovat, pokud má být pro pokračování CMD splněna podmínka
setříděnosti tříděné tabulky na pozadí.

Je to dost náročný zásah, protože moduly musí být reentrantní, což
zatím být nemusilo. Pokud se to povede, pokračoval bych IND a na
pozadí pro TRI a IND musí být pro volnou větu i ZUZ.

Pak by se asi hodilo i TBN.

Pro víceprocesorové PC by to znamenalo časovou úsporu, protože každý
thread je obsluhován jedním procesorem. Bylo by to jako zpracování
dvou úloh paralelně. ?? zda nepovolit několik asynchronních akcí
najednou, tj. více jak dvě.
******************
02.02.2015
Může se hodit zašedit neaktivní formulář VST

qa+=vst(1002,1) <* zašeď formulář běžícího VST*>
qa+=call("VST") <* spusť proceduru VST *>
qa+=vst(1002,0) <* po ukončení procedury VST obarvi formulář *>
******************
02.02.2015
??? prý Norton antivirus dělá někdy z wrxy.exe nulový soubor.
Dá se tomu nějak zabránit?
************* ****
29.01.2015
Vytvořen příkaz

winwin(Čwokn,Mř,Ms,Pmř,Pms,"<Nadpis okna>")

který vytvoří klasické windows okno, které je ale formálně
zařazeno do seznamu oken. V tomoto okně lze tedy pokračovat
v definici běžných oken nebo zde spustit víceformulářové VST .

Zatím jsem zkoušel 1. winwin() na VST a v tom v PTB vyvolat
proceduru, která vytvoří 2. winwin() a v něm spustí závislé
VST. 1. winwin(0 se tak stane neaktvní, dokud neskončí 2.
VST. Ukončovací křížek winwin() oken vydá pouze ESC.

Na webu wr584d.zip jako plnohodnotné síťové demo časově
omezené do 30.6.2015.