Hollosi Information eXchange /HIX/
HIX CODER 854
Copyright (C) HIX
2000-06-17
Új cikk beküldése (a cikk tartalma az író felelőssége)
Megrendelés Lemondás
1 Re: Linux GUI vs Windows (mind)  36 sor     (cikkei)
2 Perl & CGI doksik a weben (mind)  9 sor     (cikkei)
3 Re: thread & timer (mind)  19 sor     (cikkei)
4 Re: c & pascal & protected mode & miegymas... (mind)  31 sor     (cikkei)
5 Re: negyzetgyok (mind)  3 sor     (cikkei)
6 Re: VB, ADO vezerlo (mind)  43 sor     (cikkei)
7 Re: Sugo fajl megnyitasa NT alatt (mind)  6 sor     (cikkei)
8 Re: c & pascal & protected mode & miegymas... (mind)  62 sor     (cikkei)
9 Re: gyokfv. (mind)  45 sor     (cikkei)

+ - Re: Linux GUI vs Windows (mind) VÁLASZ  Feladó: (cikkei)

> 3) Szep-szep ez az open source dolog (En is szeretem) de oszinten,
> szerinted az application programmerek hany szazalekanak van meg ahhoz
> a tudasa, hogy egy API kodjaban kepes legyen megtalalni a bugot? (Ide
> vago link: http://www.igpm.rwth-aachen.de/~albrecht/hungry.html) Hat
> meg ha csak azt nezzuk, akine van kedve/ideje atnezni azt a jopar 1000
> kodsort, hogy tenylegesen megtalalja?

Azt nem tudom, hogy hanynak nincs meg a tudasa, viszont sejtem, hogy
hanynak nincs meg hozza a batorsaga. Azonkivul a cegek hozzaallasa is azt
tukrozi, hogy a programozoiknak nem a library-k hibait, hanem a sajat
kodjukat kell foltozgatniuk munkaidoben. En csupan azt allitom, hogy ha a
hozzaallas nem ilye n lenne, akkor hamarabb kialakulhatnanak stabil
konyvtarak, es osszessegeben rengeteg idot takaritananak meg a programozok
maguknak.

> Ha ilyen sok motifos cuccot hasznalsz, akkor nem lenne erdemesebb
> felpakolni a libeket, & dinamikusan linkelt verziokat hasznalni?

Minden bizonnyal, de annak idejen, amikor a lesstif meg korant sem volt
megbizhato felpakoltam egy par statikusan linkelt alkalmazast, es ugy is
maradt. Azota valahogy idegenkedem a Motifos cuccoktol (sokszor volt mar
olyan, hogy ha meglattam a spacifikacioban, hogy Motifot igenyel le sem
toltottem). Egyetlen elonye amit te is emlitettel, hogy mivel regebbi
ezert rengeteg kod letezik hozza, nyilvan nagyon sok programozo hasznalja
ezert ha munkahelyet valtoztatnak, nem kell uj konyvtarakat megtanulniuk
-- ugy gondolom csak ido kerdese, es az uj rivalisokkal is hasonlo lesz a
helyzet.

Apropo: a Motif meg nem objektum orientalt, ugye? Esetleg meg ez is
mellette szolhat, ha valaki nagyon idegenkedik az oo programozastol.

Udv, Tamas

Tamas Rudnai / Sophos Plc
mailto:
http://www.sophos.com
+ - Perl & CGI doksik a weben (mind) VÁLASZ  Feladó: (cikkei)

Sziasztok 
:-)

Szuksegem volna Perl & CGI programozassal foglalkozo honlapok cimere.
ELore is koszonom,

Ati
P.s: Rebel - ha el tudnad meg egyszer kuldeni a honlapod cimet...
:-)
+ - Re: thread & timer (mind) VÁLASZ  Feladó: (cikkei)

>Szeretnék egy olyan fv-t készíteni, ami a
>kb. 0,5 másodpercenként meghívódik és egy
>külön szálon fut, tehát függetlenül az
>alkalmazástól.  [ Hasonló dologra kéne,
>mint a TTimer komponens fv-nye ami az
>Interval tulajdonságában megadott értéknek
>megfelelő gyakorisággal hívódik meg...de
>lényeges, hogy külön szálon!!! ]
A TThread-bol szarmaztass egy sajat osztalyt, aminek override-old az
Execute() metodusat. Ha ebbol letrehozol egy peldanyt (TMyThread.Create),
akkor ez egy kulon szalat fog nyitni, amiben az Execute() metodust fogja
futtatni. (Amikor az befejezodik akkor lesz vege a szal futasnak is.)
Az Execute()-ban aztan csinalj egy ciklust aminek vegen periodikusan
kiadogatsz egy Sleep(500)-at! Igy a szal ugy fog mukodni, hogy a ciklus
magjanak vegrehajtasa utan 500ms-ot (az altalad emliett 0,5mp-et) "pihenni"
fog, ami utan ujra "feleled" es ujra vegrehajtja a ciklusmagot... Igy jo
lesz, nem?

Gabor
+ - Re: c & pascal & protected mode & miegymas... (mind) VÁLASZ  Feladó: (cikkei)

>> Ebbe kenytelen vagyok belekotni, mert legjobb tudomasom szerint
>> 16-bites vedett modu program ha megfeszul sem tud 64K-nal nagyobb
>> szegmenst letrehozni (persze csak ha standard DPMI szolgaltatasokat
>> hasznal
>De, tud bizony... DPMI hivassal (int 31/501) lehet 64k-nal nagyobb
>osszefuggo linearis memoriatartomanyt foglalni, aztan egy masik DPMI
Nem ugyanarrol beszelunk: en azt mondtam, hogy nem lehet 64k-nal nagyobb
szegments letrehozni, es nem azt, hogy nem lehet olyan teruletet
allokaltatni, ami a linearis memoriaban 64K-nal nagyobb osszefuggo teruletet
alkot. Ti. ez utobbi ugyanis hiaba sikerul, ha nem tudod 32-bites
offszettekkel megcimezni, akkor a gyakorlati jelentosege 0. (Ezert van az,
hogy hiaba van linear framebuffer, semmit sem er 16-bites DPMI alatt, mert
nem tudod egyetlen szegmenssel megcimezni...)

>hivassal (31/0) deszkriptort allokalsz, es egy harmadikkal (31/0c)
>kitoltod a belsejet ugy, ahogy akarod. Ha a deszkriptor G bitjet 1-be
>allitod, akkor nemcsak hogy 64k-nal, de 386-os procitol kezdve 1
>meganal hosszabb szelektorod is lehet, es azt nyugodtan hasznalhatod
>16 bites programbol is. [...]
En egy idoben kiserleteztem ilyen dolgokkal (pont az LFB kapcsan), es sajnos
eleg lesujtoak voltak a tapasztalataim. Nevezetesen arrol van szo, hogy -
emlekeim szerint - az emlitett (a deszkriptor kozvetlen irasat lehetove)
funkcio sem W9X-ek alatt, sem pl. a Borland sajat DPMI extendere alatt nem
volt hasznalhato, tehat nem lehetett 64K-nal nagyobb szegmenst letrehozni.
(A SET SEGMENT LIMIT DPMI hivas pedig eleve csak <=65535 meretet fogad el
16-bites progiktol.)
Valoszinuleg van olyan DPMI host ami alatt ezek a funkciok kitunoen
mukodnek, azonban pl. manapsag eleg nagy hiba olyan progit kesziteni, ami
keptelen dos boxban futni...

Gabor
+ - Re: negyzetgyok (mind) VÁLASZ  Feladó: (cikkei)

Es honnan tudom, hogy meddig ismeteljem a szamolast?

Üdvözlettel: Restye Gábor
+ - Re: VB, ADO vezerlo (mind) VÁLASZ  Feladó: (cikkei)

Sziasztok,

<> wrote in message news:...

> Mivel ez egy atmeneti adatbazis, kilepeskor ki kellene torolni. Abba
> mar-mar belenyugodtam, hogy az ado1.Recordset.Delete adAffectAll -ra
> lehal, hogy ebben a kontextben nem engedelyezett (???), de ha ezzel a
> for ciklussal maszok vegig rajt, akkor
> 1. : Ha senki nem bantotta a datagridet, akkor szepen lefut
> 2. : Ha kattintgatott a user (egyelore en :-) a datagriden, akkor
> elszall, mindenfele valtozatos hibaval, de leginkabb azzal, hogy a
> legutolso update ota megvaltozott az adatbazis.

Két ötlet:

1. Egyszerűen csapd agyon a rekordokat egy SQL-paranccsal:

dim cnn as ADODB.Connection
 ....
cnn.Execute "delete from YourTable"

ez a Recordset "háta mögött" közvetlenül az adatbázissal töröltet.
Ha a táblát is ki akarod törölni, akkor nem felejtsd el a "DROP TABLE
YourTable" parancsot se.

2. Az ADO-nál ezeket a konfliktusokat az idézi elő, hogy a Recordset tudja,
hogy mi volt régen a táblában. Ha ehhez képest változott az adatbázis, akkor
a Recordset Resync parancsával tudod megnyugtatni:

rs.Resync adAffectAll, adResyncAllValues

idézet a dokumentációból: adResyncAllValues 2 Default. Overwrites data, and
pending updates are canceled.

de szerintem ez költségesebb, mint egyszerűen bezárni és elhajítani a
recordsetet, és direktben törölni, ugyanis a Resync a szinkronizálás miatt
újraolvassa az érintett rekordokat, ami egy ideiglenes tábla törlésénél
szerintem teljesen felesleges. Ha nagyon rámész a sebességre, akkor még egy
tárolt eljárást is érdemes csinálnod a törlésre, mert az nem kell mindig
újrafordítania az SQL-szervernek.

Üdv,
    - Laci
+ - Re: Sugo fajl megnyitasa NT alatt (mind) VÁLASZ  Feladó: (cikkei)

Hali

Probald a ShellExecute vagy ShellExecuteEx
fuggvenyek vmelyikevel.

Andras
+ - Re: c & pascal & protected mode & miegymas... (mind) VÁLASZ  Feladó: (cikkei)

On 16 Jun 00 at 11:06, Sting > wrote:

> > > Ebbe kenytelen vagyok belekotni, mert legjobb tudomasom
> > > szerint 16-bites vedett modu program ha megfeszul sem tud
> > > 64K-nal nagyobb szegmenst letrehozni (persze csak ha standard
> > > DPMI szolgaltatasokat hasznal
> >
> > De, tud bizony... DPMI hivassal (int 31/501) lehet 64k-nal 
> > nagyobb osszefuggo linearis memoriatartomanyt foglalni, aztan egy 
>
> Nem ugyanarrol beszelunk: en azt mondtam, hogy nem lehet 64k-nal
> nagyobb szegments letrehozni, es nem azt, hogy nem lehet olyan
> teruletet allokaltatni, ami a linearis memoriaban 64K-nal nagyobb
> osszefuggo teruletet alkot.

Ugyanarrol beszelunk, de az osszefuggo linearis tartomany meg csak az 
elso lepes.

> Ti. ez utobbi ugyanis hiaba sikerul, ha nem tudod 32-bites
> offszettekkel megcimezni, akkor a gyakorlati jelentosege 0.

Amit a folytatasban irtam, epp ezt csinalja: egy darab nagy 
'szegmenst' csinal hozza. Ez volt a folytatas:

> >hivassal (31/0) deszkriptort allokalsz, es egy harmadikkal (31/0c)
> >kitoltod a belsejet ugy, ahogy akarod. Ha a deszkriptor G bitjet 1-be

Ezzel a 0c dpmi hivassal a deszkriptornak mind a 8 byte-jat be tudod
allitani ugy, ahogy akarod, mert az altalad kitoltott 8 byte-os
puffert egyszeruen belemasolja a deszkriptorba. Tehat beallithato
64k-nal nagyobb szelektor is. Most direkt elolvastam a DPMI 
specifikaciot, azt irja, hogy a hivas 2 dolgot ellenoriz: egyreszt az 
access rights/type bitjeinek megfelelo kitolteset, masreszt azt, hogy 
a cimzendo linearis terulet azon belul legyen, amit a program kapott.

> Nevezetesen arrol van szo, hogy - emlekeim szerint - az emlitett (a
> deszkriptor kozvetlen irasat lehetove) funkcio sem W9X-ek alatt,
> sem pl. a Borland sajat DPMI extendere alatt nem volt hasznalhato,
> tehat nem lehetett 64K-nal nagyobb szegmenst letrehozni.

Borlandos extender alatt nem probaltam, de w9x alatt termeszetesen 
megy rendesen. Nem tudom, neked miert nem sikerult, ma mi is ezt 
hasznaljuk dos boxbol a 16 bites fejlesztocuccainkban.

> (A SET SEGMENT LIMIT DPMI hivas pedig eleve csak <=65535 meretet
> fogad el 16-bites progiktol.)

Ezt se probaltam, de a leirasa szerint mennie kellene, ha a dpmi 
*host* (tehat nem a kliens) 32 bites. Lehet, hogy a borlandos host 
csak 16 bites, de a win alatti dpmi 32 bites... Most gyorsan 
kiprobaltam 900k-val, megy is.

> Valoszinuleg van olyan DPMI host ami alatt ezek a funkciok
> kitunoen mukodnek, azonban pl. manapsag eleg nagy hiba olyan progit
> kesziteni, ami keptelen dos boxban futni...

Ezzel egyetertek, de tapasztalatom szerint a win alatti dpmi hosttal 
nincs ilyen problema.

István
--  Istvan Marosi  --  http://www.sch.bme.hu/~marosi  --
--  Recosoft Ltd.  --  mailto:  --
+ - Re: gyokfv. (mind) VÁLASZ  Feladó: (cikkei)

On 15 Jun 00 at 5:23,  wrote:

> 2. 'recosoft' sajnos figyelmen kivul hagyta, hogy az altala szamolt
> 'kovetkezo kozelito ertek' sqrt2-e/2 alakja nem azt jelenti, hogy a
> hiba felezodik! Nem egy uj bit keletkezik iteracionkent, hanem a
> helyes jegyek szama minden lepesben _megduplazodik_, ami azt jelenti,

Biztos igazad van, de nem ertem, hogy miert. En ugy gondolkodtam,
hogy ha felirnank (ha tudnank) az igazi sqrt2-ot binarisan,
alairnank az aktualis hibat (ha tudnank) binarisan, akkor a hiba egy
iteracional allna N darab 0-abol, amit egy 1-es (es sok kisebb
helyierteku binaris jegy) kovet. Ha a ket szamot osszeadjuk,
megkapjuk az aktualis kozelitesunket, amiben a hiba elso 1-ese
elrontotta a kozelites N-edik (vagy N+1-edik) bitjet. Ket iteracio
mulva sqrt2+e/4 lesz a kozelitesunk, vagyis a hiba jobbra
shiftelodott 2-vel, igy az N+2-edik bitet rontotta el. Ez szerintem
azt jelenti, hogy egy iteracio 1 bitet hoz. Ha valahol logikai hibat
vétettem, hol. (Egyebkent a Negyjegyu fuggvenytablazat szerint is 
duplazodik a helyes jegyek szama, de ettol sem ertem jobban).

Azota utananeztem a gyok2 sokjegyu kiszamitasa tortenetenek a
'Matematikai problemak megoldasainak szamitogepes modszerei' cimu jo
regi (vagy 20 eve vettem) konyvben. Gyakorlatilag mindenki mas
algoritmust hasznalt, csak egyvalaki csinalta ezt a modszert (amit
Newton-rol neveztek el, pedig mar Heron feltalalta). A legegyszerubb
modszer az ott leirtak kozul szerintem talan az, ami az
Xnext=X*(3/2-X^2) iteraciot hasznalja (gyok2 felehez konvergal),
hisz itt csak szorozni meg kivonni kell. 

A konyv irasa kori legutolso modszerrel egymillio jegyre szamoltak ki
gyok2-ot csupan 17 iteracioval! Csak roviden a lenyege: Van vegtelen
sok P es Q egesz szamparos, amik specialis tulajdonsaga az, hogy
kielegitik a P^2-N*Q^2=4 Pell egyenletet egy adott N-re, ahol N nem
negyzetszam. Ezeknek a hanyadosa (vagyis P/Q) gyok-N-hez konvergal
kb. 1/Q^2 nagysagrendu hibaval (ha jol szamolom). Az iteracios lepes:
Pnext=P^2-2, Qnext=P*Q, ezek szinten kielegitik a Pell egyenletet, es
a szamok nagysagrendje marha gyorsan megugrik. N=2-hoz P0=6726 es
Q0=4756-bol lehet elindulni, a 17-edik iteracioban P17 es Q17 mar
500ezer jegyu szamok, ezeket kell csak elosztani egymassal egymillio
jegy pontossaggal (vagyis csak a vegen kell egyetlen osztas,
iteracionkent csak szorozni kell). 

István
--  Istvan Marosi  --  http://www.sch.bme.hu/~marosi  --
--  Recosoft Ltd.  --  mailto:  --

AGYKONTROLL ALLAT AUTO AZSIA BUDAPEST CODER DOSZ FELVIDEK FILM FILOZOFIA FORUM GURU HANG HIPHOP HIRDETES HIRMONDO HIXDVD HUDOM HUNGARY JATEK KEP KONYHA KONYV KORNYESZ KUKKER KULTURA LINUX MAGELLAN MAHAL MOBIL MOKA MOZAIK NARANCS NARANCS1 NY NYELV OTTHON OTTHONKA PARA RANDI REJTVENY SCM SPORT SZABAD SZALON TANC TIPP TUDOMANY UK UTAZAS UTLEVEL VITA WEBMESTER WINDOWS