???.txt

ide.ne.irj at freemail.hu ide.ne.irj at freemail.hu
Wed May 25 20:14:14 CEST 2005


Thus spake Andras Tantos:

> Ne vadits mar! Nem eletszeru egy string-et nem sorosan elerni? Nem eletszeru 
> visszatorolni az utolso karaktert? Rendben, egy kavefozoben nem valoszinu, 
> de egy POS terminalban, ahol mondjuk afas szamlat kell kiallitani, mar igen.

Igy van, nem eletszeru! Irtal mar GUI-t? Csinaltal mar mikrovezerlos
kutyut kijelzovel? Minek kene ilyesmi?
Mondjuk POS terminal eseten is?
Valamint mennyiben csokkentene a hatekonysagot, ha az eddig 0.0001% CPU-
ido, ami a szovegformazashoz kellett, felmenne 0.0002%-ra?
De ugy, hogy kozben minden szoveg fele meretuve tomoritodott, kisebb memoria
eleg, stb...
Szoval kitalaltal egy fiktiv peldat, amely:
-a valosagban nem fordul elo
-elvileg sem problema, mert a hatekonysagot nem befolyasolja
-az unicode elonye ebben a peldaban is csak egy kis reszben ervenyesul,
egy alig elofordulo reszfeladat megoldasat konnyiti, nem jelentos mertekben.
Minden mas (tarolas, font kezeles stb...) sokkal gazosabb!!!

> Aha. Az eredeti problema a TC unciode kodolasi hibaja volt. Aztan a vita az 
> e-mail-ek kodolasara terelodott. Ekkor te javasoltad, mint megoldast a 
> Unicode helyett az escape-elt kodlap-valtasokat kellene hasznalni. Erre en 
> leirtam, hogy a standard, es sok helyen hasznalt string-muveletek rendkivul 
> bonyolulta valnak egy ilyen abrazolasban. Ezek utan, te leirod, hogy, leven 
> te flash-ben tarolod a string-jeidet, ezert eletszerutlen, ha barki mas 
> maskent teszi.

Nem ertem mi a gond. Szo volt itt levelezesrol, dokumentumokrol,
file nevekrol, minden egyebrol.
Megegyszer megismetlem amit tegnap irtam: vannak olyan alkalmazasok,
ahol az unicode nelkulozhetetlen, mert tenyleg tobb nyelvet kell irni
egy doksiba. Pl kiadvanyszerkesztok.
Es vannak olyan teruletek, ahol egeszen biztosan teljesen felesleges
az unicode, pl mikrovezerlos egyszeru kutyuk, szinte minden, nem PC
alapu alkalmazas.
A tobbi e ketto koze esik. Vagy szukseges az unicode, vagy nem, vagy
problemas a megvalositasa, vagy nem, talalni kell valami kompromisszumot.
En csak megmutattam, hogy a PC-n kivul is van egy vilag.
Ti, mivel nem ismeritek, olyanokat terjesztetek, hogy az ASCII ki fog
halni, es minden unicode lesz. Hulyeseg!!

> De, hogy konstruktiv legyek: a 'tobbnyelvu GUI-val kommunikalo eszkoz' 
> feltetelezi a kommunkiaciot, azaz a ketiranyi adatcseret. Meghozza tobb 
> nyelven, ezert 'tobbnyelvu'. A ket iranyu, tobb nyelvu adatcsere, pedig 
> feltetelezi, forditasi idoben ismeretlen, tobb nyelvi string-ek 
> feldolgozasat. Peldaul egy masik eszkoztol, peldaul egy felhasznalotol, 

Miert?? A kavefozo is kommunikal, mert van rajta 3 gomb, amiket
megnyomhatsz. A POS terminal szinten. Hasonloan minden egyeb kutyu.
Billentyuzet viszont szinte kizarolag a PC mellett van!
Gondolkozz mar egy kicsit, mikor fordul elo, hogy szoveget kell
begepelned valami keszulekbe?
Miert jossz ilyen hulye peldakkal, ami a valosagban nincs is?
Ha csak erre jo az unicode, kidovhatod az egeszet ugy ahogy van.

> Hogy eletszeru peldat mondjak, a felhasznalo beirta a kereszt- es 
> vezetek-nevet a betegnek az EKG berendezesbe (ilyeneket is fejlesztesz, ha 
> jol tudom), mire az EKG a korhaz halozatan lekerei a kozponti adatbankbol a 
> beteg biztositasi adatait es korelozmenyet. A vissza kapott adatokat aztan 

Mivel az EKG-n nincs billentyuzet, egyaltalan nem lehet beirni nevet.
Minden felhasznalo valaszthat maganak egy kis ikont, azzal fogja
azonositani a keszulek. (Az en otletem!) Valamint kap egy szamot is 1..4
kozott. (Ennyi felhasznalot kezel a jelenlegi kutyu, de lehet hogy
felmegyunk majd 10-re) Termeszetesen general hozza egy belso azonositot is,
a keszulek sorozatszamabol es az idopontbol. Amikor kommunikal a PC-vel,
ezzel azonositja a pacienst az adatbazisban.
Nev nincs sehol... En be akarom tenni a nevet, kenyelmi okokbol, csak
meg nincs kitalalva a protokoll, hogy a PC hogyan fogja megkapni es
kezelni, visszairni a Cardy-ba stb...
A regi keszulek, amit meg nem en csinaltam, meg egyszerubben mukodott.
A 2x16 karakteres kijelzo miatt egyaltalan nem tudta a nevet, csak egy
nehany karakteres becenevet jegyzett meg. Az azonositas ugy ment, hogy a
PC-be beirtak a nevet es az adatokat, abbol a PC progi kepzett egy
hash-t, azt a keszulek megjegyezte, es a legkozelebbi kommunikacional ez
alapjan talalta meg a progi, hogy melyik keszulekkel es pacienssel van
dolga.
Nev alapjan nem tudom hogy lehetne megbizhatoan azonositani, mindig
el szoktak irni, valamint Kovacs Istvanbol minden dokinak van legalabb
3 paciense. Nem szokas. Mondjuk a TAJ szamon keresztul lehetne a
korhazi rendszerekhez kapcsolni. Folyamatban van, de ezzel nem en
foglalkozom, hanem a szoftveres kollega.
Szoval ez is egy teljesen eletszerutlen pelda volt :(((

> menti a kozponti adatbankba kesobbi feldolgozas celjabol. Leven a berendezes 
> modern, ezert a kommunkiacio a halozaton (titkositott) HTTP protokollon 
> keresztul tortenik, es tegyuk fel, hogy minden rendszer (Unicode helyett) a 
> te altalad javasolt string definiciokkal mukodik. Azert itt mar van jopar 
> string-muvelet, nem?

Nincs sehol. Nem is lesz, mert a nevet biztos hogy nem fogjuk hasznalni
semmire. Csak en eroltetem. Ugyanis el tudok kepzelni egy szituaciot, amit
az eddigi tapasztalatok alapjan a fonok kizartnak tart: hogy egy beteg
tobb dokihoz is jarhat. Amikor elmegy az ujhoz, az elozo mar kitoltotte
a nevet a keszulekben, az ujnak viszont nincs meg a rekord a szamitogepeben.
Ilyenkor a Cardy-ban tarolt adatok alapjan ki lehetne tolteni, nem kene
annyit gepelni, sokkal kenyelmesebb lenne az egesz.
Itt lenne egyetlen konverzio. A mondjuk max 20..25 karakteres nevet at
kene konvertalni a spec kodlapbol egy masikba, vagy unicode-ba.
Ha ennek a nehany karakternek a konverziojaba beledoglik a 2GHz gep, akkor
vagy eloirjuk hogy 3GHz-es kell, vagy kiszedeti velem a fonok az egeszet.
Ennyi...

> Vagy lehet, hogy nem jol ertem, es te ugy gondoltad, hogy az altalad 
> javasolt megoldas nem univerzalis, es csak azokban az esetekben hasznalando, 
> ahol elonyos, maskor meg nem? No de pont te magyaraztad, hogy az ordog a 

Minden megoldast ott kell hasznalni, ahol elonyos.
Pl az unikodot ott, ahol nem csak sok nyelv van, mert az onmagaban nem
indikacio, hanem egyszerre kell megjeleniteni sok nyelv karakterkeszletet.
Ahol eleve karakteres kijelzo van, ott nyilvan szoba sem johet az unicode,
akarmennyire is ki akar halni egyesek szerint... Tevednek!
Egyebkent meg merlegelni kell, meg kell talalni a kompromisszumot.

> kulonbozo abrazolasi modok kozotti konverzioban rejlik, es hogy a 
> Unicode-dal az a baj, hogy oda-vissza kell konvertalgatni, es, hogy az ASCII 
> meg azert jo, mert ott meg nem. Most akkor a te megoldasod miert jobb? Ezt 
> speciel nem oldja meg, nem szabvanyos es dinamikus string-kezelesre nem 
> hatekony (statikus string-eken meg nem sok kezelni valo van).

Azert jobb, mert fele meretu minden szoveg, a specialis esetek
kivetelevel (amikor sok a kodlap-valtas, az egymas utani betuk mindig
mas nyelven vannak, szoval hulyeseg) 2x gyorsabb minden sztringmuvelet,
egyszeru es gyors a font kezeles, stb...
Tovabba mert amugy sem lehet implementalni egy korrekt unicode
megjelenitest. Nincs hozza eleg memoria, stb...
Valamint nincs ra szukseg sem.

> Azert mert olyan nyelven van a neve (kinai az urge), amiben tobb, mint 255 
> karakter lehet. Igy a kodlapod nem a nyelvet, hanem a nyelvben elofordulo 

Majd ha a kinaiaknak gyartunk, el fogunk gondolkozni rajta.
De mivel ez teljesen nonszensz, fel sem merult az unicode hasznalata.

> Hogy miert irna be barmit is a user?

[..]

Meg a kavet is nevreszoloan keri, stb... Hulyesegek.
A kinai, japan es egyeb nyelvek kivetelevel minden nyelven mukodne ez is.
Csak a kulfoldiek neveben egyes ekezetek hibasak lennenek, ez lenne a
legnagyobb problema.
Persze ha eljutnanak idaig, ugyanis a billentyuzeten sem talalnak a
szukseges ekezeteket, tehat be sem tudnak gepelni.
De bizonyara az unicode azt is megoldja, hogy a magyar billentyuzet
atvaltozik kinaiva hirtelen...
Gondolkozz mar egy kicsit, vagy nezz korul a vilagban!

> - Mert a riaszto (megadott e-mail cimre) levelet kuld minden esemenyrol - 
> ugye tudod, hogy ma mar egy DNS entry is lehet Unicode?

Es ugye tudod, hogy csak orszagon beluli hasznalatra javasoljak?
Nehany hete volt tema az indexen stb...
Szivad magad ilyenekkel nyugodtan, ha ezt elvezed :)

> A kavefozo, es a mikrosuto valoban nem nagyon igenyli a szoveges (nem 
> numerikus) adatmegadast. Bar lattam mar eloadast olyan (penzbedobos) 
> kavefozorol, amelyik leadta az aktualis feltoltottsegi allapotat interneten, 
> hogy a karbantarto brigad meg tudja tervezni reggel, hogy melyik gepeket 
> kell aznap felkeresni.

Es ezt nyilvan kizarolag ekezetes domainen teheti meg, unicode kodolassal?

>> Tudod, kavefozo, jegykiado automata, munkaido nyilvantarto, riaszto,
>> mikrosuto, POS, stb... Vagy EKG, vagy barmi egyeb.
>
> Vagy TC, vagy levelezo. Leven ezekrol a programokrol volt szo a thread-ben, 
> es ezeknek a programoknak a problemaira (konkretan a levelzore) ajanlottad 
> az otletedet.

Nem en ajanlottam!!!!!!!! Nezz mar korul egy picit!
10..20 eve igy mukodik a levelezes, itt a listan is a levelek 99
szazaleka kodlapos. Ne tuntesd mar fel ugy, mint az en hulye otletemet!
Igy mukodik jelenleg! Az unicode elhanyagolhato reszben van csak jelen,
es egyaltalan nem is kivanatos egy listan.
Ertheto hogy miert irkaltok ilyeneket, teljesen el vagytok rugaszkodva
a valosagtol, alomvilagban eltek...

> Igen, de sok esetben nem az altalanos, hanem a worst-case esetre kell 
> buffert foglalnod. Pl: tudod, hogy egy fajlnevet fogsz kapni, tegyuk fel azt 
> is, hogy 8.3-as megadasban, de, leven UNICODE particiorol jon a nev, nem 
> tudod, hany (a te megoldasod szerinti) kodlapvaltas lesz benne. Leven a 
> nevet tarolni szeretned, le kell foglalnod neki a buffert. Mekkorat 
> foglalsz? Ha jol szamolunk, akkor 32+12 byteot minimum. Hogy mindezt miert 

Mar megint a hulye peldak... En ugy csinalnam, ahogy a Total Commander
temaban is irtam: mindenkeppen pont ugyanazt tarolnam, amit a FS ad nekem.
Nem konvertalnak semmit, hozza sem nyulnek. Ha vissza kell adnom a nevet,
pont ugyanazt adnam amit o adott nekem.
Hogy belsoleg hogy kezelnem, az mar az en dolgom.
Ha meg kell jeleniteni, mindenkeppen tarsitanom kell hozza egy
megjelenitheto karaktert, annak grafikajat.
Az unicode 16 bites, de 65536 karaktert nem tudok tarolni, lehetetlen.
Ezert nyilvan valami belso kodda konvertalnam, kenyszerusegbol, ami az
indexe lenne a font-tablaban a megfelelo karakternek.
Ez egy nagy szopas az unikodban! Baromi korulmenyes es memoria-igenyes
megvalositani. En filenev eseten nagy valoszinuseggel egyaltalan nem
foglalkoznek az ekezethelyes megjelenessel. Buffer gondom, es egyeb
hulye hibaim, amiket osszefantazialtal, biztos nem lenne.

> akarod tarolni? Mert mondjuk MP3 lejatszot csinalsz, ami USB-n csatlakozik 
> egy PC-hez, es ott normal HDD-nek lattszik. Nincs rahatasod arra, hogy a 
> fajlok milyen neven kerulnek ra, kezelned kell tudni oket. Es, ha megengeded 

Hehe... Az USB drive eseten a PC kezel mindent, nekem meg az FS-t sem
kell tudni kezelni, csak blokk szinten elvegezni a muveleteket amit a
PC mond nekem. A kijelzon meg legrosszabb esetben nem lesz jo az ekezet.
Az en Diva Gem lejatszomon sem jo.
Legalabb nez meg egy ilyet, mielott hulyeseget irkalsz!

> hosszu fajlnevek hasznalatat, es teszem azt tobb formatumot is tamogatsz, 
> amiket a kiterjesztes szerint kulonboztetsz meg, akkor maris meg kell 
> keresned a 'string utolso pontja utani reszt' es azt osszehasonlitani elore 
> definialt string-ekkel.

Ezt nyilvan kizarolag unicode-ban lehet megoldani!

> Vagy (szinten MP3 lejatszo), ahol a fajlokban talalhato informaciok alapjan 
> akarsz ABC-sorrendbe rendezni, vagy szurni dolokat. Pl. egy eloado szamait 
> kilistazni. Ehhez is string-eket kell osszehasonlitanod, ami a te abrazolasi 
> modszeredben nem egyszeru feladat.

Sokkal egyszerubb mint az unicode. De megjegyzem, a Diva ezzel sem
foglalkozik, nincsenek ABC sorrendben a szamok, es eloado szerint sem
lehet rendezni, mar csak azert sem, mert honnan tudna hogy ki az eloado?

> Vagy ez se eleg eletszeru pelda? Vagy nem elegge 'beagyazott' alkalmazas?

Nem, egyaltalan nem eletszeru peldak. A problemak meg egyenesen
nevetsegesek. Miert ne lehetne megoldani kodlapokkal?
Es kit erdekel, hogy egy kicsit nehezebb? Fogd fel ugy, mint egy
tomoritest, ami garantaltan 50% hatasfoku, elhanyagolhato CPU-terheles
mellett. LZW-vel lehetne jokat szopni, sokkal nehezebb lenne megcsinalni.

> Amugy meg egy megjegyzes: leven nem koveteled meg, hogy az esc utan legalabb 
> egy karakter alljon, ezert akar egy nulla karaktert tartalmazo string is 
> tettszolegesen hosszu lehet:

Igy van. Jelenleg is ez a helyzet. Folyamatosan johetnek kurzor-pozicionalo,
betumeret-valto, invertalas ki es bekapcsolo, ablak helyzet beallito es
egyeb karakterek. Semmi problemat nem okoz, mi baj lehetne belole?
Amiket osszefantazialtal, teljesen fiktiv problemak, latszik hogy sohasem
foglalkoztal a temaval, csak kotekedsz.

> Persze erre lehet azt mondani, hogy ez elkerulheto, es ez igaz is, csak meg 
> tovabb bonyolitja a string-manipulalo fuggvenyeket.

:)) Ha ez problema lenne, nem terveztem volna en magam igy a sajat
grafikus rendszeremet. Ez egy fiktiv problema, csak a te agyadban letezik,
a valosagban nem. De ha mar itt tartunk, megkerdezem, te hogyan csinalnad
a nyelvfuggo sztringek beepiteset? Vagy a kurzorpozicionalast?
Mert en egyszeruen megadok egy formatum sztringet, az adatokat, a nyelvet
tudja magatol a feldolgozo, es barmilyen kepernyot elo tudok allitani.
Menu, parbeszedablak ikonokkal, figyelmeztetes, stb.., barmi!
Amiket te megoldhatatlan problemanak hiszel, szandekosan belekerult a
rendszerbe, fel sem merult hogy barmi baj lehetne belole.
De azert okits nyugodtan, hatha tanulok valamit amire nem jottem ra ez
alatt a nehany ev alatt miota csinalom :)

> Tovabbra se gyoztel meg arrol, hogy az altalad javasolt megoldas alkalmas 
> altalanos string-abrazolasi modszernek, es mint ilyen a Unicode levaltasara. 

Nem akarom levaltani az unicode-t. Nem erdekel az unicode. Ugyanis az a
problema, amit valoban felig-meddig megold, egy nagyon specialis dolog,
a gyakorlatban nem nagyon fordul elo.

> Ha nem erre gondoltal, akkor viszont nem ertem, miert hoztad fel peldakent a 
> levelezes kodolasi problemainak targyalasakor.

Emailben sem nagyon fordul elo. Csak ha egy emailben ket nyelven
szeretnel irni, melyek kulonbozo ekezeteket hasznalnak.
Baromi ritka, en meg nem lattam ilyet.

> Tantos Andras

-- 
Valenta Ferenc <vf at elte.hu>   Visit me at http://ludens.elte.h u/~vf/
*** This advertising space is for sale ***




More information about the Elektro mailing list