ARMIN: Architecture Reconstruction and Mining 2

Le mie avventure con armin procedono meglio di quanto potesse sembrare al momento del
primo post a riguardo. Per cui l'obiettivo è dare l'esame entro due settimane.

Comunque la cosa che trovo al momento più interessante è il fatto che questo strumento si appoggi a due file (semplici file di testo, per fortuna) distinti per compiere il suo lavoro.
Il primo file è uno schema, una definizione di relazioni per cui, potenzialmente, ne possiamo aggiungere ad oltranza per spiegare meglio i rapporti tra i vari componenti di un'architettura software.
Il secondo è un file generato attraverso un parser: il rigi. E' interessante notare la semplicità del report del rigiparse che consiste in un file di testo con 3 colonne: ; per cui se la funzione fkt3 accede alla variabile var3 nel file .rsf (Rigi Standard Format) trovo:

accesses fkt3 var3

Riga che verrà correttamente interpretata da ARMIN grazie alla presenza nel file .txt di schema della riga:

accesses, function, variable

che definisce la relazione accesses.
A questo punto credo che il grosso lavoro "concettuale" sia fatto dal parser, che deve tracciare la presenza e l'utilizzo delle funzioni e delle variabili, mentre ARMIN si occupa di raccogliere queste informazioni, collegarle e renderle visualizzabili.

Resta il dubbio sull'utilizzo del package borland.. appena ho tempo indagherò bene sulle funzioni di quelle classi

mtr - a network diagnostic tool

Visto che per l'ennesima volta stavo monitorando la mia adsl con questo tool, ho deciso di dedicare qualche riga a mtr, un tool pratico e leggero per analizzare la situazione della rete, nel caso qualcuno non l'avesse mai sentito.

Premessa:la mia fottutissima linea VOIP ha un sacco di problemi.
Quando mi chiamano a casa, c'è una buona probabilità che la linea cada nei primi 5 secondi (giusto il tempo di capire chi chiama). Se invece si passa indenne questa prima fase, si può parlare all'infinito. Questo capita soprattutto durante il giorno ed, usando mtr, coincide con un alto ping tra il mio gateway voip ed il primo hop.
Perdere 200/300 millisecondi tra casa mia e la centralina di riferimento non mi sembra ottimale.. Mentre la sera questa latenza scende ad un valore più accettabile (ma comunque alto) di 85-120.
Vabbè, arrivo al dunque: questo tool è semplice da usare e vi elenco i parametri più comuni:
mtr <opzioni> <nome-host>
dove le <opzioni> possono essere:
* -c <count>: manda <count> pacchetti su cui fa una breve statistica (min, max, avg e deviazione standard)
* -r: modalità report: in combinazione con -c stampa i risultati dopo pacchetti
* --interval <seconds>: attesa in secondi tra un pinh e l'altro
* --no-dns per non risolvere gli hostname ma lasciare gli indirizzi ip

quindi per dare un'occhiata rapida allo stato della rete:
mtr -c 5 -r www.debian.org

per mandare invece pacchetti fino all'interruzione con control-c:
mtr www.debian.org

Sinceramente secondo me ci sarebbero delle migliorie da fare, del tipo al control-c stampare il report, perchè allo stato attuale lanciare mtr -r www.debian.org non ha alcun senso..

Il calcolo parallelo

Nonostante l'esame di domani (uno degli ultimi dannatissimi 4 esami che mi mancano), spendo qualche minuto per citare una definizione di calcolo parallelo data dal mio docente sulle slide del corso.

Non so se è farina del suo sacco o è a sua volta una citazione, ma è sicuramente di grande effetto.. e mi ha colpito, anche se forse ci sarebbero da aggiungere delle precisazioni..

Il calcolo parallelo è un tentativo di massimizzare quella risorsa infinita ma apparentemente scarsa chiamata tempo.

spettacolo :)

Funzionamento CDT part2

Un punto da chiarire che ho tralasciato nel post precedente è che CDT non è un compilatore, ma un ambiente di sviluppo, un IDE, a sua volta incluso in un IDE, Eclipse. Le operazioni che esegue sono quindi finalizzate a supportare l'utente nella stesura del codice e non alla creazione di eseguibili.

Per far questo fornisce al programmatore un aiuto considerevole in fase di sviluppo grazie principalmente a tre caratteristiche: la ricerca, la navigazione nel codice (ricreando una outline per raggiungere e organizzare alcuni punti salienti del file sorgente) ed il content assist (cioè fornisce suggerimenti legati al contesto).
Per raggiungere questo obiettivo, puntando anche a mantenere alte le prestazioni, si è resa necessaria la stesura di una serie di componenti atti all'analisi del codice, attività che si svolge in due macro fasi: Scanning/Preprocessing e Parsing (vedi questo post) .

Altro nodo centrale è la compatibilità tra compilatori. Infatti esistono innumerevoli compilatori C, ognuno con supporto a diverse caratteristiche e con diverse estensioni che li rendono generalmente incompatibili. L'obiettivo di CDT è di effettuare in modo ottimale il parse per del codice da compilare con GCC, il Gnu C Compiler.