I componenti di gambas

[Lux]

Ciao a tutti, avrei bsogno di tpogliermi una "semplice" curiosità.
come faccio a studiare e quindi visualizzare il codice dei componenti (ad esempio quello v4l, oppure quello sdl ecc..)?
Mi piacerebbe capire come sono fatti e come funzionano.
In teoria potrei crearne uno anch'io utilizzando gambas, vero? o serve per forza il c?
Ciao.

[fsurfing]

credo che per vedere come sono fatti tu debba visionare il codice sorgente
in teroria puoi svilupparli anche con gambas ..mi pare di ricordare che sul sito di gambas ci sia una guida

[leo72]

Tutto il sorgente di Gambas è contenuto nei vari paccehtti delle varie versioni che puoi scaricare sia da questo sito che da quello ufficiale.
Basta scompattare il pacchetto e troverai le cartelle con i sorgenti dei vari componenti. Dentro ad app/src c'è invece l'IDE di Gambas in... Gambas, che puoi caricare da Gambas e modificare come vuoi :-)

[md9327]

La maggioranza dei file sorgenti sono scritti in C/C++, alcuni (come ad esempio l'IDE, sono scritti direttamente in linguaggio Gambas.

[Ceskho]

Ma se L'IDE di gambas è scritto in Gambas vuol dire che è nato prima il linguaggio gambas o il suo ambiente grafico? cioè è nato prima l'uovo o la gallina?

[md9327]

L'ide di gambas, in realtà, è nato come applicazione a parte, prodotta da terze parti, che poi il team ha incluso all'interno del pacchetto.
Da quello che mi ricordo, inizialmente gambas non aveva un ambiente completo come ora, ma si appoggiava su alcuni moduli che, uniti, formavano una sorta di ide; sempre se non ricordo male, l'ambiente era composto da una serie di finestre a sè stanti: un finestra per il menu, una per i componenti grafici, una per l'elenco dei file del progetto; ognuna poteva essere spostata indipendentemente dalle altre sul desktop, e la cosa poteva anche non essere molto funzionale.
Appena raggiunto un certo grado di maturità, la pre-ide fu incorporata in Gambas, soppiantando il vecchio sistema, ovviamente integrando anche altre funzionalità.

Se vi scaricate i sorgenti dal sito ufficiale, vi accorgerete che molti moduli, a prescindere l'ide, sono interamente scritti in Gambas; questi, ovviamente, non vengono compilati con i sorgenti C++, ma integrati nel prodotto finale (o librerie). L'ambiente ide è in effetti una pacchetto di sorgenti Gambas, interpretati appunto dall'interprete.

[leo72]

@Ceskho:
è ovviamente prima nato il linguaggio. Poi è arrivato l'IDE ed, avendo un linguaggio completo di cui disporre, è stato (giustamente) deciso di scegliere quello per sviluppare l'ambiente di sviluppo. Anche per mostrare le capacità stesse di Gambas.

@md9327:
l'ambiente di sviluppo multifinestra è detto SDI, se non ricordo male, ma non è un modo di lavorare ormai superato. Pensa che ancora diversi progetti utilizzano questa divisione: GIMP ne è forse attualmente il rappresentante di punta. Ma mi viene da pensare anche ad altri software.
Poi è stato deciso di scegliere l'impostazione MDI, con le finestre che venivano aperte all'interno dell'applicazione principale. Infine si è passati alla sistemazione attuale, dove al posto delle finestre si hanno sezioni varie.
Sistemazione che può piacere o meno. Sicuramente dal lato della "pulizia" è meglio: si ha tutto in una unica finestra, così come non si riempie la taskbar di tanti task. Però non era male neanche la versione SDI.

[md9327]

Sì, il concetto si chiama SDI, ma io non avevo scritto che era superata, solo che la consideravo poco funzionale, ma il discorso dipende dai punti di vista.
A me piace più un singolo ambiente, specialmente se si hanno un mucchio di altre finestre aperte, da riempire il task; e poi con tutte quelle finestre ti becchi pure un raffreddore... :-)

Comunque, sono andato a rivedere i vecchi backup dei sorgenti, e in effetti ricordavo bene: l'IDE seconda serie, quello per intenderci MDI senza toolbar (l'attuale), era un'applicazione sviluppata fuori dal team; dopo un certo numero di release è stata incorporata nel progetto, e poi evoluta a come è ora.

[Lux]

Grazie mille raga! ho un solo problemino con i componenti....che sono scritti in c/c++. Per capirci qualcosa mi tocca prima imparare il c/c++ e la cosa è abbastanza lunga....conosco appena le basi del c++...Ma nessuno scrive componenti in gambas?
Avrei una domanda, come dovrei fare se per assurdo diventassi bravo con gambas a capire come funziona un componente tipo quello pche mi consente di leggere la musica?
Provo a spiegarmi meglio, se volessi creare un lettore di video/audio con gambas senza dover usare ad esempio mplayer dovre potrei studiare per capirne il funzionamento e quindi poter proggettare un componente tutto mio?
ciao.

[fsurfing]

credo per per fare un componente per visualizzare audio e video senza appoggiarsi a librerie esterne , dovresti leggerti pagine e pagine di documentazioni varie sul funzionamento del kernel e vari  e poi quasi sicuramente scriverlo in c++ .

molto meglio appoggiarsi a delle librerie già esistenti (xine , gstreamer , ecc ecc) almeno per il video, visto che per l' audio i componenti gb.music e gb.sound sono + che sufficenti, io mi sono fatto un player audio tempo fa senza particolari problemi.

[leo72]

I componenti di Gambas sono scritti in C/C++ per sfruttare la velocità di questo linguaggio compilato.
Ciò non toglie di scrivere un componente in Gambas, è in effetti permesso e lecito. Ma devi prima considerare cosa dovrà fare il componente: se è qualcosa che dovrà eseguire calcoli onerosi e lunghi, allora ricordati che la velocità di esecuzione sarà il suo tallone di Achille.

[Lux]

Ok, diciamo che quindi mi tocca imparare anche il c++(almeno le basi per capire qualcosa dei componenti)
Ora ho un paio di domandine da ignorantone quale sono :cry:
Se ho ben capito gambas ha bisogno di un "traduttore" per funzionare come ad esempio java o python, giusto? mentre in c/c++ no, è per questo che un componente in gambas è più lento?
Allora visto che ne capisco poco mi chiedo, come fanno il c/c++ a funzionare se non c'è un traduttore o meglio ancora, perchè gambas/java/python hanno bisogno di un "traduttore"?
Cambiando piattaforma invece mi vien da chiedere, sotto windows, quando si programma in visual basic, anche quello ha bisogno di un traduttore? Chiedo questo perchè mi sembrava d'aver capito che in ambiente windows la maggior parte dei programmi (cito i più comuni: pinnacle, adobe cs(flash, premiere, dreamweaver, ecc...))era sviluppata in basic e non in c/c++, quindi forse anche questi usano componenti che invece sono scritti in c/c++?
Ma esiste un linguaggio che conviene imparare o è meglio conoscerne più di uno e magari miscelarli?
 :ot: Perchè la documentazione di gambas non si può stampare? Almeno così mi dice quando provo a farlo....
Ciao e grazie mille!

[leo72]

1)
Non è necessario imparare il C/C++. Puoi benissimo scrivere delle classi invece che dei componenti: le classi che rachiuderanno i tuoi algoritmi potranno così sempre essere importati dentro altri programmi. In effetti questo è il primo step (l'uso delle classi) per creare routine riusabili.

2)
Quella che cerchi di capire tu è la differenza che c'è fra un linguaggio interpretato ed un linguaggio compilato. Partiamo dal secondo tipo....
Inizialmente i linguaggi nacquero tutti come compilati: esisteva un ambiente di scrittura che salvava del codice sorgente che veniva poi tradotto da un compilatore in linguaggio macchina, l'unico linguaggio che una CPU può "capire" senza bisogno di un intreprete intermedio. I vantaggi di un programma scritto in linguaggio macchina erano evidenti: possibilità di eseguirlo immediatamente, velocità massima di esecuzione (il programma non doveva essere tradotto in qualche altro linguaggio dato che il linguaggio macchina è inteso dalla CPU senza problemi), compattezza del codice, oscuramento del sorgente (un file contenente linguaggio macchina è un'insignificante lista di numeri incomprensibili).
Anche il BASIC nacque come linguaggio compilato, almeno nelle sue prime versioni.

Quando i computer divennero più veloci e potenti (maggior potenza della CPU, maggior quantitativo di memoria, più spazio di archiviazione), si diffusero i linguaggi interpretati. In questo caso, si ha un programma che funge da "interprete", vale a dire che legge del codice sorgente scritto in un linguaggio più familiare per l'uomo e lo traduce in istruzioni eseguibili dalla CPU. Gli svantaggi rispetto ad un linguaggio interpretato sono nel maggior consumo di risorse (si deve caricare in memoria sia un interprete sia il programma da eseguire) e nella minor velocità di esecuzione (perché l'interprete deve leggere il codice e trasformarlo in qualcosa di comprensibile alla CPU mentre un programma compilato è già salvato in linguaggio macchina direttamente eseguibile dal processore). Il vantaggio principale che si ha nell'uso di un linguaggio interpretato è quello di avere un ciclo scrittura/esecuzione notevolmente ridotto: non è necessario passare dalla fase della compilazione per eseguire un programma scritto con un linguaggio interpretato (chi compila i programmi da sorgenti sa quanto a volte la fase della compilazione possa essere lunga.
I BASIC degli anni '80 erano tutti interpretati: si ricordi ad esempio il Commodore BASIC del C64 o dell'Amiga, ad esempio, oppure il vecchio GW-BASIC presente nell'MS-DOS. Ma anche il Visual Basic è un linguaggio interpretato: si devono avere infatti le cosiddette librerie di run-time installate sul proprio PC per eseguire un programma scritto in VB.

Esiste anche una forma intermedia, quella che ricorre all'uso del cosiddetto bytecode. Il bytecode è un formato intermedio fra il linguaggio macchina ed il testo semplice: il bytecode viene eseguito più velocemente di un programma interpretato perché è un codice che l'interprete non deve rianalizzare ma è già pronto per la traduzione in linguaggio macchina, quindi la sua velocità di esecuzione risulta maggiore.

Molti linguaggi interpretati moderni adottano questa tecnica: dal Java al Python a Gambas. Anche Gambas, che ovviamente deve avere l'interprete installato sul PC su cui girerà il programma, traduce il sorgente in bytecode.