O: ATEconvert

Takže mám rychlost detekce kódování v rámci Pythonu na číslech původní verze. Ale mám to napsané podstatně přehledněji než na původním nedokončeném ATEconvertu. Přes 2200 řádkovej textovej soubor v kódování "cp1250" udělá A1200 za nějakých 42 vteřin. A3000 to pak bude mít tak za 10-15 vteřin. Detekce má něco přes 100 řádků kódu. Optimalizoval jsem to asi z 50 řádkového kódu. Ano, 2 krát větší kód se vykoná mnohonásobně rychleji. Zajímavostí je taky fakt, že když jsem nechal pouze číslovat zpracovávaný řádek, tak se detekce vykonala skoro 4 krát pomaleji. "Slušná" rychlost tisknutí znaku... .

O: ATEconvert

V prvej vete pises, ze si rychlostou detekcie kodovania na cislach povodnej verzie a potom v 5,6 a 7ej vete pises ze mas 2x dlhsi program a mnohonasobne rychlejsi. Tak neviem ako mam tomu rozumiet, ktora veta plati ?

O: ATEconvert

DJM: Rýchlosť detekcie je rovnaká ako v povodnej nedokončenej verzii ATEconvertu. Optimalizoval som z novo napísaného kódu, ktorého detekcia bola oveľa pomalšia až som sa dostal na rýchlosť povodnej nedokončenej verzie, ale s prehľadnejším kódom, než mala povodná verzia .

Ono rýchlosť detekcie záleží od toho v akom kódovaní je súbor. U súboru v kódovaní CP1250 s 2200 riadkami u ktorého je detekcia na A1200 za asi 42 sekúnd je u toho istého súboru, ale v inom kódovaní detekcia na A1200 dokončená asi za 5 sekúnd, pretože pokiaľ je v textovom súbore prítomný nepovolený znak z kódovania CP1250, ten je nepovolený aj vo všetkých ďalších kódovaniach, ktoré som schopný vylúčiť. Detekcia je teda okamžite ukončená pre všetky kódovania.

Najviac časovo náročné je určit čisté ASCII, pretože sa musí poctivo prejsť každý znak v súbore. Tam možem urobiť len jedno a to že zmeriam dĺžku zpracovávaného riadku, pokiaľ je do 128 znakov, overujem 128 znakov, zmením znak na číslo a porovnám, čí je vačšie ako číslo 127. Pokiaľ je dĺžka zpracovávaného riadku dlhšia ako 128 znakov naopak dám si FOR(128,256), číslo zmením na znak a zisťujem prítomnosť znaku v zpracovávanom riadku. Týmto obmedzím počet cyklov v rámci zpracovávaného riadku maximálne na 128.

O: ATEconvert

- pár změn v detekci - opravy chyb
- trochu změnený vzhled
- opraveny 2 chyby - již snad počítání řádku na řádek přesně

Klasicky výkon A1200.

O: ATEconvert

Jak jsi na tom v tom přechodu na to C? Je nějaký pokrok i v tomhle směru?

O: ATEconvert

Pokrok není, sem tam si něco o C čtu, ale je to výjimečně. V přechodu v základech na C nevdím zatím problém. Podobnost s Pythonem je větší než jsem myslel. Potřebuji 1 funkční program v Pythonu aby jsem ho začal přepisovat do C. Jak jsem shořel na Sabotérovi, vrátil jsem se k ATEconvert. Rychlost dokončení ATEconvertu teď záleží hlavně od toho, jak se mi bude dařit/nedařit programem udělat postupně 365 tabulek po 128 a více znacích. Editovat ručně to vše rozhodně nebudu, tak jsem sám zvědav, jestli to bude/nebude problém.

O: ATEconvert

Prosba o radu!

Jde o způsob zobrazení info po nastavení parametrů. Jsou 2 možnosti:
1. Bude zobrazena info o nastavení parametru na panelu.
2. Bude zobrazena info o nastavení parametru na panelu + po nastavení se pozadí textu hodí do šedé barvy. Když to bude logika dovolovat, toto nastavení se bude dát samozžejmě i nadále měnit. Změna barvy pozadí může zpřehlednit nastavení, které jsme již nastavili. Tedy například po nastavení vstupního a výstupního kódóvání by se "Vstupní / výstupní kódóvání" a výpis kódóvání dal do šedýho pozadí.

Vzhled není finální:

O: ATEconvert

Koukám, že máš černé pozadí. To bude potom i ve finální podobě, že to bude měnit i paletu Workbenche? Možná by stačilo i vybrané položky zvýraznit jen tučným písmem. Tedy samozřejmě jen do doby, kdy k tomu potom přiděláš i GUI

O: ATEconvert

Díky za tip, zatím to vypadá na 2. možnost. Paletu WB měnit nebudu. Není vyloučeno, že tomu udělám SETUP, kde si bude uživatel moci vybrat, co bude mít jakou barvu v rámci dostupných 8mi barev (4 co jsou ve WB nastaveny + 4 které nějak určuje WB, ale mám k nim přístup (pokud je WB na 8mi barvách, sedí všech 8 barev, které jsou nastaveny)), to ale první verze mít nebude.

Jinak to jsem jen použil jednu z nastavených barev WB jako pozadí. Nenačítávám novou paletu.

O: ATEconvert

-zmeněný vzhled, spřehlednění (údaje o souborech v tabulce), po vybraní nastavení se tedy pozadí textu do šedé barvy dávat nebude.
-doplněn základ logiky pro dodatečné načítání detekce kódování (využití hlavně u ujištění se, že je soubor v čistém ASCII a možná i jinde)
-zkontroloval jsem logiku pro počítání řádku po úpravě na dodatečné načítání detekce kódování (šlo to moc hladce tak se mi to nezdálo - žádný problém nenalezen, spíše maximální spokojenost)

Detaily budu dodělávat ke konci, se současným stavem kódu jsem spokojen a pudu dál.

Video bez zpomalení emulace!

O: ATEconvert

Barevně to už vypadá líp. Jen jeden dotaz... bude možné ten skript používat se zadáním parametrů, pokud bude vědět z jakého a do kterého kódování tu chci převést, nebo bude vždy nutné použít menu jako teď?

A co to takhle vyzkoušet, jak to jede pod Pythonem na OS4? Zdá se mi, že jsme to už řešili spolu někdy v minulosti, ale nevzpomenu si jak to tehdy skončilo.

O: ATEconvert

Barvy budou schodné, jak má kdo nastaveno ve WB. Zatím tam vybírám barvy, jak se mi to líbí s tím, jak mám WB nastaven barevně já. Bude možné okamžitě udělat převod. To bude vylepšení oproti předešlé nedekončené verzi. Na tuhle možnost hraju, aby to šlo vše vybrat z 1 obrazovky. Tá detekce je jen takové vodítko ke správnému kódování. Ale funguje dobře. "DRAC.TXT" je opravdu v kódování CP1250. Tohle kódování je určeno detekcí na sedmém řádku. Tohle ještě pak dodělám, aby při detekci CP1250 se nenačítali zbytečně další řádky. Ale jde to udělat jen u tohodle kódování. Tabulky převodu chci udělat jako externí modul = do paměti sa načtou jen ty co se používají při konkrétním převodu.

Ano již jsi se mne to ptal asi u předešlé nedokončené verze ATEconvertu. V mnoha směreh je to hodně nedokončené. Co se týče testování pod OS3, ja tomu věřím. Přeci je doporučeno pro nejlepší kompatibilitu dělat programy právě pro OS3. Ale OK, pošlu Ti verzi, jak bude čas. Samého mne zajíma, jak rychle to pude. Video by mne potěšilo. Můžeš pak dát detekovat nekolik tisícový TXT soubor. Nefunguje správně ani EXIT, tedy použít pak "křížek", nebo CTRL+C. Sotva nějak funguje ta nedokončená detekce. Ale kód té detekce je naprosto vpořádku = zoptimalizoval jsem to v rámci Pythonu, na rychlost, jak jsem to nejlépe uměl, spíše dodělat ty věci kolem, ale na to se teď nehraju. Udělám si nejblíže kód, co mi udělá 365 tabulek na převod. Snad to bude tak jednoduchý jak si myslím a nebude tam žádné "ale" nebo jsem v kaši . Na to použiju tabulky z předešlé verze ATEconvertu. Tyhle tabulky ale nebudou finální, nebo ty nejlepší, ale i tak budou v pohodě na převod. Jde o to, že vše bude reprezentováno v rámci znaků kódování iso8859_2 (Latin2), přímým převodem, ale můžu speciální znaky nahradit někdy i znakem, který bude lépe vystihovat znak z původního (starého) kódování, ale to už je jen takový perfekcionismus.

S tím, kdy Ti pošlu verzi trpělivost, jak budu mít trochu času zapracuji na tom.

O: ATEconvert

Prober mi poslal v maily přílohu, které jsem si všiml později, já to trochu zpracoval, ať je to názornější. Očíslovaní barev v OS3 jsem udělal dodatečně.

Co je vidět?

- nefunguje ESC sekvence "\f" pro mazání obrazovky (je ale ještě 1 další sekvence na mazání obrazovky)
- barva číslo 5,6,7 je v slabých odstínech šedé a to je asi ten důvod, proč se Proberovi po načtení souboru nic nezobrazí, já používám i tyhle barvy. Tedy text s červeným pozadím by se mu měl zobrazit, ale zde může dělat problém i to, že zatím nefuguje mazání obrazovky.

Program používá i pod OS3 kódování iso8859_2 - diakritika pod OS4 je v pořádku .

WB v OS4 při nastavení 8 barev zatuhne. Zatím tahle vlastnost byla označena jako "nová fičura". Tak co pánové, s kolika barvama vám WB pod OS4 vlastně pracuje?

O: ATEconvert

Tak mne OS3.9 aj 4.0 pracuje s 65536 "barvama".

O: ATEconvert

Tak chyba byla nakonec mezi klávesnicí a hrnke kafe. Používal jsem soubor, který byl prázdný (ale to by měl skript taky nahlásit, takže bugreport ). Po načtení souboru s obsahem to najelo jak mělo. Nicméně se objevila chyba při detekci kódování...