Sziasztok!
>> Nem tudja valaki, hogy mi a turot kene atirni a winNT cmd.exe
>> filejaban, hogy a dir parancsot ls-re cserelje? Mert valahogy ugy
>> raszoktam az ls-re, hogy a dir nem all kezre
>
>http://www.cygnus.com/misc/gnu-win32/
>
>Ennek segitsegevel le lehet forgatni a linux forrasokat.
>
>Esetleg irj egy ls.bat-ot!
Tudok kuldeni egy igazi ls.exe-t! (30k)
Irj maganba, ha kell.
Dragi
Ja, es a bemutatkozas:
Toth Gyorgy (24ev),ex ZX Spectrum, ex 286, ex 486dlc, jelenleg Cyrix-200-as
pentium tulajdonos, 1984-ben kezdtem a billentyuzest:
z80 Basic/z80 ASM/PC ASM/IBM3090 ASM/Pascal/C, meg ne'mi Unix/Linux,
jelenleg foleg webszerkesztes.
http://www.inf.bme.hu/~dragi/
mailto:
|
-- [ From: Horváth Gábor * EMC.Ver #2.5.02 ] --
Sziasztok!
Meg a multkori temat feszegetnem egy kicsit.
Hory irta a legutobbi szamban:
> 1. A win95 igencsak cache-eli az osszes lemezmuveletet. Viszonylag jol.
Na ez meg rendben is volna, nyilvan ezt nem is bizzak a felhasznalora (azert
nincs smartdrv, nehogy valaki probalkozzon annak berhelesevel). De szerintem
a gyorsabb masolas oka nem itt keresendo.
> Egyebkent ha megfigyeled (de lehet hogy csak nekem van regi/rossz win95-om
),
> ha pl. vc-nc-dn-bol lemezre irsz dos ablakban egy 1.4 MB-s file-t, akkor
>rohadt gyorsan kiirja, majd jol leall az egesz rendszer, amig teljesen ki
nem
> irta a file-t. hmmm, igy mar nem is jo...
Igen, ez egy nagy bakloves a reszukrol: cache a FDD write-ra is... :-((( A
smartdrv-ben alapban ez nem volt bekapcsolva, ami nagyon jo. Normalis ember
igy is hagyja... Persze a win95 mar onmagaban nem egy normalis progi, de
ebbe inkabb most ne menjunk bele...
De ha jobban megfigyeljuk, akkor a kovetkezo megallapitast tehetjuk:
Egy 1.44-es floppy tartalmat a win95 beolvassa valahany masodperc alatt. DOS
alatt ez az ido valamivel hosszabb. A fejmozgatas is gyorsabb win95-nel, ezt
siman lehet hallani... Tehat nem a cache miatt gyors a lemezkezeles, hanem
mas az ok. De mi? Erre szeretnek valami epkezlab magyarazatot kapni!
Bocs, ha untattalak benneteket.
Udv.:
HvG
|
On 6 Feb 98 at 9:26,  wrote:
> Sziasztok!
>
> Lett egy kis idom, masfel het szunet utan itt a tema folytatasa:
Ezt most is csak ismetelni tudnam :)
Nos, ha meg mindig nem idegesit sokakat, akkor nezzuk a betu
korbejarasat:
Szoval van nekunk tobb, mint 1 megabyte adatunk, amiben meg kellene
keresni egyaltalan azt, hogy hol is van rajta valami betu. Ha mar
beleakadunk valahogy egybe, akkor jo otletnek tunik korbejarni
kivulrol az alakzat konturjat, mert igy megallapithatjuk, hogy meddig
is tart ez az alakzat. Raadasul a korbejarasnak van egy olyan jo
tulajdonsaga, hogy italic irasnal az egymas fole hajlo betuk nem
zavarnak semmit, amennyiben a szomszedos betuk konturja nem er ossze.
Tehat ez egyben egy elso szegmentalasnak is megfelel, sok esetben
eleve megadja a betut magat.
A konturbejarasnak megvan az a jo oldala is, hogy a betumeret
novekedesevel linearisan nol a feldolgozasi ido, mert csak a keruleti
pixeleket nezzuk meg, mig ha minden pixelt megneznenk, akkor
negyzetesen novekedne a feldolgozasi ido.
No, kezdjuk az elejen: bele kellene akadnunk egy betube. Erre legjobb
valami szisztematikus keresest csinalni, pl. elindulunk a bal felso
sarokbol, es vegigmegyunk a legelso pixelsoron. Ha talalunk
feher-fekete atmenetet, ott mar van valami alakzat, beleakadtunk. Ha
nincs feher-fekete atmenet, ralephetunk a rakovetkezo pixelsor bal
szelso pixelere, es vegigmegyunk azon, stb.
Igy vegulis meg fogjuk talalni a legfelso legbaloldali alakzatot.
Egy pillanatra azert meg maradjunk itt: FELADAT: hogyan lehet ugy
megkeresni ezt a feher-fekete atmenetet, hogy egyszerre mondjuk 8
pixelt keressunk, ne csak egyet? (Azert nem 16 vagy 32 pixelt irtam,
mert ott bejonne a little-endiansag inkompatibilitasa a szokasos
kepabrazolasi elrendezessel, amirol elozo alkalommal irtam.) Szoval
varok otleteket, hogy nehany logikai muvelettel (and, or, xor, shift)
hogyan lehet eldonteni azt, hogy van-e feher-fekete atmenet (ahol a
bal oldali feher pixelt egy fekete pixel koveti jobbrol) az adott
byte-ban? (A byte szeleit nyugodtan hanyagoljatok el.)
No, akkor a korbejaras: (monospaced fonttal erdmes nezni!)
x x x x x x
x x x x x x
x x x x x
x x x x
-> X x x x
x x x
Tegyuk fel, hogy ott allunk a nagy X fekete pixel es a tole balra
levo feher pixel hataranal, a nyil soraban. Kepzeljuk el ugy a
pixeleket, hogy a kozottuk levo hatarolo racspontokban vannak a
koordinatarendszer pontjai, nem pedig a pixel kozeppontjaban. Az
aktualis feher-fekete atmenetet egy rovid vektorral irhatjuk le,
aminek van egy koordinataja, es egy iranya (az irany 4 fele lehet:
fel, jobbra, le, balra) Jelen pillanatban a vektor az X bal szelso
hataranal van, es felfele mutat.
(Ezen az abran "kinagyitottam" a pixeleket):
aa bb
aa bb
^ XX
| XX
Ertelemszeruen a vektor bal oldalan feher pixel van, a jobb oldalon
fekete (X). Elotte balra (a) es elotte jobbra (b) lehet akar fekete,
akar feher pixel. Amikor majd ez a vektor vegigmegy a konturon, es
forog ide-oda, akkor is jelentse az a es b pont az aktualis irany
szerint ugyanezeket a relativ helyeket. Tehat amikor pl. a betu
tetejen jar a vektor, akkor igy allunk:
aa
aa
-->
XX bb
XX bb
Ilyenkor is a vektortol (relativan) "balra" feher pixel van, "jobbra"
pedig fekete (az X pixel).
Remelem, ertheto volt, kicsit nehez ezt leirni e-mail-ben.
Korbejaras soran ugyelnunk kell majd arra, hogy a vektortol "balra"
mindig feher pixel legyen, tole "jobbra" pedig mindig fekete, hiszen
ekkor maradunk a konturon. (Az alakzatot az oramutato jarasaval azonos
iranyban akarjuk korbejarni.)
Nos, a korbejaras elemi lepese a kovetkezo algoritmus szerint allhat
elo:
if fekete(a) fordul_balra
else if fekete(b) egyenesen_tovabb
else fordul_jobbra
Ezeket az elemi lepeseket akkor kell abbahagyni, amikor visszaertunk
a kiindulasi vektorunkra.
Eloszor mindenki lassa be, hogy ez az algoritmus korbejarna egyetlen
fekete pixelt, vagy pl. a fentebbi alakzatot.
Ugyanennek az algoritmusnak a kiforditottjat is ideirom:
if feher(b) fordul_jobbra
else if feher(a) egyenesen_tovabb
else fordul_balra
Ez ugy allt elo, hogy megnegaltam a felteteleket is (a ket pixel
tesztelesenek sorrendjenek cserejevel egyutt), es megnegaltam a
fordulasokat is. Ez a dupla negalas a
not(A and B) = not(A) or not(B)
bool azonossag mintajara azt sugallja, hogy ez az algoritmus is jol
kell mukodjon. Az elsot MAX-nak nevezzuk, a masodikat MIN-nek.
Eloszor lassatok be, hogy ez a masodik algoritmus is jol korbejar pl.
egy egyetlen pixelbol allo "alakzatot".
A ketto kozott megiscsak van egy pici kulonbseg, ugyhogy meg egy
FELADAT vallalkozo szellemueknek (remelem, vagytok egy paran :)
Mi a kulonbseg a ket algoritmus kozott? Melyik a jobb? Egyaltalan
jobb valamelyik?
Varom a leveleket a listara! (Aztan legyen am! :)
István
-- Istvan Marosi -- http://www.sch.bme.hu/~marosi --
-- Recosoft Ltd. -- mailto: --
|
