clipper.817pjankovic,
-> #813, bulaja> Clipper ne koristi zero-terminated stringove, zato treba
> koristiti funkcije _parclen() i _retclen() za odredjivanje
> duzine stringa.
žini mi se da ovo nije baš sasvim tačno. Ali da mi ne bi vjerovali
na riječ evo citata iz knjige
Clipper 5.0, Referentni priručnik, Computer Hit Biblioteka, Sarajevo:
..............................................................................
char *_parc(int br_poz,...)
===========================
Funkcija _parc() se koristi za prikupljanje znakovne vrijednosti
koja je prenesena kao parametar iz Clippera.
unsigned int _parclen(int br_poz)
=================================
Funkcija _parclen() vraća logičku dužinu znakovne vrijednosti koja je
prenesena kao parametar iz Clippera. Bajt koji sadrži null terminator se ne
================================
uključuje u logičku dužinu.
void _retc(char *string)
========================
Funkcija _retc() se koristi za vraćanje znakovne vrijednosti u Clipper.
Kasnije, kada vaša asemblerska ili C funkcija vrati ovu vrijednost, ona će
biti raspoloživa i u Clipper programu. Funkcija _retc() određuje logičku dužinu
znakovne vrijednosti tako što traži znak NULL u stringu. Ako vam je potrebno
===================
vraćanje binarnih podataka koji mogu sadržavati i NULL znak, koristite funkciju
_retclen().
void _retclen(char *string, unsigned int duzina)
================================================
Funkcija _retclen() se koristi za vraćanje znakovne vrijednosti u
Clipper. Kasnije kada vaša C ili asemblerska funkcija vrati ovu vrijednost
u Clipper, ona se može koristiti kao i svaka druga vrijednost.
...
Obzirom na to da funkcija _retclen() omogućava navođenje eksplicitne
logičke dužine znakovne vrijednosti, string koji navodite ne mora na svom
kraju imati NULL i može sadržavati NULL znakove.
...............................................................................
Uostalom, imate izvorni kod mojih funkcija za konverziju kodnih
rasporeda za Clipper pa provjerite kako to izgleda u praksi. :)
clipper.819bulaja,
-> #817, pjankovic││Clipper ne koristi zero-terminated stringove, zato treba koristiti
││funkcije _parclen() i _retclen() za odredjivanje duzine stringa.
│└───
│Cini mi se da ovo nije bas sasvim tacno. Ali da mi ne bi vjerovali
│na rijec evo citata iz knjige
└───
Dzabe ti citat (koji btw ne potvrdjuje ni moje ni tvoje misljenje :),
ali Clipper sigurno NE koristi nul-terminated stringove. Najbolje ces to
proveriti tako sto ubacis NUL u sred nekog stringa - Clipper ga tretira
kao i bilo koji drugi znak, tj. ne koristi ga kao terminator.
│Uostalom, imate izvorni kod mojih funkcija za konverziju kodnih
│rasporeda za Clipper pa provjerite kako to izgleda u praksi. :)
└───
Pretpostavljam (nisam jos pogledao) da nece raditi O;> ukoliko im
prosledis string koji sadrzi i NUL.
clipper.820dpaun,
Za one koji će (jednog dana) koristiti Clp za upravljanje tekstualnom
bazom podataka, pojaviće se delikatan problem prilikom kucanja teksta,
odnosno korišćenja MemoEdit() funkcije. Obrada obimnijeg teksta
skopčano je sa vremenom, samim tim duže smo izloženi mogućnosti da
nestane struja i slično. MemoEdit() obrađuje tekst u memoriji, a na
disk (odnosno u Bazu.DBT) snima ga tek kad dobije kod CHR(23) /CtrlW/.
Pošto svako snimanje MemoNiza u DBT bazu ovu povećava za više od
jedne veličine MemoNiza, to DBT raste ko kvasac.
Zadatak je, dakle, omogućiti povremeno spremanje MemoNiza u neku TMP
dadoteku, bez izlaženja iz MemoEdit(). Uz pomoć štapa, kanapa,
korisničke funkcije, dva tastera i malo homoljske mađije - ja sam to
rešio ovako (ovo je samo skica, naravno):
FUNC ObradaMema
USE Baza
Txt := MemoPolje
Kuci := Moze := .F.
SET KEY K_F4 TO SaveTmp
SET KEY K_F3 TO SaveMem
DO WHIL !Kuci
Txt := MemoEdit( Txt, 0,0,23,79,.T.)
nKey := LASTKEY()
DO CASE
CASE (nKey == 23 .AND. Moze)
REPL MemoPolje WITH Txt
Kuci := .T.
OTERW
ENDC
ENDDO
FUNC SaveTmp
KEYBOARD CHR(23)
MEMOWRIT( Putanja + 'DosIme.Tmp', Txt )
Moze := .F.
FUNC SaveMem
KEYBOARD CHR(23)
Moze := .T.
/*
Ako u toku rada želimo do tada otkucani tekst da sačuvamo u nekom
katalogu specificiranim pod 'Putanja', a u fajlu 'DosIme.Tmp' -
pritisnemo DVA PUTA(!) F4 ... Kad se rad završi, editor napuštamo sa F3
umesto standardnim CtrlW.
Ovo rešenje, braćo, izgleda mi dobro: mogu da čuvam tekst u toku rada bez
bojazni od nestanka struje, i bez straha da će mi DBT narasti ko Avala.
Nisu mi jasne samo dve stvari:
1. Zašto se mora taster F4 pritisnuti 2 puta (ako se pritisne jednom,
zapamti samo pretposlednje stanje!), //probao sam da 'dupliram'
chr(23) u proceduri, i opet ništa), i
3. Da li je sve ovo moglo i drugačije, a?
PS. Ako se ispostavi da nije, dajte čoveku aplauz ...
*/
dPaun.Tmp
clipper.821dvokshi,
-> #820, dpaun> 1. Zašto se mora taster F4 pritisnuti 2 puta (ako se
> pritisne jednom, zapamti samo pretposlednje stanje!),
> //probao sam da 'dupliram' chr(23) u proceduri, i opet
To se desava zato sto Memoedit kopira promenljivu u neku svoju
memoriju i nju editira. Kad se editiranje zavrsi sa CTRL-W
promenljiva se zamenjuje novim tekstom.
Kad se pozove SaveTmp (u toku editiranja teksta) promenljiva
TXT jos ima stari tekst, a zamenjuje se novim tek posto SaveTmp
vrati kontrolu Memoedit -u, i CHR(23) izaziva izlazak iz
Memoedit -a.
Zato sledeci pritisak na F4 snima tacan tekst.
> 3. Da li je sve ovo moglo i drugačije, a?
Pa da probam
FUNC ObradaMema
USE Baza
Txt := MemoPolje
Kuci := Moze := .F.
DO WHIL !Kuci
Txt := MemoEdit( Txt, 0,0,23,79,.T.,'savemem')
if lastkey()=23
if Moze
replace memopolje with txt
kuci = .t.
else
MEMOWRIT( Putanja + 'DosIme.Tmp', Txt )
endif
endif
ENDDO
return NIL
FUNC Savemem
local key := lastkey()
do case
case key = K_F4
moze = .f.
keyboard chr(23)
case key = K_F3
moze = .t.
keyboard chr(23)
case key = K_CTRL_W
moze = .t.
enddo
return 0
Nisam testirao ali mislim da bi to bilo to. U grubim crtama.
d.v.
clipper.822pjankovic,
-> #819, bulaja>> Clipper ne koristi zero-terminated stringove, zato treba
>> koristiti funkcije _parclen() i _retclen() za
>> odredjivanje duzine stringa.
> Dzabe ti citat (koji btw ne potvrdjuje ni moje ni tvoje
> misljenje :), ali Clipper sigurno NE koristi
> nul-terminated stringove. Najbolje ces to proveriti tako
> sto ubacis NUL u sred nekog stringa - Clipper ga tretira
> kao i bilo koji drugi znak, tj. ne koristi ga kao
> terminator.
Ja nisam htio da demantujem tvoje mišljenje da Clipper ne koristi
NULL terminated stringove (sa kojim se, uzgred rečeno, slažem).
Kada se takav string prenese u C funkcijom _parc() on ima NULL terminator.
Drugačiji je slučaj sa stringovima u Clipperu koji sadrže NULL. Oni se u C
prenose funkcijom _parclen() koja kao argument pored dotičnog stringa prima
i njegovu dužinu, a sve to da ne bi morala da je sama određuje.
> Uostalom, imate izvorni kod mojih funkcija za konverziju
> kodnih rasporeda za Clipper pa provjerite kako to izgleda
> u praksi. :)
> Pretpostavljam (nisam jos pogledao) da nece raditi O;>
> ukoliko im prosledis string koji sadrzi i NUL.
Pravo da ti kažem, nisam probao sa takvim stringovima, ali dijelim
tvoju pretpostavku. Pitanje je samo koliko Clipper programa na ekran ili
na štampač šalje stringove koji u sebi sadrže NULL.
clipper.823bulaja,
-> #822, pjankovic│Pitanje je samo koliko Clipper programa na ekran ili
│na stampac salje stringove koji u sebi sadrze NULL.
└───
Na ekran tesko, ali za stampac postoji dosta kontrolnih kodova koji
sadrze i NUL. Naravno, nije nikakav problem njih slati odvojeno
(nekonvertovano) od ostalog teksta.
clipper.824nbatocanin,
-> #814, bulaja> Btw da li je SubNTX isti onaj koji (u shareware verziji sa kojom se
> moglo ponesto i uraditi) stoji nakacen uz neku od poruka u ovoj temi?
Ne znam šta ima u porukama. Ja imam v1.20, nisam detaljnije
isprobavao. Dat je OBJ, a ništa ne piše o ograničenjima.
clipper.825andrade,
Imam jedno pitanje za Clipper programere: proletos sam radio
jednu aplikaciju na Clipper-u 5.0 i, s obzirom da nisam od onih
koji poznaju sve njegove detalje, ovo mi je oduzelo dosta
vremena pa sam na kraju i odustao od resavanja i ostavio to
takvo kakvo je.
Radi se o biblioteci funkcija OMENU za rad sa menu-ima. Ona
kontrolise ESC taster i ako ga korisnik pritisne - odustaje od
zapocete akcije, sve do najnizeg nivoa na meniju. Problem je u tome
sto kod odustajanja od akcije, na nivou MenuBar-a, ESC osim prekida
zapocete procedure startuje poslednju koriscenu opciju MenuBar-a
pre te prekinute. Pokusavao sam razne stvari da bih ovo sprecio i
nije mi uspelo. Ako neko zna sta je trebalo uraditi neka pomaze!
Thanks!
clipper.826ppekovic,
-> #825, andrade>> Problem je u tome
>> sto kod odustajanja od akcije, na nivou MenuBar-a, ESC osim
>> prekida zapocete procedure startuje poslednju koriscenu
>> opciju MenuBar-a pre te prekinute.
Pošalji deo koda gde pozivaš procedure menubar-a.
Paya
clipper.827dpaun,
-> #821, dvokshi>> Nisam testirao ali mislim da bi to bilo to. U grubim crtama.
Hvala na objašnjenju i ideji. Kad uspem da ideju provedem kroz moju
mamutsku 'glavnu petlju' i monstruoznu korisničku funkciju, javiću.
Ostalima savetujem da ideju negde kovertiraju, jer kad se tržište zasiti
knjigovodstveno-baknarsko-maloprivredničko-itakodaljističko
artikulisanih softverskih proizvoda, doći će na red, nadam se, i
zadovoljenje potreba za skladištenje umnih proizvoda u vidu obimnijih
tekstualnih zapisa. Onda će problem na koji sam ukazao morati da se
stavi na dnevni red ...
Sada bih postavio sledeće pitanje koje se logički nameće:
ako MemoEdit kopira 'svoj' niz u taj novi niz, kako tom prilikom stvar
stoji sa memorijom? Dali taj novi niz, dok se ne smesti na disk, zauzima
novu količinu radne memorije, što će reći da se mora predvideti i
mogućnost da memorija može da 'presuši' u nekim trenucima ...
otPozdrav,
dPaun.
clipper.828dpaun,
Problem:
- Kada u GET var PICT "!" naiđu YU slova, ostaju 'mala', sem ako,
blagovremeno nije uključen CapsLock.
Pitanje:
- Postoji li neko 'gotovo' rešenje za ovo, ili se mora napisati posebna
funkcija koja će pročešljati uneti string u potrazi za malim YU
kodovima, pa secati, zamenjivati, krpiti, lepiti ...
dPaun.Cap
clipper.829bulaja,
-> #828, dpaun│Problem:
│ - Kada u GET var PICT "!" naidu YU slova, ostaju 'mala', sem ako,
│ blagovremeno nije ukljucen CapsLock.
│Pitanje:
│ - Postoji li neko 'gotovo' resenje za ovo, ili se mora napisati posebna
│ funkcija koja ce procesljati uneti string u potrazi za malim YU
│ kodovima, pa secati, zamenjivati, krpiti, lepiti ...
└────
Preko PICTURE ces tesko (nikako :) uspeti da napravis neki YuUpper, ali
mozes npr. pre READ da stavis
SETKEY ( <malo slovo>, { || KEYBOARD <veliko slovo>} )
i tako redom za svih pet nasih malih slova. Posle READ samo ponisti ovo
dodeljivanje funkcije tasterima.
clipper.830ndragan,
-> #811, janko/ biste morali da napišete na Kliperu! Između ostalog, program je
/ i sjajna reklama za Fox. :)
Očekujem sanduk šampanjca od Foks Softvera za ovo, čim prođe embargo :).
Obećavam da ću izjaviti da je '92 bila jako dobra godina.
clipper.831kanda,
-> #828, dpaun>> Problem:
>> - Kada u GET var PICT "!" naiđu YU slova, ostaju 'mala', sem ako,
>> blagovremeno nije uključen CapsLock.
>>
>> Pitanje:
>> - Postoji li neko 'gotovo' rešenje za ovo, ili se mora napisati
>> posebna funkcija koja će pročešljati uneti string u potrazi za malim
>> YU kodovima, pa secati, zamenjivati, krpiti, lepiti ...
Svojevremeno sam radio nesto u smislu teranja klipera da radi sa nasim
slovima -> u biblioteci CLIPPER.LIB postoji modul NATION u kome su
koncentrisane 'nacionalne specificnosti' ; prepravkom ovoga se postize
da kliper smatra YU slova za *slova* a ne za 'kuke i kvake', da pravilno
poredi, sortira i indeksira po nasoj abecedi, da koristi nasa imena dana
i meseci itd.
Problem je u tome sto je resenje ocigledno prilicno prljavo - iako sve
radi kako treba, nesto mi se nikako ne da da to definitivno ugradim u
CLIPPER.LIB. Ako ima sezamovaca koji bi hteli da sve to testiraju i
ukazu na eventualne bagove, nek se prijave ovde.
Usput, probajte ? VERSION(1).
Kod mene daje "Clipper (R) 5.01 Rev. 1.29 ASCII".
clipper.832bulaja,
**** new file ****
\ibmpc\program\
clipgr21.zip (150 Kb)
Clip-Graf 2.1, graficka biblioteka za Clipper 5.x/S87
U direktorijumu je ranije vec bila verzija 1.2. Promene u odnosu na nju su:
1.2A Tried to prevent a user from making filled rectangle go off the screen.
When this happens, the computer would lockup.
06/29/90
1.2B Change of address in the opening screen.
Added g_col(), g_row(), g_xpos(), g_ypos() to get the text row col
or pixel position of the present cursor location.
01/01/91
2.0 Added read and write PCX formatted image files capability.
Added additional routines to check video equipment and status.
03/01/91
2.1 Fixed some problems with PCX information gathering functions.
Separated the libraries for S87 and Ver: 5.0.
Added screen dump utility function that supports Epson,
Toshiba, HP laser and other printers.
clipper.833janko,
-> #830, ndragan> / biste morali da napišete na Kliperu! Između ostalog,
> program je / i sjajna reklama za Fox. :)
>
> Očekujem sanduk šampanjca od Foks Softvera za ovo, čim
> prođe embargo :). Obećavam da ću izjaviti da je '92 bila
> jako dobra godina.
:)
Dok nam ne prođe embargo, da li si primetio da si postao član
grupe UkrasPro (Ukras programeri) ? :) Jesi li pročitao priču
pisanu pre nego što si učlanjen?
clipper.838nbatocanin,
-> #811, janko> Ako još niste skinuli NDraganove rutine za Ukras na Foxu,
> koje se nalaze u SEZAM.3:yu.kod, skinite ih i uporedite sa
> onime što biste morali da napišete na Kliperu! Između
> ostalog, program je i sjajna reklama za Fox. :)
Zaista mi nije jasno na osnovu čega to kažeš. Pregledao sam ovaj
program i čini mi se da sve osim zaista zgodne funkcije ChrTran
postoji i u Clipper-u.
clipper.839andrade,
-> #826, ppekovic*> Posalji deo koda gde pozivas procedure menubar-a.
Evo, saljem ti source OMENU.PRG i dva demo programa koji ilustruju
mogucnosti ovog menu sistema. Negde u programu se, osim odustajanja od
tekuce operacije izvrsava prethodno pozvana, sto meni nikako nije
odgovaralo, ali nisam to uspeo da ispravim. Ako te ne mrzi, pokusaj
da pronadjes sta treba ispraviti, ali nemoj mnogo da se maltretiras oko
toga.
Hvala ti!
omenu.zipclipper.840janko,
-> #838, nbatocanin> Zaista mi nije jasno na osnovu čega to kažeš. Pregledao
> sam ovaj program i čini mi se da sve osim zaista zgodne
> funkcije ChrTran postoji i u Clipper-u.
Izvini na mom nedovoljnom poznavanju 5.0 verzije, ali Summer 87
nema ni fgets, (učitavanje linije iz tekst fajla). I to bi
moralo da se malo 'izmišlja.' U ovom konkretnom slučaju i ono
'učitavanje parčeta' što ima Kliper bi radilo posao, ali...
A nepostojanje ChrTran, je, inače, primoravalo na korišćenje
C-a ili mašinca u Kliper programu, samo da bi bilo razumno
efikasno korišćenje rutine, a već tako nešto je dovoljno da me
'zaboli glava.' Što opet ne znači da ne koristim par takvih
rutina koje sam sam napisao, ali... Za ovu primenu već samo
postojanje ChrTran je dovoljno značajno...
Priznajem da ne poznajem dobro Kliper 5.0, ni približno kao ti,
niti Fox približno kao NDragan. Ali, K.5.0 me i dalje nije
ubedio. O Fox-u samo čujem, kada nešto treba, 'ima i to.' A o
K.5.0 'to nema, ali, ima klase koje to nisu i tako sjajan novi
način za zamenu dbedit.'
clipper.841ndragan,
-> #828, dpaun/ kodovima, pa secati, zamenjivati, krpiti, lepiti ...
Ma treba to samo prelemiti. Ako ne upali, veći čekić.
clipper.842dkalaba,
Da li neko zna šta znači kada se pod UNIX-om pokrene
VP/Xi i startuje program (konkretno pisan u Clipper-u)
a na ekranu se pojavi: redir 1107 comitt ?
clipper.843kanda,
-> #840, janko>> ubedio. O Fox-u samo čujem, kada nešto treba, 'ima i to.' A o
>> K.5.0 'to nema, ali, ima klase koje to nisu i tako sjajan novi
>> način za zamenu dbedit.'
I ja se slazem sa ovim, uz par primedbi ;) :
"" K.5.0 'to nema (1)(2), ali, ima klase koje to nisu (3) i tako sjajan novi
"" način za zamenu dbedit (4).'
(1) ali se moze napisati u C-u za <4 minuta
(2) sto u foxu ne moze
(3) i koje fox nema
(4) sto fox nema
clipper.844bulaja,
U \IBMPC grani otvoren je poseban CLIPPER direktorijum.
U njega je prebacen deo datoteka koje su bile u PROGRAM
direktorijumu, a bice jos nekih novih stvari ovih dana.
clipper.845ndragan,
-> #833, janko/ Dok nam ne prođe embargo, da li si primetio da si postao član
/ grupe UkrasPro (Ukras programeri) ? :) Jesi li pročitao priču
Izem ti SOR - ne videh nijednu poruku iz grupe. Pročitaću ovih dana.
clipper.846bulaja,
**** new file ****
\ibmpc\clipper\
expand2.zip (94 Kb)
Clipper 5.01 Expand Lib v2.0, biblioteka raznih funkcija
Spisak funkcija koje se nalaze u ovoj biblioteci je prikacen uz poruku.
clipper.847gristic,
Pisci (obično) prepoznaju svoje tekstove. A šta je sa programerima?
Da li i oni mogu da prepoznaju sopstveni program nakon nekoliko godina?
Pred vama je izvod iz jednog programčića od pre par godinica, a pisao ga
je jedan od eminentnijih korisnika Sezama. Ako prepozna čik nek' se javi,
neću mu ništa. ;) (u programu nisam nigde video (c) Copyright ili nešto
slično, pa pretpostavljam da ovo nije kažnjivo O;)
.
.
.
do pootvaraj
*
* sam glavni meni
*
do while .t.
clear screen
č 1, 6 to 3, 72 double
č 2, 24 say " APLIKACIJA FINANSIJSKOG POSLOVANJA"
č 4,6 to 12,52
č 5,8 prompt "1 RAD SA MATIžNIM DATOTEKAMA ";
message 'unos, pregled i ispravke podataka o zadrugarima';
+ ' i dobavljačima'
č 6,8 prompt "2 OPŠTA UPUTSTVA ZA RAD ";
message 'kratko uputstvo za operatera'
č 7,8 prompt "3 KNJIčENJE ";
message 'unos promena'
č 8,8 prompt "4 KONTROLE, PREGLEDI, KARTICE ";
message 'razni pregledi i izveštaji'
č 9,8 prompt "5 REZERVNE KOPIJE DATOTEKA ";
message ' snimanje i užitavanje rezervnih kopija '
č 10,8 prompt '6 REĐE IZVOĐENE OPERACIJE ';
message 'godišnje obrade, ažuriranje matičnih datoteka itd'
č 11,8 prompt "0 povratak u operativni sistem "
menu to g_meni
*
* kad budeš dodavao opcije povećaj ovo modulo
*
g_meni = g_meni % 7
dalje = .t.
izb = ' '
r1 = g_meni + 5
do case
case g_meni= 0
close all
return
case g_meni = 1
g1_meni = 1
.
.
.
*
* izmena tekućeg sloga
*
set index to xmatbr,prezime
clear screen
if .not. un_mbr()
č 23, 1 say 'nema ga'
wait wtmsg to kelner
else
do zad
clear gets
if da_ne("da se menja (da/ne)?",'n')
do zad
read
replace z->prez with yuupper(z->prez)
č 23, 1 say "ok. izmenjeno" clear
wait wtmsg to kelner
izmene = .t.
endif
endif
.
.
.
*******************************************************************************
procedure knal
clear screen
store 0 to rbr, kzar,uc,ul,kdug,kpot,oldnal, brst,zbirvd, ndug, npot
store .f. to zdug, zpot, ddug, dpot
locate for &filteriska
set filter to &filteriska
go top
.
.
.
wait "nema više"+wtmsg to kelner
set filter to
return
*
*******************************************************************************
.
.
.
case polje = 'KELNER' .or. polje = ''
sta = 'žEKANJE'
htxt = ;
'kad se pojavi poruka ' + wtmsg + ' u donjem ';
+ crlf + 'redu, znači da je operacija gotova; program ';
+ crlf + 'čeka da operater pogleda rezultate. čekanje ';
+ crlf + 'se prekida pritiskom na bilo koji taster na ';
+ crlf + 'tastaturi ili mišu'
otherwise
htxt = "pomoćni tekst za ovo polje joć nije napisan";
+ crlf + 'rutina:' + rutina + ' polje: ' + polje
endcase
.
.
.
*:EOF
Ima li "sumnjivog liceta" ? ;)
Napomena: namera nije da se neko diskredituje, već *isključivo* i *samo*
ono što piše na početku poruke.
clipper.848bulaja,
-> #846, bulaja│Spisak funkcija koje se nalaze u ovoj biblioteci je prikacen uz poruku.
└───
Whoops, zaboravih da okacim file :). Here it is...
expand52.lstclipper.849nboskovic,
-> #845, ndragan*> Izem ti SOR - ne videh nijednu poruku iz grupe. Pročitaću
*> ovih dana.
Pa ako nije bilo poruka od kad si učlanjen nije ni čudo da
ih nisi video u SOR-u.
(c) klap
nikola
clipper.850albor,
Možda nekom zatreba...
Pozdrav, Boris
clipindt.zipclipper.851ppekovic,
-> #850, albor>> Možda nekom zatreba...
>> Pozdrav, Boris
>> ----------------------------------------------- 5.850 ---
>> ** Uz poruku 'clipindt.zip' (12987 bytes)
Uz poruku je program za "nazubljivanje" clipper programa. Takođe, arhiva
sadrži i makroe za dBase koji pozivaju program za nazubljivanje za tekuci .prg.
Program je pisao moderator clipper konferencije na BIX-u irae. Sam je u malom
doc-u napomenuo da program možda neće raditi kako treba sa linijama dužim od
255 karaktera-
Paya
clipper.852andrejl,
-> #847, gristic>│ Napomena: namera nije da se neko diskredituje, već
>│ *isključivo* i *samo* ono što piše na početku poruke.
Jednom prilikom gledam neki moj "istorijski" program, a
da prethodno nisam primetio da je moj u gomili nekih
sourceva i komentarišem: "koje gluposti, čemu ovo služi" i
sl. :), a kad sam shvatio da je program moj sve je dobilo
neki novi smisao :)
bye, andrejl
clipper.853toma,
-> #851, ppekovic■■>> Uz poruku je program za "nazubljivanje" clipper programa.
E, a uz ovu poruku je utility koji nazubljuje sve .prg u
tekućem dir-u i ta samo po potrebi. Program je, naravno,
rađen na Clipper-u (5.01), a autor sam lično ja!
Pozdrav from Toma.
tab.zipclipper.854ndragan,
-> #843, kanda/ "" način za zamenu dbedit (4).'
/ (4) sto fox nema
A čemu služi DBEdit? Jel' to nešto kao brauz?
/ (1) ali se moze napisati u C-u za <4 minuta
I onda bih morao da učim C, pa da nabacim neki kompatibilan (?) C
kompajler, i da dobijenu stvar obaška testiram, i da ne zaboravim da je
ubacim u mejkfajl ili gde to već ide, i kad prođem kroz to sve onda se
zaista svodi na manje od 4 minuta, što je i dalje mnooogo više od 10
sekundi (koliko mi u foksu treba dok skoknem do helpa da nađem sintaksu
za ređe korišćene naredbe), i plus dodatnih pet minuta za testiranje.
Zanima me, zaista, koliko kliperašima treba dok ubace novu rutinu
(recimo, dodavanje jedne kontrole datuma u valid) pa dok istestiraju
kako radi? Onako, u minutima.
clipper.855toma,
-> #854, ndragan■■>> Zanima me, zaista, koliko kliperašima treba dok ubace novu rutinu
■■>> (recimo, dodavanje jedne kontrole datuma u valid) pa dok istestiraju
■■>> kako radi? Onako, u minutima.
Sve zavisi od dužine programa. Recimo, program od nekih 400
linija, kompajliranje + linkovanje = 21 sec (286/16) i onda
na to dodaš onih tvojih 5 za test :)))
Pozdrav from Toma.
ps. Naravno, linkovanje sa Rtlink-om i bez ram-diska.
clipper.856vili,
Postoji li nacin da se .LIB pretvori u .PLL?
clipper.857nbatocanin,
-> #840, janko> Summer 87 nema ni fgets
5.0 ima FGets i slične rutine date kao demo program (FILEIO.PRG).
> Ali, K.5.0 me i dalje nije ubedio. O Fox-u samo čujem, kada nešto
> treba, 'ima i to.' A o K.5.0 'to nema, ali, ima klase koje to nisu i
> tako sjajan novi način za zamenu dbedit.'
Tu postoji više stvari:
Prvo, koncepcije Clipper-a i Fox-a su totalno različite. Fox ide
na zaokružen proizvod visokih performansi koji sadrži sve što će
korisniku zatrebati. Tu je i integrisana okolina, i sistem menija i
još dosta dobrih stvari. Uzmeš i imaš sve što ti treba i to vrlo
brzo. Odlična je i prenosivost na druge sisteme - očekuje se FoxPro
za Unix. Clipper ima potpuno drugi pristup: ne teži se da se sve
napravi na jednom mestu, ali se ide na maksimalnu otvorenost
arhitekture. To znači da se ide na *maksimalnu* mogućnost
prilagođavanja. I to je glavna prednost Clippera. On (možda) u startu
ima manje funkcija, ali se može proširiti na daleko više načina. Može se
zameniti skoro sve, pa čak i drajver za pristup datotekama. Jeste li
čuli za SIx drajver? To omogućava korišćenje FoxPro 2 kompatibilnih
datoteka. Za korisnički interfejs neću ni da pominjem - toga ima
toliko da skoro guši.
Drugo, može se raspravljati o onome što se dobija kao proizvod. Tu
ne vidim razliku između doplate za Fox LAN i kupovine Nantucket Tools
II ili neke slične biblioteke - a toga ima kao pleve. Takođe nije neka
razlika ako neki proizvod ima neku funkciju više ili manje - napisati
takvu funkciju, ubaciti u biblioteku i više nema razlike između te i
"fabričkih" funkcija. Naravno, dobro je ako to već postoji, ali je
zaista mala razlika da bi se nešto na osnovu toga zaključilo.
Najvažnije za korisnike, šta uzeti. Posao ćete uraditi i na jednom
i na drugom. Priče da može postojati neka značajna razlika između
napisanih programa je obična glupost. Prava istina je da su ovo
konkuretski proizvodi (mada različitih koncepcija) i da će uvek biti
"tu negde". Fox ima lepih prednosti: prenosivost, brzina, itd.
Clipper ima odličan jezik, mnogo više dodataka, itd. A šta će se
izabrati, zaista je stvar ukusa.
clipper.858kanda,
-> #854, ndragan>> A čemu služi DBEdit? Jel' to nešto kao brauz?
Pa, ako brauz sluzi za pregled i menjanje baze, onda je dbedit isto sto
i brauz. U kliperu je stvar generalizovana, uveden je TBrowse koji
sluzi za pregled bilo cega sto se moze organizovati u redove i kolone
- najcesce baze podataka, ali i nizovi, matrice, tekstualne datoteke
(npr. izvestaji)...
>> / (1) ali se moze napisati u C-u za <4 minuta
>>
>> I onda bih morao da učim C, pa da nabacim neki kompatibilan (?) C
>> kompajler, i da dobijenu stvar obaška testiram, i da ne zaboravim da
>> je ubacim u mejkfajl ili gde to već ide, i kad prođem kroz to sve
>> onda se zaista svodi na manje od 4 minuta, što je i dalje mnooogo
>> više od 10 sekundi (koliko mi u foksu treba dok skoknem do helpa da
>> nađem sintaksu za ređe korišćene naredbe), i plus dodatnih pet minuta
>> za testiranje.
Ovde je rec o principu. Fox ima puno funkcija, i to je sjajno, ali
sigurno nema *SVE* koje ti trebaju. E kad ti zatreba neka koje nema,
mozes da je pises u Fox-u... sto je ponekad neprihvatljivo jer je
rezultat prespor, a moze biti i nemoguce... sta ces onda ?
A za kliper ima BRDO biblioteka raznih korisnih i nekorisnih
funkcija (i na sezamu ima par komada). Gotovo svaka ima Norton Guide,
pa kad ti nesto zafali pritisnes sift-f1, pa potrazis... pa ako nema
ni tamo, a znas C ili asembler sednes pa napises... Dakle, ne moras
da ODUSTANES od necega samo zato sto to osnovni jezik, tj. kliper
ne omogucuje.
>> Zanima me, zaista, koliko kliperašima treba dok ubace novu rutinu
>> (recimo, dodavanje jedne kontrole datuma u valid) pa dok istestiraju
>> kako radi? Onako, u minutima.
Pa evo, bas sam sada merio : prevodjenje + linkovanje = 11 sekundi na
386/25. U minutima ? 11/60 - 0.17 minuta ili tu negde.
clipper.859nbatocanin,
-> #854, ndragan> A čemu služi DBEdit? Jel' to nešto kao brauz?
Da. Ova funkcija omogućava da osim definisanja kolona, prozora itd.
korisnik definiše svoju funkciju koja se izvršava uvek kad korisnik
pritisne neki taster. Time se postiže svašta. A TBrowse objekti su
nešto još generalnije i moćnije.
> I onda bih morao da učim C, pa da nabacim neki
> kompatibilan (?) C kompajler, i da dobijenu stvar obaška
> testiram, i da ne zaboravim da je ubacim u mejkfajl ili
> gde to već ide, i kad prođem kroz to sve onda se zaista
> svodi na manje od 4 minuta, što je i dalje mnooogo više od
> 10 sekundi (koliko mi u foksu treba dok skoknem do helpa
> da nađem sintaksu za ređe korišćene naredbe), i plus
> dodatnih pet minuta za testiranje.
Možeš i da nabaviš tu funkciju iz neke biblioteke. Za Clipper je
toliko stvari napisano da je vrlo verovatno da sve što ti zatreba već
negde postoji. Što se tiče procedure, kada je napišeš, otkucaš jedno
LIB i time tvoja procedura postaje ista kao fabrička - nema razlike.
A šta ćeš kad ti u Fox-u zatreba nešto što tu nema?
> Zanima me, zaista, koliko kliperašima treba dok ubace novu
> rutinu (recimo, dodavanje jedne kontrole datuma u valid)
> pa dok istestiraju kako radi? Onako, u minutima.
Ne previše, zavisi od mašine. Otprilike, bez kucanja teksta, oko
30-40s. Najveci deo je RTLink, a sa Blinkerom je oko 15s.
clipper.860janko,
-> #854, ndragan> Zanima me, zaista, koliko kliperašima treba dok ubace novu
> rutinu (recimo, dodavanje jedne kontrole datuma u valid)
> pa dok istestiraju kako radi? Onako, u minutima.
:) Pogotovu 'na licu mesta,' gde je recimo XT sa 80ms diskom ;)
Samo linkovanje se meri minuuutima. Kada sam ispravljao program
na jednom XT-u, 'ladno sam stizao da tokom
prevođenja/linkovanja 1) odem do kisoska sa klopom 2) popijem
kaficu 3) odem do WC-a 4) Pročitam nešto... itd. itd. ;)
clipper.861d.petrovic,
-> #860, jankoĂ> Samo linkovanje se meri minuuutima. Kada sam ispravljao program
Ă> na jednom XT-u, 'ladno sam stizao da tokom
Ă> prevođenja/linkovanja 1) odem do kisoska sa klopom 2) popijem
Ă> kaficu 3) odem do WC-a 4) Pročitam nešto... itd. itd. ;)
Jedva sam se i odlučio da prokomentarišem !!! Pazi ! Ja imam 286/16 i
nisam baš presrećan brzinom (cca 15 sek prosečno programče od oko 5000 linija),
ali se i ne žalim. To što si ti u tom momentu bio mazohistički nastrojen ili
nisi imao mogućnosti (vremena, auto, stanuješ daleko od inkriminisanog mesta)
pa si sve to radio na XT-u ne znači da je to baš tako presporo. Uostalom za
fazu testiranja možeš da koristiš .PLL biblioteke ili neki drugi linker i to
onda kod mene traje oko 7-8 sek (prevođenje + linkovanje).
Pozdrav, Dejan
clipper.862d.petrovic,
-> #856, viliĂ> Postoji li nacin da se .LIB pretvori u .PLL?
Daaaaaa. Ja trenutno to ne radim, ali imaš negde u ovoj temi od 01.08. pa
naovamo gomilu mojih pitanja, odgovora, mojih zaključaka...
Pozdrav, Dejan
clipper.863janko,
-> #857, nbatocanin> Najvažnije za korisnike, šta uzeti. Posao ćete uraditi i
> na jednom i na drugom. Priče da može postojati neka
> značajna razlika između napisanih programa je obična
> glupost. Prava istina je da su ovo konkuretski proizvodi
> (mada različitih koncepcija) i da će uvek biti "tu negde".
> Fox ima lepih prednosti: prenosivost, brzina, itd.
Spolja značajna razlika između programa se može smatrati da ne
postoji, (svi moraju da imaju unos, obradu i prikaz, zar ne?)
ali kada gledaš programe IZNUTRA... I na to unutra valjda možeš
da primenjuješ neke estetske kriterijume... slažem se sa tobom
da je to stvar ukusa svakog programera posebno... ako pogledaš,
i ja sam tako napisao onu poruku, samo kao lični stav...
Naravno, drago mi je što sam čuo tvoje mišljenje. Ti si svakako
veoma kompetentan da govoriš o Kliperu, više nego ja (što sam
već pomenuo, nadam se?)
clipper.864dejanr,
-> #854, ndragan>> Zanima me, zaista, koliko kliperašima treba dok ubace novu rutinu
>> (recimo, dodavanje jedne kontrole datuma u valid) pa dok istestiraju
>> kako radi? Onako, u minutima.
Ako pod testiranje misliš kompajliranje+linkovanje, 10-tak sekundi
za program osrednje veličine (zavisi, normalno, i od brzine računara,
diska itd, valjda je na XT-u "malo" više od toga ;). Ako misliš na neki
logički test, onda sve zavisi koliko ta izmena zadire u dubine programa
i, ako ništa drugo, koliko je meni u kome je vršena "daleko" od osnovnog
menija.
clipper.865gristic,
-> #847, gristic*> case polje = 'KELNER' .or. polje = ''
*> sta = 'žEKANJE'
*> htxt = ;
Gos'n ndragan, ždraknite poruku 5.847. ;)
1988 ? 1989 ? Inspiracija u kafani (na lap top salveti) ? ;)
clipper.866kvelkovski,
-> #856, vili>> Postoji li nacin da se .LIB pretvori u .PLL?
Pogledaj u PLL\BASE50.LNK datoteci. Tamo se kreira BASE50.PLL koji je
sastavljen od CLIPPER.LIB, EXTEND.LIB ...
Kupe
clipper.867kvelkovski,
-> #857, nbatocanin>> zameniti skoro sve, pa cak i drajver za pristup datotekama. Jeste li
>> culi za SIx drajver? To omogucava koriscenje FoxPro 2 kompatibilnih
>> datoteka. Za korisnicki interfejs necu ni da pominjem - toga ima
Koristim Clipper 5.01 vec poduzhe ali nisam nashao nachin da ukljuchim
.NDX indekse. Ima li uopshte nachina?
Kupe
P.S. Na mrezhi nisam uopshte radio pa me interesuje isplati li se (i jeli
moguce) da se napravi driver za onaj Novell-ov BTrieve (ili kako se vec
zove) ...
clipper.868nbatocanin,
-> #863, janko> ali kada gledaš programe IZNUTRA... I na to unutra valjda
> možeš da primenjuješ neke estetske kriterijume...
Ako sudiš po jeziku (eleganciji, izražajnim mogućnostima, ...), onda
ćeš teško naći nešto bolje od Clipper-a. Da ne bude subjektivno,
nedavno sam čitao neki uporedni pregled u kome se između ostalog
bodovao i jezik DBMS proizvoda i sećam se da je Clipper bio daleko
iznad ostalih u toj kategoriji.
clipper.869ndragan,
-> #847, gristic/ jedan od eminentnijih korisnika Sezama. Ako prepozna čik nek' se javi,
Ko, jel' ja? Prisutan i na broju, ser. A za onu 'eminenciju' nemaš piće
- to što sam lajav još ne znači mnogo :).
/ Ima li "sumnjivog liceta" ? ;)
/ Napomena: namera nije da se neko diskredituje, već *isključivo* i
/ *samo* ono što piše na početku poruke.
Nasmejao si me do suza. Imam ja taj običaj da promenljivim dajem
blesava imena. Recimo, ako u Foksu koristim niske udarce (fread(),
fopen() i ostale niske funkcije), broj drške (handle) obično smeštam u
promenljivu Fridrih ili GFH. Tek da vidiš na šta je ličila 'zaštićena
verzija' sorsa, gde su sve promenljive bile (search/replace) zamenjene
šiframa tipa 'zx80','atari','quit_it','listaj', a one koje su imale
smislena imena imale su sasvim deseto značenje u odnosu na stvarno...
Baš sam neki dan pričao da ću možda i otići u penziju a da neću
prestati da ser*m u sorsovima. Imam jedan biser u sistemskoj rutini
koja poziva izradu/pregled/štampu izveštaja:
č lin+ 5,kol+1 PROMPT " uzano " MESSAGE "nabudži štampač na uzana slova"
...koji je dosad postao legenda među operaterima kod naših mušterija.
Među mojim drugarima se vodi nezvanični konkurs za nejblesavije ime
(promenljive, baze, programa...). Programeri su inače najveći kumovi -
krštavamo svakog dana na veliko. Zasad vode URSDSR (ukupan radni staž do
stupanja u RO), VRANA (indikator vrste analitike), INDIANA (indikator
prenosa u analitiku), OKKORAL.PRG (obračun), DIHTUNG.PRG (upozorenje da
će se baza isprazniti), KLISTA.PRG (spisak obračunatih kamata),
SUMPOR.DBF (suma poreza na jednoj fakturi). Pozivam Zezamovce da se
priključe.
BTW, odakle ti taj sors, trebalo je da bude zaštićen :). Ex, jednom
napišem nešto u kliperu i posle četiri godine me sustigne... pravi leš
iz ormana. Stidim se po čitavom telu (što sam radio u Kliperu :). I jesu
li ikad počeli da ga koriste? Nismo se rastali u nekim lepim odnosima
(mušterija i ja), al' se nismo ni posvađali (jedino nisu platili
poslednjih 30%). Odakle ti to, leba ti?
Bue_ Ndragan
P.S.
/ neću mu ništa. ;) (u programu nisam nigde video (c) Copyright ili
/ nešto slično, pa pretpostavljam da ovo nije kažnjivo O;)
Imaš pogrešnu verziju - pisala su (u zvaničnoj) naša imena (jedan drugar
i ja) i čak je bilo predviđeno da u slučaju da se nekakav čeksum naših
imena ne složi, program pobriše sve iza desetog sloga u matičnoj
datoteci pa onda istu spakuje i preindeksira.
Inače, nije kažnjivo al' će te košta - dođeš mi kriglu piva za ovo :).
Program takođe više nema nikakvu komercijalnu vrednost, postoji (jel
može malo reklame za sve ovo?) mnooogo bolja verzija aplikacije
stambenih zadruga rađena u Foks Prou gde sve šljaka kako bog zapoveda.
P.P.S.
/ replace z->prez with yuupper(z->prez)
=======
Ukrasovcima skrećem pažnju na ovaj detalj. Pisano '88 u leto.
clipper.870neman,
-> #867, kvelkovski> Koristim Clipper 5.01 vec poduzhe ali nisam nashao nachin
> da ukljuchim .NDX indekse. Ima li uopshte nachina?
A zašto da koristiš .NDX ???
Zbog DBASEa ?????
Pa za te rabote imaš DBU kao pomagalo !
clipper.871janko,
-> #868, nbatocanin> Ako sudiš po jeziku (eleganciji, izražajnim mogućnostima,
>ć ...), onda eš teško naći nešto bolje od Clipper-a. Da ne
>ć bude subjektivno,
E, kad smo već zašli u te vode, voleo bih da mi objasniš
opravdanost uvođenja onoga što se u Kliperu zove 'CODE BLOCKS'
u bilo kom jeziku koji se, za razliku od Klipera, pošteno
iskompajlira, a ne pretvara u interni interpreter...
Moguće da živim u zabludi, ali ti 'CODE BLOCKS' mi se nimalo
nisu svideli, kada sam ih video. Iskreno bih voleo da mi neko
pokaže da to nije samo 'zakrpa' pogrešno odabranog pravca
razvoja Klipera.
Zatim, ta igranja sa preprocesorom su, ipak, samo igranja sa
preprocesorom. I C ima preprocesor, ali se JAKO umereno
koristi, (u C++-u još umerenije ;) što mislim da je dobro --
ako ti sam pišeš i održavaš svoje programe, baš te briga, ali
kada bi radio u većem timu, baš me zanima kako bi ti se sviđalo
kada bi svako izmišljao svoju sintaksu za elementarne
naredbe... E, da, mana C preprocesora je što ne radi proveru
tipa parametara koji su prosleđeni markrou u toku prevođenja.
Kako to radi Kliper 5.0?
Hoćeš li mi objasniti i šta je to što Kliperov jezik čini
elegantnim? Ja sam uvek cenio estetske vrednosti i duboko ću ga
poštovati, ako shvatim tu eleganciju?
Ne bih želeo da me doživljavaš kao nekog 'mrzitelja Klipera.'
Nisam nikada napisao nijednu aplikaciju na 5.0 verziji, i ne
poznajem je tako kao ti, pa je moguće da sam nešto pogrešno
shvatio. Meni se učinilo da je Kliper sa tim 5.0 doneo masu
stvari koje mi ne trebaju, a praktično, nijednu koja mi je
trebala. I sve vreme čekam, možda ću konačno čuti o nečemu što
je stvarno jaaako korisno, ali nikako da čujem...
clipper.872bulaja,
-> #859, nbatocanin│Ne previse, zavisi od masine. Otprilike, bez kucanja teksta,
│oko 30-40s. Najveci deo je RTLink, a sa Blinkerom je oko 15s.
└───
Ja nemam Blinker :), ali zato imam neki update za verziju 1.50.
To je neki exe koji patch-uje blinker.exe iz verzije 1.50, i
tako napravi v1.51. Patch nosi datum 16.01.92, pa ne znam da li
se ovde u medjuvremenu pojavila neka novija verzija. Btw, imam
cak i uputstvo za Blinker (.DOC file, 240Kb texta), al' i dalje
nemam Blinker :).
clipper.873vkrstonosic,
-> #857, nbatocanin>> Najvaznije za korisnike, sta uzeti. Posao cete uraditi i na jednom
>> i na drugom. Price da moze postojati neka znacajna razlika izmedu
Ima cini mi se jos jedna stvar koja je plus kod Clippera. Mnogo
vise ljudi ga koristi (kod nas). Tako da sam ja za prve decije
bolesti, okretao par telefona i od prijatelja dobijao sve informacije
koje mi trebaju. Vrlo je zgodno kad ti neko kaze i da negde postoji
bug, pa da ne moras sam da dolazis do tog saznanja, to moze da boli :)
clipper.874vili,
Problem sa memo poljima.
-----------------------
Ako u memo polju ima vise od 480 karaktera posle svakog:
replace 'memo' with memoedit('memo',...)
fajl .DBT se povecava za 1024 bajta iako nista nije dodato u memo-u.
Ako u memo-u ima, recimo, 2567 bajtova .DBT se povecava za 3072
bajta, i tako unedogled sve dok taj .DBT postane tako veliki da
jednog dana postane veci i od samog Clipper-ovog .EXE-a.
Daklem, *.DBT fajlovi se povecavaju za ceo broj kB (ili za 512 bajta)
ako se koristi funkcija memoedit(). Isto se desava i iz DBU-a, ako se
izvrsi ctrl-W pri svakom ulasku u memo polje.
Iz PCTools-a se moze videti da se svaki put u .DBT-u ponavlja sadrzaj
memo-a pri svakom izlasku u memoedit-a.
Ovo se ne desava ako u memo-u ima manje od 480 karaktera.
E, sad, postoji li objasnjenje za ovo? Da li je ovo Clipper-ov 'bug'
ili sta?.
PS. Otkrio moj kolega sa posla Pedja, ciji je .DBT dobio neslucene
razmere od oko 105kB !, a u memo-u samo 800 karaktera!.
Vili
clipper.875nbatocanin,
-> #867, kvelkovski> Koristim Clipper 5.01 vec poduzhe ali nisam nashao nachin
> da ukljuchim .NDX indekse. Ima li uopshte nachina?
Ne. Obećavaju da će biti ponovo u sledećoj verziji.
clipper.876d.petrovic,
-> #875, nbatocaninĂ>> Koristim Clipper 5.01 vec poduzhe ali nisam nashao nachin
Ă>> da ukljuchim .NDX indekse. Ima li uopshte nachina?
Ă>
Ă> Ne. Obećavaju da će biti ponovo u sledećoj verziji.
Ajd, da ga bude. Ali šta li će nam sad pa opet to? Meni ni bazu Dbase ne
može kako treba uvek da pročita, nego se zaglupi. Nedavno sam ispravljao na
licu mesta jednu bazu kad su zajeboravili šifru (koje li muke ljudi božji, sve
što sam zbudžio preračunati peške ;(( ) i nisam moga da pročitam bazu iz
Dbase-a, a DBU nisam imao.
clipper.877dpaun,
Braćo Clipperaši i mile sestre Clipperašice, u vezi ranije istaknutog
problema podizanja YU slova (poruka 828), ja sam nešto petljao sa
asemblerskom idejom nBatocanina iz jednog broja Računara, i ta stvar
radi samo u slučaju 1, i to kada se, dok smo u polju Niz1, pritisne
donja kursorska strelica (što je mnogo efikasnije i elegantnije nego da
ganjamo kursor do yu slova, uključimo zaboravljeni CapsLock, ispravimo
grešku, pozajmimo pilulu za sniženje pritiska, pošaljemo zabrinutu
sekretaricu po čašu s vodom, etc ....)
Pošto sam ja kao programer naivac tutu za klipper a tutuban za
asembler, molim da se neko prihvati daljeg majstorisanja oko ovog
problema. Može se od njega napraviti čak i BajtLP.
Kako, dakle, urediti ovu stvar, da se i Niz1 i Niz2, pa sve tamo do
NizaEntog, pošalje jednoj istoj funkciji DigniGa() a ona da radi ono
što joj ovo sexy ime kaže.
dPaun.Yu
č x,1 get Niz1 pict "č!" valid DigniGa(Niz1) && Slučaj 1
č y,1 get Niz2 pict "č!" valid Yupper(Niz2) && Slučaj 2
read
...
FUNC DigniGa()
Niz1 := Yupper(Niz1)
return .t.
*********
* Asebmlerska paremija
* prema manuskriptu brata nBatocanina
* iz Računara
**********
INCLUDE EXTENDA.INC
DATASEG
CLpublic <YUPPER>
CLstatic <string smallyu "žčšćđ">
CLstatic <string bigyu "螊ĆĐ">
CLfunc char YUPPER <char str>
CLcode
PUSH ES
PUSH BP
PUSH SI
JMP begin
r_str DB 80 DUP(0)
begin: LES SI, str
MOV BX, 0
cikl: MOV AL, ES:ŠSI+BXĆ
MOV r_strŠBXĆ, AL
OR AL, AL
JZ kraj
CMP AL, 'a'
JL yu_letter
SUB BYTE PTR r_strŠBXĆ, ' '
JMP next_char
yu_letter:
MOV BP,0
tab: MOV AL, BYTE PTR smallyuŠBPĆ
OR AL, AL
JZ next_char
CMP BYTE PTR r_strŠBXĆ, AL
JNE next
MOV AL, BYTE PTR bigyuŠBPĆ
MOV BYTE PTR r_strŠBXĆ, AL
next: INC BP
JMP tab
next_char:
INC BX
JMP cikl
kraj: MOV AX, SEG r_str
MOV BX, OFFSET r_str
POP SI
POP BP
POP ES
Clret AX BX
END
clipper.878ndragan,
-> #855, toma/ Sve zavisi od dužine programa. Recimo, program od nekih 400
/ linija, kompajliranje + linkovanje = 21 sec (286/16) i onda
Daa... otkad nisam pisao program u komadu... ex, jednom pređeš na foks,
i onda više nemaš osećaj. Moja mera nisu linije, nego kilobajt zipa.
Normalna aplikacija ima 100 - 350K, od čega 70% napravi generator, 20%
je prepisano iz slične ili iz verzije za drugog korisnika, i 10% je
tiha patnja na licetu mesta, kako neko ovde reče. Štos je ipak u tome
da FoxPro nema linker (osim za mamutski samostalni .EXE u 2.00),
kompajlira u hodu samo sveže fajlove i ne moram uopšte da izlazim iz
njega. Foks i kliper su zaista postali različiti po koncepciji.
clipper.879ndragan,
-> #858, kanda/ rezultat prespor, a moze biti i nemoguce... sta ces onda ?
Ubaci se parče rađeno u asembleru, u .obj formatu - učita se negde gore
i poziva sa CALL sa sve prenosom parametara. Tako smo svojevremeno
simulirali Scroll naredbu dok se nije pojavila.
/ 386/25. U minutima ? 11/60 - 0.17 minuta ili tu negde.
Izgradilo se to, zaista. Pamtim neke tamo stvari iz '88 - ono je bio
blagi užas.
clipper.880ndragan,
-> #859, nbatocanin/ A šta ćeš kad ti u Fox-u zatreba nešto što tu nema?
Još nisam našao. Možda 'index while' da napravi delimični indeks dok je
aktivan drugi indeks... onako 'seek... copy while... index' ali u
jednom komadu :).
Na stranu želje puste - ostalo ima, a ako nešto primetimo da fali, uvek
nađemo rešenje. Možda ne uvek istog dana, ali ga nađemo, i to u foksu.
clipper.881ndragan,
-> #865, gristic/ Gos'n ndragan, ždraknite poruku 5.847. ;)
Ne izdrža srce vam junačko, a? Dva dana ne stignem na Sezam, i odmah se
smatra da nemam petlju da se oglasim?
/ 1988 ? 1989 ? Inspiracija u kafani (na lap top salveti) ? ;)
Ne, ali od lep top modela preporučujem kelnericu.
/*> case polje = 'KELNER' .or. polje = ''
/*> sta = 'žEKANJE'
"He waits while you wait." Ulysses, James Joyce.
clipper.882neman,
-> #871, janko> Ne bih želeo da me doživljavaš kao nekog 'mrzitelja
> Klipera.' Nisam nikada napisao nijednu aplikaciju na 5.0
==============================================
> verziji, i ne poznajem je tako kao ti, pa je moguće da sam
========================================
> nešto pogrešno shvatio. Meni se učinilo da je Kliper sa
> tim 5.0 doneo masu stvari koje mi ne trebaju, a praktično,
> nijednu koja mi je trebala. I sve vreme čekam, možda ću
> konačno čuti o nečemu što
========================
Pljuvati po nečemu o čemu nemaš pojma u najmanju ruku nije korektno.
clipper.883janko,
-> #882, neman> Pljuvati po nečemu o čemu nemaš pojma u najmanju ruku nije
> korektno.
Ako to smatraš za pljuvanje. ;) I ako smatraš da baš nemam
pojma. To što nisam pisao u Kliperu 5.0 ne znači da nemam
iskustva u ovim poslovima. I ne znači da nemam svoj stav o
tome, šta sam ja želeo da vidim da Kliper koji dolazi posle 87
ima, a šta je on doneo. Po meni, prašinu u oči... Ja to zovem
iznošenje stava, i pišem ono što si citirao (da nisam napisao
nijednu aplikaciju na Kliperu 5.0) upravo zato da bih se
ogradio od eventualnih osuda da sam tvrdio nešto što nije
tačno, time što preciziram da nemam previše iskustva, i možda
tvrdim nešto što nije tačno. Ipak, za ovo što sam tvrdio, još
uvek nisam dobio kontraargumente. A voleo bih da ih čujem... To
što nisam napisao nijednu aplikaciju na 5.0 ne znači ni da ne
bih umeo, niti da ne razumem koncepte koje koristi 5.0. O
pomenutim konceptima (i mom nezadovoljstvu njima) sam upravo i
pisao. I sasvim fino mogu da razgovaram i sa tobom o njima, ako
si na to spreman... :) Šta će ti diskusija u kojoj svi ISTO
misle? Samo iz sukoba mišljenja je moguće da proistekne nešto
novo...
clipper.884janko,
Neko je ovde pominjao Blinker linker. čeleo bih da čujem
iskustva nekog ko je radio sa njim. Kako se ponaša sa Kliper
5.0 specifičnostima (.PLL datoteke, DLL koncept, podrška Kliper
5.0 virtuelnoj memoriji i te stvari...)
Ili, da sažmem pitanje: može li POTPUNO zameniti RTLINK? I
koliko je brži od njega, ako je odgovor na prvo pitanje da?
clipper.885dpaun,
-> #874, vili
>> Ako u memo polju ima vise od 480 karaktera posle svakog:
>> replace 'memo' with memoedit('memo',...)
>> fajl .DBT se povecava za 1024 bajta iako nista nije dodato u
>> memo-u.
Ne razumem ovo, brate Vili! Radim dve-tri godine sa tekstualnim bazama,
tj. pretežno se rvem sa memo i DBT, i ovo nisam zapazio (tj. da se DBT
povećava iako ništa nije dodato u memo-u). Pre nego što zinem bilo šta,
molio bih te - ako druga braća ne skontaju o čemu je reč - da dopuniš,
odnosno preciznije opišeš uočenu pojavu. Možda i sa delom listinga u
kome se nalazi operacija sa memo poljem. Memo i DBT su zato i uvedeni
da "rastu" samo kada se nešto u memo polje unese. Kada se vrši izmena
već unetog teksta, Clipper ne prepisuje novi sadržaj preko starog, već
stari označi da je spreman za brisanje a novi doda na kraj dbt baze.
Zato DBT raste ko da je u metastazi. Suvišan tekst, samim tim i svođenje
DBT-a na njenu pravu veličinu, vrši se povremenim kopiranjem cele baze.
Najbolje je ovo kopiranje ugraditi u meni kao opciju, a procedura bi
izgledala ovako:
RENAME Baza.dbf TO Tmp.dbf
REBAME Baza.dbt TO Tmp.dbt
SET DELETE ON
USE Tmp
COPY TO Baza.dbf
CLOSE Tmp
ERASE Tmp.dbf
ERASE Tmp.dbt
>> .DBT postane tako veliki da jednog dana postane veci i od samog
>> Clipper-ovog .EXE-a.
DBT, da je živ i zdrav, to treba i da radi. Znam za testove sa DBT
veličine 20 MB; kod mene je trenutno negde oko 2 MB, i sve savršeno
radi.
>> Ovo se ne desava ako u memo-u ima manje od 480 karaktera.
Clipper za memo rezerviše blokove veličine 512 bajta. Tu negde može biti
odgovor, mada mi nije jasno da li govoriš o dodavanju novih slogova u
bazu, ili o izmenama unetih slogova. žim se nešto unosi u memo polje,
baza mora i da raste.
>> E, sad, postoji li objasnjenje za ovo? Da li je ovo Clipper-ov
>> 'bug' ili sta?.
Ovako na uvce, mislim da je problem u nepotrebnom ulaženju u memoedit.
Možda ček i o nepotrebnom korišćenju memo polja, ako je reč o kraćim
tekstovima. Ovaj problem je najbolje razrađen u knjizi:
Rick SPENCE: CLIPPER 5, Voduč za programere,
Mikro knjiga, Beograd, 1991, s.161 i dalje
Tamo su navedeni slučajevi kada je najoptimalnije koristii memo, a kad
je, pak, bolje "dugačka znakovna obeležja" kako ih on naziva. Ima i
listing programa za testiranje ove dileme.
Pozdrav,
dPaun
clipper.886gristic,
-> #869, ndragan*> Ko, jel' ja? Prisutan i na broju, ser. A za onu 'eminenciju' nemaš piće
Na mestu voljno. Oslabili ti refleksi... ;)
*> BTW, odakle ti taj sors, trebalo je da bude zaštićen :). Ex, jednom
*> napišem nešto u kliperu i posle četiri godine me sustigne... pravi leš
*> iz ormana...
Izbunario iz arhive. Pravio sam Veliko_Spremanje_Mojih_1000_Disketa (redovno
svakih 125 godina po jedno) i ovo se pojavilo. Prvo sam i ja bio zbunjen, a
onda mi je sinulo: pre 2-3 godine dok još nisam imao mašinu pao mi je u šake XT
Šnajder 1620 (1640?) inkriminisane zadruge (nedokučivi su putevi kompjuterski).
Kao svaki savesni programer redovno sam pravio bekape, zipove, arcove, lhove,
žvrnjčšćove i tako ostade zakopano negde (...štooo ne voliiim da brišem arhive,
a tek što me mrziii da ih pregledaaam...tako da *sve* imam *najmanje* duplo ;<.
Tako mi je, npr., trebalo *godinu* dana da istrebim sa disketa onaj virus...
kako se ono zvaše... ah da, Tetris! (a onda instaliram DESQview/X (QEMM 6.03)
i ono DVX TETRIS !!!!). Što se zaštite tiče obožav(ao s)am da "razbijam" tuđe
zaštite i da posle toga obrišem programe, ali kod ovog *nisam* primetio nikakvu
zaštitu.
*> Stidim se po čitavom telu (što sam radio u Kliperu :).
I treba. Pored (već tada) živog Foxa... ;)
*> I jesu
*> li ikad počeli da ga koriste? Nismo se rastali u nekim lepim odnosima
*> (mušterija i ja), al' se nismo ni posvađali (jedino nisu platili
*> poslednjih 30%). Odakle ti to, leba ti?
Jok. Bio im komplikovan korisnički interfejs. Nije hteo sam da radi,
moralo je i da se razmišlja koja je razlika između strelice gore i
strelice dole, a i dobili žuljeve na laktovima. ;)
*> Imaš pogrešnu verziju - pisala su (u zvaničnoj) naša imena (jedan drugar
*> i ja) i čak je bilo predviđeno da u slučaju da se nekakav čeksum naših
*> imena ne složi, program pobriše sve iza desetog sloga u matičnoj
*> datoteci pa onda istu spakuje i preindeksira.
Misliš na ovo? O:)
č 2, 7 SAY "APLIKACIJA FINANSIJSKOG POSLOVANJA STAMBENE ZADRUGE"
č 3, 7 SAY '"***********" *************'
č 6, 35 SAY "AUTOR: Dragan Nedeljković, dipl. mat."
č 7, 24 SAY "STRUžNI SARADNIK: Branislav Grmuša, prof. inf."
č 9, 44 SAY 'nosilac posla: RO "CEMIK" NOVI SAD'
.
.
.
(z.doc)
OPIS APLIKACIJE FINANSIJSKOG POSLOVANJA
RAĐENE ZA STAMBENU ZADRUGU *************
***************
Autor: Dragan Nedeljković
Opis aplikacije
Aplikacija za praćenje finansikskog poslovanja do-
bavljača i zadrugara stambene zadruge ************* iz **-
*********** pisa=na je u bazi podataka Dbase II i prevedena
kompajlerom Clipper na računaru Amstrad/Schneider PC1640.
.
.
.
(Zvezdice sam ja stavio zbog konjspiracije ;)
*> č lin+ 5,kol+1 PROMPT " uzano " MESSAGE "nabudži štampač na uzana slova"
;)))) A ovako:
č lin+ 5,kol+1 PROMPT " uzano " MESSAGE "'Ajde spiči bre taj tvoj bedni
drndavi *ebeni štampač na ta prokleto tesna slova" (širina 79) :)))
*> Inače, nije kažnjivo al' će te košta - dođeš mi kriglu piva za ovo :).
Važi 'al neće me košta. Imam, hik, vezu u Jelen pivari. ;o)
*> / replace z->prez with yuupper(z->prez)
*> =======
*> Ukrasovcima skrećem pažnju na ovaj detalj. Pisano '88 u leto.
15.07/09.09.1988. Brrrr, mraaaaačni programerski srednji vek ;)
Za ovo (što sam izdvojio i taj red) *ti* častiš (Krigla ? Jel' to ono maaalo,
maleeecko stakleno sa drškom ? ;o))
*> Program takođe više nema nikakvu komercijalnu vrednost, postoji (jel
*> može malo reklame za sve ovo?) mnooogo bolja verzija aplikacije
*> stambenih zadruga rađena u Foks Prou gde sve šljaka kako bog zapoveda.
Eh, da sam ga našao prošle godine prodao bih im ponovo. ;) (šalim se)
Ovako sam se namučio u C-u da povežem Btrieve i Isam (ne pitaj zašto
*oba* !!!) i da štampam ćirilična trebovanja. Sada ću im (pro)dati novu
verziju u FoxPlusu pod Xenixom (FoxPro za *NIX? Eh, pusti snovi...).
Pozdrav
Goran
P.S.
Što se pića tiče: Odžaci ili Bečkerek (ili oba ;))?
P.P.S.
Jesi probao/uspeo da ukrstiš FoxPro 2.0 i Paradox Engine (štosa radi)?
P.P.P.S.
I gos'n MBP-cobol-guru jsalai ima(o je) iskustva sa njima (zadrugom). ;)
Naravno i
njegovi (stariji) cob sorsevi su tu negde (pretpostavljam). ;)))
clipper.887nbatocanin,
-> #872, bulajaNajnovija verzija Blinkera je 2.0 i po rečima Rik Spensa to je
najbolji proizvod za Clipper.
clipper.888nbatocanin,
-> #871, janko> E, kad smo već zašli u te vode, voleo bih da mi objasniš
> opravdanost uvođenja onoga što se u Kliperu zove 'CODE
> BLOCKS'
Probaću da što kraće objasnim osnovnu ideju i prednosti. Kodni blok
je, u stvari, funkcija. E sad, zašto se uvodi još nešto pored
standardnih funkcija? Kodni blokovi su *tip podataka*, što znači da
nad njima možete vršiti i obradu. Doduše, ne previše složenu, ali
dovoljnu: kodni blok možeš dodeliti promenljivoj, proslediti kao
parametar proceduri, vratiti kao rezultat ili izvršiti.
Zašto je to odlično? Zato što na taj način možete proceduri,
funkciji ili objektu proslediti osim podataka i *akciju*, tj. možete
reći ne samo "ovo je toliko, ovo toliko, ...", nego možete da kažete
"ovo uradi ovako". Mislim da teorijske posledice ovoga ne treba
naglašavati. Sećaš se mog primera za niz koji bi se teško deklarisao
u strogo tipiziranom jeziku? E, zamisli sad niz (slog, u stvari) u
kome jedan element kazuje *kako* nešto treba uraditi. Primena? Pa,
objekti su, u stvari, takvi nizovi: slog koji sadrži obične podatke i
akcije.
Zašto je zgodno procedurama prosleđivati i akcije? Uzmimo jedan
jednostavan primer: funkcija za sortiranje niza:
ASort (aArray)
vraća sortiran niz. Ali *kako* da sortira? Pa, najjednostavnije je reći:
"OVAKO"! Time obezbeđuješ visoku univerzalnost programa.
ASort (aArray, { |x,y| x >= y } )
Može se reći da se to isto postiže makroima: prosledi se string koji
predstavlja izraz za poređenje, pa se sa &cString računa. Štos je što
sa kodnim blokovima prevodilac u trenutku prevođenja zna koju akciju
treba izvršiti, pa se može napraviti prevod, dok se makro uvek mora
interpretirati iznova.
Drugo, moglo se rešiti kao u C-u: pokazivač na funkciju, pa bi se
onda pisalo "uradi onako, kako je zadato u funkciji PPP()". Onda bi se
pisalo nešto ovako:
ASort (aArray, PPP() )
Pogledajte koliko se ovim smanjuje preglednost programa: ko hoće da
zna šta radi program, mora tražiti funkcija PPP u listingu. Ali, ima i
nešto drugo. Rešenje pomoću funkcija bi saseklo mogućnost realizacije
nekih komandi. Na primer, kada se napiše
LOCATE FOR x > 4
pretprocesor to prevede u
DBLocate ( { || x > 4 }, ... )
a u slučaju funkcija bi se morala generisati posebna funkcija za
računanje izraza X > 4. Napominjem da je glupo, a ne realizovati
LOCATE preko neke funkcije.
> Zatim, ta igranja sa preprocesorom su, ipak, samo igranja
> sa preprocesorom. I C ima preprocesor, ali se JAKO umereno
> koristi
Ovde jok. Pretprocesor predstavlja pluća Clipper-a 5.0. On je
dosta moćniji od C-ovog i to ne bez razloga: skoro sve standardne
naredbe su rešene kao pozivi funkcija maskirani pretprocesorom.
> -- ako ti sam pišeš i održavaš svoje programe, baš te
> briga, ali kada bi radio u većem timu, baš me zanima kako
> bi ti se sviđalo kada bi svako izmišljao svoju sintaksu za
> elementarne naredbe...
Da, ali šta ako dobiješ/napraviš novu biblioteku funkcija? Pa moraš
da koristiš nešto ovako:
CrtajMaskuBre (Id, Row, Col, Top, Bottom, Shadow, Blink, Cvrc)
Mislim da nikog ne treba ubeđivati da se ovo daleko lakše pamti kao
CrtajMaskuBre Pos 1,2 SHADOW BLINK
Ključne reči se daleko lakše pamte, a ne moraš sve ni navoditi. Može
se i zameniti redosled parametara - ključna reč je dovoljna da se
odredi šta je to.
> E, da, mana C preprocesora je što ne radi proveru tipa parametara
> koji su prosleđeni markrou u toku prevođenja. Kako to radi Kliper
> 5.0?
U standardnim makroima radi isto kao C - nema nikakve provere.
Samo, mislim da je to standardno za pretprocesore: njihov jedini
tip podataka je TEXT. žak i u strogo tipiziranim jezicima (Clipper to
naravno nije) bi pretprocesor koji razlikuje tipove morao da radi
najpliće posle leksičke analize, a čini mi se (odoka) da to ne bi bilo baš
tako jednostavno.
Direktive #translate se mogu uslovno nazvati nekim makroima. One
umereno prepoznaju tipove, ali pružaju daleko moćnije preslikavanje
ulaznih parametara od makroa. One su potpuno nova tema.
> Hoćeš li mi objasniti i šta je to što Kliperov jezik čini
> elegantnim? Ja sam uvek cenio estetske vrednosti i duboko
> ću ga poštovati, ako shvatim tu eleganciju?
Pa evo, na stranu lični ukus. Gornje stvari (i mnoge druge) su
mogle biti rešene na 1000 drugih načina. Ja vidim lepotu u ovim
rešenjima. Krajnje čistim principima je omogućena izvanredno
jednostavna nadgradnja svih sistema: od jezika pa do kontrole
tastature. I pored velike balasti zvane kompatibilnost.
Mislim da bi se mogao napraviti sasvim dobar klasičan programski
jezik na osnovu koncepcija jezika u Clipper-u: ako se izbace delovi
koji se odnose na rad sa bazom, moglo bi se značajno ubrzati
računanje izraza i uopšte poboljšati prevod. Kodni blokovi bi mogli
da se stvarno prevode (nema pristupanja poljima), i ne vidim razloga
da se tako ne napravi jezik sasvim blizak po performansama C-u. žak,
čudi me što to još nije urađeno. A C-u svakako ne bi smetalo nešto
poput kodnih blokova.
Saznao sam da se Clipper grana u dva proizvoda, Jedan će se zvati
Aspen i biće to Win proizvod brzinskih performansi oko 60% od C-a.
Druga grana je za tekst programere i ide na dalje usavršavanje jezika
i potpunu objektnu implementaciju.
> Ne bih želeo da me doživljavaš kao nekog 'mrzitelja Klipera.'
Ma ne! Zar misliš da bi se onda raspravljao s tobom? Ja sam uvek za
čist i koristan razgovor. A možda će ovo nekom i koristiti?
P.S. Svojevremeno sam se raspitao i kazaše mi da se kaže
*pretprocesor*, a ne *preprocesor*.
clipper.889nbatocanin,
-> #874, vili> Ako u memo polju ima vise od 480 karaktera posle svakog:
> replace 'memo' with memoedit('memo',...)
Može i samo REPLACE memo WITH Space(512) ;( Sistem je jedan od
glupljih.
clipper.890bulaja,
-> #884, janko│Neko je ovde pominjao Blinker linker. Zeleo bih
│da cujem iskustva nekog ko je radio sa njim.
└───
Ako te toliko interesuju mnoge stvari vezane za Clipper 5, zasto ne
uzmes i malo da ga koristis? Ovo pitam zbog tvojih poruka gde se toliko
interesujes za Clipper 5, a tvrdis da ga uopste nisi koristio. Verovatno
ce ti mnoge stvari tako biti jasnije, ovako izgleda kao da proucavas
samo teoriju Clippera na papiru :).
clipper.891janko,
-> #890, bulaja> Ako te toliko interesuju mnoge stvari vezane za Clipper 5,
> zasto ne uzmes i malo da ga koristis? Ovo pitam zbog
> tvojih poruka gde se toliko
Zato što mi je lakše da pročitam neko iskustvo o Blinkeru, nego
da ga jurim program po gradu, eksperimentišem i zaključim da
nisam morao ni da se trudim. Pitanje je bilo vrlo konkretno:
> Kako se ponaša sa
> Kliper 5.0 specifičnostima (.PLL datoteke, DLL koncept,
> podrška Kliper 5.0 virtuelnoj memoriji i te stvari...)
>
> Ili, da sažmem pitanje: može li POTPUNO zameniti RTLINK? I
> koliko je brži od njega, ako je odgovor na prvo pitanje
> da?
Dakle, ako nema sve ono gore, ne vredi ga koristiti! Onda ne
vredi ni da se trudim da ga nabavljam i zezam se sa njime...
Sa 5.0 sam baš eksperimentisao (nisam samo čitao ;) ali me nije
tada ubedio da mi je mnogo koristan... ;) Seti se još i
nepouzdanosi 5.00 verzije itd...
clipper.892janko,
-> #888, nbatocanin> Drugo, moglo se rešiti kao u C-u: pokazivač na funkciju,
> pa bi se onda pisalo "uradi onako, kako je zadato u
> funkciji PPP()". Onda bi se pisalo nešto ovako:
>
> ASort (aArray, PPP() )
Jeste, tu si u pravu, lepše je da je sve na jednom mestu, u
ovakvoj primeni. Priznajem da je lepše sa kodnim blokovima...
> LOCATE FOR x > 4
>
> pretprocesor to prevede u
>
> DBLocate ( š đđ x > 4 ć, ... )
>
> a u slučaju funkcija bi se morala generisati posebna
> funkcija za računanje izraza X > 4. Napominjem da je
> glupo, a ne realizovati
Pa, i ovako se generiše funkcija, samo je sakrivena u istu
liniju?
Ili se blokovi koda ne prevode kao funkcije?
> CrtajMaskuBre Pos 1,2 SHADOW BLINK
>
> Ključne reči se daleko lakše pamte, a ne moraš sve ni
> navoditi. Može se i zameniti redosled parametara - ključna
> reč je dovoljna da se odredi šta je to.
Odrastao sam na jezicima koji imaju jako malo ključnih reči,
ukupno, pa na ovakve koncepte nisam navikao. Da ne govorim o
tome da mi ovo miriše da moram dva puta da testiram funkciju --
prvi put kada je pišem i realizujem, a drugi put i da li sam
napisao dobro 'izmišljenu' naredbu. Problem je i kada razvijaš
više aplikacija -- obično se trudiš, tokom razvoja, da ne pišeš
sto puta isto. Održavanje funkcija je relativno lako -- ako si
je ispravio, a koristiš je u više programa, bez problema ćeš je
nadalje koristiti u svima. Ali ako menjaš ove 'translacije,'
šta onda? Kako ti to radiš? Da li uz svaku aplikaciju vučeš
posebno sve fajlove sa translacijama ili...?
Drugi problem je još fundamentalniji -- translacije treba da ti
obezbede da ako ONO U ŠTA SE TRANSLIRA tvoj program budu
promenili, ti i dalje možeš da ga prevodiš bez brige.
Ako počneš i sam da daješ 'niske udarce,' programi ti još više
postaju zavisni od verzije kompajlera.
> Direktive #translate se mogu uslovno nazvati nekim
> makroima. One umereno prepoznaju tipove, ali pružaju
> daleko moćnije preslikavanje ulaznih parametara od makroa.
> One su potpuno nova tema.
To sam te i pitao: koliko su robusne? Da li time što uvodiš
translate trikove i strukturno slabiš program (u smislu da ti
je više dozvoljeno nego pre, a ne proverava se u toku
prevođenja?) Zato sam te i pitao, jer ti imaš ISKUSTVA. U onim
tekstovima koje su pisali tipovi koji su ga pravili, oni neće
da iznose ružne stvari, nego ga samo hvale...
> jednostavna nadgradnja svih sistema: od jezika pa do
> kontrole tastature. I pored velike balasti zvane
> kompatibilnost. Mislim da bi se mogao napraviti sasvim
> dobar klasičan programski jezik na osnovu koncepcija
> jezika u Clipper-u: ako se izbace delovi koji se odnose na
> rad sa bazom, moglo bi se značajno ubrzati računanje
> izraza i uopšte poboljšati prevod. Kodni blokovi bi mogli
> da se stvarno prevode (nema pristupanja poljima), i ne
> vidim razloga da se tako ne napravi jezik sasvim blizak po
> performansama C-u. žak,
Šta to znači 'kodni blokovi bi mogli stvarno da se prevode?'
Zar se sada ne prevode? U čemu je onda trik?
Što se tiče sintakse, danas je prilično lako realizovati jezik
sa kakvom god hoćeš sintaksom, ako se ona može napisati kao
BNF. Krajem šezdesetih pa do početka osamdesetih svi su
izmišljali jezike -- to je bio glavni sport. Ali se, hvala
Bogu, iz toga svega nešto iskristalisalo... jedna od tekovina
tadašnjih bura je upravo saznanje da kompajler treba da štiti
programera od njega samog. Neki jezici su preterivali takvim
idejama (Virtovi) a neki ih zanemarivali (stari C). Na kraju se
ipak došlo do neke 'razumne sredine.' Ta razumna sredina je da
jezik treba da ima što manje ključnih reči, što uniformniju
sintaksu, dobro rešen 'scope' promenljivih, i kontrolu tipa
prosleđenih parametara...
A šta meni najviše smeta kod Klipera? Po meni, baš to što nije
dovoljno kompajler -- a mogao je da bude...
Znam, kada se Kliper pojavio, najbitnija osobina mu je bila:
'Uzmite dBase program, propustite ga kroz Kliper, i sve će da
radi, a imaćete .EXE verziju.' (Mada, ni S87 verzija nije baš
tu bila dosledna -- bilo je nekih nepotrebnih odstupanja.)
Jezik koji je fino funkcionisao u interpreterskoj okolini,
prilično je rogobatno realizovati za kompajler. Na primer,
makro supstitucije se nikako nisu mogle koristiti onako divlje
kao u dBase programima.
Moram da napomenem da sam radio na dBase-u još od vremena
kada je najveća postojeća verzija bila II (što je i prva
verzija -- autori dBase nisu nikada napravili dBase I -- ovo je
bio marketinški trik) i sve to na CP/M-u, na kome je na disketu
(ako se još sećam) stajalo manje nego na današnju DD disketu, a
hard disk nije imao poddirektorijume (bilo je zabavno kucati
DIR tada). dBase je stvarno bilo nešto najkorisnije što je
postojalo na tim mašinama -- bilo je i za njih dovoljno brzo,
i, opet, za njih je izgledalo prilično 'bez ograničenja.' Hoću
da kažem, pratio sam razvoj di-bejz-lajk jezika dosta dugo, i
mislim da ipak imam pravo da iznosim svoje mišljenje o tome
kako izgledaju ti pravci koji su se razvili iz svega toga...
I šta su dizajneri Klipera trebali da urade sa 5.0 verzijom?
Da, umesto izmišljanja preprocesora (kojim su, opet, zakopali
sebe time što za taj jezik nikada neće moći da se napravi
čvrsta sintaksna provera -- pričao sam ti da sam želeo čak i
sam to da realizujem -- sada je to nemoguće...) i 'svođenja na
isto,' ako su već želeli da izmišljaju novi jezik (a 5.0 je,
faktički, novi jezik) naprave kompajler koji radi 'u dva moda:'
'Kompatibiliti' i 'Pravom.'
'Pravi' bi bio jedan čvrst jezik, primeren kompajliranju, koji
bi radio SVE MOGUĆE provere u toku kompajliranja, a
'kompatibiliti' bi služio onima koji ne žele da iskoriste
čitave procedure pisane u starom maniru (ali, šta će im onda
novi prevodilac O:) ?) Sad sam se setio -- za te stare
aplikacije najbolnija tačka bila je nemogućnost svapovanja
samih sebe pre startovanja eksternog programa. 5.0 to nije
donela. Donela je virtuelnu memoriju. Ali ako je stara
aplikacija radila bez virtuelne memorije, šta će mi onda
virtuelna? Sve u svemu, što bi neko staru aplikaciju uopšte
prevodio novim prevodiocem?
Verovatno su se plašili da urade nešto tako drastično, kao, da
bi ljudi mogli U ISTOJ funkciji/proceduri da mešaju stare i
nove fore... Ali od tog mešanja je više štete nego koristi...
što i ja i ti znamo... što se grbavo rodi...
Ovako, sve je, ipak, ostalo nekako nedovoljno... 5.0 je
nedovoljno interpreter (ni oni pre to nisu bili) ali, što je
još nezgodnije, i nedovoljno kompajler...
Što opet ne znači da Kliperom nije moguće uraditi puno lepih
stvari. Danas već postoji puno softverskih proizvoda kojima se
realizuju prilično složene stvari, a da oni ne poštuju
elementarna pravila 'pravih jezika.' Danas je čitavu aplikaciju
moguće razviti čak, naprimer, i popunjavanjem raznoraznih
ćelija u spredšitovima, pa silnim manipulacijama redova, kolona
(skrivanje, otkrivanje, proširivanje, idimi dođimi) i pisanjem
nekih kao makroa. A počelo je od tabela koje je trebalo da ti
sračunaju relativno proste stvari... Ono zbog čega ja nisam
previše srećan sa takvim stvarima je što da bi stvarno dobro
koristio mogućnosti jednog takvog paketa, moraš da jako dobro
proučiŠ BAŠ TAJ paket i BAŠ TU njegovu verziju, gde one
'najkorisnije' stvari nikada nisu iste u različitim
verzijama... S druge strane su 'regularni' programski jezici,
gde naučiš jezik, a onda ocenjuješ kompajler po tome koliko
dobro poštuje standard... i gde, hvala bogu, ne učiš sve
ispočetka svaki put kada se pojavi nova verzija... ili kad
preĆeŠ na prozvod druge firme. E sad, možda je moje očekivanje
da Kliper uđe u onu drugu kategoriju bila nerealna? Možda
Kliper nikad nije ni želeo da bude tako nešto, nešto što će
moći da pravi više nego jedna jedina firma, i da se koristi bez
obzira na 'okolinu?'
Ufff. Baš sam se raspisao... Priznajem, opet, da iznosim lični
stav, zasnovan na ličnim predubeđenjima, i da ne očekujem da se
svi slažu sa onim što pišem. :) Drugačija mišljenja su više
nego dobrodošla... Uz sve to, Nenade, hvala na strpljenju. Znaj
da sam te uvek duboko poštovao kao stručnjaka za Kliper.
PS. Hmmm. Pretprocesor ili preprocesor? Priznajem da je ovo
drugo pod uticajem strane literature. Ali ne znam ni neku
referencu na osnovu koje bih tvrdio da li može da se koristi?
Kad smo već kod jezika, da li se slažeš da bolje zvuči 'blokovi
koda' nego 'kodni blokovi?'
clipper.893ppekovic,
-> #891, janko>> Seti se još i
>> nepouzdanosi 5.00 verzije itd...
Već duže vreme je aktuelna verzija 5.01 koja, kao se pokazala kao pouzdana.
>> I šta su dizajneri Klipera trebali da urade sa 5.0 verzijom?
Kompatibilnost sa prethodnim verzijama kompajlera je jako lepa stvar ali i
velika kočnica pri stvaranju novih verzija. Da su napravili kompajler kakav bi
ti želeo da vidiš, onda bi se našao neki pera, marko, sima i sl. koji bi rekao:
šta se zezaju ovi u Nantucket-u, zar ću za svaku verziju sve morati da pišem iz
početka (zato sam ja digao ruke od Turbo Pascal-a, svaka verzija novi format
unit-a). Ne zaboravi i da su programeri veoma konzervativna sorta. Da bi se
navikli na novi proizvod potrebno je vremena i vremena. A ako im pružiš
komaptibilnost sa starom verziom oni počnu da korste novu sa mogućnostima
stare, pa polako "kupuju" jednu po jednu novost nove.
Naravno, i ljudi iz Nantucket-a razmišljaju o onome o čemu mi ovde pričamo,
pa ako si video poruku nbatocanin-a, tamo lepo piše da će da razvijaju clipper
u dva pravca. Jedan, ka jeziku koji bi vidim u globalu i ti želeo da vidiš, a
drugi u pravcu u kome su išli do sada.
Paya
clipper.894dpaun,
-> #877, dpaun
Suđeno mi je, izgleda, na opšte YuZadovoljstvo, da rečeni problem sam
rešim, i time se plasiram u uži izbor za neki od narednih BajtovaLP.
Rešenje je bilo u prenosu argumenata po referenci, tj. nizu koji se
prosleđuje opštoj funkciji Dig() mora da prethodi operator č. Iz niže
navedenog primera može se videti kako to izgleda u praksi. Kada
zaboravimo da uključimo CapsLock, a primetimo da nam se provukao neki
MaliYu, pritisnemo "strelicu na dole" i stvar će biti u redu; možemo,
takođe, bez brige napustiti get-read sa <enter>, MaliYu će automatski
postati VelikiYu. Za braću koja nemaju Masm prilažem ovde yu.obj. Da
podsetim da se i asem obj linkuju kao i svi drugi obj fajlovi, u ovom
slučaju, recimo:
RTlink Fi MojProg,Yu Lib ...
I još nešto. Ovo nikako nije homoljski hir. Zamislite da je korisnik
nepažnjom uneo "žIVKOVIć" a traži "čIVKOVIĆ"-a?
Ja toliko po "tem pitanju". Hvala braćo, drži tata; odoh ja u šumu da
spremam drva!
****
*
cNiz:=cNiz1:=cNiz2:=cNiz3:=SPAC(30)
č 1,1 GET cNiz1 pict "č!" VALID Dig(čcNiz1)
č 2,1 GET cNiz2 pict "č!" VALID Dig(čcNiz2)
READ
č 3,1 GET cNiz3 pict "č!" VALID Dig(čcNiz3)
READ
*
FUNC Dig(vNiz)
vNiz := YUPPER(vNiz)
RETURN .T.
********************
* yu.asm
* prema nBatocaninu
* kao što rekoh
********************
INCLUDE EXTENDA.INC
DATASEG
CLpublic <YUPPER>
CLstatic <string smallyu "žčšćđ">
CLstatic <string bigyu "螊ĆĐ">
CLfunc char YUPPER <char str>
CLcode
PUSH ES
PUSH BP
PUSH SI
JMP begin
r_str DB 80 DUP(0)
begin: LES SI, str
MOV BX, 0
cikl: MOV AL, ES:ŠSI+BXĆ
MOV r_strŠBXĆ, AL
OR AL, AL
JZ kraj
CMP AL, 'a'
JL yu_letter
SUB BYTE PTR r_strŠBXĆ, ' '
JMP next_char
yu_letter:
MOV BP,0
tab: MOV AL, BYTE PTR smallyuŠBPĆ
OR AL, AL
JZ next_char
CMP BYTE PTR r_strŠBXĆ, AL
JNE next
MOV AL, BYTE PTR bigyuŠBPĆ
MOV BYTE PTR r_strŠBXĆ, AL
next: INC BP
JMP tab
next_char:
INC BX
JMP cikl
kraj: MOV AX, SEG r_str
MOV BX, OFFSET r_str
POP SI
POP BP
POP ES
Clret AX BX
END
yu.objclipper.895ndragan,
-> #860, janko/ :) Pogotovu 'na licu mesta,' gde je recimo XT sa 80ms diskom ;)
Ih te bi trebalo zakonom zabraniti.
clipper.896ndragan,
-> #868, nbatocanin/ bodovao i jezik DBMS proizvoda i sećam se da je Clipper bio daleko
/ iznad ostalih u toj kategoriji.
Bogami, mora da žiri intimno voli Ce. Ovo primera iz 5.01 koje ste
okačili u ovoj temi me je i navelo da kažem da mi kliper sve više liči
na pretprocesor za Ce kompajler.
clipper.897ndragan,
-> #876, d.petrovic/ što sam zbudžio preračunati peške ;(( ) i nisam moga da pročitam bazu
/ iz Dbase-a, a DBU nisam imao.
Peške? No, za pešačke preračune sa neprekidnim zavirivanjem u bazu (da
vidimo šta smo napravili) posle svakog koraka, foks je ipak nenadjebiv.
clipper.898vili,
-> #885, dpaun> vec unetog teksta, Clipper ne prepisuje novi sadrzaj preko starog, vec
> stari oznaci da je spreman za brisanje a novi doda na kraj dbt baze.
> Zato DBT raste ko da je u metastazi. Suvisan tekst, samim tim i svodenje
> DBT-a na njenu pravu velicinu, vrsi se povremenim kopiranjem cele baze.
> Najbolje je ovo kopiranje ugraditi u meni kao opciju, a procedura bi
> izgledala ovako:
Pa ovo je idiotski! (Mislim na memo polja) Ocigledno je da Clipper
ima BIG BUG sa memo poljima.
> DBT, da je ziv i zdrav, to treba i da radi. Znam za testove sa DBT
> velicine 20 MB; kod mene je trenutno negde oko 2 MB, i sve savrseno
> radi.
>
A kako bi taj DBT od 2MB radio na mom disku od 42MB? Posle nekih
dvadesetak memoedita (u kojima se samo vrsi izmena odredjenih
karaktera) javio bi da nema mesta na disku.!!!
> Ovako na uvce, mislim da je problem u nepotrebnom ulazenju u memoedit.
^^^^^^^^^^^
Sta znaci nepotrebno ulazenje u memoedit???? Ako u programu postoji
opcija za izmenu ili unos memo podatka da li treba korisniku da
'napomenem' da tu opciju koristi samo 2 puta ili 7 puta ili koliko puta?
Vili
clipper.899nbatocanin,
-> #877, dpaun@ x,y GET cProm1 VALID DiziBre()
@ x,y GET cProm2 VALID DiziBre()
itd....
READ
FUNC DiziBre
GetActive():varPut(YUpper(GetActive():buffer))
RETURN .T.
A!!???
Koga ne mrzi da se bakće, može se vrlo lako postići da se YU slova
dižu i *za* vreme kucanja (kao sa PICTURE "!!!") - pogledajte
GetApplyKey() u GETSYS.PRG.
xNenad
clipper.900d.petrovic,
-> #898, viliĂ> Sta znaci nepotrebno ulazenje u memoedit???? Ako u programu postoji
Ă> opcija za izmenu ili unos memo podatka da li treba korisniku da
Ă> 'napomenem' da tu opciju koristi samo 2 puta ili 7 puta ili koliko
Ă> puta?
Postade zanimljivo pitanje. Možda pri startovanju (ne nikako pri ulasku u
memoedit, tek bi posle pričali da je Kliper spor :)) ) programa proveriti
koliko ima mesta na disku, pa upozoriti, pa ponuditi pakovanje, pa...
clipper.901d.petrovic,
-> #897, ndraganĂ> Peške? No, za pešačke preračune sa neprekidnim zavirivanjem u bazu
Ă> (da vidimo šta smo napravili) posle svakog koraka, foks je ipak
Ă> nenadjebiv.
Grrrrrrrr ;))) Ko je pominjao Blafa i Floka ? ;)
Ma ja sam morao da izvadim iz polja u bazi neke gluposti, da pofaćam
brojeve Ascii kodova i sve to izpreračunavam na digitrončetu mu da bih nekako
ukapirao šifru za ulazak u program. Sva sreća što sam se malo pre toga opametio
pa za sve aplikacije mrsim brojeve na isti način pa sam znao šta da bockam na
digitrončetu. Mrrrrrzelo me da idem kući, pa da vadim moju bazu, pa... . Sad
imam bolji fazon, znam napamet šta treba da se upiše da bih ga startovao MOJOM
šifrom :))
clipper.902dpaun,
Ko o čemu, dPaun o memu!
Poznato je da MemoEdit() može da obrađuje niz dužine 64K; Ako se proba
nešto veće, on to neće i u DOS izleće. Takođe veći fajl ne da ni da se
pregleda. Tada će, doduše, učitati deo fajla, ali u praksi ima
situacija kada je neophodno da iz našeg Clp programa listamo txt
fajlove neograničene veličine. Ovaj slučaj detaljno razmatra, uz
listinge primera, Rick Spence u knjizi "Clipper 5, vodič za
programere", u delu "Prikazivanje velikih datoteka ili niza znakova".
Kako sam zbog lenjosti propustio da blagovremeno naručim disketu sa
listinzima, ja sam pomenute primere prekucao, ali taj moj brikolaž nikako
da oživi. Pa sad pitam braću uzduž i popreko: da li je to rešio neko?
Brže s odgovorom, dosta sam čeko!
dPaun.
PS. Znate li kakva je šuma u jesen,
kad njome čovek hoda zanesen!
clipper.903ppekovic,
-> #897, ndragan>> Peške? No, za pešačke preračune sa neprekidnim zavirivanjem u bazu (da
>> vidimo šta smo napravili) posle svakog koraka, foks je ipak nenadjebiv.
Da, a ja sam čuo da u SCO-u pripremaju novu verziju UNIX-a
pisanu na clipper-u, clipper je nenadmašiv u pisanju rezidentnih
programa, kao i za programiranje CNC mašina.
Ovako možemo dokle god hoćeš, ali je zaista bez ikakvog
smisla. Valjalo bi ipak prvo da se raspitaš kakve su mogućnosti
clipper-a za praćenje stanja baze posle svakog koraka pa da onda
ocenjuješ šta je nenadjebivo a šta nije.
Da ti pomognem, clipper jednu lepu stvar koja se zove clipper
debuger.
Paya
clipper.904dpaun,
-> #899, nbatocanin>> može se vrlo lako postići da se YU slova
>> dižu i *za* vreme kucanja (kao sa PICTURE "!!!")
Bio bi to mali korak za tebe a veliki za Yužovečanstvo. A još ako bi to
zakačio ovde, znao bi o tebi i Vita šumar iz Ravne Reke, i moj komšija
Vlasta Bačilo, s kojim koljem drva u šumi, i njegova žena Vilarija, i ...
>> pogledajte GetApplyKey() u GETSYS.PRG.
Ja gledao, ništa ne video,
što video - nisam razumeo,
pa sam onda čarne oči kleo -
čarne oči, nek vam vid iskoči
>> xNenad
yPaun.žovekIzŠumeKojiNeRazume
clipper.905dpaun,
-> #898, vili>> Sta znaci nepotrebno ulazenje u memoedit????
Ne samo nepotrebno ulaženje, već i nepotrebno korišćenje memo tipa.
Je si li pročitao navedeo poglavlje kod R. Spensa?
>> Pa ovo je idiotski! (Mislim na memo polja) Ocigledno je da Clipper
>> ima BIG BUG sa memo poljima.
>>
Ja ne mislim da je reč o bagu, već o još nedorađenom alatu. Kada bude
tekstualna baza postala pomodna stvar, kao sada DBF, tada će i to morati
da se uredi. Što se tiče DBF-a, stvar je rešena tako što ti kažeš koliko
ti iznosi polje, i program ti, kod dodavanja novog sloga toliki prostor
rezerviše na disku, bez obzira da li nešto piš(n)eš u njega ili ne.
Dužina takvog polja, koliko se sećam, ne može da bude veća od 255
karaktera, ili se i ovde nešto promenilo u međuvremenu? I ova baza, tj.
DBF, raste isključivo prema mustri koju si skrojio na početku.
DBT, odnosno memo, predviđen je za upisivanje većih nizova čija se
dužina ne može unapred predvideti. Jedino ograničenje je, zasad, na 64K.
Bitnije od ovoga jeste sam koncept: DBT će se povećavati samo kada se
nešto unese u memo polje baze, a ne uvek kada se sa APPEND BLANK doda
novi slog. Kako reče brat Nenad, kad god pipneš REPLACE memo WITH
memo_polje ... Zato je veoma važno proceniti, prilikom krojenja baze, da
li je memo polje neophodno, ili se stvar može rešiti na drugi nači.
Kod unošenja novog teksta u bazu nema problema; novi tekst će biti
upisan u DBT, ona će se povećati u skladu sa tim unosom plus još neki
sitniš preko toga. Problem, po meni, nastaje kod izmena u već unetom
tekstu. Kada, na primer, nekim tekst procesorom ili editorom menjamo
tekstualni dos fajl, on će biti vraćen na disk u skladu sa izmenama.
Bolje reći, zauzeti prostor na našem disku neće se povećavati posle
svake izmene u nekom tekstualnom fajlu. Ali, o tome brine DOS. Clipper,
očigledno, nije smatrao da treba da ima mali DOS u sebi (bar ne zasad),
koji će ovu stvar voditi u skladu sa komunalnom logikom.
Moja iskustva sa Memo i DBT, pored svih očiglednih nedostataka, jesu
ohrabrujuća. Nedostatke ne vidim u ovom kancerogenom konceptu DBT-a, već
u siromašnim i oskudnim opcijama koje su ugrađene u MemoEdit(). Nešto
se, doduše, može uraditi preko korisničke funkcije, ili, čak, potpunim
isključenjem MemoEdita i korišćenjem spoljnog editora.
>> A kako bi taj DBT od 2MB radio na mom disku od 42MB? Posle nekih
>> dvadesetak memoedita (u kojima se samo vrsi izmena odredjenih
>> karaktera) javio bi da nema mesta na disku.!!!
Po ovome zaključujem da se, možda, pomalo i ne razumemo. Moje MemoEdit
seanse su, na primer, između 1 i 30 KB. Reč je o tekstovima koji nastaju
u toku terenskih istraživanja, o ispisima iz literature, o ... itd.
Izmene i dopune u već unetim tekstovima moram da vršim čak češće od
unosa nove građe. Naravno, ždraknem bar jednom nedeljno DBT i startujem
opciju za sažimanje prema potrebi. To sažimanje (naveo sam primer u
prošloj poruci), traje sve duže što je DBT veći. Ranije mi je to
smetalo, sada to vreme koje čekam nazivam humanim vremenom koje mi
bezdušna mašina daruje. Pa podignem pogled, pa primetim ljubičastu
šminku na mladoj koleginici, pa primetim obline na čistačici, pa ...
Pokušavam da zamislim problem koji te je naveo na memo, ali ne mogu. Ako
ti nije mučno, opiši tu situaciju. Brate Vili, niko te bolje od mene
neće razumeti, jer sam svu svoju sudbinu predao u ruke Clipperu baš zbog
njegovog memo koncepta.
dPaun
clipper.906pjankovic,
-> #902, dpaun
O problemu pregleda tekstualnih fajlova vecih od 64 Kb:
Svojevremeno je NBatocanin u "Racunarima" objavio asemblerski program
kojim se mogu listati datoteke proizvoljne duzine, ali ne samo to. Direktno iz
listanja se moze fajl odstampati, moze se izabrati kvalitet stampe i tako
dalje. Medjutim poslije nekoliko uzaludnih pokusaja da asemblerski listing
prilagodim svojim potrebama (naizgled je sve dobro radilo, ali je poslije
izvjesnog vremena pocinjao da se "brlja" ekran) i posto me je mrzjelo
da se dalje bakcem sa asemblerom, napisao sam to isto u Clipperu. Naravno,
NE sve u Clipperu. Funkciju za ispis na ekran sam napravio u C-u (direktno
u video memoriju). E sad, znam sta vas najvise interesuje: Koliko je to brzo
(ili sporo). E pa, brze nego sto sam ocekivao. Na samu brzinu skrolovanja
nemam zamjerki: sasvim je zadovoljavajuca. Jedino se malo duze ceka na prenos
bloka u memoriju ( u memoriju ucitavam samo odredjen broj linija). Na primjer,
da bi se ucitalo 1000 linija potrebno je oko 2 sekunde. Sigurno da su moguca
ubrzanja ali me je mrzjelo da tome posvetim vise vremena.
I u biblioteci NFLib (ima na Sezamu) postoji funkcija za pregled
fajlova neogranicene duzine. Medjutim, ona izgleda nije bas cisto napisana.
Cini mi se da nesto brlja po memoriji jer se poslije dva-tri njena poziva
u ostalom dijelu pisanom u cistom Clipperu javljaju cudne greske tipa
" varijabla nije definisana".
clipper.907toma,
Uz poruku zakačen spisak fajlova sa Rhinoceros BBS-a koji imaju
neke veze sa Clipper-om. Pošto sam video dosta lepih stvari,
zamolio bih organe da organizuju neko eventualno prebacivanje
istih u CLIPPER direktorijum SEZAM-a.
Pozdrav from Toma.
za_clip.zipclipper.909snemcev,
Pazi ovo:
Deklarišem ja danas neke promenljive za jednu proceduru,
i koristeći modućnost Clipper-a 5.01 da odjednom inicijalizujem
više promenjljivih pišem ovo:
...
PRIVATE bla_bla := tra_la_la := tandara_broc := šć
...
i nizove popunjavam kasnije iz programa u stilu
...
AADD( bla_bla, 'prvi niz' )
AADD( tra_la_la, 'drugi niz' )
AADD( tandara_broc, 'treci niz' )
...
i neće da radi ono što treba, pa to ti je. Elem, pokrenem ja
isterivač duhova, pardon bubica i na jedno ?LEN( bla_bla ) posle
izvršenja ove tri instrukcije on odgovara 3! Ja se ne dam
zbuniti, i pitam ?LEN( tra_la_la ), a on: 3! E sad već počinjem
da brinem. Zatražim ja ?bla_blaŠ1Ć, a on kaže "prvi niz", kao
što i treba da bude. Iznenađenje tek sad dolazi: ?bla_blaŠ2Ć
daje "drugi niz", a ?bla_blaŠ3Ć "treci niz".
Jel to zdravo imati tri niza koji su u stvari jedan niz?
Očigledno da im Clipper prilikom inicijalizacije dodeljuje isti
memorijski prostor. Još jednom, u malo izmenjenom obliku
hamletovsko pitanje 'Bug or feature'? Ili to ipak piše negde u
dokumentaciji kojoj nisam posvetio baš previše pažnje?
snemcev
P.S. Sorry zbog uglastih zagrada, koristim YUSCII standard.
clipper.910nbatocanin,
-> #892, janko> Održavanje funkcija je relativno lako -- ako si je
> ispravio, a koristiš je u više programa, bez problema ćeš
> je nadalje koristiti u svima. Ali ako menjaš ove
> 'translacije,' šta onda?
E, pa tu je kvaka: ovako je još bolje! Gledaj to malo i sa druge
strane: ta nova naredba može biti dragocen tampon između funkcije i
programa. Evo na šta mislim: ako promeniš poziv funkcije (parametre),
moraćeš da menjaš to po svim programima. Ako si koristio
pretprocesor, možeš samo dodati nove opcije koje pokrivaju nove
parametre, a može se koristiti i stari oblik! Tako si samo izmenom
definicije naredbe uradio ceo posao. Ovo je odlična stvar.
> Drugi problem je još fundamentalniji -- translacije treba
> da ti obezbede da ako ONO U ŠTA SE TRANSLIRA tvoj program
> budu promenili, ti i dalje možeš da ga prevodiš bez brige.
> Ako počneš i sam da daješ 'niske udarce,' programi ti još
> više postaju zavisni od verzije kompajlera.
Da, ali ako pogledaš u šta se translira (bazični Clipper), to nema
šanse a i potrebe da se promeni. Osnovne konstrukcije i pozivi
funkcija. Kritični su jedino pozivi funkcija, a tu je kompatibilnost
strašno lako sačuvati: ne diraš staru funkciju, već je označiš kao
zastarelu. Uostalom, Clipper 5.0 ima mnogo prostiji osnovni jezik od
s'87.
> Da li time što uvodiš translate trikove i strukturno slabiš program
> (u smislu da ti je više dozvoljeno nego pre, a ne proverava se u toku
> prevođenja?)
Tačno je da se tako zaista malo slabi analiza, jer se
pretprocesiranjem gube informacije o polaznoj naredbi, ali kao
posledicu tu vidim jedino slabije poruke o greškama. Kada bi se u
definisanje novih naredbi uključila i obrada grešaka, sve bi se mnogo
iskomplikovalo. Ono što sam ja radio (ne previše), veoma lepo radi i
ne pravi probleme. Nemam ideju gde bi moglo biti problema, jer je
princip po kome radi #translate veoma prost.
> Šta to znači 'kodni blokovi bi mogli stvarno da se
> prevode?' Zar se sada ne prevode? U čemu je onda trik?
Koliko je meni poznato, u interni Clipper p-kod. Ako je pitanje zašto,
mislim da je zbog konstrukcija tipa { || &expr } i pristupanja
poljima baze. Kako da generiš kod kad se referišeš na nešto za šta ne
znaš ni šta je za vreme prevođenja?
> Na kraju se ipak došlo do neke 'razumne sredine.' Ta razumna sredina
> je da jezik treba da ima što manje ključnih reči, što uniformniju
> sintaksu, dobro rešen 'scope' promenljivih, i kontrolu tipa
> prosleđenih parametara...
Pazi, Clipper nije klasičan programski jezik: ko je video jezik sa
*naredbom* za tabelarni pregled podataka? Ovo je specijalan jezik, a
u njemu je štos dodati bezbolno more funkcija, a čini mi se da je za
to uvođenje ključnih reči najbolji način.
> A šta meni najviše smeta kod Klipera? Po meni, baš to što
> nije dovoljno kompajler -- a mogao je da bude...
Ja bih najviše voleo da naprave mogućnost nekih "brzih" delova
programa. Na primer, označiš markerima "brz" deo programa, tu smeš da
koristiš redukovani jezik (bez makroa i sl. gluposti), ali se
generiše pravi prevod: time bi se potpuno izbegla potreba za stalnim
skokovima u C i u ASM.
> Da, umesto izmišljanja preprocesora (kojim su,
> opet, zakopali sebe time što za taj jezik nikada neće moći
> da se napravi čvrsta sintaksna provera -- pričao sam ti da
> sam želeo čak i sam to da realizujem -- sada je to
> nemoguće...)
Ne bi rekao. BASIC Clipper nema pojma ni o kakvom pretprocesoru i
ništa lakše nego uz svaku promenljivu čuvati i tip i kad se napiše X
:= "A", a X je broj, on da se buni. Ali, pravi problem su tu run-time
operacije: makroi i podaci u bazi. Ko će ovde da kontroliše tip za
vreme prevođenja:
&cTmp := &cStr
a kad bi se uvela kontrola za vreme rada to bi tek bila katastrofa od
sporosti!
> 'Pravi' bi bio jedan čvrst jezik, primeren kompajliranju,
> koji bi radio SVE MOGUĆE provere u toku kompajliranja, a
> 'kompatibiliti' bi služio onima koji ne žele da iskoriste
> čitave procedure pisane u starom maniru (ali, šta će im
> onda novi prevodilac O:) ?)
Ja i dalje mislim da je 90% Clipper koda dovoljno brzo. Kad bi se
dodala mogućnost onih "brzih" delova, bilo bi savršeno.
> Sad sam se setio -- za te stare aplikacije najbolnija tačka bila je
> nemogućnost svapovanja samih sebe pre startovanja eksternog programa.
Ima dosta tih programčića od nekoliko K koji svopuju sve na disk ili u EMS,
pa startuješ šta oćeš. Mislim da je glupo kresati performanse da bi
se ovo postiglo u samom jeziku tako što se smanji zauzeće memorije.
Ono, mogli bi da ugrade neku takvu funkciju u CLIPPER.LIB.
> Donela je virtuelnu memoriju. Ali ako je stara aplikacija radila bez
> virtuelne memorije, šta će mi onda virtuelna? Sve u svemu, što bi
> neko staru aplikaciju uopšte prevodio novim prevodiocem?
Zato što imaš novi kvalitet. Pre je stalno bila frka ako upotrebiš
veliki niz ili string - Out of memory! A sada, možeš bez problema da
kreiraš "memorijske datoteke" - nizove: ako ima memorije biće vrlo
brzo, ako nema radiće sa diskom i biće kao da je sa datotekama.
> Ovako, sve je, ipak, ostalo nekako nedovoljno... 5.0 je
> nedovoljno interpreter
Zašto? Ja i ovo malo interpretatorskih mogućnosti slabo koristim.
> ali, što je još nezgodnije, i nedovoljno kompajler...
To jeste.
> A počelo je od tabela koje je trebalo da ti sračunaju relativno
> proste stvari...
Jeste. Treba samo videti evoluciju programskih paketa. Prvo naprave
nešto (v1.0). Onda naprave to upotrebljivo (v1.1 ;). Zatim ugrade
zahteve korisnika (v2.0), upotrebljivo (v2.1 ;), itd. Na kraju
dobijaju proizvod sa brdom funkcija, a da time *još* nisu zadovoljili
ni blizu sve korisnike. I onda posežu za spasonosnom (?) idejom -
programski jezik kojim se to čudo programira. I onda kažu: "Jeste,
toga nema, ali uz pomoć makro-jezika...". Tako danas i najgluplji
proizvodi imaju svoj makro jezik. Da li se time definitivno dokazuje
da je programiranje jedini efikasan način za rešavanje problema?
> E sad, možda je moje očekivanje da Kliper uđe u onu drugu
> kategoriju bila nerealna?
Ni meni nije jasno zašto nisu probali da prebace Clipper na neki
drugi OS do sada. Mislim da bi to bilo dosta jednostavno.
> Kad smo već kod jezika, da li se slažeš da bolje zvuči
> 'blokovi koda' nego 'kodni blokovi?'
Nisam neki stručnjak, pa ne znam šta da kažem. Ja sam "code blocks"
prvo preveo kao "kod blokovi", što je J. Regasek u mom tekstu
prepravio u "kodni blokovi", to mi se učinilo dobro i sad to
koristim. Kad pričam ja kažem "kod blokovi".
clipper.911neman,
-> #907, toma> Pošto sam video dosta lepih
> stvari, zamolio bih organe da organizuju neko eventualno
> prebacivanje
Pa da ti malo smanjim doživljaj. I ja sam tako mislio dok nisam počeo da
ih skidam. Veeelika većina stvari je stara 1987-1990, neke su još za Clipper86.
Neke su SHAREWARE pa su u aplikaciji neupotrebljive (ispisuju poruke o tome).
Neke postoje na SEZAMU. Ima par interesantnih funkcija, ali su one
razbacane po raznim datotekama, neke su više puta definisane.
Uglavnom su pokrivene NANFOR-om.
Ako ste zainteresovani, spremiću pregled sadržaja datoteka.
clipper.912janko,
-> #910, nbatocaninNe mogu a da na početku ne izrazim veliko zadovoljstvo što se
diskusija jako lepo (po meni) razvila...
> Da, ali ako pogledaš u šta se translira (bazični Clipper),
> to nema šanse a i potrebe da se promeni. Osnovne
> konstrukcije i pozivi funkcija. Kritični su jedino pozivi
> funkcija, a tu je kompatibilnost strašno lako sačuvati: ne
> diraš staru funkciju, već je označiš kao zastarelu.
> Uostalom, Clipper 5.0 ima mnogo prostiji osnovni jezik od
> s'87.
Pod pojmom bazični Kliper smatraš direktne pozive funkcija (tj.
drugu stranu translejt direktiva)? Da li si negde pročitao
garanciju Nantuketa da jezik ni na tom nivou neće da se
promeni?
Nisam razumeo narednu rečenicu. Kako se to 'ne dira stara
funkcija nego označi kao zastarela?'
>> Šta to znači 'kodni blokovi bi mogli stvarno da se
>> prevode?' Zar se sada ne prevode? U čemu je onda trik?
>
> Koliko je meni poznato, u interni Clipper p-kod. Ako je
> pitanje zašto,
Nije mi ni palo na pamet! Hvala na objašnjenju.
> Ja bih najviše voleo da naprave mogućnost nekih "brzih"
> delova programa. Na primer, označiš markerima "brz" deo
> programa, tu smeš da koristiš redukovani jezik (bez makroa
> i sl. gluposti), ali se generiše pravi prevod: time bi se
> potpuno izbegla potreba za stalnim skokovima u C i u ASM.
Eto, tu se slažemo. Proširi 'brze' delove na CEO program i eto
čvrstog programskog jezika. Samo, onda ne otpadaju samo
makroi, već još štošta... Ono gde bi sigurno trebalo ostaviti
neku interaktivnost su upiti -- na neki način bi i dalje bilo
fundamentalno da mogu da se formiraju u toku izvršavanja.
>> 'kompatibiliti' bi služio onima koji ne žele da iskoriste
>> čitave procedure pisane u starom maniru (ali, šta će im
Ovde sam ja pogrešio -- ono 'ne žele' je trebalo, valjda, da
bude 'žele?'
>> Ovako, sve je, ipak, ostalo nekako nedovoljno... 5.0 je
>> nedovoljno interpreter
>
> Zašto? Ja i ovo malo interpretatorskih mogućnosti slabo
> koristim.
Možda zato što si tzv. 'ful tajm Kliper programer?' Ili se ja
nisam dobro izrazio na temu interpretiranja? Jednostavnost
interaktivnosti je mnogo lepa stvar -- da li koristiš diBejz UZ
Kliper? Kako 'sređuješ' stvari ručno, 'iz glave' kreiraš baze i
tako to? Sve Kliperom ili...?
>> Donela je virtuelnu memoriju. Ali ako je stara aplikacija
>> radila bez virtuelne memorije, šta će mi onda virtuelna?
>> Sve u svemu, što bi neko staru aplikaciju uopšte prevodio
> novim prevodiocem?
>
> Zato što imaš novi kvalitet. Pre je stalno bila frka ako
> upotrebiš veliki niz ili string - Out of memory! A sada,
> možeš bez problema da kreiraš "memorijske datoteke" -
> nizove: ako ima memorije biće vrlo brzo, ako nema radiće
> sa diskom i biće kao da je sa datotekama.
Koliko je virtuelna ta virtuelna memorija, usput? Da li si
primetio neka ograničenja koja su ti se pojavila u praksi? Za
kod mi je jasno da ga može da 'preklapa' koliko hoće... ali
kako se ponaša baš sa varijablama? Gde su kod njih granice?
Da li je, generalno, njih manje bolno koristi umesto manjih
datoteka?
clipper.913kanda,
-> #902, dpaun>> proba nešto veće, on to neće i u DOS izleće. Takođe veći fajl ne da
>> ni da se pregleda. Tada će, doduše, učitati deo fajla, ali u praksi
>> ima situacija kada je neophodno da iz našeg Clp programa listamo txt
>> fajlove neograničene veličine. Ovaj slučaj detaljno razmatra, uz
>> listinge primera, Rick Spence u knjizi "Clipper 5, vodič za
>> programere", u delu "Prikazivanje velikih datoteka ili niza znakova".
Pa vidi DPaune, ako ti treba samo pregled datoteke, recimo pregled
izvestaja pre stampanja, napravi TBrowse, i nabudzi mu GoTopBlock,
SkipBlock i GoBottomBlock da se pomeraju po linijama teksta u
datoteci, i definisi jednu kolonu da prikazuje sadrzaj aktuelne linije. Stvar
radi prihvatljivo brzo i kad se sve napise u kliperu.
clipper.914snemcev,
-> #8, dejanr>> Program se kod mene nije hteo kompajlirati na clipper 87.
>> Ispravio sam par sitnica i dodao pred-program za testiranje i
>> još preveo na standard "Računari"... I evo ga!
Probao sam i dobio malo čudne rezultate. Recimo:
11000 - jedanaesthiljad ( gde je a? )
12000 - dvanaesthiljade ( treba hiljada a ne hiljade )
13000 - trinaesthiljade ( isto )
14000 - četrnaesthiljade ( isto )
15000 - petnaesthiljada ( OK )
11000000 - jedanaestmilion ( gde se dede a? )
Objašnjenje?
snemcev
clipper.915snemcev,
-> #904, dpaun>> Ja gledao, ništa ne video,
>> što video - nisam razumeo,
>> pa sam onda čarne oči kleo -
>> čarne oči, nek vam vid iskoči
Ovo treba u VICEVI:najbolji! Do suza sam se ismejao!
snemcev
clipper.916pjankovic,
-> #909, snemcev> Jel to zdravo imati tri niza koji su u stvari jedan niz?
> Ocigledno da im Clipper prilikom inicijalizacije dodeljuje
> isti memorijski prostor. Jos jednom, u malo izmenjenom
> obliku hamletovsko pitanje 'Bug or feature'? Ili to ipak
> pise negde u dokumentaciji kojoj nisam posvetio bas
> previse paznje?
Tacno je da ova tri niza zauzimaju isti memorijski prostor. Svaka
izmjena u jednom automatski mijenja i druge. Prema tome : "It's a feature!".
clipper.917ciki,
Procitah malopre neke malo starije porukice i videh da je aktuelna
rasprava u semi oko dizanja YU slova u toku unosa GET/READ.
Ok imamo source u asm-u i to radi OK.
Aj sada da probamo ko sto rece nb da malo caprkamo po getsys-u,kada
ono
problema i problema.
Sva sreca to sam pokusavao odavno da uradim pa vam prenosim svoja
isku-
stva.
GET klasa ima mnogo svojih metoda(startujte samo NG pa vidite),od
kojih
je za nas narocito zanimljiva picture, jer get:picture daje picture
niz koji je korisnik definisao.(Ovo svi znamo ali ipak)
Naizgled evo naseg resenja ali to moze da upali u 25-40% slucajeva
ako se bas ne bacimo u analizu GET klase.
Ako je picture niz "č!" to je Ok jer dovoljno je to ispitati i
ubaciti
u getsys nesto kao
.....................
if ( Set(_SET_INSERT) )
if (get:Picture == "č!")
do case
case cKey == "š"
get:Insert("Š")
.....................
(Moze krace ali radi slikovitosti)
Ali zamislite picture u semi "99!!!X!999" (Ima sadista pa moras na
sve racunati.).
Sta sada ostaje.Pronaci uz pomoc neke metode get klase trenutni
polozaj
kursora unutar picture stringa pa ga usporediti sa ! itd...
Puno srece
onome
ko ovo radi.
Pozdrav Kikile!
P.S. Ako neko uradi neka ga UL.
clipper.918nbatocanin,
-> #905, dpaun> Dužina takvog polja, koliko se sećam, ne može da bude veća od 255
> karaktera
Može do 64K.
> Bitnije od ovoga jeste sam koncept: DBT će se povećavati samo kada se
> nešto unese u memo polje baze, a ne uvek kada se sa APPEND BLANK doda
> novi slog.
Na žalost, nije tako :((. Probajte ovo:
FOR i := 1 TO 1000
REPLACE Memo WITH Space(600)
NEXT
> Nedostatke ne vidim u ovom kancerogenom konceptu DBT-a, već u
> siromašnim i oskudnim opcijama koje su ugrađene u MemoEdit().
Ja suprotno: ništa mi se ne sviđa rad MEMO sistema, ni MemoEdit nije
nešto, ali se da dosta učiniti. Biće tekst o tome u narednim
"Računarima".
Trebalo bi nabaviti neku od zamenu za memo polja, ima ih prilično.
clipper.919nbatocanin,
-> #904, dpaunNećete verovati koliko je prosto: treba samo dodati jednu naredbu u
GETSYS.PRG (zbog orijentacije sam dodao i okolni kod):
...
// --- Ovo je dodato
IF "@!" $ get:picture ; cKey := YUpper(cKey) ; END IF
// --- Ovo je dodato
if ( Set(_SET_INSERT) )
get:Insert(cKey)
else
get:Overstrike(cKey)
end
...
> A još ako bi to zakačio ovde, znao bi o tebi i Vita šumar iz
> Ravne Reke, i moj komšija Vlasta Bačilo, s kojim koljem
> drva u šumi, i njegova žena Vilarija, i ...
Držim te za reč :))
clipper.920nbatocanin,
-> #909, snemcev> Ili to ipak piše negde u dokumentaciji kojoj nisam posvetio baš
> previše pažnje?
Piše, i tako je. Ponekad je i korisno.
clipper.921ciki,
Ho!
Na pocetku da kazem da pod metodama podrazumevam vidljive
promenljive instanci!!
Opet ja, ali samo sada sam uradio da se tokom pisanja dizu nasa
slova,
caprkajuci po getsys.prg-u. Ako ima zaintresovanih mogu priloziti i
listing sa sve izmenama(iako je to zabranjeno (zar ne?)).
Za one koji hoce i dalje da se muce evo pomoci.
Primenjujte metodu get:Pos koja daje trenutno mesto get bafera, pa ga
vezite za picture,tj. na primer:
CIKI____
ž --> sada je get:pos daje 5(cudo jel da?)
E sada ako imas picture oblika "!!!!!!!!" a ti jedno
┌────────────────────────────────────────┐
│ if substr(get:picture,get:pos,1) == "!"│
└────────────────────────────────────────┘
primenis i onda jos malo izmenis GetApllyKey() da bi mala slova za-
menio velikima...
Normalno ako ti je picture izraz "č!", onda izostavi ono uokvireno,
vec odmah predji na dizanje slova.
Koliko muke, a kako prosta stvar.
Pozdrav Ciki!
P.S. Moram izraziti zahvalnost I dpaun-u,pa nbatocaninu na ideji,i
muci
da mi podobno objasni svoj view program.
clipper.922ciki,
Eh sada procitah odgovor nbatocanina(krace za 20 linija nego moje,
ali se oslanja na assembler.
Pozdrav Ciki!