OldComp.cz

Na Resetkání 2013 jsem prezentoval svůj nedokončený program na převod mezi různým kódovaním textu. Měl jsem ne něj 2 připomínky. 1 od uživatele MarK, že by se mohli zobrazovat jen převody textu, který u detekce kódování nebyl vyloučen (viz 1.foto), na co jsem mu řekl své důvody, proč se zobrazuje vše. Jako správný extrémista počítám i s možností použití nepodporovaného kódovaní textu a s tím spojen libovolný výběr v použití kódování nejbližšímu, které není podporované. Narážím zde na znakové sady mimo české (ale to se nikdy nestane ) a zároveň jsem nevidel problém, proč nezobrazit vše. Taky jsem odpovědel MarKovi, že už mám v hlave 100 procentní detekci textu (pokud se nepletu). Nevím tedy, jestli se k ní dostanu, asi by to bylo škoda nevyužít. Detekce pomocí nedefinovaných znaků použita v téhle verzi je pomalá. Ale chci dělat už i na jiných věcech jako je ATEkonvert.

2. připomínku měl Mistic Joe a kvůli ní jsem založil tohle vlákno. Jde o logiku pro zobrazení detekce sekvence přechodu na nový řádek. Na foto č.1 je detekce CR+LF (v černém rámečku). A teď se dostaneme k tomu, co bych potřeboval poradit. Na 2. foto je volba kódování souboru, který vytvoříme. Zde si vybíráme kódování, jestli chceme změnit šířku řádku a taky jestli chceme změnit sekvenci přechodu na nový řádek. Jediná povinná volba je pro kódování. Zadání volby je blbuvzdorné. Na foto jsem vybral pro vytvořený soubor změnu přechodu na nový řádek pomocí sekvence LF, co používá i OS Amigy, kódování Amiga-E2 a maximální šířku řádku na 105 znaků. Mistickovi se zdá být volba zmeny přechodu na nový řádek matoucí. Líbilo by se mu, aby vybraný přechod na nový řádek pro nový soubor byl zobrazen již v černém rámečku. Teď se zobrazuje sekvence přechodu původního souboru = vstupného souboru a ne výstupného souboru, který bude vytvořen. Já to beru jako, že vidím sekvenci vstupného souboru a sekvenci pro výstupný soubor, pokud ji chci zmenit zadám do řádku VOLBA: . Můžu to změnit. Třeba že se vybere sekvence přechodu (volitelná možnost), a po entru bude černý rámeček zobrazovat naši volbu. Pak se vybere kódování + šířka řádku (volitelná možnost). Takže by se klikalo o jeden Enter navíc.. .

Zdá se Vám tedy současná logika výberu matoucí, udělali by jste to jinak?

Děkuji za názory, pokud nějaké budou

Bych to nejdriv rad zkusil, kde to stahnu?

No ono by to možná chtělo nějakou videoukázku. Takhle ze strohého popisu není úplně jasné, o co jde. Nicméně já bych z toho až zas takovou vědu nedělal. Možná by stačilo tuto volbu skrýt a jen dát zvolení výstupu Amiga nebo PC.

_________________
Amiga/Amstrad/Atari/Commodore/Mac/Nintendo/PS/PC/Sega/Tandy/ZX

No já chci, aby uživatel viděl, jaké jsou možnosti sekvencí určujících přechod na nový řádek a tahle volba je nepovinná, takže pokud se žádná nevybere, tak zůstává ta ze vstupního souboru. Ještě přemýšlím, že zavedu i zápis bez sekvence, že by se text zapsal za sebou - co to systém umožní?

Dal jsem vybranou sekvenci přechodu na nový řádek k tomu určenému textu. Takhle by mohlo být jasnější, že jí je třeba změnit v řádku VOLBA: .

Jinak ATEkonvert není dokončen. Nedávno jsem se pokusil přepsat jistou část kódu, která vypadá nevzhledně. Je to to, co vypisuje text se souboru do řádků pomocí různých kódovaní. Nevzhledná část programu nese neoficiální označení Housenka. Je to celkem 13 částí skoro stejného krátkého programu pod sebou. 7 stejných pro kódování a 6 pro rozlišení UTF-8. Jenomže potom, co jsem ve WinUAE vypnul možnost FASTEST POSSIBLE, a načetl nový text pomocí volby "0" tak z neuveřitelných 15 vteřin pro Housenku se stalo ještě neuveřitelnejších 32 vteřin pro novou část kódu, kde se vše dělalo na jedném místě. Prostě musel jsem zavést pár veličin navíc, aby si to nějaké věci pamatovalo a to sežralo při těch všech převodech tolik času navíc . Takže jsem Housenku přejmenoval na Rychlonožku a je právem zařazena do ATEkonvert pro Amigu.

Tak jsem dodělal jistou část ATEkonvert. Opravil pár chyb, vylepšil detekci prázdného souboru, přidal info o vstupném kódování při volbě cílového kódování, přidal do různých části info o tom, že byla udělaná špatná volba, nebo volba mimo rozsah těch možných. Dle mne zpřehlednil část, kde se vybírá sekvence přechodu na nový řádek (nebo zůstává původní). Kompletně (2x) přepsal detekci kódování na základě nedefinovaných znaků čím se mi konečně povedla první optimalizace kódu pod Amiga Pythonem (2. optimalizace v rámci Pythonu). Při vypnuté možnosti FASTEST POSSIBLE ve winUAE byli časy cca nasledovné. Nejhorší je vyloučit samotné ASCII. Musí se proběhnout všema znaky. A ještě když jsem k tomu přidal přechod sekvence na nový řádek pro Amigu tak to bylo hotové časové peklo . Text o rozsahu asi 2000 řádků byl zpracován asi za 4 minuty 30 sekund ). Po druhé optimalizaci je to již "jen" cca 48 sekund. Detekce třeba CP1250 byla nejdříve cca 1 minuta 30 vteřin a po druhé optimalizaci je to cca 12 vteřin. Pokud zapnu ve winUAE možnost FASTEST POSSIBLE tak jsou to vše vteřinové záležitosti. V současné části kódu ještě asi přidám možnost vynechat detekci kódování. A to asi tak, že pokud se uvede na začátku názvu vstupného souboru mezera (nebo více mezer), tak se provede jen detekce signatury na začátku souboru (kódování utf-8) a ostatní detekce se vynechá. Pak mi už zůstává se vrhnout na poslední část programu a tou je samotný zápis pomocí mých převodových tabulek a dodělat celkovou logiku co k tomu bude třeba. Ještě uvidím, jestli budu optimalizovat původní část programu použitou ve verzi pro PC (třeba celková logika pro zůžení textu bez useknutí slova, pokud bude tato možnost zadána). Dnes jsem si udělal takový malý test jak je na tom Python s rychlostí vyvolávání podprogramu. V Pythonu se tomu říká snad definice funkce, nebo něco takového. Jestli by mělo smysl optimalizovat část kódu, který detekuje kódování - stejné části kódu na vícero místech (zavedené jen kvůli rychlosti). Naštěstí se vyvolání podprogramu (bavím se zde o opakování v řádově tisících) projevilo jako dostatečně spomalující a proto část kódu nechám pěkně rozlezenou

No a přidávám nejaké to foto.

_________________
Amiga - PMD 85

Nějaké foto si strč někam kde je verze ke stažení?

_________________
Amiga/Amstrad/Atari/Commodore/Mac/Nintendo/PS/PC/Sega/Tandy/ZX

Kde? No na OLDCOMP se tomuhle místu začalo říkat znečištěná zdířka

Akorát jsem přišel na další chybu - chyba odstraněna

_________________
Amiga - PMD 85

No jo, ale tam mě nemají rádi. Pošleš mi prosím poslední verzi mailem? Díky

_________________
Amiga/Amstrad/Atari/Commodore/Mac/Nintendo/PS/PC/Sega/Tandy/ZX

No asi jsem doposud měl špatný názor co je to znečištěná zdířka. Já tím opravdu myslel prdel, nic víc a nic mín

Snad si nemyslíš, že pokud by bylo hotovo, že bych na Amigaportál tu verzi dal a sem ne. Teď si mne dostal . Vždyť i ve včerejším (nebo kdy to bylo) příspěvku píší, že se chystám na poslední část. Dnes o 2:30 ráno jsem opravil jednu chybu. Ty mne chceš uhnat že? . Akorát objevuji kouzlo ECŚCAPE SEKVENCE - BACKSPACE, abych nemusel při 1 řádkových informacích mazat celou obrazovku a různé informace, když program ukazuje, jak daleko je s propočtami by pak byly bez problikávaní. Budeš první, kdo bude mít již funkční, ale né zcela hotovou verzi. No má verze umí možná tak práci se sekvencemi. Převody jsou v poslední části programu. A já programuji shora dolů . Styl rychle to naplácat, abych šel dál a pak se vracet se mi nezamlouvá a taky rychle to naplácat a dát do světa taky ne. Chci být přesvědčen, že tam neni chyba a pokud se najde, nedá se nic dělat, bude se muset opravit. Jediné na co nebudu sahat jsou tabulky. Najde se více chyb a ty se pak jednorázově všechny spraví. Vo jedné vím a neřeším. Nejaká pomlčka mne nemůže rozházet .

No když už sme u toho kde koho nemají rádi. Dnes Scavenger dodržel bod č.6 v pravidlách Amigaportálu a poslal mi soukromou správu ve které mne označil jako sketu

Klidně sem plácnu jeho i moji správu, ale pár lidem by se to nemuselo líbit, co respektuji.

_________________
Amiga - PMD 85

No vidíš - a já myslel, že si narazil na omezení zdějšího fóra - tj. max. velikost přílohy 901kB A tak si to uložil jen na Portál. Ale pak jsem si uvědomil, že to stejně budeš distribuovat na image diskety. Takže jsem zase došel k tomu, že vlastně jsem si myslel naprostou blbost... No a vůbec. Počkej až budeš mít malé smrádě, pak budeš zmatenej jako já
No s tím Scavengerem sice nevím o co jde, ale sem bych Portálové handrkování a půtky tahal velmi nerad. Zde jsme prostě samí slušní lidé, co žijí v sluníčkovém světě a z nějakých negentlemanských -ismů bysme mohli mít minimálně omdlévací příhodu

_________________
Amiga/Amstrad/Atari/Commodore/Mac/Nintendo/PS/PC/Sega/Tandy/ZX

Tak pomalu postupuji v práci na ATEkonvert. Každopádně z jistých důvodů přejmenovávám jméno programu ATEkonvert na ATEconvert. Jinak jsem zavedl možnost přeskočení detekce kódování. Při volbě pro vyloučení detekce se bude text do volby pro výběr kódování záměrně načítat ze souboru celý a úplně od začátku (u detekce kódování se najde vždy 1. slovo s diakritikou a od tohodle slova se načte text). Zkoumal jsem, co by se mi hodil za znak na takovéhle označení pro přeskočení detekce. Použil jsem Workbench a Dopus a snažil se příjít na nějaký znak, co se nedá použít na konci jména souboru a zároveň, aby byl na klávesnici relativně snadno dostupný. Výhrálo to lomítko. Po uvedení lomítka na konci názvu souboru se provede detekce jen přitomnosti samotné signatury, která nám říká, že se jedná o kódování UTF-8. Tahle signatura je jen kombinace 3 znaků na úplném začátku souboru, co je časově minimálně náročné a pokud je soubor v kódování UTF-8 se signaturou (signatura u UTF-8 není povinná ...bohužel), vyloučím tím všechny kódování mimo UTF-8. Další co jsem zavedl je nepřevádení vyloučeného kódování v samotném výběru vstupného kódování. Urychlí se tím samotný celkový převod při načtení nového řádku, který se zobrazí do tabulky pro výběr vstupného kódování. No a poslední, co jsem udělal je v rámci možností zavedení ESCAPE SEKVENCÍ na pár míst v samotném programu. Jedná se hlavně o zobrazení průběhu převodu kódování do menu pro výběr vstupného kódování, nebo v části pro hledání nejdelšího slova v souboru (při souborech v rozsahu textů v řádech nekolik 1000 - stačí i 1000 tuhle volbu nedoporučuji u Amig bez turbokarty Kafe, čaj pivo? ) no a ještě na pár míst kde to šlo bez toho abych to celé musel přepsat , čím jsem u průbehu načítání převodu kódování zamezil nechtěnému problikávání obrazu, které jsem doteď řešil celkovým smazáním obrazovky a né jen malé části, kterou potřebuji (jó o téhle ASCAPE SEKVENCI se bavím - vím, že i samotné použití barvy v programu dělám pomocí ASCAPE SEKVENCE ).

Teď jsem s částí programu až do části pro samotný převod kódování v rámci první verze ATEconvertu opravdu spokojen a už pudu na závěrečnou část programu tak uvidím, jak to pude

A ještě pár fotek...

_________________
Amiga - PMD 85

No dnes jsem dostal pár "facek" a jsem před dilemou, jestli pokračovat dál.

Mám napsanou první logiku pro převod kódování mimo ASCII a mimo UTF-8. Testoval jsem to na cca 2150 rádkovém textu. Časi jsou šílené. Ve WinUAE při možnosti FASTEST POSSIBLE jsem převedl soubor za 1 min a 45 vteřin. Když jsem FASTEST POSSIBLE vypl, tak to bylo cca 23 minut ). Jenže se současnou logikou samotných převodových tabulek s tím časem již nehnu. Dělám to jednoduše. Mám k dispozici všechna kódování zalokalozovaná vůči Latin2. Stručně řečeno samotným písmenem a jeho hodnotou pokud znám jeho kódování, které je ale při převodu již dané skočím přímo na jeho místo v již vybrané tabulce, na kterém již "čeká" znak v kódovaní Latin2 (a latin2 již rozumíme). To je jedna část. Potřebujeme to ale ještě převést na kódování, které jsme si vybrali. Na to zase použiju vopřed zvolenou tabulku, kterou mám zalokalizovanou vůči Latin2. Již vím jaký znak hledám, takže si ho dám najít v mé tabulce. Ten znak "čeká" na míste, které pozicí sedí pro stejný znak v jiném kódování. Pokud již tedy mám pozici znaku v kódovaní pro výstupní soubor, tak
uložím znak v kódování Latin2 právě s touhle hodnotou. A převod písmene je hotov )

Je jasný, že se to dá napsat lépe, ale to bych musel změnit převodové tabulky a to teď dělat nebudu. Jen tyhle převodové tabulky jsem dělal průběžně 3 mesíce. Nemám teď čas na to tohle předělávat Pokud někdy napíšu novou verzzï ATEconvertu, je jasný, že nebudu výcházet ze současné logiky převodu - takže i tabulky budou jinak dělané. Bude jich třeba více. Teď jich mám 14, na novou verzi jich bude třeba nějakých 20? Byl by to převod napřímo = 1 převod a né 2 převody na jedno písmeno a taky by se dané písmeno nehledalo. Tohle by mělo "podstatně" urychlit převod. Můj hrubý odhad je 1/2 současného času, nebo i méně (opravdu hrubý odhad). Pokud by si někdo myslel, že převod ženu přes Neptun a zpět zde je celý kód

v CODE mi nejde měnit barva, tak to pišu bez CODE

for radek in souborVstup: #načtu řádek v souboru
____for b in radek: #načtu písmeno z řádku
________if ord(b) < 128: souborVystup.write(b); continue #pokud je hodnota písmena ASCII zapíš přímo a vrať se (načti další písmeno)
________b = a[1][ord(b) - 128] #a[1] = tabulka vstupného kódování, ve které se podívám, co je třeba na její 50. pozici za písmeno v kódování Latin2 a zapíšeme do hodnoty "b"
________if b in a[2]: souborVystup.write(chr(a[2].index(b) + 128)) #pokud je "b" v tabulce výstupném kódování a[2], najdi jeho pozici (index), převeď pozici na písmeno v Latin2 ( chr() ) a zpíš do souboru
________else: souborVystup.write(" ") #pokud b neni obsaženo v tabulce pro výstupné kódování, zapíš mezeru
#s číslama 128 snižuji, nebo zvyšuji hodnotu pozice daného písmene, stačí mi pracovat jen s polovinou tabulky (128 znaků z 256)

Proč to zde vše píšu? Časi jsou dle mne tak extrémní, že dle reakcí se rozhodnu, jestli to vůbec dokončím.

Je pravdou, že:
-parametry toho co jsem převádel:
počet znaků ascii = 712222 (slovy přes 712 tisíc )
počet znaků mimo ascii = 83957
počet nepřevedených znaků = 2781
velikost txt souboru = 780 KB

Dělám výjímku, pouštím do oběhu ALFA verzi ATEconvertu. Pokud někdo chce, múže vyzkoušet. Část programu až po samotný převod by už měla být v pořádku. Samotný převod je možný v rozmezí CP1250, ISO8859-2, KOI-8čs, Kamenických, cp852, AmigaE2. Já zkoušel jen z cp1250 na KOI8-čs. Neni podporován ani změna sekvence přechodu na nový řádek, ani zužení textu na požadovanou velikost! Při výběru kódování číst UTF-8 v rozsahu podporovaných kódování již můžete

Z mým rychlích postřehů: U výstupního souboru i když se zadá cesta, uloží se tam, kde je samotný program (u vstupního souboru cesta funguje)
Pokud nekdo bude zkoušet, vše na vlastní triko Já s tím za rok, neměl problém (pokud byl, tak jen z mé blbosti )

Alfa verze ke stažení v příloze. Nenechte se zvyklat ikonou od Prince Jasoňa Instalace není nutná, jen nakopíruje tabulky pro Iso8859-2 (Latin2) kam patří, aby pokud někdo Latin2 nepoužívá, měl správnou diakritiku v samotném programu. Kvůli rychlosti pracujte s programem na HDD, CF nebo co to tam máte . Program nabíha pomaleji. Strpění. Hlasení na začátku 2 chyb je normalní

_________________
Amiga - PMD 85

Čeče, tak to máš asi něco blbě nastavené. Máš povolený JIT ve WinUAE u CPU? Mám tu svůj testovací soubor Draculy 799497 bytů (není to ten samý, co máš na testování ty? ) - detekce okamžitá, převod trval 8,3 vtěřiny.
68030, Fastest possible, JIT, 68881, Cache size 8MB, Constant jump, FPU support, No flags, Indirect.
A vzhledem k tomu, že moje obsoletní verze WinUAE využívá jen jedno jádro, tak pustit na to všech 8, tak to prosfiští za vteřinku. Čili pokračuj, pokračuj!

_________________
Amiga/Amstrad/Atari/Commodore/Mac/Nintendo/PS/PC/Sega/Tandy/ZX

Jo testuji to na tom samém, mám tedy u něj možná již upravenou šířku řádku, ale to by takové rozdíly házet nemělo. Trochu mi nejede přes hlavu, že indikace HDD ve WinUAE mi pořád svítí, že zapisuje, jako kdyby to šlo na plný koule... . Zkusil jsem teď poměnit pár věcí v nastavení, pořád ale ta stejná časomíra, rozhodně ne tvých 8.3 vteřiny. Ještě by mne zajímalo, pokud se jedná o tvou konfiguraci WinUAE - jestli se to dá alespoň srovnat s Amigou s turbokartou. Nemá smysl tady tunit přemrštěně Amigu pod PC

_________________
Amiga - PMD 85

Tak to se samozřejmě porovnat s reálnou Amigou nedá. To je taková 030 na 500Mhz Až bude finální verze, tak jí samo prubnu na 060tce, na reálné Amče. Ale primárně to budu používat pod emulátorem, takže mi pomalost nevadí.
Ještě bych být tebou pustil SysSpeed a prověřil rychlosti zápisu na disk. Je možné, že bude zádrhel tam. A nebo bys mohl udělat to, aby to netrpělo pomalým přenosem, že si otestuješ velikost volné RAM a pokud se vejde, tak ho budeš postupně zapisovat do RAMky a potom výsledek jen překlopíš na disk.

_________________
Amiga/Amstrad/Atari/Commodore/Mac/Nintendo/PS/PC/Sega/Tandy/ZX