Haliho Lang Attila!

>visszaadja a BASIC-nek. (Mindharom variacio elofordulhat, meg a mar
>bekonvertalt file-jaimat se szeretnem eldobni.)
>  2. Ezt olyan gyorsan csinalja, mintha gepi kodban lenne -- peldaul mert
>abban van.

Hogy szertned a basicet es az asm kodot osszehazasitani? (Egyaltalan ezt
akarod?) Ha van valami cool basic fordito, ami beepit mas nyelvet, az
erdekelne. Koszi.

Sziasztok!

A hetvegen kicsit utananeztem mit lehet tenni a LPT
translator ugyben, mert multkori irasomban nem sok
kezzelfoghato volt.

Tamas Gergelynek irta:
> A kinalkozo lehetoseg a BiOS 17h -es megszakitasa.

Nem probaltam, de gondolom ez is egy jo megoldas lehet.
Csak egy gond van vele, hogy nem egyedi karaktereket
kell cserelni, hanem stringeket. Vagyis atmenetileg
tarolni kell egy sornyi adatot, es csak utana lehet
tovabbkuldeni.

Megprobaltam irni egy kezdetleges progit, amit tovabb-
fejlesztve estleg el lehet jutni a megoldashoz, ha van
valakinek kedve. Ez egy device-driver, ami alattomosan
az LPT1 nevet viseli. Mivel a DOS device listajaban az
installalt deviceok elorebb szerepelnek mint az alap-
ertelmezettek, ezert az atiranyitas ezzel meg is oldo-
dott. A mukodese egyszeru, az elso hivas soran megkeresi
az eredeti deviceot, es az outputon kivul minden hivast
neki tovabbit. Az outputnal pedig sorokra bontja az
adatokat, soronkent elvegzi a cseret, majd tovabbkuldi.
Egyenlore csak probakeppen a 'b' betut csereltem 'B'-re,
hogy lassam muxik-e, es en a magam reszerol ezzel be is
fejeztem eziranyu tevekenysegemet. Ha valakinek kedve van
befejezni akkor elkuldom a forraskodot.

A sajat kerdesemmel kapcsolatban Csiszar L-nek:
>Ez nem valami olyasmi mint egy RAMDISK?
Ez nekem is eszembe jutott, de nem. Mert a RAMDISK egy
lemezt szimulal a memoriaban, amit o maga csak szektor
szinten kezel, a DOS alakitja ki rajta a sajat FAT
filerendszeret. Nekem viszont pont az lenne a celom, hogy
valamilyen masfajta filerendszert tudjon kezelni a DOS.

***********

Assembly + QBasic Attilanak:

Sajnos nem ismerem a QB-t, igy viszont eleg nehez segiteni
(pedig maga a rutin nem tul bonyolult). Szoval azt kene
tudni pontosan hogyan adja at a QB a parametereket, es
hogy veszi vissza (ha kell). At kellene adni a filehandle-t,
meg mondjuk egy pointert, hogy hova lehet beolvasni a sort.
Amit leirtal abbol nekem ugy tunik, hogy az adott rutin
folyamatosan fogja vegigolvasni az adott file-t soronkent.
Ebben az esetben nincs szukseg sem a sorszamra, sem a file-
pointerre. Raadasul ha van eleg hely a memoriaban, akkor
erdemes lenne pufferelni, es mondjuk vagy 32 kilonkent be-
olvasni, igy mar tenyleg gyors lenne.

Udv
Emze
---
MailTo: 

Hello!

Van valaki a vonalban, aki szurja-vagja a Java RMI-t? (Remote Method
Invocation)

U.i. az istennek sem akar menni, meghozza egy feletteb furcsa
hibajelentest produkal. Na azert nem teljesen nem megy, a gond az, hogy
tobb (>70) user van es valoszinuleg ez boritja fel az rmi-registry-t.

Rovid korkep: Unix-alapu halo (intel procik), legtobb gep Linuxos, ket
System V, egy AIX. Mind a 70 user ugyanazt a feladatot programozza, egy
szervert, ami bejelentkezik az rmi-registrynel, es varja a client-ek
hivasait. Namarmost ha lefordul a szerver, akkor jon az rmi-compiler, ami
letrehozza a Stub es Skeleton fajlokat. A szerver viszont nem tud
bejelentkezni az rmiregistry-nel, mert az nem talalja a Stub-file-t es egy
ClassNotFoundException-t dob. Pedig epp az iment lett letrehozva...
Olvasasi jogok rendben, $CLASSPATH rendben.

Ennyi lenne. Egyszeruen keptelenseg, hogy nalunk van a hiba. Azt
gyanitjuk, hogy ez meg a Java fiatalsaganak (eretlensegenek) tudhato be.

Szoval tud-e valaki workaround-ot erre a problemara? A SUN RMI-FAQ-ja azt
mondja, hogy a CLASSPATH-nak a server konyvtaraba kell mutatnia. Oda
mutat, megis fellep a hiba. Arra is gondultunk, hogy azzal van a gond,
hogy az osszes usernek az object-je egyforman van elnevezve. Atneveztettuk
mindet egyertelmure (hogy orultek a userek ;), es ugyanott vagyunk...

Barna


Erdekesseg I: hogy mennyire eretlen a Java, az abbol is latszik, hogy az
rmiregistry egy het alatt 200 MB-ra nott. Memory leaks... :-) Feltunt,
hogy sokat swappel a gep ;-). Most minden nap ujrainditjuk, akarcsak
Windows lenne. :-)

Erdekesseg II: A Javaban nincs olyan hogy "felszabaditok memoriat". Az egy
process altal felszabadult memoriat csak ugyanaz a process kaphatja
vissza. Egy Java-process terjedelme tehat sosem csokken, legfeljebb no. Az
ok ertheto: security.... 

Erdekesseg III: a Linux-os Java implementacio meglepoen rossz... Minden
Java process-nek min. 20 MB kell...

Szia!

> Szoval MFC C++ vagy WinApi C?

Hat "nagyobb" dologra mindenkepp MFC-t javaslok. Az igaz, hogy az OOP nem
mindenre gyogyir, de egy Windows (tehat grafika-orientalt) program
fejlesztesehez egyszeruen alkalmasabb az OO paradigma, mint a "szokvanyos"
strukturalt programozas.

Utobbinal nagyon hamar elveszted (-m) a fonalat a sok message handler meg
window class meg ilyesmi "badarsag" :) miatt. Tenyleg hatalmas kodhegyeket
irsz, es szinte semmire sem mesz vele. 

Arrol nem is beszelve, hogy kenytelen vagy mindig ujra feltalalni a
kereket. MFC-ben egyszeruen fogod a CDialog-ot, es szarmaztatsz belole egy
sajat dialogboxot. Meg semmit nem csinaltal, a Te boxod megis tudja
mindazt, amit egy dialognak tudnia kell. Atirod az "OnInitDialog()"-ot
hogy mit tortenjek, ha megjelenik. Szamomra ez logikusabbnak tunik, mint
mindenfele message loop-okkal :) veszodni (holott valojaban ez tortenik
:). 

Nem tudom, mennyire ismered az MFC-t, ha meg egyaltalan nem, akkor... hat
csak azt mondom, hogy "nem trivialis". Eltart egy darabig, amig az ember
kiismeri magat (vagy legalabbis ezt hiszi). En azt mondom, hogy kb. 2
honap MFC-tanulas kell, mielott erdemes belevagni egy nagyobb projektbe. 

Attol kezdve viszont az MFC jol hasznalhato. En speciel a
"document-view"-koncepcioval nem igazan tudok mit kezdeni, de ezt
szerencsere nem kotelezo hasznalni.

Egyebkent a C++ nem olyan sokkal lassabb mint a C, mivel a fordito eleg
sokat tud optimalizalni ill. mivel a C++ egy "strong type checked
language" (nem tudom a magyar megfelelojet), nincs szukseg runtime
interpretalasra (kivetel a virtual dolgok).

Mas dolog persze, hogy az MFC-C++ tenyleg nagy exe-t eredmenyez (persze
csak ha statikusan linkeled). De szerintem meg mindig jo gyors. 

Es vegul egy erdekesseg: mult heten hallgattam meg az egyetemen egy
BeOS-prezentaciot, ugyanis Chris Doublers, a Be europai fo Coderje :)
jarja az oreg kontinenset, hogy nepszerusitse a BeOS-t. Tudjatok, egy uj
OS, ami meg fogja valtani a vilagot blabla.. :) egy dolgot azonban tenyleg
erdekesnek tartok: a rendszer 100%-ig objektum orientalt, es (kizarolag)
ugy is kell programozni. Tehat nem mint az MFC-ben, hogy a CWindow csak
mint egy buborek korulzarja a WinAPI-t es elhiteti velunk, hogy tenyleg
van olyan, hogy "ablak-osztaly". A BeOS-ben tenyleg igy van. 

Ciao,
Barna

>Felado : Velencei Tibor
>E-mail :  [Hungary]
> - - - - - - - - - - - - - - - - - - - - - - - - - - - -
>A dolog elso resze: C vagy C++. Ugye C-ben az ember strukturaltan
>programozik, es ugy istenigazabol igyekszik kihasznalni a nyelv adta
>lehetosegeket, es az eredmeny tobbnyire (a developer ugyessegehez
>kepest) tomor, gyors, hatekony futtathato kod. De esetleg konnyebb
Ahogy az Igazi Programozo mondja:
"Mindent meg lehet csinalni C-ben. amit nem lehet C-ben megcsinalni azt
meg lehet csinalni assemblyben. amit nem lehet megcsinalni assemblyben
azt nem lehet megcsinalni."
En nem szoktam sima C forrasokba belezavarodni, objektumosba annal
inkabb. Talan azert mert C az anyanyelvem, az objektumos forrasok pont
attol elvarazsoltak hogy az objektumok kiagyaloi kvazi atirjak a
nyelvet. A jo oreg K&R C-ben van az a puritan elegancia amit az
ujabbakbol hianyzik.

>belezavarodni, nehezebb dokumentalni, macerasabb tovabbfejleszteni.
>C++-ban jobban bele vagyunk kenyszeritve az atgondoltabb tervezesre,
>nagyon szep, "valosproblemakozelibb" forrast tudunk gyartani. Egyszerubb
A valos problemahoz lehet kozelibb, de a gephez nem:) "Valos problema"
lehet pl. ha 1000 db formot kell kezelned, vagy egyeb, egerkattingatos
progit kell hogy irjal. Valahogy nem ezt a fajta programozast erzem a
programozoi munka csucsanak, ahnem amikor erdemi szamitasi feladatokat
old meg az ember amihez szamitogep kell, es nem formokat mutogat stupid
usereknek.

>szepen dokumentalni, tovabbfejleszteni, talan alkalmasabb csoportmunkara

Dokumentalas: A robusztus OO konyvtarak mind attekinthetetlensegbe
fulladnak. Ez tapasztalati teny. OO-ban kodsorok irasa helyett
bogaraszhatsz a property meg metodus listakban. En azt az objektumot
szeretem amit en terveztem.

Tovabbfejlesztes: Egy Oracle-os generalt VB forrast tiszta gany
tovabbfejleszteni, javitani, mert annyira el van bonyolitva az egesz
hogy attekinteni szerintem nem lehet, es egyszerubb ujrairni egy-egy
reszt OO flancolas nelkul. Azt is ganyolasnak erzem, amikor pl. Visual
BASICben minduntalan a help examplekbol kell copyzni es erdemi munka
helyett a property es metodus listakban bogaraszok, hogy ezt vajon hogy
lehet megcsinalni? Es kiderul hogy sehogy, mert a OO konyvtarat ugy
terveztek, hogy csak azt tudd vele megcsinalni amit a keszitoje akar.
Kvazi kezenfogva vezet hogy ezt szabad Gezuka de ezzel mar ne foglalkozz
:(((. Csak nem veszed eszre.

Csoportmunka: joerzesu programozo nem turkal mas programozok forrasaban
hanem elhiszi hogy a fgv. azt csinalja azokkal a parameterekkel ami le
van irva a fejlecben. Igazabol ez sem OO fuggo mert ha van egy jo modul
strukturad, akkor lenyegtelen hogy K&R C vagy csicsas konyvtar, a jol
megirt fgv-eknek es moduloknak ugysincs mellekhatasuk a tobbire.
Modszertanilag nem latom indokoltnak hogy kulonbseget tegyunk a
strukturalt es az OO kozott. Mindegyiket lehet nagyon jol es 
csinalni, ugyanazokkal a semakkal.

Es egy fontos: ha valoban konnyu dokumentalni egy kodot, akkor az nekunk
codereknek regen rossz:((( Mert ekkor kapasbol nelkulozhetove valunk,
lecserelhetnek minket -a konyvtarainkkal egyutt- hisz kiadtuk a tudast
magunkbol. (ez igy nem biztos hogy jo nekunk) A Verbeli Coder mindig
tesz "hatsobejarokat" es olyan trukkoket a kodjaba amihez lehetoleg csak
o tud hozzapiszkalni.

>is. (De szerintem a modszeres strukturalt programozassal ugyanezt el
>lehet erni). Sza'l a C++ (objektumorientalt programozas) fejlettebb
>fejlesztesi eszkoz, aminek torvenyszeru velejaroja, hogy a futtathato
>kod nagyobb, lassabb, lomhabb.
Igy van... Mert a sok nagy objektum jellemzoinek es fgv.-einek csak kis
toredeket hasznalod, igy iszonyuan pazarlo, korulmenyes, lassu lesz. Es
egy fekete dobozt programozol, nem is tudod, hogy a hatterben mi zajlik
a privat fgv-ekben, mi mivel interferal. Ez az, amitol az Igazi
Programozonak -szerintem- folall a szor a hatan.

>kepest (tapasztalatom szerint) hatekonyabb futtathato kod keletkezik
>objektumorientalt turbo pascalbol, mint turbo c++-bol.) (a delphit
>inkabb hagyjuk (nem ismerem). Tapasztalat ilyen megkozelitesbol?)
Tapasztalatom szerint a sebesseg sorrend: C/C++, API, MFC. Utobbi ketto
jol lemaradva, igaz az elobbi ketto Linux, az utobbi ketto windows.

>A dolog masik resze: WinApi(32) MFC. Mint tudjuk az MFC egy tok jo
>(es tenyleg az) C++ eszkozkeszlet Wines alkalmazasok gyartasahoz.
Pontosabban: a wines GUI eleresehez es kezelesehez. Tehat hogy
editboxaid meg ikonjaid meg nyomogombjaid legyenek. Ebben nagyon jo a
winAPI.
De ha VALODI szamitogepes feladatokat akarsz megoldani, pl. gravitacios
kollapszus modellezes, vagy atombomba szimulacio nagygepeken, vagy bika
nagy adatbazisok kezelese - nos, akkor elfelejtheted az egesz windowst
ugy ahogy van. se api, se mfc, se egyeb flanc, rajossz hogy ezeket a jo
oreg C-ben lehet megoldani legeszerubben, a legjobban dokumentalhatoan,
a LEGHATEKONYABBAN a legmegbizhatobban, es persze UNIX alatt.
Ilyen komoly progiknal mar lenyegtelen dolog a kezeloi felulet -ilyen
vagy olyan nyomogomb, listbox- ezek csicsanak tunnek a szoftverbe es 
hw-be olt tobbi rengeteg munka mellett.

>Es termeszetesen a progi nagy, lomha, lassu (lassabb, mint mfc nelkul).
>Tudom a hardware fejlodik, meg miegymas, de akkor is!
En magamnak veszek erosebb vasat, nem B.G.-nek.

>(Meg az is erdekes hogy az MS oprendszereken
>szimpatikusabb az MFC nem ?) (vagy a fejlesztoszkozoknel nincs MS
>flame?)
Bevallom nekem az MS ugy altalaban nem szimpatikus, hosszu lenne
kifejteni hogy miert. A fejlesztoeszkozei baromi nagyok, lassuak,
instabilak. Legutobb felorat tokoltem azzal, hogy nullarol felrakva a
MSVC5-ot egy piti konzol alkalmazast osszekalapaltam. Ugyanez Linux
alatt 5 perc, pedig abban sincs tobb rutinom, sot...
Arra akarok ezzel celozni h. ugyanaz van a fejlesztoeszkozoknel is, mint
a Word, Excel, stb. eseteben: nyomatjak az egyre nagyobb, lassubb,
csicsasabb verziokat amelyek egyre instabilabbak, egyre nehezebb
konfigelni oket, es a funkciokeszletuk 99%a a kutyanak se kell. Viszont
eszi a vinyot meg a memoriat meg a CPUt.

Vegre hadd jojjon a javaslatom:
1/ valaszd szet a UI (user interface) funkciokat es a program tobbi
reszet. Kiderul mi az, amit az usernek allitania kell, tehat erdemi
input. Az az elegans, ha ez minel kisebb. Gagyi szokas, hogy minden
lenyegtelen hulyesegre millio opcio van, csak a lenyeges dolgok nem
allithatok (a la M$Office)
Ugyanigy, mi az output?
2/ dontsd el, kell-e egyatalan GUI, ha kell akkor hogy erdemes tagolni
stb. ezt tervezd meg. Altalaban eleg a winapi.
3/ ha igy eljutottal az erdemi feladatig akkor az dontse el, hogy kell-e
OO vagy nem. Ha sok es bonyolult adatszerkezettel dolgozol akkor OO, igy
konnyebb lesz tervezni es lekodolni, marmint ha van/lesz rutinod benne. 
En ha lehet maradni szoktam a jo oreg C-nel. Objektumos dolgokban (COM)
eddig semmi elegansat nem talaltam, annal tobb szivatast. Es lehetetlen
optimalizalni.

udv:
VAti