Newsgroup: it.comp.os.dibattiti
Titolo: On-line 6 demo scaricabili di Nanodesktop

I files, che mostrano qualcosa della nuova tecnologia,
sono disponibili all'indirizzo:
http://visilab.unime.it/~filippo/Nanodesktop_PSPE/Homebrew%20Demos/ndPSPE_Homebrew%20Demos.htm
Saluti
Pegasus
P.S.
Ehm....
Come slide powerpoint mi sono venuti bene questi
file eh..... :))))))))
Poi anche quel link con su scritto "download" non
č male.....

 è male.....
curiosità: che è un file pbp?
A quando i sorgenti?

 Powerpoint Better Presentation
LOL!
Spero che il Nanodesktop (che credo esista davvero, deve essere una tesina
di qualche esame) sia meno prolisso di GalaxyOS, aka Vegeta OS....

 A quando i sorgenti?
A circa 30 giorni...
Saluti
Pegasus

 ha scritto nel messaggio 
news:14uynw3posycy.3...@40tude.net...

Complimenti per l'arroganza....
Saluti
Pegasus

 
per quale motivo?
Perchè insinuo che tu sia Vegeta, artefice di una delle più belle saghe di
i.c.o.d., il Vegeta OS poi Galaxy OS, che ha regalato pomeriggi spensierati
a tutti noi? 
Sbaglierò, non mi nascondo dietro un dito, *ne sono assolutamente
convinto*. 
Scrivete le stesse cose, nello stesso esatto modo, con lo stesso esatto
stile vieppiù prolisso, e tu sei apparso dopo che lui si è accorto che con
quegli screenshot (Dio quanto mi mancano quei giorni!), aveva frantumato il
muro del ridicolo a Mach 8
Non affannarti a convincermi del contrario, lasciami pure vivere nella mia
fallace ma consolatoria convinzione che Vegeta sia ancora tra di noi, e
come il Dalai Lama si incarni di generazione in generazione senza
abbandonarci mai. I want to believe. 
(Sigh, il fake di Anna, "cinque caposviluppatori nel mio studio",
"trattenuto il fiato", eh che tempi, che tempi, ragazzi!)
Se invece mi dai dell'arrogante per aver definito il tuo lavoro "una
tesina", se sei uno studente universitario dovresti sapere che il
diminutivo non ha nulla di dispregiativo. Se è invece è una tesi finale,
beh, allora scusa, chiamala come ti pare. Sono sicuro che stavolta
produrrai qualcosa di funzionante, perchè ti sei esposto con nome e
cognome, però ti sarò eternamente grato per Galaxy/Vegeta.
Ti prego non cambiare mai.

 A circa 30 giorni...
li aspetto con interesse

 beh, allora scusa, chiamala come ti pare.
No, ti do dell'arrogante perchè di fronte ad un progetto che è
costato mesi di lavoro e che consente di fare qualcosa che a
livello di ricerca universitaria nessuno ha mai fatto prima
(Embvision project), qualcosa che quantomeno meriterebbe
un minimo di rispetto (soprattutto verso uno che era stato
accusato di non sapere scrivere una riga di C, ed ora invece
dimostra che qualche riga di C magari la sa scrivere) tu liquidi la
questione semplicemente con un "tesina".
Certo, ovvio, prima erano slide powerpoint, ora che ci sono
gli eseguibili allora... no, aspetta, no.... ecco sì, è una tesina
per qualche esame, ovvio, lo fanno tutti gli studenti di
Informatica I un lavoro così....
Saluti
Pegasus

 livello di ricerca universitaria nessuno ha mai fatto prima
(Sigla di Star Trek, prima serie: papaaaa paparapapaaaaaaaa papppppaaaa
"Spazio. Ultima frontiera"...)
Vabbè a parte gli scherzi:
Tu e le personalità che in te allegramente convivono avete spalato merda
per mesi o anni sul lavoro fatto dagli sviluppatori che lavorano, dicendo
che erano degli incapaci, che le le librerie qua e la, che i driver patazum
patazum, che la coerenza delle ABI trallallà, mentre invece tu qui, tu la,
trattando con spocchiosa sufficienza e come fossero degli scemotti gente
che ha delle contropalle GROSSE COSI', e che sino a prova contraria ha
messo in piedi un progetto che, piaccia o meno, funziona ed è
maledettamente completo e complesso.
Ed ora pretendi una standing ovation sulla fiducia per un progetto che
sicuramente sarà interessante, e sarà pure fatto bene, ed ammetto che forse
non sono in grado di capire pienamente, (non mi spaccio per quello che non
sono, io), però che diamine... sarò arrogante io, ma un minimo di umiltà da
parte tua non guasta. 
Se mi mandi il link del tuo fan club, prendo la tesserina.
PS: senza offesa, migliora un pochino l'inglese se vuoi avere più
visibilità per la tua pagina. Si dice "to thank" e non "to thanks", ad
esempio.

 Se mi mandi il link del tuo fan club, prendo la tesserina.
Non ci siamo capiti....
Io ho detto "un minimo di rispetto". Com'è che tu hai capito che
"io pretendo una standing ovation"?
Nessuna standing ovation, guardacaso non sono venuto qui a
dire "guardate come sono bravo...", sono venuto a chiedere se
c'era qualcuno che voleva darmi una mano, perchè il codice che
ho scritto finora, tutto quello che ho fatto finora, poco o molto
che sia, l'ho fatto da solo, e se mi devo perfino scrivere i font
è chiaro che non posso arrivare a fare tutto.
Chiaro ora?
Quello che mi ha dato fastidio, è che sia stato bollato come una
tesina di qualche esame, come se ora un professore desse ai
suoi studenti da fare, così, per un esame come l'altro, la
creazione di una tecnologia di quel tipo, così, dal nulla, su una
piattaforma dove **prima di Nanodesktop ed eccettuato LUA**
non c'era nulla per programmare, zero, nada, niet, mentre ora
chiunque vorrà creare applicazioni per Linux e per PSP, potrà
farlo.
Saluti
Pegasus

 esempio.
oddio ... non toccare quel tasto:
pegasese: Nanodesktop isn't released yet
inglese: Nanodesktop hasn't been released yet
pegasese: It makes more easy to program
inglese: it makes easier programming / it makes it easier to program
pegasese: X-Windows
normale: x window (senza 's' finale)
pegasese: In a first time (dirattamente dal messinese: in un primo tempo)
inglese: On a first attempt / On its first attempt
pegasese: In a first time, Nanodesktop was created for making more easy
the development of PSP Applications (Homebrew) ... proprio qui manca il
nesso. 
inglese: On a first attempt, Nanodesktop was created to get the
development of PSP applications, easier than it was before 
continua..... ... se avessi tempo....
-- 
echo onailimissaM | awk 'BEGIN { FS = "" }
{ for (i = NF; i >= 1; i-- )
  printf $i }'; echo

 continua..... ... se avessi tempo....
MA ROTFL!!!

 Informatica I un lavoro così....
per avere una onesta e corretta valutazione devi dare il codice
sorgente, perché all'attuale stato delle cose non si capisce cosa hai fatto.

 farlo.
Ok, giusto. Lasciamo gli insulti da parte (e magari ricordati di come
sei stato trattato la prossima volta che esprimi un giudizio) e parliamo
di aspetti tecnici
Nanodesktop provides graphical routines, and other routines for open and
close files, for loading/saving images, for memory manager, for mouse
emulation.
Ma scusa,aprire e chiudere file non lo fa la libreria standard C? La
gestione dellamemoria con malloc e free non la fa la libreria del C?
Inoltre perché invece di creare l'ennesimo toolkit non avete cercato di
portarne uno già disponibile. Ce ne sono tanti che girano anche senza X.
PS:  so you can use the library over any card that run Linux kernel.
manca la s a run. Nelle Nanodesktop features forse intendi supports e
non support, se il soggetto è nanodesktop

 Ok, giusto. Lasciamo gli insulti da parte 
Con questo chiudo, ma ribadisco che a casa mia "Tesina" non è un insulto.

 portarne uno già disponibile. Ce ne sono tanti che girano anche senza X.
Perchè l'obiettivo finale è un altro.
Il Visilab di Messina svolge da anni studi sulla visione artificiale.
Mi era stato chiesto di portare le librerie OpenCV di Intel su
una piattaforma portatile. La PSP ha una potenza di calcolo
spaventosa, ed è per questo motivo che l'idea di portare le
OpenCV su questa piattaforma è stata considerata buona.
Ma, purtroppo, programmare la PSP per un utente normale
(non Sony) è un inferno (per le ragioni che ti ho detto prima),
e quindi è stato prima necessario creare un ambiente come
Nanodesktop che consentisse di avere un sistema a finestre.
Per inciso, il porting di un qualsiasi toolkit già pronto non sarebbe
mai stato possibile per alcune ragioni.
Intanto, si basano tutti sull'idea che sotto ci sia il kernel Linux: ma
qui non c'è il kernel Linux, quindi qualsiasi tentativo di aprire un
file /dev o di chiamare una malloc, o eseguire una printf, avrebbe
provocato un crash.
In secondo luogo, si basano sull'idea che sotto ci sia una memoria
ampia, mentre la PSP ha solo 32 Mb di Ram (e certo non potevamo
portarci X).
In terzo luogo, il problema è che le OpenCV sono state scritte per
Windows o GTK ed in questo caso non avremmo avuto nessuna
delle due. Ho allora preferito creare un software che consentisse
di risolvere i problemi di compilazione e di programmazione della
PSP (una volta per tutte: ed infatti i forum che ho avvertito stanno
mostrando grande interesse), e che ci fornisse un ambiente grafico
scritto da zero e con il suo bel HAL a fornire trouble hiding per
permettere l'esecuzione su emulatore PSPE.
In quarto luogo, un toolkit già pronto avrebbe fornito funzionalità che
su PSP magari sono inutili, e che avrebbero solo sprecato Ram (mentre
Nanodesktop occupa solo 500k).
In quinto luogo (chiaro perchè non ho pensato manco per un secondo
a questa idea?) c'è il problema che i toolkit partono dal presupposto
che sotto ci sia un mouse reale (e la PSP, il mouse, proprio non ce l'ha...)
Da ultimo, Nanodesktop integrerà del codice per gestire una webcam
USB esterna. Siamo i primi al mondo a tentare una cosa simile, e ti
lascio immaginare cosa ci si potrebbe fare (un pò di fantasia...). Un
toolkit non avrebbe mai risolto questo problema....
Saluti
Pegasus
P.S.
Quel sito l'ho creato in nottata in una mezz'ora. Un pò di comprensione:
per ora sto seguendo 500 cose in una volta e quindi il tempo è poco....

 ricerca nel settore) sulle immagini.
La prima cosa innovativa è che prima c'era il nulla (ah già, vero,
LUA che è 30 volte più lento....), ed ora invece chiunque può
scrivere la sua applicazione a finestre per PSP in dieci minuti.
Qualcuno interessato potrebbe pensare di portarci anche GTK+
sopra, ma non divaghiamo.
Di scientifico, c'è quello che vogliamo farci. La PSP con Nanodesktop,
le OpenCV ed un software che vogliamo scrivere, può diventare un
cervello artificiale per un robot (forse Robosapiens) che sarà in grado
di analizzare l'ambiente esterno (è questo l'EmbVision project).
Probabilmente farò la mia tesi di laurea su questo progetto.
Inoltre, per la prima volta i ricercatori universitari che usano le schede
hardware Fox possono usare un ambiente a finestre che giri sopra ai
kernel Linux delle schede e che non sia X (e chi usa una Fox sa che
la cosa è ***molto*** interessante).
Saluti
Pegasus

 artefice di una delle più belle saghe di i.c.o.d.
                                   ^^^^^
:s/saghe/seghe/g  ;-)
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


The optimist thinks this is the best of all possible worlds.
The pessimist fears it is true.      [J. Robert Oppenheimer]

 A circa 30 giorni...
Una domanda, perche` non accesso al CVS in read-only anonimo e se vuoi 
anche in SSH per evitare pserver? Oppure (e meglio) svn+ssh://?



Non so se sia il caso. Ci penso su e ti faccio sapere.
Comunque, spero concorderai, finchè non metto i sorgenti
sul sito il problema non si pone.... :)))))
Piuttosto, qualcuno mi può fare un favore? So che negli
Stati Uniti stanno avendo dei problemi di compatibilità degli
homebrew di demo sui loro PC.
Noi in laboratorio non abbiamo riscontrato nulla, comunque....
qualcuno può scaricare PSPE ed eseguire una prova degli
eboot.pbp ?
Saluti
Pegasus


No, il problema č che lě č come se ci fossero 2 libc ed una, quella di PSPE,
ha bisogno che l'aiuti te ad aprire il file (poi nei sorgenti capirete
cosa intendo dire....)


:s/saghe/seghe/g  ;-)
"Che belle le saghe, peccato che facciano mele"

 la cosa è ***molto*** interessante).
ehm... questo è falso. c'è già il framebuffer. in
http://www.acmesystems.it/?id=22
 trovi citato l'intervento di un certo
John Crispin che parla proprio di questo.....


io veramente mi riferivo ai suoi commenti sui formati fi
pacchettizzazione calati dal cielo contro tutti come se lui fosse dio in
terra.
nemmeno secondo me tesina è un insulto. si fanno delle belle tesine se
si ha voglia di fare.

 per ora sto seguendo 500 cose in una volta e quindi il tempo è poco....
prendi i commenti come suggerimenti. Insomma, a suo tempo hai sparato
contro gli sviluppatori di vari progetti. Adesso non vorrai un
trattamento coi guanti di velluto, no? :-)

>Lo so che c'è il framebuffer, non è quello il problema.
Ovvio, c'è il framebuffer, ma il problema è X.
Io porto Nanodesktop su Linux perchè tanto a me costa davvero poco:
si scrive un nuovo HAL per Linux ed è fatto il lavoro.
Su Linux Fox, infatti, sfrutta il framebuffer Linux. Naturalmente,
siccome le API di livello superiore all'HAL sono uguali, a quel punto
ci gira tutto il software per Nanodesktop già visto su PSP.
In altre parole: puoi sviluppare software per Linux e farlo girare
su PSP e viceversa.
Saluti
Pegasus

 cosa intendo dire....)
guarda che l'ho capita benissimo. Io ho un problema simile con un
software che gira su linux, windows e dsp di t.i. . E con delle
puttanate di define e i makefile fatti bene il problema č stato risolto
in mezza mattina con in mezzo anche un bel po' di cazzeggio.

 io veramente mi riferivo ai suoi commenti
Ah, ok, ti avevo frainteso. Sorry :-)

 ed ecco un altro bel crash.....
Non entro in merito nel resto del discorso perchè non ho le competenze in
materia ma mi chiedo: ha un senso sviluppare uno strato di astrazione
perchè la alloc crasha l'emulatore? Non sarebbe meglio correggere il bug
dell'emulatore? Ma poi, stai dicendo che /ogni/ chiamata di alloc schianta
inesorabilmente l'emulatore? Ed allora come fa a funzionare? Da profano
suppongo che senza allocazione dinamica della memoria si possa fare ben
poco. Se qualcuno ha la pazienza di spiegarmelo..

 trattamento coi guanti di velluto, no? :-)
In effetti avete ragione.
Saluti
Pegasus

 poco. Se qualcuno ha la pazienza di spiegarmelo..
Se non hai Nanodesktop sotto, quando fai gli homebrew usi
solo allocazione statica.
Si lo so, nessuno ha ancora preso gli sviluppatori di PSPE a calci
nel sedere.
Se hai Nanodesktop sotto, lui ha un bel
char VirtualMemory [16000000]
che crea un buffer statico che ti servirà da memoria. Poi ndHAL_Alloc
e ndHAL_Free emulano il comportamento di una Alloc e di una Free
allocando i dati in questo array statico come se fosse una Ram.
Naturalmente, sulla vera PSP, ndHAL_Alloc si richiama malloc e
ndHAL_Free si richiama free dalla libreria libc della PSP.
Saluti
Pegasus

>
a che risate che ci faremo quando usciranno fuori i fantomatici
sorgenti.... oddio, la gtk gli vanno in crash perche' manca il kernel
linux di sotto. Oddio che risate che ci faremo.


 linux di sotto. Oddio che risate che ci faremo.
Sai le risate che mi faccio io....
dimmi un pò, tu come la porti gthread-posix.c su PSP?
Te la devi riscrivere da zero, o ti gira semplicemente
ricompilando?
E l'output come lo gestisci? Anche li devo avere un
ambiente a finestre sotto, oppure il codice per disegnare
la finestra me lo crea il toolkit GTK ?
Pango ed ATK come te li porti?
Per accedere all'hardware grafico uso il fbdev? Ti sfugge
che quella è un interfaccia presente nel kernel linux
oppure ce l'hai presente in qualche modo?
Saluti
Pegasus

 Fox) e su PSP (dove non c'era proprio niente), mi и piaciuta ecco.
ok, ma creare un toolkit nuovo и sciocco. Fai un sacco di fatica e
rischi di non avere utenti.
Complimenti per il lavoro, ma personalmente reputo che abbiate scelto
purtroppo un hardware infelice e una soluzione faticosa. Questo ti dа
indubbiamente un mare di soddisfazione se vuoi smanettare, ma se vuoi
fare qualcosa che funziona (nel senso che tanta altra gente te lo usa e
che puт adottarlo senza dover reimparare un mare di cose) и
probabilmente un grave errore

 portarci sopra i software del mondo x86.
mi sembra sinceramente eccessivo.

 
sbaglio o tu hai scritto comunque da zero?
Daltronde, mi pare che e' stato piu` semplice fare il porting delle GTK su
windows che non fare il porting di gimp o di gaim.
ma comunque, se ti dicessi che quello che tu ritieni improbabile esiste
gia':
 PSPBEEB is a port of the version 0.0.4 from Dave Eggleston, using GTK
and SDL environement.


 
Hai preso questa notizia da un sito internet come pspnews.
Non ci farei tanto affidamento: per Nanodesktop per esempio
hanno detto che Nanodesktop usa OpenCV mentre sono le
OpenCV che usano Nanodesktop.
Io il codice sorgente di PSPBEEB ce l'ho davanti in questo
momento. Non c'è alcuna traccia di GTK+ quindi se lo sono
sognati: scaricatelo e controlla tu stesso.
Saluti
Pegasus

 probabilmente un grave errore
Ma sai, il problema non è poi così critico come
lo vedi tu.
Per esempio, ho fatto il porting delle OpenCV di
Intel su Nanodesktop.
I prototipi delle funzioni rimangono gli stessi,
pertanto i programmatori possono programmare con
OpenCV in modo non molto diverso da come programmavano
con PSP. Perchè la nuova HighGUI.c si occupa di
tradurre le chiamate alle routine di OpenCV in
qualcosa di compatibile per Nanodesktop.
Su GTK+, se uno ha voglia di farlo, si può fare la
stessa cosa, non è nulla di impossibile.
Solo che si può fare ora che il codice di
Nanodesktop c'è, non prima...
Saluti
Pegasus

 Intel su Nanodesktop.
le opencv le ho viste una volta per curiosità anni fa. non mi è chiara
una cosa: perché hanno bisogno di un ambiente a finestre?

 una cosa: perché hanno bisogno di un ambiente a finestre?
Perchè, dopo che hai manipolato l'immagine (che è
allocata in una struct di tipo cvImage) dopo dovrai
visualizzarla in qualche modo, no?
Di solito si usa cvNamedWindow e cvShowImage.
Solo che nel codice originario, queste routine si richiamano
delle routine del toolkit GTK+ o di Windows per
creare delle finestre sullo schermo.
E qui casca l'asino.....
In secondo luogo, cvCreateTrackBar ha bisogno di
un pezzo di codice sotto che gestisca la barra di
scorrimento. Che di solito è fornito dai toolkit, ma
siccome qui non abbiamo i toolkit... lo fornisce
Nanodesktop.
Saluti
Pegasus

 qualcosa di utilizzabile.
Quindi il Nanodesktop esiste perchè PSPE è closed source? Ma l'Ppensource
non era un male, che portava a sistemi operativi per ragazzini, poco
professionali ed ingegnerizzati?

 cosa intendo dire....)
Beh, se intendi che vi sono solo i prototipi delle funzioni oppure che 
vi sia un VFS e basta, non hai una libc :)
Non scherzo, almeno non rispetta gli standard ISO che impone 
l'implementazione delle funzioni di file handling f* (da non confondere 
con quelle posix). Se intendi qualche altra puttanata che si trova 
nelle glibc, tipo i define di M_PI e cose simili, devi giocare un po' 
come ha detto Ottavio.


 Anche un semplice printf era un problema.
Allora non hai una libc ma una merda di libreria che non funziona e ti 
consiglierei di buttarla al cesso. Mi dai l'indirizzo di chi ha messo 
in giro sta libreria? L'hai ancora l'url vero?


 eboot.pbp ?
Se c'e` l'emulatore per OSX ok. Se devo ricompilare un emulatore per 
linux no. Se devo usare windows... beh ho passato una settimana con 
windows e domini, e ne ho abbastanza per ora :)



No, il bello è che la libreria funziona. E fa quello che deve fare....
Mi spiego (attenzione perchè sto per dire cose che per chi
vengono dal mondo x86 sono inconcepibili, ma tant'è....).
Le librerie che noi abbiamo attualmente per la programmazione
PSP **non** sono state rilasciate da Sony, che ha un SDK
riservato solo agli sviluppatori, ma sono rilasciate da un gruppo
di ingegneri (il gruppo ps2dev), che ha riadattato un SDK
prima scritto per la Playstation 2.
Inoltre, un altro gruppo di ingegneri si è messo a studiare i
firmware di Sony per trovare per ogni routine i parametri
e gli entry-point.
Quando si programma su PSP non si interagisce solo con la
libc, ma anche con un certo numero di routine che si trovano
nei cosiddetti kernel modules. Durante il funzionamento della
libreria, l'SDK della PSP richiama, ove necessario, il necessario
kernel modules ed esegue la necessaria funzione. Questo
può essere fatto per mezzo di una funzione che si chiama
SceKernelLoadModule () e che è richiamata internamente
dalla libc della PSP.
Attenzione: la funzione SceKernelLoadModule richiama i moduli
da una directory virtuale chiamata "flash0:\" . Directory virtuale
che sulla vera PSP esiste, mentre nell'emulatore PSPE no.
Ora seguitemi. Il codice che alloca la memoria nella PSP, è
allocato in una funzione del kernel che sta dentro un modulo
del kernel. Pertanto, psplibc richiama internamente questo
modulo, se vede che non è caricato, ed esegue l'allocazione.
Su PSP.
Vediamo su PSPE. Siccome sono implementati solo pochi
moduli, il tentativo da parte della libc di richiamare il modulo
per la gestione dell'allocazione fallisce miseramente.
Ed infatti, in stderr.txt trovi un bel:
Can't find sysmemforkernel
che è un modulo che contiene il gestore di memoria. Ora
attenzione: la libc procede semplicemente ignorando l'errore
e restituendo un valore per alloc a caso ma l'area di memoria
non è stata effettivamente allocata.
Quando il programma utente cerca di scrivere sul puntatore
che è stato allocato (ma il realtà non è vero, solo che il
tuo codice C non se ne può accorgere), il processore
virtuale emulato di PSPE genera un'eccezione e
l'emulatore si chiude.
Quindi, al solito, non è PSPSDK che non funziona.
E' PSPE che è una disgrazia per gli sviluppatori.
Saluti
Pegasus


No, intendo che sotto PSPE sceIoOpen ti apre un file
in scrittura solo se usi O_RDWR mentre se usi
O_WRONLY lo crei ma non ci puoi scrivere dentro....
Mentre sotto PSP la medesima routine della libc,
medesimo codice, funziona bene.
Oppure che sotto PSPE sceIoLSeek fallisce sempre
con codice di errore -1, mentre sotto PSP la routine
funziona.
Ed allora, siccome tutto questo deve essere coperto
all'utente, sotto PSPE l'HAL di Nanodesktop inserisce
una speciale routine che emula i seek dei file in
lettura (mentre non puoi fare seek dei file in scrittura,
ma meglio di niente), mentre sotto PSP l'HAL di
Nanodesktop richiama le routine della libc
in modo normale.
Saluti
Pegasus

 E qui casca l'asino.....
portavi gtk!
Ciao

 E' PSPE che è una disgrazia per gli sviluppatori.
e voi sciocchi ad usare una simile piattaforma

 e voi sciocchi ad usare una simile piattaforma
Dipende dai punti di vista....
Ragionando come te la questione si risolve in un secondo:
prendiamo una board con processore x86, ci mettiamo
sopra Linux, sopra DirectFB, sopra GTK, sopra le
OpenCV e siamo pronti al lavoro.
Non avremmo avuto bisogno neanche di crearlo
Nanodesktop.
Il mio punto di vista è che, se volevo fare qualcosa di veramente
utile, dovevo creare qualcosa per colmare un vuoto e per farlo
dovevo andare dove non c'era nulla, non dove c'era già
tutto.
Su PSP, prima, per creare homebrew era necessario suicidarsi,
(eccetto se si voleva usare LUA), di ambienti a finestre manco
l'ombra, e quindi l'idea è stata di andare lì.
Vedremo se i fatti mi daranno ragione: per ora so che ci sono
moltissimi sviluppatori che possono essere interessati a questa
tecnologia perchè con poche righe di codice si fanno la
loro applicazione a finestre, mentre prima decisamente no.
Certo, Nanodesktop ha bisogno di crescere, deve ancora
integrare tante funzioni, ma intanto prima non esisteva, adesso
esiste e, visto che lo rilascio come LGPL, con il lavoro di
tutti può diventare un bel sistema (tenuto conto di ciò che ho
fatto io, da solo, se ci fossero tanti sviluppatori a dare il
loro contributo....).
Saluti
Pegasus

 portavi gtk!
Mica tanto. Ieri ho controllato. Hanno tentato di portare
GTK+ su PSP ed i tentativi hanno fallito in modo
miserabile.
Vuoi sapere perchè?
http://www.directfb.org/wiki/index.php/PSP_Port
Ora, le routine di basso livello di Nanodesktop
consentono di avere un framebuffer adatto
a DirectFB, di avere il controllo del sistema
di input e di reinizializzare l'hardware grafico.
Visto che Nanodesktop già permette di fare
queste cose, l'unica cosa che manca è la
gestione dei threads che inserirò appena avrò
un poco di tempo perchè è una cosa abbastanza
complicata.
Ma, a questo punto, chi mi impedisce di portare
DirectFB e sopra di portare le GTK+.
Ma questo, si poteva fare dopo avere creato
Nanodesktop, non prima....
Saluti
Pegasus

 esiste 
chissà perkè ma queste parole mi ricordano quelle relative a pippaOS... 
ops..!  era VegetaOS ;)
comunque... *esiste*? BWAHAHAHAHAHAHAH! Facce vedè le prove 
dell'esistenza de sto capolovoro d'ingegneria sw, và..
Ah e ricordati di dare una lustratina a powerpoint e, come dicevano 
nell'altro post, consultati con anna, prima... rotfl.

 ha scritto nel messaggio 
news:44BE55A8...@cipria.net...

Ehm....
Cipria.....
.... dimmi un pò, fesso totale, quei demo come li ho fatti?
Al di là del fatto che non hai notato dove è ospitato
Nanodesktop (e tra 30 giorni tu farai la figura di ****
più straordinaria degli ultimi 11 milioni di anni....)
Non gli screenshots dei demo, proprio i demo che tu
puoi scaricare ed eseguire sul tuo PC....
Quelli, come li ho fatti?
Con Powerpoint?
Saluti
Pegasus

 domini, e ne ho abbastanza per ora :)
Ci vuole un secondo. Scarica l'emulatore PSPE
con la libreria SDL (dovrebbe essere già inclusa),
crea nella directory di PSPE una sottodirectory
ms0 (serve ad emulare la memory stick)
e poi dai un bel
PSPE.EXE [percorso del file eboot.pbp]
da Windows oppure Linux con WINE.
Ciao e grazie.
Pegasus

 in modo normale.
Mi spieghi perche` dovresti usare le routine non standard in un 
programma C che puo` usarle?
Una buona regola e` rimanere nello standard fino al momento in cui non 
ci sia altro modo per agire, ad esempio un semplice socket implica 
l'essere platform-dependent. Tanto la fopen poi e` implementata come la 
open, quindi non hai alcun problema.


 E' PSPE che è una disgrazia per gli sviluppatori.
*SE* si rilascia una libc, minimo si deve implementare il minimo di 
funzionalita` richieste dallo standard. Il comportamento da te 
descritto *NON* e` dovuto alla PSPE, quanto proprio alla libc, che non 
rispetta lo standard.
Non te lo indica il medico di usare la loro di libc. Puoi usarne una 
diversa se vuoi, e naturalmente se esiste. Se non esiste, cito Verdone: 
``a no` m'hanno dato un buono, che vor di`?''...


 Se questo non accade butta al cesso bestemmiando la libc.
E' garantito dallo standard su PC.
Su PSP scordati lo standard ISO, proprio levatelo completamente
dalla testa.
Se tu provi a fare una fopen il linker ti spara un bel
unresolved symbol e buonanotte sonatori (sia con -lc
che con -lpsplibc).....
Ed infatti se ti guardi qualche sorgente di homebrew per
PSP tutti usano SceIoOpen perchè è quella che deve
essere richiamata.
Ciao
Pegasus

 ``a no` m'hanno dato un buono, che vor di`?''...
No, per quanto riguarda le routine Open/Close hai ragione
tu, ma per quanto riguarda le routine malloc, il problema č
proprio che il codice C tenta di caricare un modulo che sulla
vera PSP c'č, mentre sull'emulatore no, e quindi....
Ciao
Pegasus

Pegasus ha scritto:
<snip di facezie>
vedremo... nel frattempo ricordo tutte le diatribe su vegetaos e c'era 
anche qualcuno che c'era cascato (come adesso...). Smentiscici.

 essere richiamata.
e quindi è una piattaforma di sviluppo ridicola

 loro applicazione a finestre, mentre prima decisamente no.
anche qua siamo interessati, posta il codice :-)


Tutto sommato mi sembra anche abbastanza compatto rispetto a quello che
dovevi scrivere in C sotto Windows  qualche annetto fa per aprire una
finestra :)

 ha scritto nel messaggio 
news:1153342471....@m79g2000cwm.googlegroups.com...
Pegasus ha scritto:

Qualcosa così?
int xmain ()
{
    int WndHandler;
    ndInitSystem ();
    WndHandler = ndLP_CreateWindow (0, 0, 300, 100, "First window", 
COLOR_WHITE, COLOR_LBLUE,
                                                                    COLOR_WHITE, 
COLOR_BLACK);
    if (WndHandler>=0)
    {
        ndLP_MaximizeWindow (WndHandler);
        ndWS_WriteLn ("Hello word in window", COLOR_WHITE, WndHandler, 
RENDER);
    };
    ndDelay (1);
    ndSystemHalt (0);
}
:))))
Ciao
Pegasus


No mi riferivo all'Hello World senza NanoDesktop... Tutto sommato
compatto rispetto alle 150 e passa linee di codice per aprire una
finestra con le API di Windows una decina di anni fa prima che
esistessero i vari framework o Turbo Pascal (lacrimuccia)

 ha scritto nel messaggio 
news:1153343363....@i42g2000cwa.googlegroups.com...
Pegasus ha scritto:

No, aspè, il programma di quei ragazzi scrive Hello
world sullo schermo in alto a sinistra, niente finestre,
nulla, nada, niet, le finestre prima di Nanodesktop
o ti creavi un Windows Manager con LUA (30 volte
più lento del codice C di Nanodesktop) o ti impiccavi.....
Piuttosto, con Nanodesktop un Hello world in
finestra si fa con 15 righe (lo hai visto no?):
non saranno le 150 righe di Windows.... ma direi
che non va neanche tanto male.....
:))))))))
Saluti
Pegasus

 essere richiamata.
No, perche` chi l'ha fatta e` un idiota, non perche` *deve* essere chiamata.
Se c'e` una libc allora *DEVE* rispondere allo standard. Se non c'e` 
allora chiaramente no. Se c'e` e non risponde allo standard *NON E` UNA 
LIBC*.
Butta al cesso quella piattaforma.


 vera PSP c'è, mentre sull'emulatore no, e quindi....
E quindi chi ha fatto quella libreria aveva IL DOVERE di caricare il 
modulo al volo se gia` non lo era SENZA rompere il cazzo all'utente che 
deve fare una stupidissima allocazione di memoria.


 
Ed infatti il codice di malloc per PSP ti richiama
il modulo di memoria: sotto la vera PSP la malloc
dell'SDK ti funziona.
E' sotto l'emulatore che ti fallisce perchč
il codice binario richiama SceKernelLoadModule,
ma la chiamata fallisce perchč l'emulatore non
sta emulando alcuna directory "flash0:\".
Saluti
Pegasus


Ma sei sicuro?
Mi sembra difficile immaginare che la Sony non fornisca un insieme di
tool integrati (dalla IDE fino al debugger) per sviluppare su quella
piattaforma. Da come parli sembra che chi fa giochi per la PSP a
momenti programma come su un C64, anzi peggio.

>momenti programma come su un C64, anzi peggio.
No, la Sony fornisce un suo SDK ufficiale, ma solo ai loro
sviluppatori ed a 90.000 Euro.
Gli altri devono usare l'SDK non ufficiale.
Va segnalato che nel corso dei mesi si sono fatti sforzi non
indifferenti per cercare di rendere il tutto piů amichevole:
per esempio, si č integrato Dev-C++ con l'SDK della
Sony (quello che poi facciamo noi con Nanodesktop del
resto...).
Poi c'č Metrowerks che ha rilasciato il suo Codewarrior
per PSP, alcuni mormorano usando sotto l'IDE l'SDK
non ufficiale su cui si basa tutto il codice homebrew non
Sony, ma i costi, come ben capisci, sono molto
elevati.
Saluti
Pegasus

 linker molto stupidi devono avere -lm esplicito.
mi ero sempre chiesto il perché del -lm ! si impara sempre qualcosa di
nuovo :-)

 comprarlo....
di solito per le università o è a prezzo ridottissimo o proprio gratis.
Basta chiederlo.
Texas Instruments dà pure le schede gratis alle facoltà.
voi avete parlato con sony?

 sta emulando alcuna directory "flash0:\".
Ancora ti posso dire tranquillamente che avete toppato piattaforma in 
modo eclatante.
Sono riuscito a fermare il mio prof a buttarsi a capo fitto sul cell 
processor fino a quando non vedro` il primo cell IN MANO e funzionante. 
Voi avete fatto come sony, ed ora vi ritrovate con un prototipo che non 
funziona. Cambiate idea, risparmierete tempo ovvero denaro.
