Home


Aktualizováno 17.07.19 16:01:51
*******************
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;