Home


Aktualizováno 17.11.19 16:46:33
****************
16.11.2019
Teď jsem se dostal k práci s adresáři. Takže jedeme všechno .enable long_name2
a zapomeňte, že někdy existovala jména souborů 8.3.
.next je jako .nextn a tak se vrátí jméno souboru a vždy v lname je jeho úplné
jméno (tj. disk/adresář/jméno) a zachová se transkripce jména z adresáře.
Takže se může vrátit a.RDA nebo A.rda atp. Doposud jsme byli zvyklí na pouze
velká písmena.
****************
10.11.2019
Je to jako kdych se znovu učil mluvit. Musím krok po kroku oživovat funkce (zatím
v ATP). Ve většině případů se jedná o formální změny. ale existují místa, kde se dost
zapotím. Hlavní problém je v tom, že kód vznikal 30 let a poločas rozpadu mám
pouze pár let. Přitom přirozeně musím držet zpětnou kompatibilitu.

Dnes například jsem rozchodil .global, .call do subroutiny s parametry, jednodušší
.if a v poslední řadě indexy u textových proměnných. Kromě možnosti pracovat v UTF16
ale nevzniká žádná přidaná hodnota.

Do verze WR588 se soubor v UTF16 převedl při čtení do KOI08 a nyní se KOI08 při
čtení převede do UTF16 a UTF16 se zachová.
****************
31.10.2019
V rámci přdělávání na UTF16 jsem narazil v menu na rekonstrukci menu z obrazovky.
To vyžaduje režim T, který již moc nepodoruji a mám pocit, ze je to dnes slepá větev.
Pokud to ještě někdo používá, ať se ozve. Jinak to v menu zlikviduji.
****************
23.10.2019
Po přebušení 111 podprogramů jsem uspěl s komentářem:

spouštění wrxxx tst

a v tst.cmd bylo

;Ahoj

Na první pohled je to jednoduchá pitomost, ale před tím jsem musil zvládnout
načíst init5w., font5w. a prn5w., dále naplnit parametry přes parse p0-p9 a
provést detekci příkazu ; a jeho interpretaci. Vše na dvoubajtovém textu vstupů
a dvoubajtových jménech souborů.
****************
18.10.2019
Dal jsem se do šíleného projektu - celý WR pojede v UTF16 včetně souborového
systému (ve Windows jsou jména souborů uložena v UTF16!). To znamená, že
by bylo možné např. jako komentář mít v textu češtinu, ruštinu a finštinu nebo
tento hybrid mít jako jméno souboru.

Přirozeně změna komunikace místo bajtově orientovaného vstupu a výstupu na
dvoubajtový (UTF16 - každý znak dva bajty) znamená spíše tisíce než stovky
změn v stávjícím kódu.
****************
17.09.2019
Ve WR byla dosud práce s jedním clipboardem. Nyní jsem učinil pokus to změnit.
Ctrl C resp. Ctrl O a Ctrl V funguje jako dosud. Přibylo ale

Ctrl - (numerické!) - vyčisti clipboard
Ctrl + (numerické!) - přidej další blok do clipboardu (max 9)
Ctrl * (numerická!) + cifra 1-9 - vlož n-tý blok z clipboardu

Přirozeně místo Ctrl- & Ctrl+ lze pouze Ctrl C resp. Ctrl O. Pak Ctrl+
přidá druhý blok.

POZOR!!! Mimo WR dá Ctrl V všechny bloky a ne první!
****************
06.09.2019
Připomínám, že kalkulačka ve výrazu likviduje před výpočtem všechny mezery.
Na návrh ing. Tesaře je nyní výsledek též uložen do clipboardu.
****************
27.08.2019
V rámci odstraňování nedodělků jsem připustil v OPT řetězcovou položku.

%opt
ti,id,ar.
uziv
.co(q[1]:30:="ahoj" )
pc q[1]
en
pc
ahoj
Tiskneme q[1]
;
%
****************
Ještě jsem do toho hrábl, takže po aplikaci funkce sum je také:

$strlen - počet vyhovujících vět
$poc1 - minimální hodnota
$poc2 - maximální hodnota

Připomínám, že i ve VST lze tyto hodnoty získat:

.put $key,13
%vst
!
c:\e\eki\prodej
pc r$
pc
/
$
.bpr
.co(qg=sum("c:\e\eki\prodej","fak","uhr 1.1.2019/31.12.2019 ;")
qi=[$strlen]
qj=[$poc2])
.pr(xy 10 10; qg 0 r ; xy 11 10; qi 0 r ; xy 12 10; qj 0 r ;)
.epr
/
$
%

******************
17.08.2019
Po dokončení funkce sum jsem si uvědomil, že by bylo škoda funkci
omezit pouze na VST a tak jsem přidal zobecnění:

sum("<relace>","<položka>","<podmínka>")

takže příkládek vypadá takto:

.put $key,13
%vst
!
c:\e\eki\prodej
pc r$
pc
/
$
.bpr
.co(qg=sum("c:\e\eki\prodej","fak","uhr 1.1.2019/31.12.2019 ;"))
.pr(xy 10 10; qg 0 r ;)
.epr
/
$
%

Obecně lze tedy sečíst nyní cokoliv z jakékoliv tabulky i v ATP:

n=sum("c:\e\eki\prodej","fak","uhr 1.1.2019/31.12.2019 ;")
;'n'
*******************
17.08.2019
Možná, že se vám bude hodit funkce SUM (pouze VST) ve tvaru:

sum("<položka>","<podmínka>")

která vrací součet všech hodnot položky z vět hlavní tabulky, které splňují
zadanou podmínku. Testoval jsem na příkládku:

.put $key,13
%vst
!
c:\e\eki\prodej
pc r$
pc
/
$
.bpr
.co(qg=sum("fak","uhr 1.1.2019/31.12.2019 ;"))
.pr(xy 10 10; qg 0 r ;)
.epr
/
$
%

*******************
17.07.2019
V rámci SFTP zjištěno, že ne všechny servery ctí UNIX a tak nově založený
adresář neobsahuje soubory "." a ".." a ani nevrátí počet prvků 0, ale
hlášku "There are no more files". Na základě tohoto zjištění upraveno SFTP
a pro usnadnění práce je v $poc1 počet prvků adresáře.
*******************
11.07.2019
SFTP po chybě se vracelo nestandardním způsobem - nenahazovalo systémovou
chybu WR. Upraveno a doplněn chybník - viz web.
*******************
17.06.2019
Dnes jsem řešil problém v EET s chybným PKP pro nulové tržby. V tvorbě PKP
je použit chybně formát n2 (pro nulovou hodnotu dává dvě mezery). Opravte si
"n2" na pouhé "k". Vypadá to, že nulové tržby se zatím neposílaly.
*******************
29.05.2019
Ve wr588 jsem upravil INF tak, že u virtuální tabulky lze hledat i v podřízených
tabulkách. Ne, že by to příliš k něčemu bylo, spíše se jedná o symetrii jazyka.
Když byla připuštěna podmínka na celou virtuální tabulku, tak hledání
se realizovalo chybně na bloku dat z hlavní tabulky.
*******************
29.05.2019
Dostal jsem na stůl pokračování story s hledáním podle ? v INF ve virtuální
tabulce. Vtip spočívá v tom, že podmínka je řádně zvirtualizována, ale aplikuje
se na blok informace z hlavní tabulce - nikoliv na zvirtualizovanou větu.
Podmínku tedy lze klást pouze na hlavní tabulku, což licence s ? nedodrží.

Zatím jsem ve wr587 zakázal při ? + INF pokračovat na připojené tabulky. Mějte
ale na paměti, že v INFu nelze klást podmínky na podřízené tabulky!!!
*******************
28.05.2019
Na základě reklamace na funkčnost SFTP byly provedeny četné úpravy algoritmů.
Nicméně musím kostatovat, že se jedná o první reálné použití SFTP.
*******************
21.05.2019
Protože se mně letos již 2x dostal na stůl problém s XML kódovaným UTF16,
ale little endian - Unix, což jsem v XML nakonec připustil, je otázkou,
zda v PIPu v převodu do UTF16 big endian, nepodpořit i tu Unixovou verzi.
To by mělo smysl, pokud by váš zákazník požadoval data v tomto kódu.
******************
20.05.2019
Průběžně odstraňuji problémy, které mně přicházejí na stůl. Dá se říci, že
jsou to většinou idividuální problémy, na které s největší pravděpodobností
nikdo další nenarazí. Spíše narazí, že při opravě něco dosud funkčního poškodím.

Spíše kuriozní problém se mně dostal na stůl, kdy hledání podle identifikátoru
? (nikdy jsem to osobně nepoužil) se nacházely věty, které podmínku
nesplňovaly. Studiem kódu jsem zjistil, že hledám ve všech textových položkách
podle jejich délky, takže vzor "N...." v jednoznakové položce o obsahu "N"
zabral! Po letech jsem tedy provedl opravu v tom smyslu, že prohledávám
pouze položky o délce větší nebo rovné délce vzoru. Kuriozní na tom
je, že to minimálně 10 let nikomu nevadilo (ani tomu dotyčnému).
*******************
08.04.2019
Při ZUZ z XMLRDA do RDA a přepínači EX fungovalo bez problému přejmenování
položek ve vstupní relaci. Zprovoznění dosazovacích příkazů ale v tomto
případě nepomohlo. PTB s přepínačem OV běží nad hlavní větou a přepínač
OZ běží nad subvětou, takže se moc nepotkají. Z tohoto důvodu jsem musil
zprovoznit práci s pomocnými číselnými i textovými položkami, které
doposud nešlo používat. Nyní tedy lze v sekci OV naplnit pomocné proměnné
ze společné části vět a v sekci OZ z nich plnit vhodné položky výstupní
RDA.
*******************
05.04.2019
Konstatoval jsem, že nešlo na pravé straně aritmetického příkazu uvést
položku z XMLRDA. To se podařilo protlačit. Dosud se to řešilo přejmenováním
v XMLRDA (obvykle v ZUZ) na jméno položky v cílovém RDA.
*******************
02.04.2019
XML nyní na základě úvodních znaků 0xff,0xfe detekuje UTF-16 formát
a akceptuje ho. Ještě pro UNIX UTF-16 detekuji obrácený gard dvouznaku.
*******************
18.03.2019
V podstatě ZIP pracuje s Huffman tree, které po stanovení optimálního zipu
zredukuje na řadu bitů tak, aby se dal strom zpětně v UNZIP zrekonstruovat.
Kdoby čekal, že budou kódovat třeba rětězec "bookstore\book", ten by se
šeredně zmýlil. Vtip spočívá v tom, že v bitových povelech je "COPY" a tak
se nejprave na začátku bookstore\book znak po znaku zrekonstruuje a pak se
řekne kopíruj n znaků od tohoto místa na další místo výskytu řetězce.
*****************
16.03.2019
Pokouším se porozumět zipování souborů. Původní předpoklad, že ZIP obsahuje
jakousi knihovnu zkratek + bitový záznam dle této knihovny vzal rychle
za své. Např. text:

bookstore
bookstore\book
bookstore\book\category
bookstore\book\date
bookstore\book\year
bookstore\book\price
bookstore\book\ntitle
bookstore\book\ntitle\lang
bookstore\book\title
bookstore\book\title\lang
bookstore\book\author
bookstore\book\author\name
bookstore\book\author\age

se zakóduje 87 bajty (originál 294 bajtů), ale v těch 87 bajtech nenajdete
žádné písmeno z originálu! Zatím jsem v místech (unzip), které jsem pochopil,
přepracoval jako obvykle původní kód s významnou redukcí.

Na počátku jsem zkusil zipovat po svém. Kromě značně dlouhému času zipování
bylo výsledné zkrácení originálu víceméně žalostné vůči originálnímu ZIPu.
*****************
08.03.2019
POZOR: ing. Polida z Ekosoftu mně sdělil, že jakýsi podnik dostal od finanční
správy pokutu za to, že čas v zaslané transakci byl o 1 s před jejich časem.
Protože hodiny v PC se synchronizují cca 1x týdně, doporučuji u transakcí
ubrat pár sekund oproti času v PC.
?? Jestli bych to neměl udělat ve své režii při výrobě časového razítka v EET.

Protože voláme eett(0) - dal jsem parametru význam eet(-3) couváme o 3 sekundy.
Ošetřen i přestupný rok a couvnutí např. za 2020-01-01T00:00:00.
*****************
28.02.2019
Takže všechno zpět, .TESTHTTP/.READHTTP funguje postaru, protože problém byl
v tom, že uživatel odkazoval na soubor tak, jak ho viděl FTP přístupem
v TotalComanderu a ve skutečnosti se úvodní adresáře mimo FTP nesmí uvádět.
*****************
27.02.2019
Dnes jsem dostal příklad na .TESTHTTP, kde ve jménu serveru byly dvě přípony.
Např. www.xxxx.hys.cz. To používaná rutina v API neskousla. Proto jsem použil
metodu z .HTTPS, převedl textovou adresu na IP adresu a tu použil v .TESTHTTP
a .READHTTP. Takže teď dvě přípony projdou.
*****************
27.02.2019
.test $flg nezobrazoval nahozené X a Y u M3 a K a W u M4. Dodělal jsem to.
*****************
19.02.2019
Pevnou linku na chalupu jsem zrušil, takže si číslo 469 67 63 74 vymažte.
*****************
19.02.2019
Dnes jsem dostal dotaz, jak zjistit poslední znak řetězcové proměnné
v instrukci. Po chvíli bádání jsem naprogramoval

%zuz
uziv
uziv u
;
q[1]:30=ce(jm,2)
zav:=cu(q[1],30,1)
//
%
inf u

za předpokladu, že jméno ma 30 znaků.
*****************
05.02.2019
Do GRD přidán po startu implicitní režim - Minimalizace šířky sloupců.
*****************
06.02.2019
Nyní místo

desif /hnazdar a.sif a.txt

lze

pip a.txt=a.sif/dt:nazdar

V důsledku rozšíření funkcí PIPu, byl prográmek sifr.exe zrušen.
*****************
04.02.2019
V prvním kolem jsem zrealizoval:

pip zip.zip=abc.txt/cm:nazdar

což se rovná příkazům

pip zi.zip=abc.txt/cm
sifr /hnazadr zi.zip zip.zip

takže na straně příjemce je třeba:

desif /hnazdar zip.zip zi.zip

a zi.zip je normální zip soubor.

Místo

sifr /hnazdar a.txt a.sif

lze nyní

pip a.sif=a.txt/st:nazdar
*****************
04.02.2019
Vyskytly se dotazy na možnost šifrovat soubory tak, aby příjemce nemusil
mít REDAP. Vyřešil jsem to vytvořením dvou 32 bitových prográmků

sifr.exe
desif.exe

běží pomocí příkazového řádku

sifr /h odkud kam - na heslo se to zeptá

sifr /h<heslo> odkud kam - použije <heslo>

desif se ovládá stejně a pouze ten pošlete příjemci!
Vše v www.redap.cz/sifr.zip
*****************
01.02.2019
Program:

odbcadd "Microsoft Excel Driver (*.xls)","DSN=tmp","DBQ=nazdar.xls"
%zuz
{{tmp[;;;?$]#6}}
(=) LISTY.rda
.se()
.co()
%
inf listy.rda

proběhne normálně i když soubor nazdar.xls neexistuje. Zkoumáním,
proč se nehlásí chyba jsem zjistil, že při otevření v ZUZ generuje ODBC
driver zřejmě prázdný nazdar.xls, který pak po uzavření zmizí.
Pravděpodobně příprava na eventuální zápis do založeného souboru.

Proto jsem přidal do odbcad test na existenci souboru za DBQ=.
*****************
16.01.2019
Převody .codepage 8 a 9 do KOI jsou v CSV, obráceně v ZMT, obousměrně
ve funkci conv() a v PIP. Je třeba 8 a 9 ještě někde zrealizovat?
*****************
06.01.2019
Protože upravený DIFF se v jedno případě choval podivně, hledal jsem
příčinu. Ve WR587 jsem to opravil, ve WR588 zcela předělal.
*****************
05.01.2019
V návaznosti na práci s typem HM zavedena funkce HM(hh.mm) umisťující
do položky typu HM čas hh.mm např.

hm=HM(11.58)

takže není nutno psát

hm=11*60+58
******************
Protože "Poznámkový blok" akceptuje i Unix UTF16 (zápis big endian)
tj. sudé a liché bajty jsou přehozené vůči Windows, WR588 to též
nyní nevadí - může být big endian i little endian. Podmínkou je, aby
soubor začínal standardním 0xfffe nebo 0xfeff.
26.12.2018
V ZMT připuštěn seznam identifikátorů s přejmenováním
pro přepínč cs:2.

%zmt
od:59,cs:2,q5:16.
uziv.csv
uziv
.bco
qa=100
.if(pc>100) q[01]:30:="Ahoj" .else q[01]:30:="Nazdar"
.eco
.se(pc<1000)
pc/"Pořadové číslo",jm/"Jméno",qa/"Počet",q[01]/"Pozdrav".
%
.codepage 6
edi uziv.csv

Je vidět, že lze plnit i pomocné proměně qa,qb,... i q[01],q[02],... a jejich
obsah přenést na výstup CSV. Část výstupu:

82;Ing.Václav Koryta;100;Nazdar;
85;Ing. Jan Kudrna;100;Nazdar;
89;Pan Petr Kříž;100;Nazdar;
92;Ing. T. Kellner;100;Nazdar;
106;RNDr. Václav Škarka;100;Ahoj;
108;Ing. J. Straka;100;Ahoj;
171;Ing. Jaroslav Apolín;100;Ahoj;
195;Ing. Josef Julina;100;Ahoj;