PCPROG.2

06 Nov 1992 - 26 Jul 1993

Topics

  1. algoritmi (223)
  2. ms.dos (250)
  3. asembler (141)
  4. jezici (278)
  5. pascal (1307)
  6. cccc (752)
  7. cpp (91)
  8. clipper (1027)
  9. baze.podataka (229)
  10. razno (379)
  11. van.teme (189)
  12. basic (56)

Messages - jezici

jezici.103 spantic, -> #100, dcolak
> Ima, ima, upravo nas guše sa njim u školi, a > nemam 13 dd za MSF 5.0 ili 5 za MSF 4.0.. Na zahtev građanstva ide. Inače MS FOTRAN 5.1 ide na 11 DD i 2 HD ( OS/2 ) 5.25" disketa. Mada sam viđao uspešne adaptacije istog ( instalacione ) na svega 2 HD diskete. Neko će pomisliti "pirati" ;) Ma OK, ali šta reći za čoveka koji ima original paket i koji je sa zadovoljstvom prešao na bekap od svega 2 HD diskete? bcf7713b.zip
jezici.104 bojt, -> #103, spantic
>> Na zahtev građanstva ide. Inače MS FOTRAN 5.1 ide na 11 DD i 2 >> HD ( OS/2 ) 5.25" disketa. Mada sam viđao uspešne adaptacije >> istog ( instalacione ) na svega 2 HD diskete. Neko će >> pomisliti "pirati" ;) Ma OK, ali šta reći za čoveka koji ima >> original paket i koji je sa zadovoljstvom prešao na bekap od >> svega 2 HD diskete? Odgovorno tvrdim da sve što treba može da stane (arjovano) na svega jednu HD disketu (a imam i originalni paket).
jezici.105 inesic, -> #102, spantic
> Mora da je WINDOWS NT dobra stvar :) Aha! Pogotovo ako imaš 586 na 100MHz i jedan gigabajat rama.
jezici.106 dcolak, -> #103, spantic
│ Na zahtev građanstva ide. Inače MS FOTRAN 5.1 ide na 11 │ DD i 2 HD ( OS/2 ) 5.25" disketa. Mada sam viđao uspešne │ adaptacije istog ( instalacione ) na svega 2 HD diskete. │ Neko će pomisliti "pirati" ;) Ma OK, ali šta reći za │ čoveka koji ima original paket i koji je sa zadovoljstvom │ prešao na bekap od svega 2 HD diskete? Zahvaljujem se u ime građanstva! |) Sledge DAMMIR!
jezici.107 nimi, -> #91, ndragan
> / Ovo sto koristim nisu .dbf datoteke vec je baza under ORACLE > Tj, ono sto sam hteo da pitam je da li IDA baza podleze pod > standard ili je bas Orakl u pitanju, implementiran kao niz > pretprocesora za razne jezike? Resenje mi se svida, a s druge > strane mi je drago sto vise nisam na vaksu - oni mazgovi tamo > nikad mi ne bi kupili takav komad softvera. IDA Baza to bese ono sto su nam Braca Slovenci sredili VAX-ovu mreznu bazu. I ja sam jako malo gledao IDA Bazu a i dosta je vremena proslo ,ali obzir na to da je mrezna baza SQL ne bi prosao, a i da je prolazio skinuli bi ga prodavci tople vode. ORACLE je pak jedini pravi RDBMS koji od 1979 fura SQL. Mislim da je to najkompletniji podskup SQL-a podrzan u nekoj implementaciji, moram priznati da i u mojoj staroj firmi nisu kupili isti produkt ali ga na srecu u novoj imam na par mesta, Bull DPS 7000, SUN, DOS doduse u raznim verzijama. > / World for XBase languages. Ali se takva filozofija mora pratiti u > / programiranju sto u predhodnom nije slucaj. > > Ovo mi nije jasno, sta si hteo da kazes... gde sta nije slucaj? Hteo bih jos jednom i ovom prilikom da pohvalim rad gore cenjenog autora Nenada Batocanina (NBatocanin) - Knjiga u kojoj sve pise (Racunari 89). Ideja o koriscenju recnika podataka treba maksimalno iskoristiti u svim xBase jezicima npr. za cuvanje veza izmedju nekih tabela (.dbf datoteka) i onda sva u prvom redu brisanja nekih zapisa iz tabela mogla bi da prave upite u taj recnik i donose odluku o brisanju, analogno bi se mogla raditi pri azuriranju. Ima dosta materijala koji bi mogao da se iz te ideje izvuce. ORACLE (gde to nije slucaj) vec kao RDBMS ima takav sistem ugradjen i ideju o recniku je ubacio u V 6.0, tako da i kada omasis kod nekog programa za brisanja, azuriranja ili sl. on sam javlja gresku pa je nemoguce legalnim sredstvima narusiti bazu (legalna sredstva: svi programi sa pre-procesorskim direktivama, forms, interaktivni SQL - SQL Plus, pri importu nekih podataka raznim utility-ima i sl. ). Sam vodi brigu o tome koji ce indeks koristiti, sam ih odrzava i sl. Pozdrav Milan
jezici.108 ndragan, -> #101, imtel
/* pisac prevodioca za COBOL. :) / i lično je pisao kernel za njega, u MSC 7.0 naravno... ;) Ajde. Iz prethodne rasprave očekivao sam da ga je pisao u kobolu :)
jezici.109 imtel, -> #105, inesic
* > Mora da je WINDOWS NT dobra stvar :) * * Aha! Pogotovo ako imaš 586 na 100MHz i jedan gigabajat rama. NT programi mogu da iskoriste max. 2 GB memorije dok preostalih 2 GB iz adresnog prostora može da koristi samo OS (ustupak učinjen RISC procesoru MIPS R4000 za koji je takodje namenjen). Kad se setimo da je pre 15-tak godina 640 kB izgledalo nedostižno ;) Kome je NT spor, može da ga pokrene na npr. 4 x 486 vezana paralelno (već je isproban na 20-tak takvih sistema), a pored 386/486/586 i R4000 radiće i na DEC Alpha superchip-u na 200 MHz, pa kad se stavi nekoliko takvih... vozi Miško ;) Ima još mnogo zanimljivosti o NT-u, kad se prouči njegova unutrašnja struktura mora se priznati da je moćno zamišljen, pa neka je i malo ispred hardware-a. Uvek je hardware lakše dostizao software... ZorMi
jezici.110 ndragan, -> #107, nimi
/ isti produkt ali ga na srecu u novoj imam na par mesta, Bull DPS 7000, / SUN, DOS doduse u raznim verzijama. Drugar, tebe su razmazili. Ako nisi ubacivao ansi sekvence u 'Filler pic "xxxxxx" value "<ESC>Š1;3h" ' i slično, onda si čisto imao sreće :) / Ideja o koriscenju recnika podataka treba maksimalno iskoristiti u / svim xBase jezicima npr. za cuvanje veza izmedju nekih tabela A, to. Podržavam, naravno. Baš smo danas u firmi raspravljali kako uvesti nekog sistema u to gde će se voziti računa o takvim stvarima. Generator obavezno pravi difolt praznu rutinu koja se poziva pre brisanja, još samo da se naviknemo da je punimo :) / raznim utility-ima i sl. ). Sam vodi brigu o tome koji ce indeks / koristiti, sam ih odrzava i sl. SQL pretrage i ostale naredbe nad većim brojem slogova u Foks Prou koriste upravo tu logiku, i to je ujedno i najveći dobitak pri prelasku sa prethodne verzije.
jezici.111 .obj, -> #109, imtel
> Ima još mnogo zanimljivosti o NT-u, kad se prouči njegova unutrašnja > struktura mora se priznati Ajde malo detaljnije... Ja sam malo razgledao EXE datoteke koje proizvodi MS C za NT. Malo mi je čudno da gotovo uopšte nema 32-bitnih instrukcija. Struktura EXE datoteka je potpuno drugačija nego kod Win16 EXE i, čini mi se, još rasipnija. U NT EXE-u program je podeljen na sekcije obeležene sa .text, .data, .rsrc, .idata itd. Takođe, resursi su zapisani u UNICODE-u! Imam utisak da je sistem koji je zamišljen prilično dalekovid. > Kome je NT spor, može da ga pokrene na npr. 4 x 486 vezana paralelno > (već je isproban na 20-tak takvih sistema), a pored 386/486/586 i R4000 > radiće i na DEC Alpha superchip-u na 200 MHz, pa kad se stavi nekoliko > takvih... vozi Miško ;) Nek' on radi kako valja na normalnim PC, lako ćemo mi za te 4x486... ;) Po meni, PRVO treba na delu da se pokaže 32s (ili nešto slično što bi bilo 32-bitna nadogradnja na Win16, za mase), pa tek ako on ispadne upotrebljiv, možda jednog dana NT postane 'popularan' ;) OS.
jezici.112 lkudlik,
zeleo bi nesto vise saznati o softveru "progres"
jezici.113 ppekovic,
Šta novo fonosi MS Cobol 5.0 (osim podrške za windows) pročitajte u konferenciji NOVOSTI, poruka 4.1272. Paya
jezici.114 alenin,
Drugar mi ima problem , pa bih zamolio fortran znalce i ostale da pripomognu .Evo u cemu je stvar -> Problem je u otvaranju fajlova, kod naredbe: OPEN(UNIT=13,FILE=FILES( 6),FORM='FORMATTED') Nece da otvori vise od 20 bez obzira dali je stalni ili privremeni fajl. Saljem i CONFIG.SYS . Program je pisan za F77L fortran profesional verzija. Stalno prijavljuje istu gresku a to je da nema dovoljno mogucnosti da otvori vise fajlova. Potrebno je mu je da resi generalno problem, jer ima programe gde se otvara i do 50 fajlova istovremeno. To se desava na 386 sa mat.koprocesorom. CONFIG.SYS DEVICE=C:\DOS\HIMEM.SYS DEVICE=C:\DOS\EMM386.EXE RAM on 1024 frame=d000 BUFFERS=50,0 FILES=50 DOS=UMB LASTDRIVE=E FCBS=50,0 DEVICEHIGH /L:1,12048 =C:\DOS\SETVER.EXE DOS=HIGH STACKS=9,256 SHELL=C:\DOS\COMMAND.COM C:\DOS\ /p DEVICEHIGH /L:1,9072 =C:\DOS\ANSI.SYS Pozdrav :) i hvala onome ko odgovori :)
jezici.115 dejanr, -> #114, alenin
>> Problem je u otvaranju fajlova, kod naredbe: >> >> OPEN(UNIT=13,FILE=FILES( 6),FORM='FORMATTED') >> >> Nece da otvori vise od 20 bez obzira dali je stalni ili privremeni >> fajl. Uh. Bojim se da znam o čemu je stvar ali da ti ne mogu pomoći. Isti efekat primećen je i kod Microsoft C-a - bez obzira šta piše u CONFIG.SYS, ne može da se otvori više od 20 fajlova. Ovu pojavu je detaljno proučio Alexa, i došao do zaključka da je u pitanju prostor dimenzionisan za file handle-ove u okviru PSP-a i docnije u jednoj radnoj tabeli koju C alocira. Više detalja o tome možeš da pročitaš u "Bajtovima lične prirode", mislim januara 1992. Obzirom da su svi Microsoft jezici "iznutra" jako slični i koriste manje-više iste biblioteke, verovatno je u pitanju isti problem u fortranu. Za C je nađeno rešenje, da se neke tabele odvojeno alociraju i neki pointeri preusmere na njih. Ne sećam se baš tačno, ali možeš da pročitaš u rečenim "Bajtovima lične prirode". Verovatno bi se nešto slično moglo uraditi i za FORTRAN, ali moraćeš sam da čačkaš oko toga, ne znam "gotovo" rešenje.
jezici.116 zokalezic, -> #114, alenin
> > OPEN(UNIT=13,FILE=FILES( 6),FORM='FORMATTED') > > Nece da otvori vise od 20 bez obzira dali je stalni ili > privremeni fajl. Saljem i CONFIG.SYS . Program je pisan za > F77L fortran profesional verzija. > Stalno prijavljuje istu gresku a to je da nema dovoljno > mogucnosti da otvori vise fajlova. Isti problem sam imao u TP 6.0. Rešenje je dos funkcija 67h, u BX ide broj otvorenih datoteka . Za detalje vidi Helppc .Ovo radi na dosu >= 3.30. Normalno u config.sys treba da ima Files=koliko hoće.
jezici.117 dejanr, -> #116, zokalezic
>> Isti problem sam imao u TP 6.0. Rešenje je dos funkcija 67h, u >> BX ide broj otvorenih datoteka . Za detalje vidi Helppc .Ovo >> radi na dosu >= 3.30. Normalno u config.sys treba da ima >> Files=koliko hoće. Bojim se da ovo neće rešiti problem u MSC-u, a mislim ni u FORTRAN-u koji je sigurno jako sličan jer je takođe Microsoftov ;) Ali ne škodi da se proba, javi ako uspe!
jezici.118 ppekovic, -> #117, dejanr
>> Bojim se da ovo neće rešiti problem u MSC-u, a mislim ni u FORTRAN-u >> koji je sigurno jako sličan jer je takođe Microsoftov ;) Ali ne škodi >> da se proba, javi ako uspe! Kako se mogući broj otvorenih fajlova na C-u može popeti na 255, imate u jednom primeru u C snippets arhivi. Paya
jezici.119 bojt, -> #114, alenin
>> OPEN(UNIT=13,FILE=FILES( 6),FORM='FORMATTED') >> Nece da otvori vise od 20 bez obzira dali je stalni ili >> privremeni fajl. Saljem i CONFIG.SYS . Program je pisan za >> F77L fortran profesional verzija. MS Fortran otvara do 15 fajlova, a čini mi se da i u dokumentaciji piše nešto o tom ograničenju. NDP Fortran 386 otvara do 36 fajlova. >> Potrebno je mu je da resi generalno problem, jer ima >> programe gde se otvara i do 50 fajlova istovremeno. Ako nije tajna, za šta mu treba 50 fajlova istovremeno?
jezici.120 spantic, -> #114, alenin
> fajl. Saljem i CONFIG.SYS . Program je pisan za F77L > fortran E sad, Dejan ti je odgovorio za MS FORTRAN 5.1 ali pošto vidim L da nije reč o Lahey FOTRANu? Koliko je meni poznato to je najbolji FOTRAN za MSDOS kompatabilan je sa VAXovim FOTRANom što je garancija kvaliteta :) Šalu na stranu ali sa LFom nije bilo takvih problema. Ako su se ipak javili u navedenom slučaju javi pa da se vidi.
jezici.121 bojt, -> #120, spantic
>> E sad, Dejan ti je odgovorio za MS FORTRAN 5.1 ali pošto vidim >> L da nije reč o Lahey FOTRANu? Koliko je meni poznato to je >> najbolji FOTRAN za MSDOS kompatabilan je sa VAXovim FOTRANom >> što je garancija kvaliteta :) Eh, eh, eh. F77L jeste jedan fin, kratak i nadasve brz kompajler. Toliko brzo kompajlira da je to stvarno impresivno. Medjutim, kod koji proizvodi je 50% sporiji od koda koji se dobija MS Fortranom. Pored toga, ima i neke neprijatne bug-ove (mada je vrlo robustan po pitanju segmenata), naročito kod indeksiranja raznim tipovima integer-a. Što se kompatibilnosti sa VAX Fortranom tiče, on je, kako mu i u dokumentaciji piše, "u velikoj meri" kompatibilan, što obično znači da će neko ko je divljao na VAX Fortranu imati dosta problema jer, po Marfijevom zakonu, obično kompatibilnost fali baš tamo gde ne treba. U svakom slučaju, nije ništa više kompatibilan sa VAX Fortranom nego MS Fortran. Na kraju, MS Fortran je prilično očišćen od bagova a, što uopšte nije zanemarljivo, može da se poveže sa MS C-om.
jezici.122 dr.grba, -> #119, bojt
>> Ako nije tajna, za sta mu treba 50 fajlova istovremeno? Ima tome godina, odem kod potencijalnog kupca softvera da vidim o cemu se radi...Na masini zateknem (nema veze, ali) najruzniju Clipper aplikaciju u zivotu. Direktorijum je sadrzao oko 450 fajlova na MFM disku, pod DOS 3.31. U konfiguraciji stoji FILES=200. Mislim - greska, hteo covek da napise 20 i skinem na 30. Resetujem masinu... Sreca moja, jos sam bio tu kad je program crkao. Tek onda sam video u AUTOEXEC-u SET CLIPPER=F200;... ...sam se osvestio i vratio kako je bilo. A ta aplikacija nije legla vec dve godine. Za neki banalni program koji sam im prodao hoce da mi dignu spomenik, jer "zamislite, sve vreme radi ispravno, kako je on dobar!" Dodje mi zao sto Clipper dopusta ono F1999, pa majstori otvore 10*x baza plus 3*10*x+5 indeksa, pa fercera. Pozdrav, dr ÔpŰa P.S. Onaj covek je bio posten, pa u uputstvu sugerirao svakodnevni backup. Sad ne znam da li da stavim (: ili ):
jezici.123 alenin, -> #118, ppekovic
|:O Kako se moguci broj otvorenih fajlova na C-u moze popeti na |:O 255, imate u jednom primeru u C snippets arhivi. Gde bih mogao da nadjem taj podprogram iz C-a i da li bih ga nekako mogao dobiti posto nemam C-compajler a mogu ga povezati sa mojim linkerom naravno i uputstvo kako se poziva ili dali je moguc start nazavisno od mog programa, sto bi bilo bolje. Stim u vezi je i interesantno pitanje kako da iz dos komandog postupka uticem na SET HENDLE COUNT (. . .), odnosno kako da preuredim tabelu da bih pokusao da resim problem. To sve podrazumeva da sam samo programer u Fortranu, Paskalu (malo ) a C verovatno neznam previse. Dubravko
jezici.124 alenin, -> #119, bojt
Pre svega HVALA za odgovore, korisni su. Ali sale nema, broj potrebnih otvorenih fajlova je nasledjena stvar iz programa koji se prenose sa velikog sistema, a radi se o grafickom kompletu za generisanje raznih mreza (FEM). Resenje je da se preceslja ceo program i da se parcijalno otvara i zatvara datoteka, E ALI, to je za sada tezak put jer se radi o 70-tak SUBROUTINE programa koji su napisani na oko 2000 linija. Dubravko
jezici.125 alenin, -> #120, spantic
Da zaista se radi o F77L- LAHEY, koji je najbolji, ali ipak ima problema u definisanju otvorenih fajlova, sto u krajnjem slucaju moze da se resi reorganizovanjem programa, ali predstavlja tezi put. Prema tome imam potrebu za pomoc, odnosno saradnju. Uputstva koja imam ne daju odgovor koji moze da resi problem, jer se oslanja na DOS- FILES=... odnosno preko INCLUDE ukljucivanje drugog potprograma koji nastavlja otvaranje fajlova, sto sam pokusao. Ostaje da se direktno u sistem udje i kontrolise taj broj sto predstavlja za mene teskocu (neznam postuap za rad sa memorijskim prostorima u sistemu). Svi pokusaji testiranja otvaranja fajlova kroz vise podprograma, (u svakom po nekoliko -recimo 10-tak) nisu uspeli. Sad je trenutno u pitanju manji paket, koji zahteva oko 30 fajlova istovremeno (uslovno od zahteva vrste rada), ali sledeci paket je tezi zalogaj (radi se o dinamickim postucima u podrucju nelinearnosti materijala u MKE ili FEM metodi). Dubravko
jezici.126 bojt, -> #124, alenin
>> Ali sale nema, broj potrebnih otvorenih fajlova je nasledjena >> stvar iz programa koji se prenose sa velikog sistema, a radi se >> o grafickom kompletu za generisanje raznih mreza (FEM). Resenje >> je da se preceslja ceo program i da se parcijalno otvara i >> zatvara datoteka, E ALI, to je za sada tezak put jer se radi o >> 70-tak SUBROUTINE programa koji su napisani na oko 2000 linija. Pa što odma' ne kažeš da se radi o FEM. Verovatno je u pitanju neki sors, pisan 70ih, kada nije bilo mnogo RAM memorije (neki main-frame-ovi su imali samo 8K RAM-a), ali je zato bilo prostora na diskovima ohoho, tako da se sa većinom nizova operiše direktno sa diska (access='direct'), pa otud i potreba da se u jednom trenutku postoji gomila otvorenih fajlova. Ovo za posledicu ima višečasovno pa i višednevno izvršavanje programa, a da pri tome snaga platforme ne utiče značajno na brzinu. Što je najstrašnije, skoro sav softver iz oblasti FEM koji je nastao kasnijih godina donosio je po pravilu poboljšanja u predprocesorima (razni generatori, novi konačni elementi) i postprocesorima (razni tipovi sortiranja tekstualnog izlaza, grafički prikaz proračuna), dok je najproblematičniji deo programa, koji se odnosi na formiranje i rešavanje matrice krutosti sistema, najčešće jednostavno prenošen iz STRESS-a ili SAP-a (pošto je sors tih programa bio dostupan univerzitetima). Ako se uz sve ovo radi i nelinearna analiza, onda se taj najproblamtičniji postupak obavlja u iteracijama, što postaje maltene nepodnošljivo (sećam se da je jedan, za današnje prilike ne preterano veliki problem na GF-ovom PDP-ju rešavan preko 2 meseca) Osamdesete godine donele su nekoliko paketa koji su uveli optimizaciju band-a matrice krutosti sistema, što je značajno smanjilo vreme izvršavanja i potrebe za memorijom. Medjutim, tek u poslednje vreme pojavljuje se poneki program iz te oblasti koji maksimalno koristi resurse RAM memorije, te tako napokon postaju "podobni" za kakav-takav normalan rad.
jezici.127 ndragan, -> #122, dr.grba
/ AUTOEXEC-u SET CLIPPER=F200;... A ja svojevremeno pitao da li je to narodni običaj među kliperašima da se u startu sve pootvara, pa kažu 'jok, more, šta ti pada na pamet...'. Trebalo bi da se (ljubitelji tog stila) izbore za dodatne bodove na uslove rada. Mora da su se svi isporazboljevali - kad ti je tako sve otvoreno, tu mora da piči promaja all in 010H...
jezici.128 dr.grba, -> #127, ndragan
>> Trebalo bi da se (ljubitelji tog stila) izbore za dodatne bodove na >> uslove rada. Mora da su se svi isporazboljevali - kad ti je tako sve >> otvoreno, tu mora da pici promaja all in 010H... A da ti ne kazem sta CHKDSK pronadje - 5 MB smeca mesecno, cirka. A defragmentacija, brate....rupa k'o na ciganjsko cebe... All in 20(oct), dr ÔpŰa --> Laki je malo nervozan.
jezici.129 bulaja,
Bilo bi lepo kada bi se diskusija o programskim jezicima (C & Modula,..) prebacila u ovu temu (ako niste znali, i ona postoji :).
jezici.130 bulaja,
[ reply 7.484 PC.PROG.2:cccc (stomic) ] ││Ali je i dalje pascal. Kad je M2 toliko dobar, zasto ne uzese sve? │└─── │Zato sto bi nastala Turbo Modula-2, koja bi totalno preuzela │trziste Turbo Pascalu. Zasto sami sebi da prave konkurenciju, │kada se tada TP vec dooobro prodavao. └─── Ako vec imaju interesa da drze dva C++ kompajlera (Turbo i Borland), ne vidim zasto ne bi razmislili i o tome da imaju Turbo Pascal i npr. Borland Modula-2? Ili npr. Borland ima i dBase III/IV a i Paradox, pa im opet nista ne fali :). Ocigledno nisu ti razlozi u pitanju :).
jezici.131 dejanr,
[Odgovor na 7.529, janko] >> > Šta mislite da napravimo mali kolektivni test? Da smislimo >> > neki problem... >> > Trebalo bi da bude neki problem numericke prirode koji ce >> > se, recimo na nekom 386/33 (jer to većina ima) izvršiti za >> > 5-6 minuta, s tim što bi trebalo da ima i nekog muljanja >> > po disku i tako to. Ako ima ideja za problem, ja sam >> > raspoložen da učestvujem u eksperimentu. Mislim da bismo >> > dobili zanimljive >> >> Ako poredimo brzine izvršavanja, intenzivan numerički problem >> će daleko više da testira kvalitet FP emulatora (pogotovu na >> 386)... Npr. TP ima, između ostalog, format brojeva koji radi >> brže, ali nije IEEE, pa poredeći TP sa njegovim 5-to bajtnim FP >> i C sa IEEE formatima, nećemo zaključiti nešto pametno... Ja bih zato i preferirao nešto što radi sa integerima i piše po disku.
jezici.132 ficus, -> #131, dejanr
:) Ja bih zato i preferirao nesto sto radi sa integerima i pise po :) disku. a kako cemo da zanemarimo probleme subjektivne prirode mozete recimo u asm-u da napisete sporiji program od onog u pascalu ili c-u sve zavisi od toga kako napisete prg. inace zasto sa citanjem i pisanjem na disk to je mnogo sporo i mnogo hardverski zavisno.pa cak i zavisno od trenutka pisanja na disk zbog rasporeda slobodnih cluster-a ja bih izbacio i to sa diskom.
jezici.133 dejanr,
[Odgovor na 7.535, ficus] >> Pa sednem napisem jedno 20-tak funkcijica 100-tinak makroa i eto >> resen problem indexnih datoteka. Sad bi bilo zgodno imati i lepsu >> komunikaciju sa ekranom i opet se posao svodi na isto. Ovo >> svee zajedno ce za prvu firmu trajati dosta dugo, za drugu ce >> vec biti samo par doradica i ako je sve dobro osmisljeno vec >> kod 4 ja cu lakse i brze komunicirati sa datotekama u asembleru >> nego u clipperu. Lepo zvuči, ali da li je stvarno tako? Nije baš jednostavno napisati procedure koje će racionalno raditi sa bazama podataka, brzo pretraživati, sortirati itd. Uopšte nije lako, treba tu dosta teorijskog znanja, onda dosta prakse (u DOS svetu razne stvari koje su teorijski jako brze ispadnu dosta spore, zbog memorije itd) i jako puno vremena. I onda se postavlja pitanje, zašto si to radio ako je sasvim lepo urađeno u Clipper-u ili Fox-u? Ukratko, nisam ubeđen da ćeš *toliko* lakše i brže komunicirati sa datotekama (ako će uopšte biti lakše i brže!) da bi se čitav taj razvoj isplatio, sve da je firmi za koje pišeš ne 4 nego 40. Kako to lepo kaže PPeković, na kraju bi uz silan trud, funkciju po funkciju, napisao neki "Clipper", i veliko je pitanje da li bi on bio u klasi postojećeg i relativno jeftinog Clipper-a. >> clipper je dobar za baze podataka u nedostatku dobrih biblioteka >> koje bi ga zamenile (on i jeste neka vrsta biblioteke) ali mu je >> mana fiksna duzina slogova i jako spor pack. Što se tiče fiksne dužine sloga, to jeste mana svih jezika koji su "nasledili" .DBF format. Kao i mnoge druge stvari u PC svetu, taj format je možda bio ok kada se pojavio, ali je pustio preduboke korene i sada se održava na nekoj "inerciji" a u stvari predstavlja kočnicu. Jedan moj kolega inače "zakleti kliperaš" kaže da je taj problem fiksnog sloga sada "zauvek" rešen pojavom stekera (odnosno dblspace-a i sličnih) što sa jedne strane nije van pameti, a sa druge strane ja uvek kažem da bih se teško odlučio da važne podatke "stakerišem", a i nije primenljivo uvek, Novell itd (mada će novi Novell imati i kompresiju u sebi, dakle možemo se "batrgati" ali bojim se da će nas kompresija pre ili posle "sustići" ;) Što se tiče pack-a, ja ga nikad ne koristim. Ako u bazi ima jako malo promena, ostavim obrisane slogove, 'leba ne jedu. Ako su promene intenzivne, onda po ideji koja je još u antička vremena :) izložena na Sezamu, umesto da slog brišem zamenim mu prvi znak u nekom indeksiranom polju sa ~ i onda sa SEEK uvek nađem prazan slog kad mi treba novi da upišem, a tek ako je .not. found() onda radim APPEND BLANK. Ovo u praksi izuzetno dobro funkcioniše. Što se tiče (da ne kažem "glede" ;) dobrih biblioteka, ja na takve nisam naišao iako sam probao razne. Mislim da je najbolji pokušaj ovaj Paradox Engine koji Borland trenutno gura - možda je još malo nezgodan u nekim stvarima, ali još par verzija i biće upotrebljiv. Ne sumnjam da će i Microsoft da smisli nešto slično i onda ćemo možda stvarno moći da penzionišemo Clipper. Raze PD, polu-PD i jeftine data base biblioteke "malih" firmi nisu mu nikakva konkurencija; bar one koje sam ja probao.
jezici.134 ficus, -> #133, dejanr
:) Lepo zvuci, ali da li je stvarno tako? Nije bas jednostavno napisati :) procedure koje ce racionalno raditi sa bazama podataka, brzo pretrazivati, Slazem se da nije jednostavno ali to treba uraditi samo jednom. :) Uopste nije lako, treba tu dosta teorijskog znanja, onda :) dosta prakse (u DOS svetu razne stvari koje su teorijski jako brze ispadnu :) dosta spore, zbog memorije itd) i jako puno vremena. I to se slazem ali sto se brzine tice ona ne mora da mi bude toliko bitna ako je recimo duplo duze pretrazivanje ind. fajla a znacajno stedim na duzini. Istina postoji tu i ono indeksiram na prvih 5 char a ostalo trazim rucno pa dobijem nesto sporije ali znatno manje ntx fajlove. :) Ukratko, nisam ubeden da ces *toliko* lakse i brze komunicirati :) sa datotekama (ako ce uopste biti lakse i brze!) da bi se citav taj Pa sad lakse sigurno nece biti (bar ja mislim da nece biti posto planiram da probam nesto slicno da napisem u toku raspusta) inace cisto da se razumemo ja imam izuzetno slobodna shvatanja u izboru prg. jezika i radio sam i u clipperu ne bas puno ali imam desetak hiljada linija koda iza sebe. naravno tih 10000 linija koda je vise od 75% @ ... say i @ ... get ali svejedno sto se brzine tice tu nema dileme brze biti nece jer necu fiksnu duzinu sloga tako da pointeri moraju da budu duzi ako nista drugo. Ali cu biti u prednosti s obzirom na duzinu. :) Jedan moj kolega inace "zakleti kliperas" kaze da je taj problem fiksnog :) sloga sada "zauvek" resen pojavom stekera (odnosno dblspace-a i slicnih) :) sto sa jedne strane nije van pameti, a sa druge strane ja uvek kazem da :) bih se tesko odlucio da vazne podatke "stakerisem", a i nije primenljivo Imam 30000 reci u recniku i stacker pukne :'(( smrc,smrc BANG (bio je dobar drug ..... ocajan programer i lep les) ->misli se na mene ok slazem se da je stacker resio probleme ali ja imam disk od 40mb i koristim ga jedino zato sto me nuzda naterala a i to sto ga koristim pod stackerom se nalaze bc,clipper,dbase,masm tako da ako pukne imam install diskete. Svi koji su posle izvesnog vremena dobili poverenje u stacker (tacno prema marfijevom zakonu) i stavili sorceove pod njega kroz najvise 2 meseca rekli su mi da ga pod hitno skidam sa diska. :) Sezamu, umesto da slog brisem zamenim mu prvi znak u nekom indeksiranom :) polju sa ~ i onda sa SEEK uvek nadem prazan slog kad mi treba novi da :) upisem, a tek ako je .not. found() onda radim APPEND BLANK. Ovo u :) praksi izuzetno dobro funkcionise. slazem se to sam znao i ranije i cuo sam od vise ljudi ne komplikuje program previse mada imam ja i drugu ideju koja ga fizicki uklanja brzo ali da je to jedina mana clippera inace i ja sam zakleti clipperas dok ne napisem svoje procedurice. :) Mislim da je najbolji pokusaj ovaj Paradox Engine Neznam nisam ga probao ali koliko sam cuo o njemu eto jednog od resenja. Imam napisane procedurice i poso gotov mada deluje mi komplikovan za koriscenje (koliko sam video) Naravno ono za asembler je stvarno malo bilo preterivanje ali opet kroz par meseci rada na raznim bibliotekicama imao bih visi programski jezik u asembleru. A kako mi se cini ni sad bas nije mnogo nizak (mislim na .repeat , .while , .if , invoke , .....) uporedite to sa gwbasicom (ja otvoreno priznajem da sam nekad znao da pisem programe na basicu a sad definitivno niti znam niti imam nameru). P.S. Mislim da dobar programer (kad kazem dobar mislim na nekog ko ima jako puno iskustva dakle ja otpadam) moze da napise jednostavniju podrsku za indexne fajlove u c++ za par dana kao neku klasicu i da resi sve probleme.
jezici.135 prvul,
Reply to: Ů 7.535 PC.PROG.2:cccc Ů ficus, 03.05.Mon 15:20, 6550 char Ů for (i=1;i<=128;i*=2) { ... } Ů▄▄ Ja baš pominjah operatore za rad sa bitovima a ti tako... to se u C-u kaže: for (i=1;i<=0x80;i<<1) { ... } Ono 0x80 je čisto da bi bilo preglednije, kada god se petlja sa bitovima zgodno je pisati 0x konstante...
jezici.136 dejanr, -> #134, ficus
Slažem se sa većinom stvari koje si naveo u poruci, samo jedno pitanje. Da li je osnovni boljitak koji očekuješ od cele te biblioteke da dobiješ program čiji će .EXE fajl biti bitno kraći, pa makar po cenu da bude u nekim slučajevima sporiji i da se oko svega toga naradiš? Meni nije baš jasno zbog čeka bi to bilo toliko bitno, bolje da je kraći, naravno, ali mi ne smeta EXE i od 500 K ako treba.
jezici.137 ficus, -> #136, dejanr
:) Da li je osnovni boljitak koji ocekujes od cele te biblioteke da dobijes :) program ciji ce .EXE fajl biti bitno kraci, pa makar po cenu da bude u Definitivno neeeee! :) jasno zbog ceka bi to bilo toliko bitno, bolje da je kraci, naravno, ali :) mi ne smeta EXE i od 500 K ako treba. ma ne smeta meni ni exe od 1 mb ali mi smeta ono ostalo sto zauzima oko 5 mb a moglo bi da zauzima manje od 500 kb tj datoteke inace exe od 500kb mi apsolutno nebi smetao P.S. ortak za koga sam radio recnik zamolio me je da JOS MALO POVECAM POLJE ZA PREVOD tj za jos nekih 10 znakova a to je jos minimum 250-500kb pa tako polako uvedose nama nemci sankcije na prazno mesto na hard disku sa svojim slozenicama. ,
jezici.138 stomic, -> #130, bulaja
$ Ako vec imaju interesa da drze dva C++ kompajlera (Turbo i $ Borland), ne vidim zasto ne bi razmislili i o tome da imaju $ Turbo Pascal i npr. Borland Modula-2? Ili npr. Borland ima i $ dBase III/IV a i Paradox, pa im opet nista ne fali :). $ Ocigledno nisu ti razlozi u pitanju :). Ipak drže dva kompajlera za isti jezik. M2 i TP još uvek :) nisu isti jezici. Ne znam tačno, ali zar TC++ I BC++ se ne razlikuju samo u alatima koji idu uz njih i eventualno što jedan može da generiše 32bitni kod? Sorry, ako grešim, nisam siguran. U svakom slučaju što ne bi držao dve verzije istog jezika. Jedan za one malo profesionalnije a jedan za manje :)). Pozdrav, stomic@hobbiton.
jezici.139 stomic,
[ Reply to 7.528 (Janko) ] $ Neće tebi nikad zatrebati drugi jezik, jednostavno zato što si $ previše isključiv. Gde su koreni te isključivosti, stvarno ne $ znam. Kada bi imao dobar auto, da li bi odbijao da sedneš u $ neki drugi model? Koliko se sećam Dragisha je koristio i C, pa su verovatno tu koreni :). Pozdrav, stomic@hobbiton.
jezici.140 stomic,
[ Reply to 7.536 (Paki) ] $ Hvala Bogu da čovek nikad nije video JPI. A zato svi znamo kaki $ izgleda TP. Govori li ti to nešto? Naravno! Da pričate o stvarima koje ne poznajete :). I da automatski, većina, prihvata stvari koje svi koriste čak nepokušavajući da pogledaju okolo :). Ok, lepo je imati komšiju koji radi u istom jeziku i koji će uvek pomoći, ali ipak pogledajte malo i na drugu stranu :). Pozdrav, stomic@hobbiton.
jezici.141 stomic,
[ Reply to 7.535 (Ficus) ] $ >> Dalje, koliko ljudi ovdje je napisalo program od 10,000+ $ >> linija u Cu. I koliko je to trajalo? Excluding zz za koga $ svi >> znamo, a znamo i koliko je trajalo. $ $ A zar nije poenta dobrog jezika da sa sto manje pisanja $ napises sto bolji program???? Dragisha je naveo 10,000+ linija samo kao primer da se zapitate koliko je lako održavati veliki program u C-u. Ili svaki program koji ima preko 10,000 linija je loš :)))? Pozdrav, stomic@hobbiton.
jezici.143 ficus, -> #138, stomic
:) $ Ako vec imaju interesa da drze dva C++ kompajlera (Turbo i :) $ Borland), ne vidim zasto ne bi razmislili i o tome da imaju :) Ne znam tacno, ali zar TC++ I BC++ se ne razlikuju samo u :) alatima koji idu uz njih i eventualno sto jedan moze da generise :) 32bitni kod? Sorry, ako gresim, nisam siguran. Razlikuju se po tome sto uz borland idu td,tasm,tpof(profajler),sto ovaj radi i pod windowsom ali sami jezici su isti kao i kvalitet generisanog koda i borland c++ 3.0 NE GENERISE kod za 386 a 3.1 ga generise tako da nije razlika u tome nego jednostavno u utility koji idu uz bc/tc.
jezici.144 janko, -> #131, dejanr
>>> > Trebalo bi da bude neki problem numericke prirode koji > Ja bih zato i preferirao nešto što radi sa integerima i > piše po disku. Hoćeš li da kažeš da si prvi put hteo da napišeš NEnumeričke? To nas vraća na sam početak. Treba da odaberemo dovoljno "neutralan" algoritam za sve jezike. Recimo da realizujemo neki program koji nešto čita iz neke datoteke (Sadržaj datoteke bismo mogli zadati. Očigledno da to mora biti tekst datoteka da bi bila jednaka za sve jezike, i da ne bismo spali na korišćenje funkcija tipa blockwrite?) onda analizira to što je pročitao i na kraju piše rezultate u drugu datoteku. Šta dobijamo? Ako je analiza dovoljno mala više će se primećivati samo fajl I/O, a ako je dovoljno velika, šta će nam uopšte fajl I/O? Zato predlažem DVA algoritma. Jedan, kojim bismo merili, isključivo, koliko brzo jezik radi sa fajlovima i drugi, kojim bismo merili "procesne" mogućnosti jezika. Možemo da teramo i dalje -- ove procesne mogućnosti možemo da odvojimo na intidžerske obrade i FP obrade (dakle, tri algoritma). Za FP obrade i dalje stojim pri svojim zahtevima -- kod koji je preveden za hardverski koprocesor i standardni format brojeva, a ne za emulator, i merenje izvršavanja na računaru opremljenom koprocesorom. (A ako hoćemo da merimo i brzine emulatora, a ne samo kvalitet generisanog koda kompajlera, onda isti kod možemo da merimo i time što ga prevedemo za emulator (tamo gde to mora da se naglasi) i pustimo na računaru bez koprocesora)). E sad, šta ćemo od svega ovoga da radimo? Sve od ovoga, ili samo po nešto? Prednost ovakve "podele na manje" je zgodna -- izbegavamo maskiranje jednih efekata drugima, a i dobijamo rezultate koji kažu "ovaj jezik je dobar u tome i tome, a u ovome i ovome je sjabiji od onog tamo." Za kod kojim bismo merili "procesiranje procesorom" da bismo stekli sliku o osobinama jezika i kompajlera, svakako mora da bude organizovan tako da intenzivno poziva potprograme, mora da referencira promenljive različite "vidljivosti" i veličine i pristupa indeksnim promenljivama. (promenljivama ili promenljivima, pitam se ja, hm?) Ima li neko još neke sugestije?
jezici.145 dejanr, -> #144, janko
>> Hoćeš li da kažeš da si prvi put hteo da napišeš NEnumeričke? Ne, mislio sam nešto što ima veze sa brojevima, ali celim, možda se nisam najsrećnije izrazio. Nekakvo Eratostenovo sito ili tako nešto. Inače, stvarno bi dobro bilo da to bude više problema, ali ne znam koliko bi nam entuzijazam potrajao, jer to treba više ljudi na više jezika da uradi. Zato i predlažem da uzmemo jedan problem i da to što pre "obavimo".
jezici.146 bulaja, -> #133, dejanr
│Jedan moj kolega inace "zakleti kliperas" kaze da je taj problem fiksnog │sloga sada "zauvek" resen pojavom stekera (odnosno dblspace-a i slicnih) └─── Ma kakvi stakori :). Tada baza zaista zauzima manje mesta, al' program pojma nema o tome i naravno radi kao da je rec o normalnim (fiksnim) slogovima. Uz to je jos i sporije, a da ne pricamo o pouzdanosti. Zaista me cudi zasto jos niko nije napravio database koja radi sa slogovima varijabilne duzine. U ogromnoj vecini slucajeva baza podataka sa kojima sam radio promenljivi slogovi bi bili najbolje resenje jer je prostor alociran za fiksne slogove uglavnom vrlo slabo iskoriscen, a jednom uneto podaci se retko menjaju. Zanima me ima li mozda neka database biblioteka za C koja ima i standardne stvari (razne tipove polja, indekse,..) a radi sa slogovima promenljive duzine?
jezici.147 dejanr, -> #146, bulaja
>> Zaista me cudi zasto jos niko nije napravio database koja radi sa >> slogovima varijabilne duzine. To se svakako može uraditi, ali time bi se gubilo na performansama. Koliko, to zavisi od realizacije, ali jasno je da je lakše i brže operisati sa slogovima fiksnih dužina.
jezici.148 paki, -> #140, stomic
­> Naravno! Da pričate o stvarima koje ne poznajete :). I da ­> automatski, većina, prihvata stvari koje svi koriste čak ­> nepokušavajući da pogledaju okolo :). Ok, lepo je imati ­> komšiju koji radi u istom jeziku i koji će uvek pomoći, ali ­> ipak pogledajte malo i na drugu stranu :). Da je toliko dobra, ne verujem da bi se mnogo pričalo o Pascalu, a Modula pominjala tek ovako, uzgred ;>
jezici.149 vitez.koja, -> #136, dejanr
#=> Slazem se sa vecinom stvari koje si naveo u poruci, samo #=> jedno pitanje. Sta ima da ocekuje ? Decko je jos mlad i zelen, ne mora bas da se izdrzava, zar mu nije bolje da svrlja dok moze i uci umesto da se zakopa u kliper i privredjuje ? Evo, ja sad pisem neki c interpreter, kad nekom pomenem on napravi facu i kaze "koj ce ti kurac, da neces borlanda da prestizes ? Bolje da pises knjigovodstveni program malih mogucnosti u kliperu, zaradices neku kintu". Kako bolje, naucio sam puno novih stvari zabavljajuci se s interpreterom, izasao sa finim linijskim editorom i help sistemom, cela stvar se sastoji iskljucivo od moj koda ili standardnih c biblioteka. Programirao zadovoljstva radi, jer jos ne moram da se ishranjujem. Sad kad bih uzeo da pisem kliper program, garantovano bi bio bolji nego da nisam radio ovaj 'beskorisni' interpreter. A cini mi se da je za buduceg programera mnooogo korisnije da se sam lomata i pise konkretne stvari, pa makar one i zaostajale za najboljim proizvodima koje racunarsko trziste nudi, nego da proucava probleme sahovskih konja i rasporedjivanja tegova po hipotetickim terazijama.
jezici.150 ficus, -> #146, bulaja
:) Zaista me cudi zasto jos niko nije napravio database koja radi sa :) slogovima varijabilne duzine. U ogromnoj vecini slucajeva baza podataka Pa ja i rekoh da je to mana clippera ako bude srece ja cu napisati klasicu za rad sa slogovima varijabilne duzine.
jezici.151 ficus, -> #147, dejanr
:) To se svakako moze uraditi, ali time bi se gubilo na performansama. Pa ocigledno je da nemozes imati i jare i pare ili ces imati kratke ili brze datoteke. Sa obzirom na standardne namene datoteka ja sam za spore i kratke.
jezici.152 ficus,
>:) projektovanja mogu da se odlucim zbog bilo cega na nesto drugo. >:) svoje studente, da svaki projekat nosi u sebi obaveznu tacku u >:) kojoj se bira jezik, tj alat. Pa sad moz da bude bolje da izaberes drugi prg jezik ali stvarno samo u izuzetnim slucajevima. Cinjenica je da je idalje baze podataka najlakse raditi u cliperu a igrice u c-u ili pascalu. Ali se zato covek specija- lizuje. :) zbog toga sto sam izabrao C. A 'poor readability' mi je dva puta :) vise poor. To ce reci da argumentacija bas ne stoji. Ajd sad svi ste krenuli na tu citljivost sourcea. Po meni je source citljiv onoliko koliko ga ti citljivo napises a o tome da je po meni c mnogo citljiviji od paskala pa pretpostavljam samim tim i od module... :) kome ces lakse da svoj veliki projekat razbijes u manje dijelove, Mislis da se u c-u to tesko postize? :) nego bi davao za njega BP i TP. Ajde da bar dajes BC ili TC, pa da Pa nebi on dao bc ili tc suvise su vredni. >:) Mislim da je to donji prag od koga se program moze smatrati >:) netrivijalnim. Ima izuzetaka. Srecna okolnost za Sezam je da Pa nemozes kompleksnost jednog programa da procenis po broju linija imam recimo programce u clipperu sa oko 6000 linija neznam tacan broj ovo je otprilike. I smatram da je taj program sigurno mnogo jednostavniji nego moj yamb koj nema ni 1000 (bar ja mislim ovako otprilike). Lako je napisati program od 10000 linija kad je 75% posla block copy i slicno. Kompleksan program je program koj sadrzi kompleksnu obradu a dobar programer je onaj koj tu kompleksnu obradu napise da bude brza i uz to mu program bude elegantan. Zar ne? >:) Nemoj samo da, radi ocuvanja tona diskusije:), kazes da nemas >:) potrebu za icim osim C++:)). Imas pravo. Ja naprimer. Imam klinke iz prve godine u skoli i oni jos nisu ucili c a profesori im traze seminarske radove i eto. Ja sad moram da radim u pascalu ;))))
jezici.153 mjova, -> #138, stomic
> Ne znam tačno, ali zar TC++ I BC++ se ne razlikuju samo u > alatima koji idu uz njih i eventualno što jedan može da > generiše 32bitni kod? Sorry, ako grešim, nisam siguran. što se tiče ovoga, imao sam prilike da vidim TC++ (valjda 2.0 - nisam baš siguran) i primetio sam da se razlikuju mnoge stvari. naime, probao sam samo da zamenim .lib koje sma imao u BC++2.0 ovim, ali došlo je do mega-zbrlja. nisam se upuštao da proverim o čemu se radi, ali ustanovio sam da se razlikuju mnoge stvari da linkovanje jednostavno nije moguće. vremenom su mi zatrebale diskete i sve je otišlo u zaborav.
jezici.154 mjova,
[odgovor na PC.PROG.2 cccc.553/miro] >ű> uvođenjem ograničenja programer "tera" da piše čistije i pravi >ű> manje grešaka. To bi moglo da sugeriše i zaključak da > Uvođenjem ograničenja smanjuje se rizik da slaba karika u > lancu, iliti slabiji programer u timu, zabrlja stvar. pa jeste, ali ako ti radiš tako da ti treba provera tokom izvršavanja programa, onda ti posao ne valja. mene lično zanima kako se u nekom jeziku može manipulisati onim što 'obrađujem'. prvi program sam napisao u bejziku, ali nije mi to sve bilo dovoljno brzo i precizno pa sam počeo da radim u asmebleru, naravno za Z80 ;). e, kad sam pazario PC počeo sam da koristim C jer to jednostavno nisam imao prilike ranije da vidim, a čitao sam šta se sve može. ono što mi je bilo bitno to je C imao: čačkanje po memoriji, princip vrlo sličnom asm-u, doslednost, jednostavnost itd.
jezici.155 pmijat, -> #146, bulaja
>> Zaista me cudi zasto jos niko nije napravio database koja radi >> sa slogovima varijabilne duzine. U ogromnoj vecini slucajeva >> baza podataka sa kojima sam radio promenljivi slogovi bi bili >> najbolje resenje jer je prostor alociran za fiksne slogove >> uglavnom vrlo slabo iskoriscen, a jednom uneto podaci se retko >> menjaju. S obzirom da svoje programe pisem u COBOL-u (trenutno MS COBOL v4.5), da navedem nesto o njemu : 1. Ima slogove varijabilne duzine. Svaki slog u svom opisu prvo se (logicki) izdeli na fiksni i varijabilni deo (taj varijabilni deo je neka tabela promenljive duzine), i taj varijabilni deo se stavi na kraj sloga u njegovom opisu. Jedino je potrebno u nekom polju ispred njega navesti broj clanova te tabele. Npr : ..... 02 br-cl-tab PIC 999. 02 tabela OCCURS 1 TO 300 TIMES DEPENDING ON br-cl-tab. 03 tabela. 04 tab-polje-1 PIC ... 04 tab-polje-2 PIC ... ..... Bitno je da se iza varijabilnog dela u opisu sloga ne nalazi vise ni jedno polje, inace cela stvar pada u vodu jer ce COBOL ladno svaki slog snimati kao da ima celih trista clanova tabele. Potrebno je jos u zaglavlju datoteke staviti i klauzulu : RECORD IS VARYING IN SIZE 2. Pocev od verzije 4.5 MS COBOL je kao dodatak dobio i Screen painter program kojim se za pet-deset minuta moze nacrtati maska ekrana, i ta maska prevesti u cobolski source za ukljucivanje u programe. Time se mnogo dobija u produktivnosti. 3. Obogacen je rutinama za prepoznavanje kursorskih i Fxx tastera, pomeranja i event-a misa, kao i za uzimanje dela ekrana u neki bafer i pucanja istog na ekran, cime se lako pravi lep i normalan korisnicki interfejs (sa sve pull-down menijima, iako i ja licno ne volim u svojim aplikacijama - i dalje sam pristalica hijerar- hijskih menija) 4. Ima drajver za upravljanje relacionim bazama podataka preko SQL-a (EXEC SQL tralala..) - ovo jos nisam imao prilike da isprobam u praksi. 5. Moguce je linkovati funkcije ili procedure pisane u MS C-u ili Lattice C-u (nazalost ne i u Borland Turbo C-u), tako da se mogu dodati i sve ostale potrebne stvari 6. Ima prilicno dobar debugger (naravno ne u klasi TD-a) koji omogucava izvrsavanje programa liniju po liniju, ili se moze zadati brzina izvrsavanja aplikacije, pri cemu ce se na ekranu imati listing u kome je osvetljena linija koja se izvrsava. Naravno, u bilo koje vreme moze se pregledati sadrzaj pojedine promenljive (i promeniti), ili postaviti "monitor" na promenljivu. Mane su mu sledece, po meni : 1. Lose uradjena podrska overlay-a - u memoriji se u isto vreme moze nalaziti samo jedan overlay (nemoguce je da overlay poziva drugi overlay). 2. Desavalo mi se da ako preteram sa DATA DIVISION-om (ne terajte me da kazem koja je granica, jer je i sam ne znam), program koji se izvrsava blokira kompjuter iz cista mira, bez ikakvog upozorenja, i to tako da se ni sa CTRL-ALT-DEL ne moze resetovati. Ovo mi se jednom desilo kada sam radio jednu dzinovsku aplikaciju i pokusao da je uguram celu u jedan program (19 datoteka, oko 30 maski ekrana raznih velicina itd). 3. Dosta kucackog rada zbog samog nacina pisanja naredbi u COBOL-u, mada ovo ne smatram nekim velikim nedostatkom kada se covek navikne, jer i ovako 70% vremena pri razvoju aplikacije se trosi u misaoni deo posla oko smisljanja toga kako ce ta stvar da radi, a samo oko 30% u kucanje source-a iste (u navedeno vreme nisam ukljucio Murphy-a) 4. Sama sporost i "bangavost" PWB-a (Programmer's WorkBench - nesto kao Borlandova IDA), za koga smatram da bi se (kao i Windows-i) izvrsavao normalno brzo tek na 486 masini. Na kraju ovog mog romana, da napomenem da sa CLIPPER-om i FOX-om, kao i sa database bibliotekama na C-u nemam nikakvog iskustva. CLIPPER i FOX sam pogledao, i od njih odustao "na prvi pogled". Najbitniji razlog za to bio je taj sto nemam vremena da "treniram" neki novi alat za razvoj aplikacija. Trenutno jedino pomalo ceprkam po C-u. Molio bih citaoce da ovu poruku ne shvate kao pocetak diskusije ovaj_jezik_je_bolji_od_onog_jezika, vec samo kao navodjenje nekih iskustava sa COBOL-om, koga oko 4 godine koristim kao jezik za razvoj aplikacija. Isti sam naucio ne nekom kursu 1988, a sva ostala znanja stekao sam "ceprkajuci", u nedostatku prave literature (tek ovaj 4.5 je snabdeven help-om iz koga se dosta dalo nauciti). Nazalost, jos nisam "ponosni vlasnik" originalne verzije sa pratecih 2,5t dokumentacije. Iz tog razloga izvinjavam se na svemu sto sam propustio da navedem, ili ako sam u necemu pogresio. Pozdrav Predrag(pmijat)
jezici.156 dejanr, -> #149, vitez.koja
>> Programirao zadovoljstva radi, jer jos ne moram da se ishranjujem. >> Sad kad bih uzeo da pisem kliper program, garantovano bi bio bolji >> nego da nisam radio ovaj 'beskorisni' interpreter. Potpuno si u pravu. Zapravo, ja (sa žaljenjem) primećujem da većina nas danas "živi" gotovo isključivo od znanja stečenog baš u tim prvim godinama bavljenja programiranjem radi programiranja, pisanja asemblerskih programa "za džabe", traženja bezbroj života i sličnih "nestašluka". Što više u to vreme naučiš to će ti posle biti lakše! A i nama bi dobro došlo da povremeno radimo nešto "zabadava" i "neproduktivno", jer ako čovek ne drži korak sa događajima, neće dugo biti konkurentan. Na primer, trenutno Clipper "dobro ide", ali šta kada za koju godinu svi budu tražili grafičke aplikacije pod OS/2 ili Win NT? PS Verovatno sledi odgovor: "do tada će izaći Clipper za OS/2" ;>
jezici.157 dejanr, -> #151, ficus
>> Pa ocigledno je da nemozes imati i jare i pare ili ces imati kratke ili >> brze datoteke. Sa obzirom na standardne namene datoteka ja sam za spore >> i kratke. Ja bih pre bio za brži rad makar po cenu dužih datoteka. Danas su diskovi prilično jeftini, a računarsko vreme je prilično ograničavajući faktor. Naravno, pitanje je *koliko* će program biti sporiji zato što je datoteka duplo kraća. Tek kada se to zna može da se donese neki zaključak.
jezici.158 stomic, -> #148, paki
$ Da je toliko dobra, ne verujem da bi se mnogo pričalo o $ Pascalu, a Modula pominjala tek ovako, uzgred ;> Znači ti isključuješ sve o čemu se malo priča :). Nekada sam i ja koristio TP i obožavao Borland (još uvek mu svaka čast na brzini). I onda naletih na JPI (zahvaljujući Dragishi i Miru, prvenstveno) i oduševih se. I šta sam trebao da radim, da bacim zato što se o tome ne priča? Da više verujem drugima nego svojim očima :)? Pozdrav, stomic@hobbiton.
jezici.159 kale, -> #146, bulaja
>> Zaista me cudi zasto jos niko nije napravio database koja radi sa >> slogovima varijabilne duzine. Napravio Ingres.
jezici.160 pusa, -> #154, mjova
> ono što mi je bilo bitno to je C imao: čačkanje po memoriji, princip > vrlo sličnom asm-u, doslednost, jednostavnost itd. C je osim toga mnogo zgodan jer mozes da nataras kompajler da optimizira stvar, recimo kazes sta ide u registar, pa inkrementiras umesto dodas jedan... Dobro bi bilo kada bi to uradio sam kompajler pa isto preveo i a=a+1 i a++ ali na malim kompjuterima nema takvih kompajlera koji tako dobro optimizuju, pa dobro bar da to radi u saradnji sa programerom. Siguran sam da ce svaki dobro napisan C program na PC-ju da se izvrsi znatno brze nego jednako dobro pisan program na Pascalu ili Moduli, bas zbog tog!
jezici.161 miro, -> #135, prvul
ű> Ja baš pominjah operatore za rad sa bitovima a ti tako... to ű> se u C-u kaže: ű> ű> for (i=1;i<=0x80;i<<1) { ... } ű> ű> Ono 0x80 je čisto da bi bilo preglednije, kada god se petlja ű> sa bitovima zgodno je pisati 0x konstante... Kao što sam tamo rekao, operatore za rad sa bitovima imaju i Modula-2 (mimo standarda, ali već su normalna stvar) i čini mi se Turbo Pascal. Ovo drugo sam davno radio pa me ispravite ako griješim. Što se tiče različitih baza, stvarno izgleda glupo dok ne zatreba:). Najbolja mi je fora kad ti oktalno daje mod fajla pod Unix-om. Kad sam prvi put vidio mislio sam da je glupo, drugi put sam se zadivio:)).
jezici.162 miro, -> #152, ficus
ű> Pa sad moz da bude bolje da izaberes drugi prg jezik ali ű> stvarno samo u izuzetnim slucajevima. Cinjenica je da je ű> idalje baze podataka najlakse raditi u cliperu a igrice u c-u ű> ili pascalu. Ali se zato covek specija- lizuje. Ti si nešto govorio o bibliotekama i tako to. E vidiš, ja sam prije pet-šest godina počeo rad na jednoj biblioteci koju radim i dan danas i koja mi završava sve što nekome drugome završava Clipper. Znači, mogu sve u M2, osim naravno stvari koje gotove dobijem u drugom jeziku. Tu radi JPI:). ű> Ajd sad svi ste krenuli na tu citljivost sourcea. Po meni je ű> source citljiv onoliko koliko ga ti citljivo napises a o tome ű> da je po meni c mnogo citljiviji od paskala pa pretpostavljam ű> samim tim i od module... Lični stav. Inače, čitljivost paskala otežavaju BEGINovi, a i to što blokovi od jedne isntrukcije nemaju terminator. To prevazilazi M2 i mogu ti reći da je rezultat odličan. Što se tiče čitljivosti Ca, ja vjerujem da ga Covci čitaju bez problema, isto kao što vjerujem da Kinezima njihovih 5000 (valjda je to osnova) ideograma ne predstavlja veći problem nego nama naših 2*30. ű> :) kome ces lakse da svoj veliki projekat razbijes u manje ű> dijelove, ű> ű> Mislis da se u c-u to tesko postize? Ne mislim, već znam!:) Veliki problem Ca su globalna imena. Ako ti u npr. 50 modula u Cu imaš neka globalna imena, moraš sam da vodiš računa da ih daješ različita. A to nije baš zabavno iz projekta u projekat. Ovo kao primjer. Može još, ako želiš. ű>> :) netrivijalnim. Ima izuzetaka. Srecna okolnost za Sezam je ű> da ű> ű> Pa nemozes kompleksnost jednog programa da procenis po broju ű> linija imam recimo programce u clipperu sa oko 6000 linija ű> neznam tacan broj Naravno, zato sam i napisao da ima izuzetaka.
jezici.163 miro, -> #160, pusa
ű> C je osim toga mnogo zgodan jer mozes da nataras ű> kompajler da optimizira stvar, recimo kazes sta ide u ű> registar, pa inkrementiras umesto dodas jedan... Dobro bi bilo Ehhh, u jednom vremenu algoritmi optimizacije nisu bili neka pamet pa su programeri morali da pišu kod tako da ga oni kakvi su ipak dovedu do nečega. Međutim, oni su danas ipak malo odmakli pa se znaju i sami snaći. ű> kada bi to uradio sam kompajler pa isto preveo i a=a+1 i a++ ű> ali na malim kompjuterima nema takvih kompajlera koji tako ű> dobro optimizuju, pa dobro bar da to radi u saradnji sa ű> programerom. Što se tiče a=a+1 i a++ to je nešto što je najlakše za optimizovati. Preporučujem ti da pogledaš Uha i Almanna koji to vrlo zorno objašnjavaju. Optimizuje se ne samo inkrement već i operacije sa stepenima broja 2 što radi isto kao bit operatori i tako dalje. BTW, u 'nedavnom manifestu' piše koji je smisao imao ++/-- operator u prvom Cu. Tada se to radilo na PDPju a njegov zaista fantastični asembler ima način da nešto inc/dec nakon/poslije pristupa. Na mom fakultetu se to učilo, valjda jeste i kod vas u BG. Na 'malim kompjuterima' se sasvim uspješno vrti GNU C++, a on je vrijedan poštovanja u svakom pogledu, pa i u pogledu optimizacija. A o Zortech C++, MS Fortran optimizacijama da i ne govorim. ű> Siguran sam da ce svaki dobro napisan C program na PC-ju ű> da se izvrsi znatno brze nego jednako dobro pisan program na ű> Pascalu ili Moduli, bas zbog tog! Let's try.:) Znaš onu 'Boj ne bije svijetlo oružije, već boj bije srce u junaka'?:)
jezici.164 janko, -> #163, miro
> optimizovati. Preporučujem ti da pogledaš Uha i Almanna > koji to Reč je ljudima koji se zovu, izvorno napisano, Alfred V. Aho i Jeffrey D. Ullman. Uho i Almann? :)
jezici.165 dr.grba, -> #150, ficus
>> Pa ja i rekoh da je to mana clippera ako bude srece ja cu napisati klasicu >> za rad sa slogovima varijabilne duzine. Nije to mana Clippera. To je nedostatak koji nije bio odsudan u vreme projektovanja dBase formata datoteka. Tada Clipper nije ni postojao. Pozdrav, dr ÔpŰa
jezici.166 dr.grba, -> #156, dejanr
>> PS Verovatno sledi odgovor: "do tada ce izaci Clipper za OS/2" ;> Do tada ce izaci Clipper za OS/2. (((; Ne, salim se, zaboga! Ne brisi poruku! >> ...A i nama bi dobro doslo da povremeno radimo nesto "zabadava" i >> "neproduktivno", jer ako covek ne drzi korak sa dogadajima, nece dugo >> biti konkurentan... Sad bih, zapravo, mogao da kvotiram mnoge iz ove rasprave. Drago mi je da vidim da postoje ljudi koji postuju unapredjivanje ovog naseg posla (za mene je i zadovoljstvo i posao, posto zivim od programiranja). Dok je samo zadovoljstvo, mnogo je lakse baviti se ucenjem i usavrsavanjem, jer nema psiholoskih barijera. Verujte, nije lako u atmosferi pritiska da neki posao bude sto pre (a sto bolje) uradjen, sesti pa istrazivati sta se nalazi u ovoj ili onoj biblioteci, kako iskoristiti neku funkciju, kako optimizovati neke aspekte programa... Na duge staze ima efekta, ali nikad nisam zadovoljan. Da sam mogao svoje ideje da razvijam u vreme kada NISAM MORAO da radim, sigurno bih danas bio bolji u svom poslu. I zato pomalo zavidim svim ovim klincima srednjoskolcima, koji danas razbijaju C i asembler bolje nego sto cu ja ikada to moci. A u sustini sam zadovoljan, jer ce bar ti klinci sami moci da ispeku svoj zanat, a ne da budu prepusteni na milost i nemilost nervoznim i isfrustriranim profesorima. Da ne govorim o navici da se non stop uci novo, sto se mora, a vec mnogo puta je receno zasto... Pozdrav, dr ÔpŰa
jezici.167 ficus, -> #157, dejanr
:) Ja bih pre bio za brzi rad makar po cenu duzih datoteka. Danas su diskovi :) prilicno jeftini, a racunarsko vreme je prilicno ogranicavajuci faktor. Jest a ja imam hard disk od 44mb :'((((((((( smrc, smrc, buaaa :'((( i kad tu strpas bc clipper itd itd... JA sam morao da brisem tp da bih oslobodio mesto za datoteku sa recima. :) Naravno, pitanje je *koliko* ce program biti sporiji zato sto je datoteka :) duplo kraca. Tek kada se to zna moze da se donese neki zakljucak. DAtoteka ce biti cak preko 8 puta kraca (4 puta skoro sigurno a cak kad bi slogovi bili i fixne duzine sve bi bilo krace 2 puta) ali u praksi preko 8 puta kraca datoteka a brzina se nece osetiti u programu.
jezici.168 ficus, -> #161, miro
:) Kao sto sam tamo rekao, operatore za rad sa bitovima imaju i :) Modula-2 (mimo standarda, ali vec su normalna stvar) i cini mi se :) Turbo Pascal. Ovo drugo sam davno radio pa me ispravite ako Sto se toga tice ne gresis apsolurno si u pravu mislim da se u pascalu to zove shl i shr ali nisam siguran. Ali diskusija uopste nije bila o samim operatorima shiftovanja nego o preglednosti i mogucnostima for-a u c-u (i dalje je u prilicnoj meri pregledan ali ima mnoooogo vece mogucnosti)
jezici.169 ficus, -> #162, miro
:) ű> da je po meni c mnogo citljiviji od paskala pa pretpostavljam :) ű> samim tim i od module... :) :) Licni stav. Slazem se. O ukusima ne vredi.... :) Sto se tice citljivosti Ca, ja vjerujem da ga Covci citaju bez :) problema, isto kao sto vjerujem da Kinezima njihovih 5000 (valjda :) je to osnova) ideograma ne predstavlja veci problem nego nama :) nasih 2*30. Ali ga sad ipak malo pretera. Kad sam reko citljiviji mislio sam da bilo ko ko zna bar osnove c-a ume da procita program u c-u i da ce se u njemu lakse snaci nego u prg-u u pascalu. Sto se module tice ja nju necu da napadam (nisam ni dosad samo sam branio c) jer nisam radio u njoj istina voleo bih da vidim kako sve to izgleda ali... Mislim kod module mi se svidja to da lako mogu da vezem c i pascal i ostalo (kolko sam ukapiro to je sve podrzano u moduli) ali cisto iz prakticarskih razloga (ako mi u timu jedan pise u paskalu drugi u c-u a treci u boze_sacuvaj_me_cemu). :) Veliki problem Ca su globalna imena. Ako ti u npr. 50 modula u :) Cu imas neka globalna imena, moras sam da vodis racuna da ih Koja crna globalna imena. zaobidji me sa tim ali ako si mislio na file scope promenljive sasvim lepo sljakaju u c-u a ako bas oces onda mozes i da koristis klse u c++ -u. A ako nisi mislio na file scope onda ako imas dve promenljive sa istim imenom neka bude p kako znas kojoj si pristupio kada napises p. P.S. ako pomenes kvalifikatore ima ih i u c-u <class-name>::<prom> :) Ovo kao primjer. Moze jos, ako zelis. Samo napred. P.S. Posto ja vec rekoh da nisam jezikonapadacki tip i posto mi nebi skodilo da naucim jos koji prg. jezik ajd rekni mi koliko je kompletna jpi modula ali sa sve c kompajlerom i ostalim sto uz to ide? (mislim na broj disketa)
jezici.170 ficus, -> #155, pmijat
:) S obzirom da svoje programe pisem u COBOL-u (trenutno MS COBOL v4.5), Ej, to me zanima koliko je to disketa? ************************************** :) 1. Ima slogove varijabilne duzine. Svaki slog u svom opisu prvo :) se (logicki) izdeli na fiksni i varijabilni deo (taj varijabilni :) 02 br-cl-tab PIC 999. :) 02 tabela OCCURS 1 TO 300 TIMES DEPENDING ON br-cl-tab. Jest ali meni trebaju stringovi varijabilne duzine. Istina da se simulirati ali posle mi treba index na tim stringovima... :) 5. Moguce je linkovati funkcije ili procedure pisane u MS C-u ili :) Lattice C-u (nazalost ne i u Borland Turbo C-u), tako da se 'esil siguran da nemoze bc :(((( mislim znam da stvar stoji nesto bolje ako stavis kompilaciju kao c a ne kao c++ (mislim na clipper) :) 3. Dosta kucackog rada zbog samog nacina pisanja naredbi u COBOL-u, E pa to bi bila glavna mana cobol-a. Ali je zato citljivost povecana. Jos da nije pozicioni jezik. Ucio sam ja cobol ali jako davno i posto je sve to bilo (za klinca koj je zavrsio 6 razred O.S.) prilicno kruto jer je jedina masina na kojoj sam to mogo da probam bio DPS 66 kome je sistem padao zbog vrucine na svakih sat vremena a o drugim lepotama rada preko tekstualnog terminala i da ne pricam, vrlo brzo sam digo ruke od prakticnog rada i zabranio sam svima da mi cobol i pomenu. Sada bi vec trebao i to da jednom pregrmim (trebace mi). :) 4. Sama sporost i "bangavost" PWB-a (Programmer's WorkBench - nesto kao :) Borlandova IDA), za koga smatram da bi se (kao i Windows-i) izvrsavao :) normalno brzo tek na 486 masini. E pa sad microsoft nikad nije umeo da napise IDE to znam iz "prakticnih" iskustava sa masm-om. :) shvate kao pocetak diskusije ovaj_jezik_je_bolji_od_onog_jezika, vec samo Pa sad za poslovnu primenu (za koju je inace i namenjen) jeste jedan od najboljih ali za neke druge stvari... Ipak ponekad treba imati izbor izmedju vise prg. jezika.
jezici.171 bulaja, -> #147, dejanr
││Zaista me cudi zasto jos niko nije napravio database koja radi sa ││slogovima varijabilne duzine. │└─── │To se svakako moze uraditi, ali time bi se gubilo na performansama. │Koliko, to zavisi od realizacije, ali jasno je da je lakse i brze │operisati sa slogovima fiksnih duzina. └─── Lakse je samo za onoga ko pise lib, inace bi sve trebalo da bude potpuno transparentno za korisnika. Za bazu podataka sa slogovima promenljive duzine trebalo bi napraviti malu indeksnu datoteku za poziciju svakog sloga preko koje bi se referencirali slogovi za skakanje po bazi (GoTo <RecNo>). Za odredjivanje pozicije dosta je jedan long int (dakle svega 4 bajta po slogu) gde mi npr. pisao relativan pocetak odredjenog sloka (npr. slog broj 123 pocinje od 45,678.-og bajta) i onda bi se pristup odvijao identicno kao i da su slogovi fiksne duzine (u kom slucaju se pocetak sloga dobija iz rednog broja i duzine jednog sloga). Tako bi gubici u performansama pri skakanju po bazi bili neznatni (potrebno je samo malo vremena da se pristupi indeksnoj datoteci). U slucaju sekvencijalnog pristupa, moglo bi cak doci do poboljsanja performansi, jer je potrebno ucitati manje podataka sa diska (zbog manje duzine sloga).
jezici.172 dejanr, -> #166, dr.grba
>> Drago mi je da vidim da postoje ljudi koji postuju unapredjivanje >> ovog naseg posla (za mene je i zadovoljstvo i posao, posto zivim od >> programiranja). Dok je samo zadovoljstvo, mnogo je lakse baviti se >> ucenjem i usavrsavanjem, jer nema psiholoskih barijera. Verujte, >> nije lako u atmosferi pritiska da neki posao bude sto pre (a sto >> bolje) uradjen, sesti pa istrazivati sta se nalazi u ovoj ili onoj >> biblioteci, kako iskoristiti neku funkciju, kako optimizovati neke >> aspekte programa... Na duge staze ima efekta, ali nikad nisam zadovoljan. Svojevremeno sam za "Računare" radio kraći intervju sa g. Draganom Kopunovićem, našim čovekom i vlasnikom softverske firme u Kanadi koji je ovde bio da dogovori neke programerske poslove. Zapravo to i nije bio intervju nego smo razgovarali oko neke moguće saradnje (od koje, na žalost, ništa najzad nije bilo), pa se tokom tog razgovora došlo do toga da bi bilo interesantno ponešto preneti i čitaocima "Računara", pa je tako od razgovora "sklepan" intervju ("Računari 41"). U svakom slučaju, g. Kopunović je rekao da bi za svakog programera ovde dobra ideja da krene da piše neku OS/2 (tada se tek pojavio OS/2) aplikaciju. Na moju primedbu da je prilično veliki posao savladati neki novi OS, a veliko je pitanje da li će se neki program, u koji je uloženo dosta vremena, prodati, i da ta njegova sudbina ne zavisi samo od programa nego i od mnogih drugih stvari, pa pomalo i od sreće. Gospodin Kopunović je na to rekao da to nije toliko bitno, jer sve i da se program ne proda, znanje koje je stečeno tokom pisanja tog programa se može itekako prodati. "Prorekao" je da nije daleko dan kada će bolje perspektive za posao (pri tome nije mislio na "posao u YU" ;) imati programer koji je solidno verziran u pisanje programa za OS/2 i slične platforme od virtuoza programiranja pod DOS-om. Međutim, moram da kažem da kod nas jako loše ide sve što nije DOS aplikacija. Ja sam pre jedno pola godine imao malo vremena i napravio jedan Windows program, zapravo prepisao neki svoj raniji program za tužbe tj. za štampanje predloga za dozvolu izvršenja. Program je, naravno, nekada pisan na Clipper-u i integrisan je u razne programe koje imam na raznim mestima instalirane. Napravio sam ga baš da bih probao kako idu stvari pod Windows-om, u nadi da ću videti koliko je sve to pouzdano, kakvi se problemi javljaju u praksi itd. A problem je zahvalan jer je podataka relativno malo, lako se pravi backup, ostaje trag svega na papiru pa i neka havarija nije nenadoknadiva. A jako je zgodno kod štampanja, da se koriste malo raznovrsniji fontovi, da se štampa ćirilicom iz Windowsa itd. E, od tada kada sam ga napisao pokušavam da ubedim nekog od onih koji inače koriste taj moj program za tužbe da uzme Windows verziju, i bukvalno nema šanse :( Naravno, ideja je bila da im to dam džabe, da bi pratio kako funkcioniše. Svi imaju Windows na disku da bi igrali pasijans i mine, imaju i miša koji su uglavnom dobili džabe uz računar, ali im se kosa na glavi nakostreši kad vide onaj ekran sa scroll barovima, menijem itd. Kažu blješti ekran, sitna slova, komplikovano za upotrebu (????) daj ono lepo što je pre radilo. Ne znam da li ja to imam mnogo konzervativne klijente ;( Meni se čini da je ovo pravi trenutak da se (što se domaćeg tržišta tiče) pišu PD/SW Windows programi i da se na njima "ispeče zanat". Pogledajte, recimo, kako je sjajan 'SezamDrive 4 Win' napravio .obj. Vrlo me zanima koliko će još vremena proći dok firme ne počnu da traže takve stvari.
jezici.173 dejanr, -> #171, bulaja
>> Za bazu podataka sa slogovima promenljive duzine trebalo bi napraviti >> malu indeksnu datoteku za poziciju svakog sloga preko koje bi se >> referencirali slogovi za skakanje po bazi (GoTo <RecNo>). Za >> odredjivanje pozicije dosta je jedan long int (dakle svega >> 4 bajta po slogu) gde mi npr. pisao relativan pocetak odredjenog sloka >> (npr. slog broj 123 pocinje od 45,678.-og bajta) i onda bi se pristup >> odvijao identicno kao i da su slogovi fiksne duzine (u kom slucaju se >> pocetak sloga dobija iz rednog broja i duzine jednog sloga). Taj deo priče je nesporan, problem sa slogovima promenljive dužine nastaje kada neki od njih edituješ pa isti postane kraći (manji problem) ili duži (veći problem). U tom slučaju nema druge nego prepisati ga na kraj baze, a prostor koji je zauzimao se oglašava kao prazan. Ako posle naleti novi slog koji može da upadne u slobodan prostor, super. Ako ne, prostor se sve više i više fragmentira i najzad u nekom strateškom trenutku mora da se radi trash collecting tj. kompresija datoteke kako bi se prazni prostori uklonili. Za neki manji DBMS takva operacija je dosta traumatična, pa je uglavnom projektuju tako da se vrši na zahtev korisnika (PACK), što je često neprihvatljivo jer "neuki" korisnik to nikad neće uraditi ("ne diraj lava dok spava" ;) pa će performanse sve više padati a prostor koji datoteka zauzima najzad prerasti ono što bi bilo da su slogovi fiksne dužine. Za veće sisteme to ide automatski, ali projektovanje takvog DBMS-a verovatno prevazilazi ono o čemu ovde pričamo.
jezici.174 pavbok, -> #172, dejanr
B> Meni se čini da je ovo pravi trenutak da se (što se domaćeg tržišta B> tiče) pišu PD/SW Windows programi i da se na njima "ispeče zanat". B> Pogledajte, recimo, kako je sjajan 'SezamDrive 4 Win' napravio .obj. B> Vrlo me zanima koliko će još vremena proći dok firme ne počnu da traže B> takve stvari. Sa obzirom da se od pre neku godinu skoro svi programi preusmeravaju na Windows okruženje, a još i sa pojavom Windows NT-a, svi će biti primorani da se okrenu Windows okruženju a to znači i programiranju za i u Windows-ima. To mi je jako drago jer je Windows jedan veoma jak OS. Meni je u stvari lak i jednostavam rad i u DOS-u i u Windowsu, ali u zadnje vreme što više provaljujem Windows i njegove OLE i Drag and Drop funkcije, sve mi je lakši i move i copy i rename failova. Velika prednost je svakako i Cliboard koji je verovatno jedna od najboljih opcija Windowsa uz svakako gore navedene OLE i DaD funkcije. Ja nisam programer već se bavim kompjuterima i programima prvenstveno za Dizajn i obradu teksta (prelom časopisa i knjiga i sl.), poznajem Basic i pomalo Pascal ali samo toliko da napisem npr. program za Telegrafiju (ovo je bilo u Vojsci) i ćaletu za loto itd., ali poznajem šta je budućnost i vidim da će NT biti vrhunac vrhunaca Operativnih sistema, (ah da, čuo sam da je Windows 3.xx pisan u Pascalu) jer sam na OS-ove iz nužde, a naravno i iz ljubavi izuzetno mnogo oslonjen, koristeći programe za obradu teksta i ostalo. Još jedan plus za Windows je i taj, npr. što je veoma dobro organizovan rad u više programa odjednom, i smanjena mogućnost zaglavljivanja kompjutera, samo Ctrl-Alt-Del i Enter i vratite se u Program Manager. A tek NT, kako kažu, biće nešto sporiji ili ne u zavisnosti od Hardvera od Win 3.0, kod koga će skoro biti isključeno zaglupljivanje računara. Uf, al' se napričah, ajd' prijatno svima. Bojan P.S. Programeri i ostali samo napred u Windowse i nećete pogrešiti. Znate onu ko rano rani, tri sreće grabi (ceo dan mu se spava)!
jezici.175 ficus, -> #173, dejanr
:) prostori uklonili. Za neki manji DBMS takva operacija je dosta traumaticna, :) pa je uglavnom projektuju tako da se vrsi na zahtev korisnika (PACK), sto Prilikom svakog brisanja proverim koliko je stvar fragmentirana i ukoliko sam presao neki limit (10%???) lupim mu pack i resim problem a dotle sto bolje koristim ono mesto sto ga imam.
jezici.176 ficus, -> #172, dejanr
:) Medutim, moram da kazem da kod nas jako lose ide sve sto nije DOS :) aplikacija. Ja sam pre jedno pola godine imao malo vremena i napravio Iz veoma jednostavnog razloga - ja nemam windowse na hardu (instaliram ih jedino sa vremena na vreme kad stvarno burzujisem sa mestom na disku) sve zivo drzim na disketama i ono sto instaliraminstaliram tek tolko kolko mi treba i svejedno nema mesta za windows. a o duzini aplikacija koje rade pod Windows-om i njihovoj "brzini?????" da i ne pricam. Inace slazem se da je sistem buducnosti (citaj: "daleke buducnosti") kad ako nista drugo budem imao hard od bar 85mb+stacker naravno i to da radi na nekoj pristojnoj brzini. znam ja da sad disk od jedno 105 mb nije skup ali kad sam ja kupio sebi komp ovih mojih 44 mb su bili citava vasiona. Pogotovu kad se uzme u obzir da sam pre toga imao 20 mb i tu je bilo dosta mesta za sve sto mi je padalo napamet (pcshell 5.1,tp,tc,clipper,dbase,.... pa cak i igrice) i eventualno mi je ponekad zafalilo 500 kb max. i to sve je super funkcionisalo do pre nekih 2 godine a tad su proizvodjaci softvera ..... (pa zna se sta su uradili) i sad ja imam "obican C++" na """"SAMO 40mb"""" istina kod mene je u mnoooogo minimalnijoj verziji (9mb) pa gde ja tu da smestim windows-e??? :) kakvi se problemi javljaju u praksi itd. A problem je zahvalan jer je Pa na prvom mestu problem brzine na standardnom 386/33/44mb ili cak i 85mb ali problem ostaje isti. :) scroll barovima, menijem itd. Kazu bljesti ekran, sitna slova, :) komplikovano za upotrebu (????) daj ono lepo sto je pre radilo. Ne znam Za prva dva necu da diskutujem jer je stvar ukusa. Ja koristim 50 redova i jos uvek me da kucnem u drvo oci sluze. ali sto se komplikovanosti tice naj- veci deo iste lezi u brzini OS-a a ostatak na onome: "znam dos koj ce mi windows".
jezici.177 paki, -> #158, stomic
­> prvenstveno) i oduševih se. I šta sam trebao da radim, da ­> bacim zato što se o tome ne priča? Da više verujem drugima ­> nego svojim očima :)? Što da ne ;>> Šalim se. Stvarno nisam video JPI Modulu, ali po textovima u Računarima i njenoj popularnosti ovde nisam baš stekao najbolje mišljenje o njoj. Ko zna, možda jednog dana i ja probam i oduševim se :)
jezici.178 bdm., -> #177, paki
## Što da ne ;>> Šalim se. Stvarno nisam video JPI Modulu, ali po ## textovima u Računarima i njenoj popularnosti ovde nisam baš stekao Ti tekstovi su bili mnogo davno (seti se nedavno objavljenih bisera iz tekstova Računara)... :) ## najbolje mišljenje o njoj. Ko zna, možda jednog dana i ja probam i ## oduševim se :) Dođi do mene ako hoćeš da vidiš (odma da te vrbujem). :) BDM.
jezici.180 dejanr, -> #178, bdm.
>> Ti tekstovi su bili mnogo davno Oćemo isti test, sa novim verzijama? Dobijete tamošnje primere, ispravite sors ako smatrate da nešto nije "u duhu jezika" (pretpostavlja se da se neće menjati algoritam, naravno, mada ne verujem da postoji brži od primenjenog), prevedite ga i probajte. Dakle, najnovija verzija JPI Module 2 koju imate, i najnovija verzija paskala koju imam. Poredimo vreme prevođenja, dužinu prevedenog koda (recimo, uz default "prekidače") i vreme izvršavanja na 486/50 ili 386/33, kako izaberete?
jezici.181 ficus, -> #178, bdm.
:) Dodi do mene ako hoces da vidis (odma da te vrbujem). :) Ja rekoh pre par poruka da i mene cisto zanima kako to izgleda drugim recima koliko mi disketa treba i koliko mesta na hardu?
jezici.182 pmijat, -> #170, ficus
>> Ej, to me zanima koliko je to disketa? >> ************************************** 6 HD 1.2MB disketa. Kada se instalira, zauzima oko 7-8 MB na disku. BTW, opciono biras da li ces da instaliras i delove za razvoj Windows aplikacija (dobro si cuo), kao i za OS/2. Sve to ide u paketu. >> Jest ali meni trebaju stringovi varijabilne duzine. Istina da >> se simulirati ali posle mi treba index na tim stringovima... Razjasni malo kakvi to stringovi varijabilne duzine. Da li mozda mislis na neko, kao, memo polje ili bas mislis na to da se svako slovno polje u slogu upisuje samo onoliko na disk koliko je dugacko? >> 'esil siguran da nemoze bc :(((( mislim znam da stvar stoji >> nesto bolje ako stavis kompilaciju kao c a ne kao c++ (mislim >> na clipper) Na zalost, siguran sam. Kao jedan primer, tlink nece ni da cuje za MS-ove .obj-ove. A MS je uz cobol isporucio par komada malih .obj (od po 2-3k) koji se MORAJU linkovati zajedno sa .obj-ima iz MS C-a, MS Pascal-a, Laticce C-a, ali NE i TC-a 8((. >> povecana. Jos da nije pozicioni jezik. Ucio sam ja cobol ali >> jako davno i posto je sve to bilo (za klinca koj je zavrsio 6 >> razred O.S.) prilicno kruto jer je jedina masina na kojoj sam >> to mogo da probam bio DPS 66 kome je sistem padao zbog vrucine To je praistorija. Jedan drugar koji je u srednoj skoli ucio COBOL i tamo ga zamrzeo da ne moze ime da mu cuje, a trenutno radi na TP-u, kada je video moj listing komentari su mu bili : "nazubljeni COBOL???!!!", "COBOL koji ne lici na COBOL", i "ovo vise lici na Pascal". >> E pa sad microsoft nikad nije umeo da napise IDE to znam iz >> "prakticnih" iskustava sa masm-om. Tacno. Ja zato i dalje rabim takodje praistorijski norton editor (probo ja da predjem u qe, ali ne ide nekako...), i par .bat fajlova koji mi vrse posao oko kompilacije i mila majka... >> Pa sad za poslovnu primenu (za koju je inace i namenjen) jeste >> jedan od najboljih ali za neke druge stvari... Ipak ponekad >> treba imati izbor izmedju vise prg. jezika. Naravno. Ne pada mi napamet da pisem graficke aplikacije u njemu 8). Pozdrav Predrag(pmijat)
jezici.183 tarva, -> #172, dejanr
Í───────────────── ║> .... Svi imaju Windows na disku ║> da bi igrali pasijans i mine, imaju i miša koji su uglavnom dobili ║> džabe uz računar, ali im se kosa na glavi nakostreši kad vide onaj ║> ekran sa scroll barovima, menijem itd. Kažu blješti ekran, sitna ║> slova, komplikovano za upotrebu (????) daj ono lepo što je pre ║> radilo. Ne znam da li ja to imam mnogo konzervativne klijente ;( Ë───────────────────────────────────── Nemaš, svi ih imamo :(. Radio sam neki program za zubare u Clipperu i napravio test funkciju iz ClippGraph-a za fino crtanje zuba, ubacio miša, tako da samo "klikneš" na zub i crtaš po njemu, ali zubar koji je koristio raniju veziju nije hteo ni da čuje, bilo mu je lepše u karakter modu bez miša. Ja sam bio zapanjen i odustao (za sad) od ideje da ubacim miša i podršku grafici. Zaista, još mnogo će vode proteći dok se ne osmele da pređu na Windows verzije naših programa. žak je bolje ako nikad nisu ranije radili na računaru, misle da tako mora, pa se naviknu.
jezici.184 pmijat, -> #172, dejanr
>> igrali pasijans i mine, imaju i miša koji su uglavnom dobili >> džabe uz računar, ali im se kosa na glavi nakostreši kad vide >> onaj ekran sa scroll barovima, menijem itd. Kažu blješti >> ekran, sitna slova, komplikovano za upotrebu (????) daj ono >> lepo što je pre radilo. Ne znam da li ja to imam mnogo >> konzervativne klijente ;( Paaa, da znas, i nemas. Po nekim ljudima sa kojima sam razgovarao (jedan se recimo bavi DTP-om, znaci "korisnik" je a ne "programer"), Windowsi i mis su dobra stvar za graficke aplikacije tipa COREL i sl, ali za obicne poslovne stvari, gde se obicno trazi brzina unosa i rada, ljudi pre opredeljuju za DOS varijante i to bez upotrebe misonje. Zasto ? Zato sto je brze pritisnuti SHIFT+kursor za markiranje i CTRL+Ins / SHIFT+Ins za copy/paste nego za to potezati rukom do misa. Vecina kompjuterskih radnih stolova su krcati papirima i papiricima i mis se obicno nalazi negde ispod njih. Sto se lepote aplikacije tice, opet, ljudima su mozda cak i lepse DOS aplikacije ako je korisnicki interfejs ukusno dizajniran, od klasicnih Windows prozora sa menijem u zaglavlju ekrana i raznoraznim check-box-ovima. Jedan od korisnika mi je recimo izjavio "da mu se kosa digne na glavi kad vidi onaj meni na vrhu ekrana" (sistem sa pull-down menijima) jer "ko ce da popamti gde se tu sta nalazi". Covek voli obicne menije na sred ekrana, i to po mogucstvu da uz svaku stavku ide par reci o tome sta ta opcija radi. A sad, malo i o stampi : vecina poslovnih korisnika tera aplikacije za trgovacke knjige, gde im je bitno da BRZO dobiju tabele na papiru, a nije ih mnogo briga kako ce to da izgleda, pa cak lako prezale i ako nema YU slova na stampacu (sta ga briga, kad SDK to prihvata). Zamislite koliko bi trajala stampa konto-kartica neke firme iz Windows-a u grafickom rezimu. Stampaci su mnoooogo brzi u text modu. Molio me covek da mu donesem "neki lep program da moze da kuca poslovna pisma". Imao je CHI, znao da radi sa njim, ali cuo je da ima mnoogo boljih stvari... Elem, dodjem ti ja kod njega, instaliram mu Udovice, W4W 2.0, 30-tak YU TTF, pokazem mu kako W4W radi i on se odusevi k'o kucence... Dodjem kod njega posle 15-tak dana, kad on i dalje kuca u CHI-ju. Zasto ? "dok onaj tvoj lepi program odstampa sta sam mu otkuc'o, ja u ovome ruznom mogu Rat i Mir da pustim u dva primerka". Svidja mu se Minesweeper, pa sam mu ostavio Windows-e na masini. BTW, ima 386, 4MB RAM-a, 100 MB HD. Poenta ove price je bila u tome da postoje programi koje je opravdano praviti za windows-e, a postoje i ostali programi. Firma koja se na primer bavi vodjenjem knjigovodstva drugim firmama, da tera svoj software pod Windows-ima, brzo bi otisla pod led, osim ako nema 686 sa 4 GB RAM-a i stampac adekvatnih mogucnosti... Ovo sam procitao u VICEVIMA : Q: Kako od 486 napraviti XT ? A: Instaliras Window-se ! Pozdrav Predrag(pmijat) p.s. Izvin'te zbog PAD-a
jezici.185 ganta, -> #172, dejanr
--> Meni se čini da je ovo pravi trenutak da se (što se domaćeg tržišta tiče) --> pišu PD/SW Windows programi i da se na njima "ispeče zanat". Pogledajte, --> recimo, kako je sjajan 'SezamDrive 4 Win' napravio .obj. Vrlo me zanima --> koliko će još vremena proći dok firme ne počnu da traže takve stvari. Ipak, u nekim firmama (recimo u Nolitu), ne znaju šta je to DOS, bio sam (prijatno) iznenadjen. A da je pravi trenutak, i da imamo potencijale .obj je na pravi način dokazao. G.
jezici.186 bulaja, -> #173, dejanr
│Taj deo price je nesporan, problem sa slogovima promenljive duzine nastaje │kada neki od njih editujes pa isti postane kraci (manji problem) ili duzi │(veci problem). └─── Prica oko varijabilnih slogova je pocela posto sam zakljucio da u vecini slucajeva primene baze podataka nije potrebno previse menjati vec unete podatke. Ukoliko je potrebno njihovo stalno menjanje (pre svega menjanje duzine stringova, posto za brojeve nije neki problem), tu zaista nastaju ti problemi za implementaciju, ali oni nisu previse strasni niti su neresivi. Slucaj da se vecem delu slogova poveca duzina je svakako ekstreman i nerealan :). U proseku ce se uvek nesto produzavati, nesto skracivati i dobar algoritam za trazenje praznog prostora po bazi bi trebao bez problema (i usporenja) da izlazi sa time na kraj. Moze se napraviti cak sistem koji ce deliti slog na delove, pa ce pocetak (ili vecina podataka) ostati na starom mestu, a tu ce stojati i pointer gde se nalazi ostatak sloga. Ovo bi odvelo do fragmentacije na nivou slogova, sto se sigurno ne bi pozitivno odrazilo na performanse :), ali tada ne bi bilo opasnosti od povecanja neiskoriscenog prostora u bazi. │performanse sve vise padati a prostor koji datoteka zauzima najzad │prerasti ono sto bi bilo da su slogovi fiksne duzine. └─── Datoteka ce rasti (pod uslovom da imamo posla sa "glupim" sistemom:), ali performanse ne bi trebale da se promene. Do usporenja bi jedino moglo doci pri sekvencijalnom pristupu, ali se to lako da resiti tako sto svaki slog u sebi sadrzi i pointer na sledeci slog (jos jedan long int, ali nije strasno:).
jezici.187 mstanic, -> #174, pavbok
>> poznajem >> šta je budućnost i vidim da će NT biti vrhunac vrhunaca >> Operativnih sistema, (ah da, čuo sam da je Windows 3.xx E, svašta. :))) Zar smo u budućnosti osuđeni baš na gore navedeni tzv. OS? Ja onda ostajem u svetloj prošlosti.
jezici.188 petrovics, -> #183, tarva
>> Zaista, jos mnogo ce vode proteci dok se ne osmele da predu na >> Windows verzije nasih programa. Cak je bolje ako nikad nisu >> ranije radili na racunaru, misle da tako mora, pa se naviknu. Ne znam zasto se toliko forsiraju Windowsi i tamo gde im u stvari i nije mesto? U firmama se od racunara uglavnom trazi da se brzo i efikasno obavi neki tekuci posao bilo da je rec o knjigovodstvu, fakturisanju, vodjenju kalendara, podsetnika, telefonskog imenika ili obradi kratkih tekstova. Za ovakve primene su DOS aplikacije mnogo brze, upotrebljivije i efikasnije uopste. Lakse je i brze pritisnuti par funkciskih tastera nego ganjati misem menije i ikone. Estetski izgled aplikacija je bitan samo u tom smislu da nisu bas totalno bezveze, daleko od tog da moraju da budu nalickane i jos u grafickom rezimu. Licno smatram da je Windows dobar samo za finije poslove u koje ubrajam obradu duzih tekstova, prelom, grafiku i mozda jos par stvari. Bas bih voleo da vidim coveka koji bi rado, svaki dan skljocao misem u potrazi za analitickim karticama u finansiskom knjigovodstvu ili dok hoce da na brzinu napise jednu fakturu. Ipak treba raditi u okruzenju koje je adekvatno za taj posao pa makar ono bilo i demode star desetak godina. pozdrav, Sasa
jezici.189 dejanr, -> #188, petrovics
>> Ne znam zasto se toliko forsiraju Windowsi i tamo gde im u >> stvari i nije mesto? U firmama se od racunara uglavnom trazi da >> se brzo i efikasno obavi neki tekuci posao bilo da je rec o >> knjigovodstvu, fakturisanju, vodjenju kalendara, podsetnika, >> telefonskog imenika ili obradi kratkih tekstova. Za ovakve >> primene su DOS aplikacije mnogo brze, upotrebljivije i >> efikasnije uopste. Lakse je i brze pritisnuti par funkciskih >> tastera nego ganjati misem menije i ikone. Estetski izgled >> aplikacija je bitan samo u tom smislu da nisu bas totalno >> bezveze, daleko od tog da moraju da budu nalickane i jos u >> grafickom rezimu. Ova argumentacija je po mom mišljenju sasvim ispravna *A L I* sećam se u "stara dobra vremena" kada je CP/M izumirao i DOS se pojavljivao, da je postojala *IDENTIžNA* argumentacija da "to" nije potrebno, da nema vajde od toga što su ekrani uokvireni, da se sasvim lepo kuca 1 za stavku 1 menija, 2 za stavku 2 itd. Po svemu tome, za DOS-om i ovim "a la Norton" interfejsima nema potrebe. A opet, kako je išlo vreme, tako su standardi rasli i sad kad vidiš program koji je bez "šminke" odma' pitaš koji je "seljak" to pisao (nije da i ja nemam par takvih programa iz starih vremena koji se i dalje vrte :( ) Ukratko, ne požeš da zaustaviš progres. Jeste, sasvim lepo računovodstva i knjigovodstva i magacini i slične stvari rade pod DOS-om, ali za koju godinu niko neće hteti da ih pogleda ako nisu u grafičkom okruženju. Zato i kažem da treba na vreme da se pripremamo. Inače, ja ne osećam baš preteranu želju da previše radim pod Windows-om, ali mora se...
jezici.190 ppekovic, -> #174, pavbok
>> šta je budućnost i vidim da će NT biti vrhunac vrhunaca Operativnih >> sistema Slabo si čuo. Trenutni vrhunac vrhunca, kako si ga nazvao. je unix i još dugo godina će biti unix. NT će morati dobro da se pomuči da bi tu bilo šta promenio, pogotovu imajući u vidu da nije najavljeno ništa revolucionarno, tj. ništa što na unix-u već ne postoji. >> A tek NT, kako kažu, biće nešto sporiji ili ne u zavisnosti od >> Hardvera od Win 3.0, kod koga će skoro biti isključeno zaglupljivanje >> računara. Trebao bi da pogledaš malo oko sebe i iznenadićeš se da tako nešto već postoji i radi već godinama. Hint: Unix, OS/2 Paya
jezici.191 ppekovic, -> #173, dejanr
>> Taj deo priče je nesporan, problem sa slogovima promenljive dužine nastaje >> kada neki od njih edituješ pa isti postane kraći (manji problem) ili duži >> (veći problem). U tom slučaju nema druge nego prepisati ga na kraj baze, >> a prostor koji je zauzimao se oglašava kao prazan. Ako posle naleti novi Niko da se seti da u clipper-u postoje polja sa promanljivom dužinom. Naravno, memo polja. Kod njih se baš vidi sve ovo što si rekao. Ukratko, memo polja idu u posebnu bazu (jel beše DBT?) u kojoj se za svaki slog alocira 2048 (ili 1024?, nije ni bitno) bajtova. Ako polje pređe alocirani prostor, novih 2048 se dodaje na kraj baze uz jedan pointer od prethodnog ka tom novom bloku. Priča koju je Bulaja ispričao je lepa a ponekad i praktično primenljiva. Lep primer je sor. Tu jednostavno jednom uneseš slog i ne diraš ga više (osim čitanja naravno). Paya
jezici.192 ppekovic, -> #169, ficus
>> Kad sam reko citljiviji mislio sam da bilo >> ko ko zna bar osnove c-a ume da procita program u c-u Grdno se varaš. C pruža veliku slobodu u programiranju koju neki koriste na najgori mogući način stvarajući programe koje vrlo često ni sami posle izvesnog vremena ne mogu da čitaju. Što je najgore, trude se da bude tako jer smatraju da što manje ljudi ume da pročita tvoj source, ti si bolji programer, a upravo je obrnuto. Paya
jezici.193 ppekovic, -> #150, ficus
>> Pa ja i rekoh da je to mana clippera ako bude srece ja cu napisati klasicu >> za rad sa slogovima varijabilne duzine. Lepo je videti nekoga ko se zanima za strukture i organizaciju podataka, jer je to oblast koju kako teoretski tako i u velikoj meri i praktično, vrlo mali broj programera poznaje što se u mnogim programima da videti. Ko se prepoznao? :) Paya
jezici.194 ppekovic, -> #163, miro
>> ű> Siguran sam da ce svaki dobro napisan C program na PC-ju >> ű> da se izvrsi znatno brze nego jednako dobro pisan program na >> ű> Pascalu ili Moduli, bas zbog tog! >> >> Let's try.:) >> >> Znaš onu 'Boj ne bije svijetlo oružije, već boj bije srce u >> junaka'?:) Svojevremeno su zzivotic i bojt imali dvoboj u kome je zz branio boje C-a a bojt fortana. Pobednik je bio, ... neka vam to oni sami kažu jer je i sam tok dvoboja bio veoma zanimljiv (malkice je bilo varanja :)))) ). Paya
jezici.195 cacxa, -> #149, vitez.koja
> A cini mi se da je za buduceg programera mnooogo korisnije > da se sam lomata i pise konkretne stvari, pa makar one i > zaostajale za najboljim proizvodima koje racunarsko > trziste nudi, nego da proucava probleme sahovskih konja i > rasporedjivanja tegova po hipotetickim terazijama. I konji i terazije jesu konkretne stvari. I C interpreter je konkretna stvar. Pa čak i Clipper aplikacije. ;) Konkretno, konkretna stvar je bilo šta što napišeš a nešto radi, ali to naravno nije bilo ono na šta si ti mislio. Razgraničavanje problema na konkretne i apstraktne je relativna stvar, međutim oba primera koja si naveo su itekako konkretna, baš konkretno :) na tvoj način. Problemi vezani uz šahovski tablu, (konji,kraljice,etc.) se rešavaju rekurzivnim metodama, dušu su dali za uvežbavanje i praksiranje problema tipa 'vidi može li još, može, gurni na stek, idemo dalje...'. Konkretno - NCD, dir/u, razni šahovi, etc. Hipotetičke terazije, nekorisno, nekonretno ? :) Kako za koga. Imaš n disketa, m fajlova, kako rasporediti? Da, postoji u ARJ-u svič -av, ali to što imaš su već arhive ;) . A nije šala, pukneš na svakoj disketi 0.1-0.3 Mb i skupiš celih 1.2-1.44 praznine. Diskete džabe... E, to su ti terazije, ako znaš da rešiš, znaš da napišeš i hipotetički program koji će da ti nabudži konkretne diskete. I druge stvari mogu da se optimizuju 'ljuljanjem' na terazijama. PS: Apsolutno hipotetičke i nekonkretne stvari ćeš videti kad stignu Jozef K.-ovi zadaci sa saveznog ;)))
jezici.196 paki, -> #180, dejanr
­> Oćemo isti test, sa novim verzijama? Dobijete tamošnje ­> primere, ispravite Tooo! Odavno nije bilo onako zanimljivih textova (&testova) u Računarima :)
jezici.197 ficus, -> #182, pmijat
:) 6 HD 1.2MB disketa. Kada se instalira, zauzima oko 7-8 MB na disku. :) BTW, opciono biras da li ces da instaliras i delove za razvoj Windows :) aplikacija (dobro si cuo), kao i za OS/2. Sve to ide u paketu. Pa dobro kad ubijem clipana (clipper + Dbase 4) bice dovoljno mesta. Kako stoji stvar sa literaturom? :) Razjasni malo kakvi to stringovi varijabilne duzine. Da li mozda :) mislis na neko, kao, memo polje ili bas mislis na to da se svako :) slovno polje u slogu upisuje samo onoliko na disk koliko je dugacko? Pa konkretan problem ti je recnik. Imas tri indeksne datoteke: 1. Srpske reci (jedno polje 80 char) 2. Nemacke reci (jeno polje 40 char) 3. veza (dva polja numeric picture 999999) Dakle baza se retko menja ali je jaaaaako dugacka jer ima 15.000 reci sa prevodima dakle recnik od 30.000 reci. :) Na zalost, siguran sam. Kao jedan primer, tlink nece ni da cuje :) za MS-ove .obj-ove. A MS je uz cobol isporucio par komada malih Ok valjda ce se linkovati bar sa asm-om mada to vec vise nije to :(((. :) "nazubljeni COBOL???!!!", "COBOL koji ne lici na COBOL", i :) "ovo vise lici na Pascal". :)))))))))))))))))))))))))))) E pa ovo je dooooooobro. Pocinje jako da me interesuje. Uopste nije pozicioni ili je dozvoljeno nazubljivanje ali od bese li 13-ta pozicija ne secam se? P.S. Dolazis li u klub. Ajd ako dolazis da ti donesem diskete. P.P.S Kakav je help.
jezici.198 bojt, -> #194, ppekovic
>> Svojevremeno su zzivotic i bojt imali dvoboj u kome je zz >> branio boje C-a a bojt fortana. Pobednik je bio, ... neka vam >> to oni sami kažu Odrao me k'o vola ;). >> jer je i sam tok dvoboja bio veoma zanimljiv >> (malkice je bilo varanja :)))) ). Nije bitnije uticalo na rezultat. ;) Cilj dvoboja je bio u tome da se napravi program koji bi brže radio search/replace u nekom tekstu, za šta se fortran (naravno) pokazao ultra kilav. Za neki problem sa mnogo numerike u pokretnom zarezu stojim i dalje na raspolaganju. ;) Inače, ideja o dvoboju se začela na jednom sajmu u Sarajevu. ZZ i ja smo gledali kako DVV testira neke mašine, izmedju ostalog i tako što je u WP-u radio replace na nekom velikom tekstu, a to je trajalo ohohohoho. Tu ZZ i ja počnemo da pljujemo po WP-u, diskusija uzme maha i tako, mic po mic, dodjosmo mi do stadijuma kada sam ja počeo da ubedjujem DVV-a kako za 5 minuta mogu da napravim program u fortranu koji će taj isti posao, na istoj mašini da uradi 100 puta brže od WP-a. Najveći problem je bio linkovanje programa sa bibliotekom za koprocesor a da radi na AT-u bez koprocesora, što je bilo brzo prevazidjeno, tako da smo zavrtali uši DVV-u celo veče. Pred kraj zezanja ZZ mi je pripretio kako će u C-u da napravi program koji istu stvar radi znatno brže. I bi tako ;).
jezici.199 mazi, -> #190, ppekovic
> Trebao bi da pogledaš malo oko sebe i iznenadićeš se da tako > nešto već postoji i radi već godinama. Hint: Unix, OS/2 Nego, ja onako, čisto da pitam, ne polazeći od toga koji je sistem bolji ili koji je najbolji, itd. Konkretno: Zašto UNIX i sve njegove podvarijante nisu stekle neku veću (kad kažem veću, mislim reda Windowsa, npr.) popularnost na PC mašinama, kad već ima gomilu rešenja koja se tek sad stidljivo pojavljuju u Windowsima i raznim drugim multitasking, multiuser okruženjima. Da li je to zbog resursa koje zahteva, zbog svoje okrenutosti višekorisničkom radu, nedostaku softvera, neprilagođenosti samo jednom korisniku, ili nešto treće. I, da li je onda sad UNIX-ova šansa, jer su sada PC računari postali dovoljno snažni za njegove potrebe. Ja ovo pitam onako, zanima me, bez nekih krajnjih aluzija, da ne bi bilo komentara tipa: Ma ništa ne znaš, UNIX je najbolji. Samo realno, molim :)) Ivan.
jezici.200 madamov, -> #184, pmijat
****** Po nekim ljudima sa kojima sam razgovarao (jedan se recimo bavi DTP-om, znaci "korisnik" je a ne "programer"), Windowsi i mis su dobra stvar za graficke aplikacije tipa COREL i sl, ****** Opet jedna od starih priča. Najefikasnije se radi korišćenjem i tastature i miša paralelno, pogotovo kod DTP-a. Drugi je problem što Windows to ima malo lošije rešeno od nekih drugih GUI-a, mislim na efikasnost paralelnog korišćenja miša i keyboard shortcut-a Isto važi i za aplikacije drugog tipa, ovo govorim iz višegodišnjeg iskustva u korišćenju bar tri vrste GUI-a.
jezici.201 tarva, -> #188, petrovics
Í────────────────── ║> Ne znam zasto se toliko forsiraju Windowsi i tamo gde im u ║> stvari i nije mesto? U firmama se od racunara uglavnom trazi da ║> se brzo i efikasno obavi neki tekuci posao bilo da je rec o ║> knjigovodstvu, fakturisanju, vodjenju kalendara, podsetnika, Ë───────────────────────────────────── Lično, koristim Windowse samo kada me "nateraju", kada je potrebno nešto nacrtati, napisati tekst koji liči na nešto i to baciti na laser, stoga bih se moga osložiti s tobom da mi Windowsi i nisu važni (imam ih samo na disku u firmi, kod kuće - NE. 90% poslova u DOS -u radim iz komandne linije + NCD + dosedit. Ali... Winodows okruženje je daleko "ljudskije" nego DOS, lakše se uči i hteli mi to ili ne, verovatno će polako potisnuti DOS. Stoga mislim da nam je to svima sudbina. Možda ne baš MS Windows, ali neki Windows baziran OS je na putu da potisne DOS. Već sada mnogi korisnici koji su u poslednjih godinu dana kupili računar imaju Windowse i mogu ti reći da oni koji rade pod Windowsima izgledaju mnogo veseliji i više vole računar nego oni kojima je DOS jedina veza sa svetom. ;) Jednostavno ove prve računar ne plaši previše, ovi drugi se groze i ono malo kucanja po DOS-u koje je neophodno da bi se startovala aplikacija, napravio BACKUP i dr. Jasno, i ja mislim da se gotovo 99% posla može uraditi sasvim elegantno iz DOS aplikacije, ali isto tako znam da bi oko 30% kupaca računara moglo i bez njega, samo kada bi malo reorganizovali svoju "papirologiju", ali onda "bye, bye" i ovo malo posla koji postoji danas ;). Pozdrav, Tibor.
jezici.202 tarva, -> #184, pmijat
Í───────────────── ║> A sad, malo i o stampi : vecina poslovnih korisnika tera ║> aplikacije za trgovacke knjige, gde im je bitno da BRZO dobiju ║> tabele na papiru, a nije ih mnogo briga kako ce to da izgleda, pa ║> cak lako prezale i ako nema YU slova na stampacu (sta ga briga, ║> kad SDK to prihvata). Zamislite koliko bi trajala stampa ║> konto-kartica neke firme iz Windows-a u grafickom rezimu. Stampaci ║> su mnoooogo brzi u text modu. Ë───────────────────────────────────── Tu si ga pogodio.:(( To je glavni problem sa našim štampačima. Ali dobrim delom to još uvek ide na krivicu štampača. Sa laserom to je daleko podnošljivije. Sad, druga je priča što je malo ljudi u stanju da sebi priušti i HP ili neko slično čudo. Koliko vidim napolju je situacija malo drugačija, pa se sve više ljudi okreće laserskim printerima, čak i oni kojima pisanje tekstova nije glavna preokupacija. Osim toga, pod Windowsima je štampanje u pozadini, a ti možeš slobodno da nastaviš da radiš nešto drugo. To je, naravno, moguće i pod DOS-om, ali nisam video puno programa koji rade na taj fazon.
jezici.203 bdm., -> #180, dejanr
## Oćemo isti test, sa novim verzijama? Dobijete tamošnje primere, ispravite Što da ne, čisto da vidimo kakva je trenutna situacija. :) ## vreme prevođenja, dužinu prevedenog koda (recimo, uz default "prekidače") ## i vreme izvršavanja na 486/50 ili 386/33, kako izaberete? A šta misliš da se naprave programi (znači EXE) upakujemo to u jednu arhivu i okačimo ovde pa posle nek svako ceni na svojoj mašini, gde ja sad da jurim 486? :) BDM.
jezici.204 bdm., -> #181, ficus
## Ja rekoh pre par poruka da i mene cisto zanima kako to izgleda ## drugim recima koliko mi disketa treba i koliko mesta na hardu? Evo, ovo što ja koristim (trenutno samo M2, i samo MThread mem. model, košta te na disku nekih 3.5 MB). Ako si raspoložen javni se na mail. BDM.