Newsgroup: it.comp.os.dibattiti
Titolo: SIGNORI CI SIAMO: RILASCIATO NANODESKTOP 0.1alpha SOURCE CODE

c.d.o.
Documentazione, manuale di installazione, sorgenti,
librerie, librerie di supporto, compilatore, licenze
ecc. ecc. ecc. sono disponibili qui:
http://visilab.unime.it/~filippo/Nanodesktop_PSP_PSPE/Downloads/Distribution_0_1_Alpha/Nanodesktop_Distribution_0_1_PSP.zip
Ricordatevi che si tratta solo di un alpha. Ci sono molti
problemi tecnici da risolvere.
Tra qualche ora mi faccio risentire....
Saluti
Pegasus

 c.d.o.
cazzarola, se magari separassi il tuo codice dal toolkit opensource per
psp e dalle librerie non tue.... con 60 MB di roba compressa non fai
bella figura per la mole, anzi.... Se poi ci togli i binari e i
precompilati sembri quasi uno sviluppatore normale. A che mi serve
scaricare gli .exe che non ho nemmeno windows?
giusto per darti un po' di suggerimenti
Passa agli autotools, non sarà mica il modo di distribuire i sorgenti, no?
typedef long long int ndint64;
toglielo o quantomeno cambialo in typedef int64 nsint64 almeno
all'inizio. Pspdev ti fornisce stdint.h, quindi se il compilatore
supporta  l'ansi C99 quel typedef rischia solo di fare casino. Ora, non
è una sega mentale se l'ANSI ha deciso di togliere il compito di
definire i tipi di dato di lunghezza fissa allo sviluppatore e di darlo
al compilatore. Anche perché, in questo modo, se cambi compilatore non
rischi di fare casino.
Altra cosa: perché hai duplicato PSP/SDK/PspDev/psp/include/ctype.h in
PSP/SDK/NanoCore/NanoC/src/ctype.h . Comunque riconosco volentieri che
quello che avvei scritto sei mesi fa sul compilatore è vero: fa proprio
schifo ed è gravemente incompleto.
Visto che hai /tmp/PSP/SDK/NanoCore/NanoC/src/string.h che senso hanno
le funzioni che senso hanno funzioni come
char ndStrCpy (char *StringaDest, char *StringaSrc, unsigned char Limit,
char MakeMagn);
char ndStrCpyBounded (char *StringaDest, char *StringaSrc, unsigned char
LimitX1, unsigned char LimitX2, char MakeMagn);
?
Che senso hanno tutte le funzioni ndFS_*? implementa le funzioni fread
ed fwrite.
Comunque lasciando le cose stilistiche a parte, andiamo al piatto forte
tenuto per l'occasione alla fine:
Il makefile PSP/SDK/Nanodesktop/src/makefile.gcc è quantomeno bizzarro,
considerando che non compila i sorgenti che hai postato. Ohibò!

 considerando che non compila i sorgenti che hai postato. Ohibņ!
Come no. Compila.
Installa Windows, le Cygwin e segui quanto scritto nel manuale. Se non 
compila
vediamo come risolvere, ma da me  qui compila.
Ciao
Pegasus

 Come no. Compila.
no che non compila, non puņ compilare. Nel makefile compili solo un file
e linki ad una libreria che dovrebbe essere generata dai sorgenti, ma il
target della libreria non c'č.

 target della libreria non c'и.
Sм che compila. C'и un bel:
all: $(OUTLIB_PSPE_1) $(OUTLIB_PSPE_2) $(OUTLIB_PSP_1) $(OUTLIB_PSP_2)
e c'и per una ragione precisa.....

 Me la spiega questa, scusa?
volentieri. le strutture FILE nello standard ansi c servono proprio per
fare astrazione sull'apertura dei file indipendentemente dalle chiamate
a sistema da fare. Altrimenti perché fopen funziona allo stesso modo su
unix e su win?

 c.d.o.
A che si riferiva il countdown, allora?
bye G.L.
-- 
Renaissance, aka Gian Luca Sole
Per rispondere, togli nospam al contrario, e cambia nazione
"E' assolutamente evidente che l'arte del cinema si ispira
alla vita, mentre la vita si ispira alla TV" - Woody Allen

 unix e su win?
Ed infatti funziona allo stesso identico modo anche nella NanoC (oddio,
proprio identico no, c'è qualche piccola differenza qua e la che non
poteva essere eliminata, ma in linea di massima direi che siamo lì al 99.9%
e ci avvicineremo sempre di più con il passare del tempo).
Se tu controlli il codice sorgente di ndDevIL per esempio (o di ndlibjpg, o
di ndlibpng), ti accorgerai che usiamo fopen, fclose ecc. ecc.
Ossia esattamente quello che si fa nel mondo PC.
Le routine HAL vengono usate nel codice di Nanodesktop, ma c'è da tenere
conto del fatto che sono dei semplici inline alle routine della NanoC che
sono standardizzate. Quindi, di fatto, è come se anche Nanodesktop usasse
fopen, fclose, ecc. ecc.
Ciò che non è standardizzato, è la routine per accedere alle directory 
entry.
opendir, readdir, closedir, non esistono nel mondo PSP (o meglio, si 
chiamano
in modo differente). La stessa struttura che gestisce le direntries è 
diversa.
Ed allora, ecco che l'HAL di Nanodesktop interviene e copre tutto. Quando
porterò Nanodesktop su Linux basterà cambiare quelle 3 routines
nell'HAL e wrapparle a quelle della libc unix standard.
P.S.
Sì, lo so, avrei potuto scrivermi delle routine opendir, readdir e closedir 
ed
integrarle nella NanoC, ma quando poi avrei dovuto portare Nanodesktop
su n-Gage si sarebbe ripetuta la stessa identica storia: quindi, o mi scrivo 
un
piccolo HAL per ogni piattaforma che mi wrappa le funzioni in modo corretto,
o mi metto a cambiare le libc di tutte le piattaforme per farle venire 
uguali a
quella Unix, cosa che sinceramente mi sembra un pò insostenibile alla 
lunga....

 problemi tecnici da risolvere.
Ok. Prima di tutto, cambia Wellcome in Welcome, e` meglio (tua 
homepage). Poi non te la prendere per i commenti che faro` se li reputi 
offensivi. Uomo avvisato.
- Elimina i compilati, lascia i sorgenti.
- Metti un readme con la descrizione delle directory
- Metti chiaramente COSA e` vostro e cosa NO: ndDevIL contiene zlib che 
NON e` vostra. Le librerie vanno evidenziate, tipo che ne so, nella 
root una directory tipo ``3rdparty/''. Pare che vi siate riscritti 
tutto voi (zlib, libjpeg, libpng, libtiff...), anche se ci metti un DOC 
che **nessuno** leggera`.
- Di` a sto Dario, che macro del genere:
#define eround(v,x) (((int)((v/x)*10)%10) > 0 ? (v/x) : (v/x)+1)
#define eround16(v) eround(v,16)
le scrive un idiota. Compito per casa: cosa succede se fai:
eround16(43 + 5);
- Siete consci che usare il commento // (valido solo C99) sputtana la 
maggioranza dei compilatori che tanto di bocca buona (i.e. accettano 
codice NON STANDARD)? Il gcc NON e` un compilatore C se non ci metti 
ALMENO -ansi. E levate i nested comments. Leggi e posta di piu` su 
comp.lang.c, ti aiuterebbe.
Sul codice vado a braccio, vedo un sacco di immondizia.
- Voi usate i tipi long long, che non sono proprio ovunque standard. 
Compito a casa stabilire dove esiste e dove no (come i long double).
- Usate nomi tipo _nome o __nome che *NON* vanno usati.
- Usare typedef per stabilire quanti byte e` lungo un intero puo` 
essere molto pericoloso. L'hai compilato su, ad esempio, un athlon 64? 
Occhio!!
- Non usate gli inline proptotypes, non servono a nulla.
- Un header memory.h che fa solo l'include di string.h e` ridicolo.
- I commenti in UTF-8 in italiano con lettere accentate facilitano la 
rimozione del sw da parte di qualunque non-italiano. Buttateli al cesso.
- Le inline functions (inline void f(void) {...}) sono un suggerimento 
che non serve a nulla. Una volta testate fai un define se la velocita` 
conta.
- Perlaputtana, ma cosa cazzo e` st'abominio ndHighGUI.c (e altrove)???????
#include <nanodesktop.h>
#include <cxcore.h>
#include <ndHGUI_Variables.c>
#include <ndHGUI_cvInitSystem.c>
#include <ndHGUI_cvErrors.c>
#include <ndHGUI_cvSetParamNextWnd.c>
#include <ndHGUI_cvWindows.c>
#include <ndHGUI_cvShowImage.c>
#include <ndHGUI_cvLoadSave.c>
#include <ndHGUI_Utils.c>
^^^^^^^^^^^^^^^^^^^^^^^^^
- Vedo molti e troppi buffer over/underflow, usate [255] con cautela, 
poiche` non controllate quasi mai quanto andrete a copiarci dentro. 
Occhio.
- Fate makefile come cristo comanda vi prego. Potete evitare gli 
autotools che complicano la vita se siete bravi.
- Il codice NON e` assolutamente standard. Puo` non compilare e ha una 
marea di undefined behavior.
In conclusione, buoni sforzi, codice amatoriale. Continuate comunque a 
testa alta, fregatevene degli altri.
Resto sempre dell'opinione che il prof. e` matto perche` e` un progetto 
senza futuro, e imo e` inutile. Ma so come vanno le cose 
all'universita`, quindi non mi sorprendo.
-- 
Sensei <senseiwa@Apple's mail>
Research (n.): a discovery already published by a chinese guy one month
               before you, copying a russian who did it in the 60s.


Grazie del consiglio.
Ciao
Pegasus

 #include <ndHGUI_Variables.c>
Beh... Lo standard non dice niente a proposito di include di file
di codice (AFAIK). :-D
C:\>iao Angelo
-- 
Posted via Mailgate.ORG Server - 
http://www.Mailgate.ORG

 Componente Nanodesktop HighGUI.
Dimmi una cosa... Hai mai visto qualcuno che non si possa definire
programmatore della domenica includere file di codice? Cosa cazzo li
hanno inventati a fare i file di include?



Giusto. E, tanto per sapere, dove avrei incluso i files di codice?
Per inciso, nanodesktop.c e ndhighgui.c sono solo files .c che
includono altri files .c nell'ambito della sola compilazione della
libreria: in questo modo, quando il compilatore compila la
libreria, è come se vedesse un solo file sorgente con le
routines.
Le applicazioni, invece, hanno il loro "include <nanodesktop.h>"
che include solo i prototipi delle funzioni.

 routines.
Paura che si spaventi se vede piu' di un file?



In base a cosa non si sa..... boh....
Tu hai un file .c che contiene il codice sorgente di una libreria. Solo che
ad un certo punto ti accorgi che è troppo grande e quindi inizi a spostare
(per semplice comodità tua), il codice in vari files a seconda della 
funzione.
Ma, siccome vuoi mantenere tutto su un unico scope, ti tieni il file .c
principale (che è quello che il compilatore compilerà), che si limita
a richiamare i file x1.c, x2.c, x3.c, x4.c ecc. ecc. ecc.
Quando psp-gcc andrà a compilare nanodesktop.c, prima includerà
x1.c, poi x2.c, poi x3.c ecc. ecc. ecc.
Ed alla fine avremo la nostra libreria statica. Non si capisce sinceramente
dove sia lo scandalo.
Le applicazioni hanno il loro nanodesktop.h da includere che contiene solo
ed esclusivamente i prototipi delle funzioni pubbliche e poco altro di più.
Ciao
Pegasus

 dove sia lo scandalo.
Nessuno scandalo... Come non lo sono i Programmatori della
Domenica: in fondo tutta la nostra societa' si basa sulla
produzione di immondizia.


 produzione di immondizia.
Questa e' una perla, la posso usare per la sig?

 lunga....
anche qua a dire il vero fai un po' confusione. Fare il listing di una
directory и ad un livello concettuale superiore di aprire un file.
Quindi per fare le cose fatte bene dovresti implementare stdio.h e poi
fare che la gestione delle directory dipenda da stdio e sia customizzata
 per il varie piattaforme.
In conclusione, il lavoro c'и perт и tanto amatoriale e secondo me
costerebbe poca fatica fare il salto di qualitа.

 In base a cosa non si sa..... boh....
puoi avere simboli duplicati in fase di linking.

    $(CC) $(FLAGS) tuttoIlProgramma.c
giusto per sparare sulla croce rossa: $(C), manco il nome della
variabile d'ambiente segue un minimo di convenzioni....

 di codice (AFAIK). :-D
angelo, quanti programmi seri hai visto che lo fanno?

 costerebbe poca fatica fare il salto di qualitą.
Se avessi qualcuno che mi aiuta....
Ciao
Pegasus

 ha scritto nel messaggio 
news:4581a57f$1...@newsgate.x-privat.org...

Quello lo ha scritto Angelo. Io nei makefile.gcc il $(C) ce l'ho....

 Se avessi qualcuno che mi aiuta....
senti un po', esiste una toolchain precompilata per linux?

 diffusamente.
Io son sicuro che e' std99, mi son fottuto la testa ?
Perche' non va bene usarlo con lo switch per l'ansi 99 ?
  ngw
 
-- 
Last Played: Artificial Life - Energy - Operation Iv

 senti un po', esiste una toolchain precompilata per linux?
No, ancora no, anche perchč Nanodesktop ha bisogno di Dev-C++
e di PSPE per funzionare "realmente" (nel senso che per lo sviluppo,
serve l'IDE e l'emulatore). Stavo pensando ad un toolchain per Linux
+ Anjouta + WINE PSPE.EXE, ma per ora non posso lavorarci
perchč il 22 ho un esame (era per questo che avevo fatto il countdown).
Perň domani devo sentire (o vedere non so), il professore e parleremo
anche di questa cosa.
Perchč me lo chiedi?


appunto! la variabile usata da tutti è $(CC) ;-)
ma questo un l'aspetto minimale.

 Perchè me lo chiedi?
mi piacerebbe darti una mano a sistemare il packaging solo che non è che
 ho molto tempo prima di febbraio.... Però per farlo mi serve una
toolchain, altrimenti come collaudo i makefile?
Secondo me tu sei prevenuto: molti dei commenti che ti sono arrivati
sono più costruttivi, solo che tu l'hai buttata troppo sul personale
(oddio, un po' ti sta pure bene perché per 5 mesi venivi a fighegiare a
vuoto sul ng :-) )

 angelo, quanti programmi seri hai visto che lo fanno?
Includendo Pegasus... Direi 1. (Sbaglio, o a fine frase c'era una
faccina?) ;-)
C:\>iao Angelo

 Perche' non va bene usarlo con lo switch per l'ansi 99 ?
E questo dove lo avrei detto?
C:\>iao Angelo

 Quello lo ha scritto Angelo. Io nei makefile.gcc il $(C) ce l'ho....
Guarda meglio quello che ha scritto Angelo, per tua comodita' ti dico
che e' la seconda delle righe quotate.
C:\>iao Angelo

 Grazie del consiglio.
Questo ti aiuta: 
http://c-faq.com/
 --- usa gli standard!


 di codice (AFAIK). :-D
Bho, quando l'ho sotto mano lo vedro` :)


 Campana.
Confermo:
sensei:x$ cat a.c
#include <stdio.h>
#if 0
inline int freak(int i) { return i % 2; }
#else
#define freak(i) ((i) % 2)
#endif
// Hehehe
int main(void)
{
  printf("%d\n", freak(5-8/4));
  return 0;
}
sensei:x$ gcc -Wall -pedantic -ansi a.c
a.c:8: error: parse error before '/' token
sensei:x$ gcc -Wall -pedantic -ansi -std=c99 a.c
Anche se largamente usato, // e` rigettato da xlc, tanto per fare un nome.


 tanto per fare un nome.
Ne prendo atto, anche se xlc e' il primo compilatore di cui vengo
a conoscenza che non accetta quel tipo di commento.


 Componente "non so cosa e` un header". Ti rendi conto?
Ehm....
richiedo scusa di nuovo....
ma secondo voi, ndhighgui.h esiste perchè non avevo di meglio da
fare oppure ha una sua funzione?
Nella cartella di OpenCV/samples ci sono dei source code di demo
con le OpenCV.
Compito a casa: perchè iniziano con
#include <ndhighgui.h>
?
Saluti
Pegasus

 per la PSP in una cartella del fs di Linux, Linux me lo usa?
hmmm... nno, credo più semplicemente che se c'è una lib precompilata viene
linkata automaticamente nell'eseguibile finale, senza venire ricompilata,
qualsiasi sia la piattaforma di compilazione.
ho detto una cagata?
:P
ciao
-- 
NoWhereMan
-- NoWhereBlog: 
www.nowhereland.it
-- FlatPress: 
http://flatpress.nowhereland.it
 blog flat-file powered,
xhtml1.1strict compliant
-- deviantArt: 
http://nowhereland.deviantart.com

 
http://gcc.gnu.org/onlinedocs/gcc/Inline.html
sensei si riferisce sempre allo standard
giusto due esempi:
http://publib.boulder.ibm.com/infocenter/macxhelp/v6v81/index.jsp?topic=/com.ibm.vacpp6m.doc/language/ref/clrc07cplr243.htm
http://msdn2.microsoft.com/en-us/library/z8y1yy88.aspx
cerca "suggestion" all'interno della pagina; e, reference di c alla mano, è
scritto anche lì :)
ciao
ps: io non ti sto facendo le pulci, pegasus, volevo solo chiarire cosa ha
detto sensei ;)


 gcc rogna anche se non metti un "a capo" a fine file:
non più. io uso sempre -ansi -std=c99 e non rompe le balle per il caporiga.
comunque uso /* */ perché mi piace di più di // :-)

 Anche se largamente usato, // e` rigettato da xlc, tanto per fare un nome.
che compilatore è xlc ?

 #include <ndhighgui.h>
Il codice non e` scritto bene, accettalo. Ci sono errori anche gravi, 
cose fuori standard, idiozie.
Quando al WWDC hanno sottoposto il pane OpenAFS per OSX che scrissi, mi 
diedero una marea di commenti negativi. Sai che c'e`? Avevano 
ragione... io non sono un gran programmatore ObjectiveC, ne` un 
super-guru di HCI/GUI. Ho detto ``avete pienamente ragione''.
Fallo, e ti troverai meglio. Il C lo conosco sufficientemente per darti 
qualche consiglio. E ti consiglio di usare comp.lang.c per sottoporre 
dubbi, che li dentro c'e` gente mooooooolto brava (e non intendo ME 
stesso).




The IBM C Compiler. Di bocca fina direi...



Sensei, qui il problema non и questo. La questione и lievemente diversa.
Qui bisogna guardare la situazione nel suo complesso, e valutare i pro
ed i contro.
Scaricati OpenCV Intel per x86. Prova i demo.
Ora vai qui:
http://visilab.unime.it/~filippo/Nanodesktop_PSP_PSPE/Homebrew%20Demos/ndPSP_PSPE_Homebrew_Demos.htm
Tu stai vedendo delle applicazioni che girano normalmente su un PC, che 
adesso
girano su una PSP. Considera che stai parlando di una piattaforma che se ne 
и
sempre fregata felicemente di tutti gli standard conosciuti ed in via di 
realizzazione.
Niente kernel compatibile Unix, niente X-Window, niente GTK, niente libc di
fatto.....
Una piattaforma dove per fare un hello world si doveva fare quello che hai
visto l'altra volta.
Ora, grazie al lavoro del sottoscritto, vediamo delle funzioni standard del 
C che
funzionano, vediamo delle librerie che vengono portate in modo quasi 
dignitoso,
vediamo un ambiente a finestre che funziona, pensa un pт che si puт persino
usare il C standard per lavorare.
Ora il punto и: quel coso, che tu disprezzi tanto, non si и scritto da solo.
Io sono perfettamente consapevole dei limiti (non a caso и una 0.1alpha),
ma vorrei anche un piccolo riconoscimento, che guarda caso non c'и
stato (o meglio, l'ho avuto su altri NG specializzati che hanno apprezzato
il lavoro).
Quelle routines vanno scritte, vanno testate, se vengono fuori i bug me li 
devo
scovare io, e non ho un debugger che mi aiuti, i commenti li devo scrivere, 
il
sito internet lo devo fare sempre io.
Ora, se io avessi 10 sviluppatori sotto di me, potrei aumentare la qualitа 
del
software.
Ma a quel livello, allo stato attuale, in quelle condizioni di lavoro, con 
un
ambiente che non ti offre nulla (niente X-Window, niente GTK, nulla)
non si puт chiedere ad una sola persona  ciт che in pratica chiedi tu.
Non ha senso, и del tutto assurdo.
Quello che и possibile fare, attualmente, и prendere il compilatore che hai 
a
disposizione e seguire le regole sintattiche di *quel* compilatore. Che 
d'altra
parte и l'unico che si puт usare, ossia il psp-gcc.
Non si puт richiedere che uno non usi // perchи un oscuro compilatore AIX
non te lo supporta: prenditi il gcc per AIX, anche se ancora non si capisce
di preciso a cosa servirebbe un'operazione di quel genere, ma non venire a
lamentarti con me del fatto che tu vuoi compilare Nanodesktop sul
compilatore xlc che non supporta uno standard di 8 anni fa (e, tra 
parentesi,
operazione totalmente inutile perchи nessuno ti ha mai scritto da nessuna
parte che ciт ti viene garantito, ed anche perchи Nanodesktop non nasce
con quello scopo).
Se poi uno vuole migliorarlo, c'и scritto sopra open-source, e c'и una 
licenza che
apprezza molto i miglioramenti.....
Saluti
Pegasus

 software.
certo, ma forse anche perdere un po' meno tempo a postare post 
kilometrici sui ng e codare un po di più forse aiuterebbe.

 software.
qua sbagli . questo ti relegherà sempre tra i programmatori brocchi e/o
amatoriali. Fa una cosa in meno ma fa le cose meglio.


Se c'è un mondo intero che sa che il compilatore per PSP è il psp-gcc
ed io lo scrivo limpido in 3 posti, e mi si viene a contestare che non
l'ho scritto da nessuna parte (ovvio: la PSP esegue codice x86, no?)....
la colpa non ce l'ho certo io.....
Se poi il principio è che:
a) uno vuole scaricare un software progettato per girare su una
console e ricompilarselo su una macchina totalmente
incompatibile e con un compilatore incompatibile;
b) l'operazione è materialmente inutile e del tutto impossibile;
c) la colpa, quando ovviamente non funziona, è del programmatore.
non so più che cosa dirti a questo punto

 non so piů che cosa dirti a questo punto
te lo dico io: non hai capito un cazzo. rimani pure nella tua beata
ignoranza, sentiti pure ganzo ma resterai sempre un programmatore della
domenica.

 [...]
Vedi sopra. Ho fatto critiche COSTRUTTIVE mi pare.
Se non ti stanno bene, bon. Lascia stare, prendo atto che non vuoi che 
nessuno ti dica come aiutarti. Ti ho pure detto che ho accesso alle 
documentazioni ACM e IEEE perche` le pago di tasca mia (gia`, potenti 
mezzi universitari), se ti serviva qualcosa te l'avrei mandata.
Piu` disponibile di cosi`? Non so come.
Volevi la pacca sulle spalle? Non ti serve a nulla: serve che qualcuno 
ti dica DOVE sbagli. Perche` tutti sbagliano. Io in prima persona. E so 
che il developer non vede gli errori perche` legge il codice come e` 
nella sua testa e non come l'ha scritto.


 nessuno ti dica come aiutarti.
concordo.

 proprio come i salumieri.... :-)
Me la spieghi per favore? Non l'ho capita sul serio :)


 Me la spieghi per favore? Non l'ho capita sul serio :)
pardon, era una citazione di un mio altro post nel thread.
La gestione del pacchetto di pegasus è indubbiamente fatta per fare
volume, non a caso è stato lui a vantarsi di avere sviluppato 130 mega
di programmi).
Questo modo di fare ricorda tanto alcuni salumieri che ti tagliano più
affettati di quelli richiesti, e poi alla fine come pegasus dicono "che
faccio, lascio?"

 faccio, lascio?"
Pur di inventarti cavolate contro di me non sai piů che cosa dire:
e come mai, se l'obiettivo era quello, non redistribuisco
anche i binari delle applicazioni nello stesso package?
Eppure ogni nanodesktop apps mi prende 4 Mb buoni, quindi, stando
alla stupidaggine che dici, mi sarebbe convenuto anche redistribuire
le applicazioni. Ed invece di quelli rilascio solo i sorgenti. Come mai?
Ah, e vedi Ottavio, che non ti ho riso in faccia prima perchč mi andava
di fare cosě. Ti ho riso in faccia perchč mi hai preso per ignorante dicendo
che mi serve un cross-compiler per fare quello che dici tu, quando io
in quel package redistribuisco il psp-gcc.exe (notate il .exe) che č proprio 
un
cross-compiler, e sono mesi che ci lavoro (nel senso che lavoro con un
cross-compiler) e quindi il discorso č del tutto demenziale.....

 anche i binari delle applicazioni nello stesso package?
che cazzo vuoi, coglione sfigato? sto parlando con te? no.
dai, vai a farti le seghe pensando a quanto sei bravo da un'altra parte.

 dai, vai a farti le seghe pensando a quanto sei bravo da un'altra parte.
Bravo, idiota, un intervento di una civiltà esemplare, che ti
qualifica in pieno....


Deve esserti dato atto, e sono sincero in questo, che fra tutte le
persone del NG tu ti sei comportato nel modo migliore possibile.
Tu sei stato il piů serio, occorre ammetterlo.
Io ho detto "che tu disprezzi tanto", riferendomi a quel "scelte idiote".
Spero che questo sia stato chiarito.
Non č che non voglio essere criticato: č solo che mi aspettavo un altro
tipo di commenti, per esempio sugli algoritmi usati, sulla compatibilitŕ
OpenCV, sulle API. Invece mi vedo commenti su cose come i //,
ma soprattutto, quello che mi ha infastidito, č che si dicono cose che
non rispondono al vero, come che non so che cos'č un header.
Mentre che cos'č un header magari lo so....
Comunque, spero che sia stato chiarito tutto. Grazie dei commenti,
non ce l'ho assolutamente con te e ti invito a fare altre critiche
costruttive se vuoi.
Ciao
Pegasus

 qualifica in pieno....
sei tu quello che si mette a ridere in faccia per primo.

 comunque uso /* */ perché mi piace di più di // :-)
Sono due metodi diversi di commentare, io li uso entrambi. il commento
//
risulta molto piu' chiaro nel caso di editor che non hanno la
colorazione
del codice sorgente.
C:\>iao Angelo

 creazione di directory o per avere la dimensione di un file...
Perche` e` dipendente dalla piattaforma cio` che chiedi. Per sapere 
quanto e` grosso un file puoi usare fseek/ftell, che sono standard, 
mentre le directory... beh, non e` detto che esistano :) Altrimenti 
usi, come e` giusto che sia, la libreria dell'OS.
PS. Si e` vero quasi tutti gli OS hanno le directory ma non e` lo 
standard che lo decide, mentre tutti hanno file.


 standard che lo decide, mentre tutti hanno file.
   Parlando di OS, non ti so dire... Ma, parlando di posti dove ci puoi
programmare usando in ANSI C, beh, ti posso assicurare che quando scrivi il
firmware per un (esempio, ma ce ne sono nmila altri) LPC2129[1] non ci
trovi file ne' directory ;-), giusto stdin/stdout sulla seriale se fai un
po' di macumbe iniziali...
   Probabilmente come l'ANSI C definisce uno standard per gestire un file (è
un'astrazione che non c'è *sempre*) avrebbe potuto definire un altro
standard per gestire delle directory (che, e su questo ti do' ragione,
possono non esserci in un numero più ampio di casi)...
[1] - Uso arm-gcc con -ansi -pedantic perché sono un maledetto pignolo...
-- 
                          |    I veri programmatori non
\|/ ____ \|/   \ ||_|     | commentano il loro codice. E`
"@'/ ,. \`@"    \|| |     | stato duro scriverlo, deve
/_| \__/ |_\ Vax Headroom | essere duro capirlo.
   \__U_/                 |

 costruttive se vuoi.
No problema. Quando qualcuno si impegna e` SEMPRE degno di lode, anche 
se fa una cagata di hello world, ma l'impegno e` sempre da premiare 
(cosi` almeno mi comporto con gli studenti, a patto che non facciano 
gli sbruffoni). State facendo un buon lavoro---IMO inutile e il tuo 
prof e` da bastonare---e lo ripeto. E ripeto, si vede che ci sono cose 
molto amatoriali. Questo e` un bene: c'e` da migliorare la propria 
conoscenza.
Non e` questione TUA, siete un team, e se questo vuol dire che qualcuno 
ha fatto una cappellata, DEVI agire:
1. readme, makefile/project nella root
2. third-party directory
3. iso c compliance
Sono le *basi* su cui fondare un progetto.
La (1) ti mette al riparo dalla mia critica che non compili sotto AIX: 
credi che non abbia visto psp-gcc??? Ma non e` *EVIDENTE*.
La (2) ti mette al riparo dalla merda di codice, tipo quel #define, e 
mette in evidenza solo il vostro lavoro. La libz e` vecchia come il 
cucco e non e` vostra, ma non e` *EVIDENTE*.
La (3) ti permette di evitare undefined behaviors e di poter senza 
sputar sangue mettere un x-compiler anche per linux, aix, osx o 
l'orologio digitale di mio zio. Un giorno puo` servire, fidati.


 [1] - Uso arm-gcc con -ansi -pedantic perché sono un maledetto pignol o...
Vero, i file rappresentati come un OS li vede non ci sono sempre. Pero` 
lo standard definisce FILE (data type) come stream (cui si associa un 
path), e gli unici che ci sono sempre se non erro sono stdin, stdout e 
stderr. La questione storica mi intriga, chiedo a chi ne sa di piu`...


 creazione di directory o per avere la dimensione di un file...
sulla directory è vero, per la dimensione del file fseek+ftell.

 Per sapere quanto e` grosso un file puoi usare fseek/ftell, che sono standard,
purtroppo, anche su questo, non c'e' certezza assoluta:
ISO/IEC 9899:1999 (E)
         7.19.9.2 The fseek function
         [......]
         int fseek(FILE *stream, long int offset, int whence);
         [......]
         3 - For a binary stream, the new position,
         measured in characters from the beginning
         of the file, is obtained by adding offset
         to the position specified by whence. The
         specified position is the beginning of the
         file if whence is SEEK_SET, the current
         value of the file position indicator if
         SEEK_CUR, or end-of-file if SEEK_END.
==>     A binary stream need not meaningfully
         support fseek calls with a whence value
         of SEEK_END.
         [......]
...e in una nota a pie' di (un'altra) pagina:
         7.19.3
         .....
         225) Setting the file position indicator to
         end-of-file, as with fseek(file, 0, SEEK_END),
         has undefined behavior for a binary stream
         (because of possible trailing null characters)
         or for any stream with state-dependent
         encoding that does not assuredly end in the
         initial shift state.
Ciao
-- 
Cybertoldo
Per rispondermi via email, sostituisci moc.liamg con 
gmail.com

 purtroppo, anche su questo, non c'e' certezza assoluta:
che ne dici di fsetpos e ricerca binaria della dimensione? :-)

 usi, come e` giusto che sia, la libreria dell'OS.
Dubito fortemente che una piastra a microprocessore abbia
qualcosa di lontanamente assimilabile ad un file senza un S.O.
sotto...
C:\>iao Angelo

 purtroppo, anche su questo, non c'e' certezza assoluta: [...]
Hai pienamente ragione. L'unico modo portabile e sicuro e` quindi 
leggere il file, tenendo conto di eventuali riporti durante le somme 
(vi sono i range MINIMI garantiti dei vari tipi interi, quindi si puo` 
operare con ingegno).
La soluzione raccomandata e` come quella solita: scrivere un wrapper 
sulle api dell'OS.


 sotto...
Beh, ho chiesto e a quanto risulta le ragioni per non parlar di 
directory sono storiche. VM/CMS, OS390, CP/M, MS-DOS 1.0, PDP-11/RT-11, 
HP MPE, Encore MPX sono esempi, cosi` come banalmente il BIOS ed in 
generale i firmware.
Effettivamente, il linguaggio e` il linguaggio, e non deve 
necessariamente provvedere a tutto cio` che viene in mente. Quello e` 
compito dell'OS.
