Ha meg nem adja és így marad, akkor az az érdemjegy fogja sérteni a lelkivilágát amit kapni fog rá Esetleg az otthoni "jogai" fognak csorbulni ha elhúzzák...

T68m, szerintem te a Lisp-re gondolsz mint letűnő nyelv. Az AutoLispet speciálisan az AutoCAD rendszerekhez alakították ki a simából és rengeteget használják. Sok kiegészítést, elemkönyvtárakat ebben írtak meg, ha valamit nem tud/nem úgy tud az autocad mint szeretnéd, akkor ezzel megcsinálhatod. Az utasításokkal a legmélyebb szinten buherálhatod a rajzokat, a program futhat az autocad parancssorában vagy dialógus alapú kezeléssel. Most kezdtem el tanulni és néha még igencsak pofán tud csapni

Egyet értek....de félek a kód átadása sérteni fogja a szerző jogait

ennyi kitérő után tényleg nézzük már azt a kódot!

xman: autolispról elég rég hallottam. Azt hittem el is süllyedt az a nyelv. Egyátalán mire jó?

Már miért ne kattintgathatnám össze? Ez a lényege! Ettől NEM turbo vagy borlandpascal hanem delphi!
Na ezek után csináld meg gyorsabban!

Ha jól emlékszem nekem egy F9 vagy CTRL+F9 az egész

Nem tom mi az a komoly feladat, de en akkor hasznaltam mikor pontos idozitesek es folyamatos hardwerbuzergalas kellett (irq kezelessel specko timecode reader kartyaval meg plusz egy sajattal), nekem ez eleg komolynak tunt. Na ez delphiben nem hiszem, hogy ment volna kezdve ott, hogy egy ms driver fejleszto kit sem ocso moka (mig egy bp7-t adtak 14e ft-ert akcioban...), es hat az idozitesek akkor is orok problemat okoznak (persze ez nem a delphi hibaja).

Hát ezzel egyet kell, hogy értsek Ha megszabjuk, hogy írni kell ablakot nem kattintgatni, akkor T68m már a 20-adik ablakot nyitja BP-ben mire a Delphi bekéri a telepítőkódot. Viszont a Delphi pont azért RAD, hogy ezzel ne kelljen törődni. Delphi<>pascal, Delphi=Object pascal. Aki otthon van pasban, annak semmi gondot nem okoz az áttérés és egy csomó problémája megszűnik. Viszont leadás előtt ez tényleg nem célszerű.

Pár hülyeséget meg tényleg mondhattam, mivel már 8 éve egy sort se írtam pascalban (Delphiben kell dolgozni, bár nem kifejezetten programozói állás, sőt most kizárólag autolisppel kell foglalkozni. Tényleg, ahhoz ért valaki ? ). Szerintem felejtsük el a kis vitánkat T68m és ha tudunk, segítsünk Riannak. Felrakhatná azt a forrást ahol még krixkraxol.

én. Lemérhetjük.

Konkretizálva a feladatot: te telepítesz (vagy sem, ahogy akarod, persze, ha már felajánlottad, akkor úgy korrekt, ha igen) ÉS MEGÍROD delphiben a programot, ami felhoz egy ablakot. (Tehát nem összekattingatod) Értelemszerűen ugyanazokat az előre megírt könyvtárakat/unitokat, stb. használhatjuk)

mellesleg akkor már a 3.0 sem volt pascal - szerinted - hanem egy pascal nyelven alapuló fejlesztőrendszer a DOS-hoz.

Hát, sajnos nem mindig. Ha ez így lenne, én már a pascalt úgy dobtam volna a lomtárba, amilyen gyorsasággal lehet, de hát sajnos nem így van

Nem a delphi az nem pascal.
A delphi az egy pascal nyelven alapuló GUI windows-hoz. (Illetve utóbbi verziókban már cross platform volt)

De ha szerinted a delphi = pascal, akkor álljunk neki egyszerre, írni egy primitív programot, ami windows-ban felhoz egy üres ablakot.

Vajon ki végez hamarabb?

Sztem telepítéssel együtt gyorsabb delphiben

szted a Delphi nem pascal?

Ez logikus és jogos. Csak az a kérdés, hogy lenne-e ideje áttérni mielőtt le kell adni az egész vackot. A tanároknak mindegy, és ha befejezte, nyugiban áttér (úgyis muszáj lesz).

Lehet, hogy rossz a kérdés, de miért Pascal? Sokat használtam, és meg is utáltam rendesen
Ha hasonlót akarzs, akkor ott a Delphi, ha paltformfüggetlent, akkor a Java. Ezeket használják is. Nem hiszem,h néhány elvetemültnél több ember hasznáná a Pascalt KOMOLY feladatokra... eljárt felette az idő. Freepascalostul is.

Persze, valószínűleg programhiba. Csak éppen a programot nem láttuk ... Mivel adatbáziskezelést csinál és a hozzászólásaiból is kiderült, memóriagondjai vannak... Érdekes, nekem soha a büdös életben nem voltak memóriagondjaim se tp-ben se bp-ben se freepascalban. Gondolom neked iszonyat nagy tapasztalatod van tp-ben és olyan hatalmas programokat írsz, hogy IDE alól már le se tudod fordítani csak parancssorból... Innentől hidegen hagy a téma, majd te megcsinálod neki... Az meg egy másik dolog, hogy ha már eljutott a szakdolgozatig, illene ilyen apróságokat megoldania.

jaja, ez egy nagyon SÚLYOS felfogásbeli és rendszerszemléleti tévedés. Gyakorlatilag mindent elárul kijelentőjéről.

Ugyanis a hiba okát pontosan meg kell határozni, nem pedig kisérletezni kell azzal! Ugyanis, mi van, ha freepascalban tünetmentes fut a rendszer. (hasonlóképp, mint ahogy azt a topicnyitó felvetette, hogyha kitöröl belőle néhány jelentéktelen részt) Akkor kijelenthetjük, hogy jó? Rábízhatunk fontos dolgokat? Hogy esetleg többhónapos használat után derüljön ki, amikor a kár már sokszorora a mostaninak?

A hibát (pontosabban az hibának vélt dolgot), legyen az 64kb-os határ, memórifelülírás vagy akármi, csak azután szabad elhárítani, hogy egyértelműen megbizonyosodtunk róla, hogy ténylegesen az okozza a rossz működést.

(természetesen ugyanez vonatkozik az "írjuk át dinamikusra" hsz-ra is.)

tényleg ne nyissunk vitát, hogy ki a jobb programozó, mert ennél már csak a kinek van jobb mobilja/kocsija az unalmasabb.

Sajnos ellent kell mondjak neked, mert a topicnyitó szempontjából semmilyen használható infót nem írtál. Mert amit mondtál (amiben nem volt vita), az helyes, csak épp nem idevágó. Ezzel az erővel flémelhetnek a napkitörésekről is!

És meglepő, hogy ekkora tp tapasztalattal a hátad mögött, nem érzed, hogy ez nem tp, hanem programhiba.

Valóban, ha a topicnyitó felrakná a forrását, talán rendesebb válaszokat is kaphatna. Milyen fordítót is használ ? TP6, TP7, patchelt BP7 ? Így freepascalban is le lehetne ellenőrizni, és tényleg értelmét vesztené ez a hülye vita a 64kb-os adathatárról...

Ebben igazad van T68m, rosszul emlékeztem és rosszul írtam le a 64kb-os határ dolgot, tényleg a kódnak nincs köze hozzá. Viszont ettől még nem beszélek hülyeségeket ! Ha jól látom egyedül én írtam használható infókat, ha gondot okoz a dinamikus memóriakezelés az már nem az én hibám !! Remélem nem kezdünk vitázni, hogy ki mikor mennyit pascalozott, mi is TP-ben írtuk a szakdogát anno '97-ben...

tedd fel, hogy mi is megnézhessük!

Koming szán Elég sok lehetőséget elémtártatok, elöbb átnézem a számomra érthetőkel:) Aztán majd írok hogy mit sikerült kiokoskodni. Természetesen a programomban nem találtam hibát. Olyan programrésznél jelentkezik a hiba, amihez egyébként nem nagyon nyúltam már egy ideje.

kb. én is, ezért az elején kevésbé voltam biztos, hogy jól emléxem-e, de most már tuti.

viszont a topicnyitó problémájától ez igen messze esik. Nyilatkozhatna már, hogy megtalált-e a hibát, vagy még mindig a tp-ben keresi?

Annyira nem szélsőséges eset, mert annak idején én is belebotlottam pedig nem emlékszem, hogy valami marha nagy adatbázisos prg-t írtam volna.

Mondjuk most, hogy mondod abban igazad lehet, hogy mintha ez fordításkor jelentene hibát nem pedig futáskor, de erre nem emlékszem....uszkve 15 éve programoztam TP-ban!

marha nagy limit (ahogy fentebb is írtam), hogy a főprogramban (unitonként) nem lehet 64k-nál nagyobb adatmennyiség!

1. ez nagyon szélsőséges eset
2. nincs összefüggésben a kód méretével!
3. eljárásokban, függvényekben és heapben tároltak ebbe nem számolódnak bele
azaz, amiről ti írtatok, az a COM programokra volt jellemző, a 4.0-ás pascaltól már EXE-k vannak.
+1 különben is, ez, 64k globális változókkal való túllépése FORDÍTÁSI, nem futási hibát okoz
++1 a topicnyitó problémájának ehhez köze nincs. Ott valami memóriafelülírásról van szó. Csak egyszerűbb a tp-re fogni, mint megkeresni a saját hibáját.

Majd ha megtapasztaltad írj vissza!

A lényeg, hogy ha csak úgy nekiugrasz pascalozni, globális változókkal tömbökkel (mint a topicnyitó) akkor pik-pak belebotlasz a 64K-s limitbe.

Fordítási direktívákkal vagy más szakszerű módszerekkel nyilván ki lehet kerülni, de ezek hiányában hiába mondod akkor is van 64K-s limit!

legalább ne beszélnél hü.lyeségeket....

csak a főprogramban lévő adatterület számít. Annak túllépése pedig fordítási hibát okoz.

láttal már turbo/object-vision teljes fordítást? Kissé meghaladja a 100.000 programsort, pascalban.

A 64k-s feltételezésetek alapban hülyeség. A COM programoknál volt, hogy a kód/adat/stack szegmens egyenként nem haladhatja meg a 64k-t. Az EXE-k esetén már igen. Annyi az összes adatokra vonatkozó megkötés, hogy a nem heap és nem stackban tárolt adatok, tehát a főprogramban tárolt adatok összesége nem haladhatja meg a 64k-t. (tehát ez nem vonatkozik az eljárásokra, függvényekre, mert azok a stackban tárolnak, csak és kizárólag a főprogramban lévő változókra, ez UNIT-onként értendő)

ez egyszerűen tévedés! Azért nem fagy, ha kitörölsz egy jelentéktelen részletet, mert akkor más, a futás szempontjából közömbös rész fog felülíródni a hibás programod által.

Egyébként nem értem miért okoz nehézséget bekapcsolni az ellnőrzést, hogy ezt te magad is meglásd...

Ha befejezed ezt a dogát ajánlom a Delphivel való azonnali ismerkedést, hiszen az ilyen adatbáziscuccokra a legalkalmasabb. Egy felhasználói felület összedobása se több egy félóránál és csak a kódra kell koncentrálni. Utánna élvezheted a korlátlan (sic! ) memória előnyeit (meg persze megismerkedhetsz a win kényes sértődős lelkivilágával is ).

Dezsőnek igaza van. Egy adatbázis programnál a rekordszerkezet a lényeg. Kialakítasz egy normális rekordszerkezetet és típusos fájlként kezeled őket. Egy tanulókkal foglalkozó rekord nem lehet több néhány száz byte-nál. Utánna 2 rekordtömbre van szükség, egy adattárolóra és egy bufferre. Mindig csak egy (max. 2) rekord van a memóriában. A gyors műveletekhez indexelsz, és egy rekordos fájlban rettentően egyszerű csereberélni. Amúgy meg nem a forrás mérete számít hanem, hogy a fordítás után az exe mennyit rak a memóriába.

Heap használata:
{$M 16384,0,655360} 16K,0,640K
stackméret(max. 65520),min.heap,max.heap(max.655360)

type tomb=array[1..60000] of byte;
tombptr=^tomb;
var dptr:tombptr; dinamikus tömb
da:^integer; dinamikus változó

new(ptr); lefoglalás a heap-ben
new(da);
ptr^[i]:=496;
da^:=25;
dispose(ptr); felszabadítás
dispose(da);

A Freepascalos hibához nem tudok hozzászólni, szó szerint: "nem várt fájl vég az 1331-es sorban", ehhez látni kéne az 1331-es sort és társait. Freepascalos fordítással még nem volt gondom csak egyszer, amikor hibás konfigolás miatt nem fordított object fájlokat az unitokból.

Adatbázis kezelésnél, nem érdemes nagy tömböket használni. Inkább használj adatfájlokat. Végül is azok is tömbök, csak nem a meróriába tárolódnak. Illetve mindig csak kis darabjai vannak bent a memóriában. az adatfájlokkal is mindent meg tudsz csinálni amit a tömbökkel lehetséges.

Xman nagyon jol osszefoglalta, a lehetseges megoldasokat. Plane ha "adatbaziskezelot" irsz akkor mindenkepp dinamikusan kene foglalni a memoriat nem tomobokkel kinlodni. Letezik olyan kiegeszites amivel swap memoriakent lehet hasznalni a hdd-t hasonloan mint a windows (de nem ez megoldas csak megemlitem, hogy van ilyen is, ezt egy 2 floppys 640kb-ram-os xt-nel hasznaltam amiben hdd-sem volt, a masodik lemezmeghajto volt a swap disk...).

1200-soros kod nem okozhat gondot* de erdemes minel jobban strukturalni, ecceru rovid es attekintheto unit-okat kene hasznalni (oop-t mar nem is merem mondani).


*Gyorsan megneztem egy regebbi pacal progimat (karakteres alapu tvison-hoz hasonlo de annal fejlettebb ablakkezelessel, szinten van benne kemenyen adatkezeles is). Ez 22 db .pas fajlbol all es 430KByte a forrasa (+nemi assembly) es siman fordul es fut...
Van egy vesa grafikas ablakkezelom is annak a foprogija 180KByte forras (plusz egy csomo unit) szinten fordul es fut.
Sot talaltam egy TP3-as(!) progit is az is tobb mint 100KByte forras.

Freepascalt letöltöttem. Fordításkor ezt a 2 hibaüzit kapom:

NAPLO20.PAS(1331) Fatal: Unexpected end of file
NAPLO20.PAS(1331) Fatal: Compilation aborted

Ez mi lehet?

Ez a verzióm még pascalban hibátlan, de itt freepascalban nem megy.

Amúgy pascalban ez a Mark - amit Dester Te írtál nem rossz ötlet a tesztelésre:)

Pascalban dinamikus tömböket nem lehet használni?

Na azért ez az 1200 sor 35 kilobájt és ha 1100 sor még sikeresen lefut, de 1200 sor már nem, ebböl az következik hogy a program túl nagy nem? Emléxem 12 éves koromban c64-re programoztam, és ha a programom elért egy nagy gombóc méretet, akkor eldeformálódtak a "Sprite" -jaim:) Persze az se volt nagy program, de épp elég volt ahhoz, hogy felforduljon az egész. Mellesleg itt nem csak a tömbjeim a nagyok, mert kipróbáltam hogy (mivel ez egy osztálynapló program) visszább veszem a tanulókra szánt előre lefoglalt tömböket, de így sem fut le a program zökkenőmentesen.

Ejjha, én 12 éves koromba azt se tudtam, h mi az a programozás :D

Én 12 éves koromban írtam 1200 soros programot TP-ben, és le tudott fordulni.

Nekem rémlik valami fordítási direktíva, amivel a memóriakezelést lehet piszkálni, asszem a {$M} volt az, és 3 paramétere van emlékeim szerint (talán stack, heap, ???). Talán azzal is tudsz valamit kezdeni, úgy emlékszem annak idején eléggé hasznos volt, de már nagyon régen volt...

OFF: azért az a tanár, amelyik egy 1200 soros proramra azt mondja, hogy túl nagy, az véleményem szerint nem lehet valami jó tanár (mégha C-t is tanít, gondolom ott se számít soknak az 1200 sor). Meghát, egy "normálisabb" program (játékok, stb.) kicsit többől áll, mint 1200 sor...

Igen, vsz elírtam a topicot:) Nem a programom túl nagy, hanem a tömbök amiket használ

Xman... hát leesett az állam nagyon nagyonon hálás vagyok, hogy egy ilyen hozzáértő válaszolt a topicra:) Átgondolom amiket írtál, a programomba nem nagyon szeretnék belejavítani már... hanem fejleszteném ezerrel. Asszem a freepascalt megnézem. Mégegyszer köszi:) Ha lesz valami feldobom ide...

A kód és az adat együttes mérete nagyobb mint 64kb és kifut a területből. TP-ben és BP-ben alapból max. 64kb lehet a tömbök és változók összes mérete.

- Dinamikusan hozz létre tömböket a heap-ben (mutatókkal), így elméletileg 640 kb-ot használhatsz, de ezeket is maximum 64 kb-os méretekben. Ez lenne a legcélszerűbb.

- BP7 alatt védett üzemmódban a tömbök max. mérete marad 64 kb, de azt hiszem max. 16 megát lehet használni.

- Oszd fel a programot több unitra, optimalizáld a változókat, használj kisebb tömböket, és több lemezműveletet. Persze így lassulni fog, de ha normális filekezelést használsz (pl. rekordos fájlok) ez nem lesz észrevehető.

- Ha kizárólag DOS alatt futtatnád a programot, használhatnád a beépített EMS memóriakezelő részt, de az sz.@.r ügy még tisztán dosos gépen is. EMM386.EXE memóriamanagert igényel. Nem célszerű.

- Használj overlay technikát, ami olyasmi mint az unitok (*.ovl fájlok), és a program a kódnak mindig csak azt a részét tartja a memóriában amit épp használnia kell. Ez több lemezművelettel járhat, mivel az ovl fájlokat állandóan cserélgeti, de ha rendesen át van gondolva, nem probléma.

- Van XMS memória kezelő unit, amivel tetszőleges méretű memóriatömböket használhatsz az 1 mega fölötti részen, de nem tudom, hogy win alatt megy-e rendesen. HIMEM.SYS memóriamanagert igényel. Olyan 2-3 megányi területet használtam vele kb. 4-500 kb-os tömbökben. Ha érdekel előkerítem, forrással, példákkal.

- Free Pascal. Ugyanaz mint a TP/BP csak alapból nincs benne a 64 kb-os memóriakorlát, mert GO32 memóriamanagert használ. Ez egy külön fájl, aminek egyszerűen a program mellett kell lennie. Teljesen 100% pascal kompatibilis és egy csomó hasznos új dolog is van benne. DOS és Win alatt is kitűnően és megbízhatóan működik. Ha kifogy a teljes memóriából, lapozófájlt hoz létre a lemezen. Ezzel olyan 8-10 megányi tömböket kezeltem EGYBEN Van hozzá olyan VESA unit, ami kezeli a nagyfelbontásokat nagy színmélységben (pl. 1024x768x24) és egyben látja a videomemóriát, nem 64 kb-onként.
http://www.freepascal.org/

- Áttérés a Delphire Minden probléma azonnal megoldódik, de gondolom ez annyira nem járható út neked csak így hirtelen

Pascalban volt valami 64K-s limit.

Márpedig a program kód-od és az adatok meghaladják a 64K-t ezért xarja össze magát.
A megoldást sajnos nem tudom, de az biztos, hogy a hiba a 64K meghaladása! (Arra emlékszem, hogy ezt meg lehet kerülni, illetve ki lehet védeni, de arra már nem hogy hogyan!)

Az viszont tényleg vicces, hogy túl nagy program 1243 sorral...
A nagy program olyan 100.000 sornál kezdődik (igaz azt valószínűleg nem pascalban írják )

Hali. Nem GDF, és a tanárom nem paszkált tanít, hanem C-t. Ezért nem tudott még választ adni, neki is át kell nézni a paszkál kezelését, de nekem elég sűrgős lenne ez, mert ez a szakdolgozatom. Ha megnézed azt a képet amit linkeltem, ott jól látszik, hogy a rendelkezésre álló memóriát (64k) lassacskán kezdik elérni a deklarált tömbök (41k). Tehát 41 kilo van a memóriában. Gondolom a program+változók nem férnek bele a memóriába. A progiba nem szúrtam el semmit, ha kitörlök egy olyan részt aminek pl nincs is jelentősége, akkor megjavul a program. Ez könnyen le is tesztelhetző egy egyszerű clrscr utasítással.

már rég tp-ztem, de nyugodt lehetsz, nem írtál nagy programot!

ha turbo-visiont használnál, akkor lehetne olyan, hogy nem tudná fordítani/futtatni az ide a programodat, de akkor ezt egyértelműen jelezné. Erre megoldás a bp volt, ami eleve lemezre fordít. Már konkrétan nem emlékszem, több, mint 10 éve, hogy használtam, hogy miért is kezeli jobban a memóriát a bp, mint a tp, de ez a te szempontból teljesen lényegtelen. (ja, azt hiszem, hogy a bp kezeli az extended memóriát)

a tanárod meg nyugodtan adja vissza a diplomáját, ha ilyeneket beszél. Rákérdezhetek? Gdf?

Valójában, szinte tuti, hogy felülvágtad valami rossz tömbhivatkozással a progid és/vagy az adatterületeket.
Egyszerűen kapcsold be a range chechkinget {$R}, valamint ajánlott még a stack és heap chechking is. Ezeket én még futtatásnál is bekapcsolva hagyom, minimálisan lassítják a progit és inkább szálljon el a rendszer egy jól látható hibaüzenettel, mintsem misztikus hibákat ejtsen!

Sziasztok!

A következő a gondom! Írtam egy 30 kilos pascal progit (adatbázis kezelőt). Még amikor 29 kilobájtos volt a program nem volt vele semmi gond, de most a 30-adiknál szétesett pár utasítás.

pl.: a clrscr függvény. Nem törli a képernyőt, hanem telefirkálja sárga fura jelekkel, és a speaker is sípol.

- egy tömb változóit nem tudom visszanyerni mert helyette krix-kraxok vannak. A tanárom szerint túl nagy a programom és valahogy váltanom kellene memória területet.

Valaki segítene?
Pascal információk: