Home


Aktualizováno 14.05.23 08:12:21
*******************
14.05.2023
Vážení uživatelé, pokud chcete zabavit děti nebo vnoučata, zkuste si stáhnout
TETRIS.ZIP. Zkusil jsem a pak se podíval na střeva CMD vzniklých před 20 lety
a jsem nucen konstatovat, že bych to dnes asi nedal.
*******************
20.12.2022
Ve Windows byla opuštěna maximální délka souboru 260 znaků. To nám působilo
problémy. Proto byl doplněno automatické zkracování jmen souborů na 260 znaků.
To obecně může vést k problémům při kopírování souborů se jménem delším než
260 znakú.
*******************
02.07.2022
Dostal se mně na stůl problém s extrakcí části souboru pomocí .bopenw. Bohužel
tento příkaz otvírá soubor v UTF16. Nicméně příkaz .open8 místo .bopenw tento
problém řeší (.open8 je i ve starších verzích WR).

Vzhledem k tomu, že momentálně nepracuji na vývoji wr592, přenesl jsem do wr591
dvě věci. Za prvé v EDI ALT 8 zapisuje soubor v KOI08, soubory s příponou .BAT
zapíše vždy 8 bitově a za druhé v GRD přibyl režim et:4 generující interně vs,ak
a působící na klávesu Insert, která je vlastně po vs,ak původně nefunkční. Nyní
se dá s ní označovat a odznačovat věty stejně jako myší.
********************
02.04.2022
Rýpal jsem se v podmínkách ATP a nevím, zda odstranit nesymetrii v tomto smyslu:

u.ret re 6 0

a pak

.if(u.ret=="RE") je ano, když u.ret:="RE "

ret:="RE "
.if(ret=="RE") je ne - pro ano musí být .if(ret=="RE ") ...

nevím, zda by to způsobilo někomu problémy, kdyby

.if(ret=="RE") bylo také ano. A nevím, zda to vůbec někdy někomu vadilo.

Každopádně .if(ret=="RE ") by bylo stále ano.

U u.ret== se od zadu u vzoru ignorují nuly a mezery u ret nikoliv.
********************
28.01.2022
Od ing. Petráše mně přistál na stole problém s pádem WR590 s chybou 600. Zjistil
jsem, že to je legální přeplnění paměti díky velmi dlouhým souborům cca 30 MB a 150000
větami. Postupně jsem omezil kešování velkých souborů a docílil i rapidní zrychlení
celého relativně složitého běhu.

Poté jsem zkusil WR591 a zjistil jsem, že celý chod trvá cca 12x déle i po úpravách
provedených ve WR590. Postupně jsem našel problém v indikaci - omylem jsem vymazal
nepodmíněnou část a ponechal podmíněnou část. Pak jsem řešil problém dlouhé
odezvy při práci s řetězci. Další problém vyplynul z chybějící možnosti přejmenování
souborů pokud obsahovaly UTF16 znaky. To jsem v minulosti vyřešil kopírováním
ze starého jména do nového - což ovšem znmená dvojnásobný zápis. To jsem
rešil úpravou převodu na původní rename z API s tím, že relace musí mít jména
převoditelná do KOI. Nakonec jsem ještě našel problém v práci s keší.

Po těchto zásazích jede WR591 stejně rychle jako WR590. Vše se ovšem vyvrbilo
díky příkladu od ing. Petráše, protože pro malé RDA by si nikdo problému
s rychlostí nevšiml.
********************
05.12.2021
Ing. Petráš řešil problém nikterak nesouvisející s WR, ale protože problém byl v
tom, že na počítači po reinstalaci Windows10 program měl úplně špatně
diakritiku, napadlo ho, že vás o tom bude informovat, kdyby náhodou se
někdo na Vás obrátil s takovým problémem.

Divné chování bylo způsobeno tím, že po reinstalaci W10 bylo rovnou
zatrženo:

Beta: Používat Unicode UTF-8....

Nicméně jsme konstatovali, že ne všech verzích se taková otázka vyskytuje.
********************
31.12.2021
Především jsem se zbýval skutečností, že wr590 nevoněly 16 bitové CMD.
To se podařilo napravit. Takže nyní ve WR591 s init5w s +M5 se tvrdě
všechny soubory procházející editorem ukládají jako 16 bitové. S -M5
se ctí původní formát souboru.
********************
28.12.2021
Pokud se nechcete trápit s ručním řešením Sudoku, zkuste prográmek

www.redap.cz/sudoku.zip

v sudoku1.dat je zápis výchozí Sudoku - místo prázdných míst uveďte nuly.
Někdy výsledek není jednoznačný a je proto v dalším oběhu nutno zvolit
na nějaké prázdné místo jednu hodnotu z návrhu dvojic. Pokud to nebude
mít řesení, zvolte druhou hodnotu.
********************
28.12.2021
Když jsem již zabředl do toho dělení do sloupců, vyrobil jsem prográmek, který
čísluje na zadaný počet x řádků na stránce a zadaný počet y sloupců způsobem:
1. sloupec 1 až (x-1)
2. sloupec x až (2x-1)
3. sloupec a další analogicky

Na poslední stránce je obecně menší počet řádků xx a tak ta stránka je zkrácena
na xx řádků a sloupce jsou pak 1 až (xx-1), pak xx až (2xx-1), atd.
Pokud to někoho zajímá viz www.redap.cz/cisl.zip
******************
26.12.2021
Mírně jsem opravil nějaké odchylky v PIP a prověřil instrukci ROZ, kterou předpokládám
nikdo nepoužívá. Sestavil jsem si (dost pracně) příklad na vytištění uživatelů
do tří vedle sebe ležících sloupců. A to:

%roz
ov.
uziv>
(cel(cc:999:0),zb(cc:999:0)) NULL
!
cel=dv(q0-1,3,zb)
//
(=,sc(cc:999:0)) uziv1
zb 0 ;
uziv1.sc=cel
//
(=,sc(cc:999:0)) uziv2
zb 1 ;
uziv2.sc=cel
//
(=,sc(cc:999:0)) uziv3
zb 2 ;
uziv3.sc=cel
//
%
%opt
ti.
uziv1>
uziv2>
sc.
uziv3
sc.
uziv1.jm uziv2.jm uziv3.jm
en
Nadpis
;
%

Nevím, zda to někdo někdy použije.
******************
23.12.2021
Vzhledem k tomu, že stále častěji je ve Windows vypnuto zkrácené zobrazování souborů
8.3, množí se dotazy typu - WR soubor nezobrazí, průzkumník ano ap. To však neznamená
nic jiného, než že je vypnuto .enable long_name2 a WR tak jede v zobrazení 8.3, tudíž
se mu dlouhé jméno do formátu nevejde.

Proto jsem přidělal chybové hlášení pro tento případ, kdy v režimu 8.3 se objeví
dlouhé jméno a operace WR skončí s chybou. Doposud dlouhé jméno se přeskočilo.
******************
15.12.2021
Zkusil jsem rp(...) na řádek s nafukujícími se texty a rp to zvládl bez problému.
Nic se na konci neuřízlo. I zastyděl jsem se, že jsem byl v mládí chytřejši a opravil
jsem v tomto smyslo i rp0(...).
******************
Jinak se snažím postupně zlikvidovat 8 bitové texty a výpisy, pokud to není
nic proti ničemu. Výsledek není navenek nikde zatím vidět.
******************
Trochu mně vypeklo, že při rp0 roztahující původní řetězec se odřizne konec
řádku. Nakonec jsem zjistil, že je to správně - do původní proměnné se roztažený
řádek nevejde. Je tedy v takovém případě přidat na konec patřičný počet
mezer.
******************
Tak jsem si udělal radost a nevím, zda i někomu z Vás. Vytvořil jsem funkci rp0
s parametry jako rp, pouze s tím rozdílem, že poslední parametr je počet znaků,
od kterého začíná záměna a podstatné je to, že záměna se provede pouze jednou
a dál se nehledá.

Je to tedy funkce pro konkrétní řetězec - obvykle jeden řádek a rp0 v něm neudělá
takovou paseku, jako rp. Např.

s:=" 11 11 11 11 "
s:=rp0(s,"11","22",16)
;'s' bude " 11 11 22 11 "
******************
Na úpravu kódu jsem použil RP(...), nicméně problém je v tom, že nelze stanovit
odkud kam se má v textu nahrazovat. Cástečně jsem si pomohl rozdělením řádku
na dvě části, ale náhrada )) za ) zafungovala v první části třeba 2x. Musil bych
řádek rozděli na tři části s tím, že střed by obsahoval pouze upravovaný příkaz.
******************
11.12.2021
Pokračuji v uhlazování kódu wr591. Přidělal jsem si proto jakýsi doplněk
find a where v tom smyslu, že mohu hledat dva řetězce na jednom řádku. Řetězce
oddělím Ctrl B a pak najdu první část a pouze do konce řádku za úvodním
řetězcem hledám druhý řetězec. Možná se to může též někomu hodit.
******************
10.12.2021
Takže po dvou dnech usilovné práce, jsem nalezl cca 70 rutin, které se již
nepoužívají a přes 100 deklarací rutin, které nejsou nebo se nepoužívají.
Celkem jsem objem kódu zmenšil o cca 3 %. Musím se ale pochválit za schopnosti
ATP, bez kterého bych to nedal.
******************
09.12.2021
Začal jsem s čištěním kódu WR591. Odstarněním zakomentovaných řádků jsem vymlátil
100 kB dat. Bohužel jsem přišel i na letitou chybu v délce řetězcové proměnné
v případě, že dosáhla délky přesně 128. To jsem opravil i ve wr590.

Nyní se pokouším vyrobit programy v ATP na detekci podprogramů, které se nikde
nevolají.
******************
04.12.2021
Zrealizována nová položka KU, analogická KN, pouze s tím rozdílem, že akceptuje
texty v UTF16.
******************
29.11.2021
Zkonstatováno, že "pip <RDA>/df" nevypisuje knihovny jako "pip <RSD>=<RDA>/df".
Doplněno.
******************
29.11.2021
Zahájil jsem práce na nové položce KU analogie KN, která je ale pouze osmibitová.
Texty v KU budou 16 bitové.
******************
16.10.2021
WR591 je k dispozici všem, kteří mají WR590 - je nutno zažádat o wrset591.exe.
******************
10.07.2021
Opraven odkaz na dokumentaci wr590 (byl odkaz na wr591, která zatím neexistuje).
******************
02.07.2021
Počítám, že wr591 bude součástí letošního paušálu. Do WR590 nebudu s výjimkou
nějakých oprav ve druhé polovině roku zasahovat, ani nic přidávat.
******************
30.06.2021
Dostal jsem na stůl XML s obratem, který jsem ještě neviděl, nicméně zobrazovač
XML si s tím poradí:

<?xml version="1.0" encoding="UTF-8"?>
<start>
<abx a="xyz">Nazdar </abx>
<abc>Nazdar <cde>
ahoj
</cde>
</abc>
</start>

abx je standardní tvar, který umíme. abc je obrat, který neumíme.
<abc> text <cde> znamená, že text je hodnota abc, ale ukončení je
další úrovní <cde>. Prozatím by to vypadalo:

<abc>Nazdar </abc>
******************
27.06.2021
Vzhledem k tomu, že .readhttp přestává pomalu fungovat, udělal jsem v něm změnu,
že když volačka selže, spustí se automaticky .readhttps.
******************
25.06.21
Setkal jsem se s problémem, kdy vstupní tabulka byla DBF v kódu windows 1250
a v ZUZ bylo přiřazení "tx:=txt" - txt z DBF. V tomto případě se interně
položka txt překlopí do UTF16 a na výstupu do KOI08. Nedopadne to dobře pro
znaky s a z s háčkem. V tomto případě stačí dát do parametrů ZUZ q5:61.
Úpava je přirozeně zpětně kompatibilní.

Další problém jsem opravoval pro případ, že v kódu ZUZ bylo přiřazení

[atp]:=tx1
tx2:=[atp]

atp je nyní v UTF16 a do tx2 se v tomto kódu přenesla - chyběl přepis do KOI08.
******************
13.06.2021
Ještě zopakuji, že ATP pracuje 16-ti bitově - z KOI08 CMD čte pp řádcích a
KOI08 je převáděno na pozdí na UTF16, UTF8 soubory též konvertuje do UTF16 a přirozeně
UTF16 soubory čte přímo. V UTF16 ale nejsou návěští a jména proměnných. Jména
souborů se berou v UTF16 módu.

V druhé etapě jsou tiskové bloky XT/XO ponechány interně v UTF16, knihovny KN
z důvodů kompatibility jsou v KOI08. Z toho vyplývá, že tisk jede v UTF16 módu.

U EDI jsem potlačil prozatím zápis do UTF16, výsledek editace se píše po převodu
do KOI08. Obecně je již řadu let EDI v módu UTF16.

Celá akce byla značně komplikovaná a na první pohled nic nepřináší. Pro přechod
na mezinárodní abecedy je ale připravená.
******************
12.06.2021
Na webu je demo verze WR591D pro eventuální otestování na vašich CMD.
I když jsem odladil tisíce možností, tak bohužel disponujeme alespoň desetisíci
jiných možností. Proto si buď raději vytvořte zálohu dat nebo testy provádějte
na kopii vašich dat. V init5w si nastavte místo +M5 radějí -M5 - vypne se tvorba
UTF16 souborů. Za eventuální připomínky předem děkuji.
******************
Takže momentálně máme v KOI názvy proměnných, návěští a identifikátory
v RDA. Přirozeně i RV a RE kvůli kompatibilitě. XT a XO se překládají
v UTF16. Menu je nyní interně v UTF16. Celé ATP jede v UTF16. Takže
v 8 bitech toho již moc nezbývá.

Kromě odpovědí na vaše dotazy a řešení připomínek se v tom rýpu 1.5 roku.
Při tom doufám, že to bude zatím interpretovat správně CMD alespoň jako WR590.
*******************
08.03.2021
Zadařilo se ve wr591 uchodit NAK, HTM a CHM. HTM nyní generuje UTF16
kód a zdá se, že např. "start ..." to akceptuje. CHM nikoliv, generuje
proto pro překlad Windows 1250. V NAK a příručce se mně vyrojily navíc
řádky začínající ".;". Tj. jejich vypouštění v předchozích verzích
asi byla chyba.

Zabudoval jsem do WR591 i opravu ".if" v ATP jako ve WR589.
*******************
25.02.2021
Pokud jsem se vratil k wr56, pak výsledek byl 13.6/12.3, takže to dost
lítá. Navíc nyní je první % a pak @ind. Původní předpoklad, že @ind
je výrazně pomalejší tedy neplatí. Naopak u všech verzí je nejpomalejší
%. Zdá se, že při větším objemu dat se cache systému naplní a další
práce se tak zpomalí. Nicméně nedokážu vysvětlit, proč wr590 je daleko
nejrychlejší - např. 2x rychlejší než wr56.
*******************
25.02.2021
Nicméně pro úplnost k problému dodávám, že soubor má 16 MB a necelých
19 tisíc vět. Takže tvorba čtyřnásobného udržovaného indexu kolem
10 s na mém archaickém PC asi časově nikoho nemusí ohrožovat.
*******************
25.02.2021
Mírně jsem pokročil. Asi je to dáno cache systému. Pokud pořadí
obrátím, ind@ je sice pomalejší, ale ne tak drasticky. U wr589
9.7/8.3 a u wr590 dokonce obráceně 6.9/7.3. Pokud to zopakuji,
první čas se mírně zkrátí 5.2/7.5. Je to vše s přesností +-0.1 s,
takže 7.3 může být skoro 7.4 a 7.5 zase skoro 7.4.

Rozdíly v časech mezi verzemi mohou být dány i rozdílem
v konkrétním sestavení. Ještě se nad tím zamyslím, ale vzhledem
k tomu, že moduly kolem IND a TRI jsou letité, nevidím moc možností
k nějaké nápravě či změně.
*******************
24.02.2021
Teď mám na stole záhadnou chuťovku. Čtyřnásobný index vytvářený pomocí

ind @
a
%ind

je to v podstatě totožný kód, ale ne tak výpočetním časem:

WR56 11.7/11.7 s neliší se
WR588 12.1/11.9 s to by ještě šlo
WR589 8.2/7.4 s to se sice liší, ale je to rychlejší
WR590 21.2/13.9 s největší rozdíl a nejpomalejší

WR590 ale bylo ladicí - je vždy pomalejší, takže demo:

WR590 7.1/3.8 s je to fofr, ale stále dramatický rozdíl

Podotýkám, že CMD začíná .disable cache!
*******************
22.2.2021
V jakémsi mezičase jsem si sestavil wr591 po vypuštění cca 43 kB kódu (vypuštění
části prázdných procedur a náhradou 8 bitových procedur 16 bitovými v počtu 170
rutin). Jinak jsem zasáhl do cca 400 modulů z necelých 600.
Mohu konstatovat, že to moc zatím nechodí.

Faktem je, že zdánlivě drobný zásah způsobí rozpad kódu a ukáže se, že zásahů
musí být celá řada, než se linker uklidní a půl den je pryč.

Při tom vidím instrukce INS, ROZ, EDK, VSK, VSD, KON ap. Jestli pak to ještě
někdo používá?
*******************
19.02.2021
Zlikvidoval jsem cca 20 osmibitových rutin po náhradě 16 bitovou rutinou. Nyní jsem se
dostal do fáze, kdy likviduji prázdné osmibitové rutiny - bohužel se i ve wr590 pilně
na některých místech volají, takže z tohoto pohledu je WR590 nefunkční. Protože je
ve WR několik tisíc příkazů a funkcí, záleží na konkrétním CMD, zda se do nějaké
díry trefí. Nicméně se zdá, že v dohledné době budu musit z WR591 udělat WR590,
protože WR591 bude funkčnější.

Při této práci je problém, že zdánlivě prostá náhrada, vede k celé řadě úprav
v předcházejících voláních nebo následujících voláních, takže problémy doslova
kynou pod rukama.
*******************
16.02.2021
Pokračuji ve wr591 v odbourávání nepotřebných jednobajtových rutin po jejich náhradě
utf16 rutinami. Dnes jsem se i ve wr590 snažil rozchodit ZIP a ZPP, což se podařilo.
*******************
09.02.2021
Takže po několika tisíc úpravách a včera a dnes drobných opravách WR591 se zdá
docela chodivá. Nicméně mně čeká ještě dost zdlouhavý proces postupné likvidace
bajtových rutin a pokud jsou ještě někde k něčemu, pak jejich náhradou dvoubajtovou
rutinou.
*******************
02.02.2021
Přetypování short resp. unsigned char na wchar_t ve zdrojích WR vedlo k cca 5000
formálním chybám. Ty jsem postupně odstranil, a pak při linkování vyběhlo cca
200 neexistujících proměnných a podprogramů. Dnes jsem to stáhl na 10 případů.
Teprve v momentě, kdy se podaří WR sestavit, začne skutečné ladění a úprava
zdrojů.
*******************
29.01.2021
Vzhledem k tomu, že připomínky k wr590 víceméně utichly, zahájil jsem druhou část
(neméně obtížnou) a to tisk vést v UTF16 namísto dosavadního KOI08. Formálně
jsem zahájil změnu ve WR591, abych měl zatím alespoň něco funkčního tj. WR590.
*****************
28.01.2021
Uchodil jsem viz rusky.zip
*****************
18.01.2021
Pokud do EET pošlu účtenku v utf16, tak ji schrupne, ale odpověď vrátí v UTF-8.
*****************
17.01.2021
Zdá se, že přidáním ".codepage 6" na tři místa se vyřešily problémy s písmenky.
Aktualizaci www stránky nyní provedu pouze pomocí wr590, takže doufám, ze se to
povede!
*****************
16.01.2021
Zkoumáním, proč se kazí některá písmena při údržbě webové stránky pomocí WR590,
jsem došel k následujícímu výsledku:
Soubory HTML jsou ve Windows 1250, ale rozdíl mezi kódováním KOI08 a tímto nikde
není vyznačen. WR590 jede interně v UTF16 a tudíž si osmibitové soubory (předpokládá,
že jsou v KOI08) převede do UTF16. Pokud jsou ale ve Windows 1250, nedopadne to
úplně dobře - tuším, že písmena 'š' s 'ž' se změní.
Jedinou, relativně snadnou cestu, z toho vidím použitím příkazu .codepage 6, obecně
je použitelný i na jiné kódování. Interně pak převod bude q5:69 místo q5:19.
*****************
13.01.2021
Můj CMD na aktualizaci www.redap.cz hrubě neprocházel. Teď mně zbývá již poslední
krok - proč se kazí dvě česká písmena.
*****************
09.01.2021
Opraven příkaz .write. Připomínám, že .open otvírá KOI soubor, .open8 utf8 soubor a
.open16 utf16 soubor. .write se tomu pak musí při zápisu přizpůsobit.
*****************
08.01.2021
Odstraněna příčina pomalejšího zobrazování ve VST.
*****************
07.01.2021
Opravena čeština u hlášky s neexistující dokumentací a dokumentace svedena z dok590
na dok589. Zlegalizován zápis 'datum%d', který doposud procházel.
*****************
Napraveno cls(253)
*****************
06.01.2021
Uchodil klávesnici KLA a grdwin - zde zajímavý problém, kdy nadpis okna je deklarován
jako UTF16, ale bere pouze Windows 1250. Evidentní chyba Windows.
*****************
Takže nyní generujeme awpxxx.his, chwxxx.his, hwsxxx.his.
*****************
05.01.2021
Připustil jsem v GRD rozměr okna 99xy a uchodil winmenu. Protože se soubory HIS kříží -
8 bitů a 16 bitů, budu je musit nějak rozlišit. Jinak to padá.
*****************
04.01.2021
Dostal jsem několik hlášek, že WR590 padá nebo mrší cosi, ale po vypreparovaní sekvence to
funguje. Proto se neodříkám zaslání celé aplikace s návodem, jak chyby dosáhnout. Já si pak
s tím již poradím.
*****************
04.01.2021
Děkuji za zaslané podněty k wr590, ale momentálně se musím věnovat připomínkám k wr589, které
budu pak musit promítnout i do wr590.
31.12.2020
Od 9.2019 jsem se rok rýpal ve wr590 s cílem pracovat místo v KOI08 v kódové stránce UTF16.
Poslední kvartál 2020 jsem na wr590 zanevřel, protože původní jednoduchá myšlenka se ukázala
jako pořádný oříšek a úpravy kódu nebraly konce.

Momentálné je ATP 16 bitový, tisk částečně 8 bitový. Z důvodu momentální bezproblémové
kompatibility editor ukládá výsledek 8 bitově (v KOI08, ale mám jakési UTF8) místo správně
16 bitově.

WR590 dělá mnoho věcí jako wr590, ale obávám se, že stále ještě mnoho věcí nefunguje. Proto
dávám na web demo wr590 - nesetuje se! s prosbou na cestující veřejnost, aby v případě
volné chvilky si wr590 ověřila na své/svých aplikacích a v případě potíží mně dala vědět
co je ještě třeba dodělat.