A differenza del caso FastWeb, il quale per il calcolo si basava solo sull SSID della rete, in questo caso ci serve anche il seriale del router che, come dimostrato dalla ricerca precedentemente linkata, è ricavabile tramite un sistema a due incognite dal quale, la WHC, ha tirato fuori una tabella di valori noti, tabella che ho inserito nel mio script.

Di conseguenza, a meno che il lettore non ampli la propria tabella a mano, seguendo le indicazioni della WHC, lo script funzionerà solo con SSID del tipo :

• Alice-96xxxxxx
• Alice-93xxxxxx
• Alice-56xxxxxx
• Alice-55xxxxxx
• Alice-54xxxxxx
• Alice-48xxxxxx
• Alice-46xxxxxx

Sono sicuro cmq che cercando nella rete delle tabelle un po più estese si trovano

Lo script è commentato (come il precedente), in modo tale il lettore avrà la possibilità non solo di utilizzarlo, ma anche di capirlo, che è la cosa che più mi preme al fine di una condivisione libera dell’informazione e della cultura informatica in generale.

Enjoy.

Related posts:

1. Script per il calcolo della chiave WPA dei router FastWeb Pirelli.
2. Alice Router Unlocker
3. Informazione di Servizio, Chiave Pubblica

“Bene” mi sono detto, “Se hanno questo servizio, avranno anche una pagina dove spiegano l’algoritmo e pubblicano il codice” .

Beh, la pagina c’era, e non era nemmeno un loro lavoro bensì quello di un altro gruppo (vedere il link “fonte” alla fine di quell’articolo), ma non c’era il sorgente!

In pratica, queste persone, hanno preso il lavoro che altri hanno pubblicato liberamente e per tutti, lo hanno ri-pubblicato (citando la fonte eh, per carità), ne hanno ricavato un servizio (guarda caso un servizio che fa gola a molti su un sito con degli ads pubblicitari) ma non hanno condiviso a loro volta le conoscenze distribuendo il codice del servizio … un po disonesto non vi pare?

Cioè, se io prendo un informazione libera, sono moralmente tenuto a rendere altrettanto libera qualsiasi opera io ne possa ricavare … non legalmente, ma moralmente.

Ebbene, ci penso io con un mio script fresco fresco

Vi posto qui di seguito il codice di uno script PHP che, seguendo quell’algoritmo, parte dal SSID di un router e stampa la chiave WPA di default.

Ribadisco, come loro, che :

Attualmente è possibile recuperare la chiave Wireless degli Access Point FastWeb Pirelli, nello specifico con i seguenti Mac Address:

00:08:27 Pirelli Broadband Solutions
00:13:C8 Pirelli Broadband Solutions
00:17:C2 Pirelli Broadband Solutions
00:19:3E Pirelli Broadband Solutions
00:1C:A2 Pirelli Broadband Solutions
00:1D:8B Pirelli Broadband Solutions
00:22:33 Pirelli Broadband Solutions
00:23:8E Pirelli Broadband Solutions
00:25:53 Pirelli Broadband Solutions
00:03:6F Telsey S.p.A. (in fase di Test)
00:21:96 Telsey S.p.A. (in fase di Test)

Detto questo, a breve pubblicherò uno script analogo ma per i router Alice, dato che stanno uscendo lavori anche in questo senso

Related posts:

1. Script per il calcolo della chiave WPA dei router Alice Gate VoIP 2 Plus Wi-Fi
2. Alice Router Unlocker
3. Informazione di Servizio, Chiave Pubblica

Il tutto si basa su una funzione di hashing che, prendendo in input la stringa della chiave, restituisce in output un numero intero (l’hash) univoco per ogni chiave o, in caso non sia univoco, gestisce queste “collisioni” di hash frammentando la tabella in più “bucket” .

Fatta questa introduzione, andiamo al nocciolo del discorso.

Era un po di tempo che avevo riscontrato dei bug in Hybris ma che, a differenza di tutti gli altri bug sia segnalati dagli utenti che trovati da me, non riuscivo ne ad isolare ne ad individuare nel codice … un casino insomma! XD

E cosa vado a scoprire? Che tutti erano dipesi proprio da quella libreria di Google! Le collisioni tra chiavi diverse e hash non univoci a quanto pare non sempre sono gestite, anzi studiandosi un po la questione sono riuscito a capire che questa libreria funziona bene solo quando la tabella contiene poche (qualche decina) chiavi, ma quando le chiavi iniziano a diventare parecchie (ed in Hybris sono usate ovunque, quindi sono veramente tante) le collisioni vengono gestite male e ne consegue che il lookup di una chiave, magari mai definita, invece restituisce il valore di un altra chiave che non c’entra niente invece di restituire NULL, indicando che la chiave non è definita.

Questo era un problema veramente grande, poichè le implementazioni nella libreria standard di questa struttura di dati (std::map) sono molto poco performanti, le altre che ho provato (boost e librerie di terze parti) son sempre poco performanti, e re implementare tutto da zero avrebbe richiesto settimane di codice e altre di tuning e ottimizzazione del tutto.

Di risolvere il bug nella libreria di Google proprio non se ne parlava, poichè andava riscritta praticamente da capo … insomma, mi son trovato davanti ad un bel dilemma!

Così mi son inventato un metodo tutto mio, utilizzando un albero n-ario, dove ogni nodo è composto da un valore (un carattere ascii),  un “end marker” (un puntatore all’oggetto mappato da una data chiave), e i nodi figli .

Diciamo di voler definire la variabile di nome “foo” .

A questo punto, la catena di nodi che verrà creata sarà :

f -> o -> o

E all’ultimo nodo (o) verrà impostato l’end marker con il valore della variabile, mentre gli altri end markers precedenti saranno impostati a NULL .

Ora definiamo “fag” :

f -> o -> o (ramificazione già esistente)

\

a -> g (nuova ramificazione)

E così via per ogni variabile, dove si creano nuovi nodi per catene non definite e se ne aggiungono degli altri per catene già esistenti.

Verificare l’esistenza di una chiave ed ottenerne, se presente, il valore associato a questo punto è facilissimo .

Basta traversare l’albero in base al nome della variabile, possono succedere a questo punto le seguenti cose :

- Il nome della variabile porta ad una ramificazione non esistente -> La chiave non esiste

- Raggiunta la fine della ramificazione, l’end marker è NULL -> Esiste una chiave che inizia con la stessa stringa di questa (esempio lolz e lol), ma non esiste questa in particolare.

- Raggiungiamo la fine della ramificazione e troviamo un end marker valido -> La chiave è definita e restituiamo l’oggetto associato.

In questo modo, si mantengono prestazioni analoghe se non superiori ad una hash table, l’intera struttura usa meno memoria (una hash table, per ogni elemento ha un istanza della chiave, mentre in questo caso ha solo l’istanza del suo ultimo carattere e l’end marker), e soprattutto è impossibile che ci siano collisioni !

Così è nato ASCII Tree, la struttura che ora viene utilizzata al posto della libreria di Google, problema risolto!

Un altra importante novità è che il garbage collector, da un approccio di reference counting è passato ad un approccio mark & sweep, molto più affidabile, veloce e soprattutto risolve alcuni problemi del vecchio garbage collector che mi ero prefissato di risolvere.

That’s all folks

Related posts:

1. Hybris memory lookup, now Google powered!!!
2. Come hackerare Google e rimanere indisturbato per un anno.
3. E anche ia64 è fatta! (god bless libffi)

E’ disponibile, presso questo repository, una libreria scritta in Hybris per connettersi al database Redis, progetto che sta facendo passi da gigante grazie al supporto della comunità open source e soprattutto del suo creatore Salvatore Sanfilippo.

Questa libreria vuole essere sia un omaggio che un contributo alla scena open italiana e soprattutto agli sforzi di uno sviluppatore brillante, in un paese che sembra ne incoraggiare ne ricompensare menti di questo tipo.

Related posts:

1. MSP – Multi-Dimensional Space Processing Library
2. [IMPORTANTE] Hybris 1.0 Roadmap, ho bisogno di consigli user-side
3. Hybris 1.0 beta, strutture e primo passo per l’OO

Fa eccezione http://stackoverflow.com/, l’equivalente di Yahoo Answers per programmatori, sistemisti e tecnici informatici in genere.

La logica è semplicissima … ci si iscrive, si fanno delle domande su qualche problema che si ha, si risponde alle domande delle altre persone e si accumulano punti.

Semplice quanto efficace, non ho mai visto tanti guru della programmazione in un unico sito … c’è davvero gente molto in gamba da tutte le parti del pianeta (tutte tranne l’Italia probabilmente, chissà com’è -.-), persone che oltre ad essere tecnicamente brave sono sempre disponibili a darti una mano.

Alcuni problemi che ho avuto con Hybris li ho risolti proprio grazie a loro, quindi mi sembrava carino omaggiare il servizio con un articolo.

Nient’altro … se siete curiosi il mio profilo è questo.

Related posts:

1. C Stack Inspection
2. Win32 Service Class
3. StackHack

Coooomunque … nell’ultimo commit, oltre a risolvere alcuni bugghettini del timer e della classe Context, ho trovato un metodo per rendere

import std.*;

Veloce quanto gli import singoli .

Ma prima riassunto delle puntate precedenti

Da qualche commit Hybris integra tutta la libreria standard tramite moduli esterni caricabili dall’utente con la direttiva import seguendo la gerarchia dei namespace .

Ovviamente, più moduli si importavano (quindi più funzioni si importavano), più erano elevati i tempi di risoluzione di una funzione, ovvero quell’intervallo di tempo in cui l’interprete trovava il puntatore alla libreria esterna per gestire una chiamata a funzione … questo perchè + elementi ci sono in una lista, + confronti vanno fatti prima di trovare un dato elemento.

Questo rendeva preferibile una digitura (ad esempio) :

import std.io.console;

Alla dicitura :

import std.*;

che caricava tutto indiscriminatamente …

Tant’è vero che, a parità di algoritmo e di hardware, lo stesso script impiegava 21 millisecondi con l’import selettivo, e ben 26 millisecondi (a volte di più) con l’asterisco.

Problema risolto!

Il lookup nella lista ora avviene solo la prima volta che viene chiamata una funzione, da quel momento il suo puntatore viene messo in una hash table di cache che verrà usata successivamente per il lookup .

Detto molto in parole povere, Hybris è ora in grado di capire quali funzioni vengono usate (e soprattutto quali più spesso), adattandosi di conseguenza … risultato ?

Entrambe le diciture ora occupano solo 21 millisecondi di esecuzione

Related posts:

1. Hybris, e così son tutti contenti.
2. [IMPORTANTE] Hybris 1.0 Roadmap, ho bisogno di consigli user-side
3. E anche ia64 è fatta! (god bless libffi)

Attualmente, bisogna dichiarare esplicitamente quali moduli importare dal namespace standard (chiamato appunto std), tuttavia son venuto incontro alle necessità dei più pigri (me compreso) che, non essendo interessati alla velocità di esecuzione, preferirebbero precaricare tutto il possibile per non dover dichiarare manualmente i moduli necessari.

Ho implementato l’operatore ‘*’ per gli import, ispirato al java, tramite il quale è possibile importare ricorsivamente interi namespace e loro derivati in una sola riga … ad esempio, se volessimo importare tutte le funzionalità di I/O (su file, console, stream xml, tcp/ip e http), basta un :

import std.io.*;

All’inizio dello script, oppure, se proprio vogliamo importare TUTTO, si può scrivere più semplicemente :

import std.*;

Questo operatore è valido SOLO se viene specificato il namespace principale (in questo caso std), ovvero una dicitura del genere :

import *;

Genererà l’errore :

Could not use ‘*’ as main namespace.

Questo perchè ho voluto pensare al futuro … ipotiziamo che un domani Hybris abbia 500 moduli implementati da utenti vari (magari! ^^), importare tutto con * significherebbe tempi di calcolo troppo eccessivi e troppe risorse richieste, invece indicando il namespace padre, rimane la comodità ma è più selettiva.

La libreria standard è composta dai seguenti moduli :

• std
  • math : Funzionalità matematiche
  • pcre : Supporto alle espressioni regolari
  • encoding : Funzionalità di encoding

• • io
    • console : I/O su console
    • file : I/O su file
    • xml : I/O su flussi XML
    • network
      • tcp : Primitive per i socket tcp/ip
      • http : Funzionalità HTTP e HTTPS

• • type
    • string : Gestione stringhe
    • array : Gestione array
    • matrix : Gestione matrici
    • binary : Gestione flussi binari
    • map : Gestione mappe associative
    • type : Gestione dei tipi
    • reflection : Introspezione dei tipi

• • os
    • dll : Caricamento ed esecuzione di funzioni da dll di sistema
    • threads : Multithreading
    • time : Gestione del tempo e della data
    • process : Gestione multi processo

Related posts:

1. Cogito ergo sum
2. [IMPORTANTE] Hybris 1.0 Roadmap, ho bisogno di consigli user-side
3. Spostata la documentazione di Hybris su Wiki

Questi tre giorni non sono stato a casa, ho passato la Pasqua (ah, a proposito, auguri in ritardo a tutti! ) con la mia fidanzata, la sua famiglia, amici ecc e ho avuto modo proprio di sperimentare su me stesso questo fenomeno …

Ho pensato a come è nato Hybris, al motivo per il quale è nato, a come si è evoluto nel tempo …

Inizialmente era un progetto quasi “intimo”, nel senso che non avevo intenzione alcuna di pubblicarlo, non tanto perchè sono geloso del mio lavoro (lol figuriamoci XD), ma perchè ero partito con la consapevolezza che non sarebbe mai diventato un qualcosa di completo e funzionale come un vero e proprio linguaggio di programmazione, bensì doveva essere il mio piccolo tool personalizzato/personale per automatizzare determinate cose che normalmente facevo a mano (una specie di linguaggio macro + specializzato insomma) e per questo non adatto ad altre persone che potessero avere esigienze e forme mentis diverse dalle mie.

Il tempo ha dimostrato quanto il mio presupposto iniziale fosse sbagliato, il tempo e la mia costante voglia di migliorare me stesso ed i miei software, e me ne sono reso conto benissimo, peccato che non ho (fino ad un giorno fa) considerato oltre al fatto in se stesso (che di per se in effetti è poco più di una sega mentale) le conseguenze sul mio lavoro che questa cosa possa avere.

Ok, giri di parole e pensieri contorti a parte, faccio il punto della situazione (finalmente) .

Pensando a questo post ed al topic del quale doveva essere una risposta, ho capito che su alcune cose avevo completamente torto o, se non altro, partivo da una visione ristretta delle cose.

Hybris non è più il “mio giocattolo”, non lo è da quando ho eseguito il primo commit su github e da quando ho aperto un sito dedicato … mi son reso conto di quanto sia stato arrogante e stupido da parte mia voler “regalare” un qualcosa alla comunità, e poi, quando qualcuno mi faceva notare (in modo brusco ok, ma non tutti siamo perfetti) lo standard qualitativo che questa comunità impone, ignorare la cosa e voler fare di testa mia continuando a considerare Hybris “il mio giocattolo” … arrogante, stupido ed incoerente … mea culpa.

Da questa deduzione son seguite delle decisioni.

Prima di rilasciare la 1.0 stable, saranno implementate le seguenti cose :

1. Supporto completo sia per Linux (come ora), per Windows e possibilmente per *BSD.
2. Supporto completo alla programmazione object oriented, polimorfismo, ereditarietà, ecc.
3. Reimplementazione della libreria standard tramite moduli dinamici .
4. Implementazione di una seconda libreria standard, tramite classi scritte direttamente in Hybris.

Ebbene, mi serve un consiglio da chiunque abbia voglia di aiutarmi … sono indeciso sul punto 3.

Ho studiato la situazione e ci sono tre approcci possibili, ognuno con i suoi pro ed i suoi contro, che mi accingo ora a spiegare.

** Libreria standard integrata nel core.

Questa è la situazione attuale di Hybris, le funzioni standard sono integrate nel core stesso di Hybris, quindi per un ambiente funzionante non servono moduli aggiuntivi se non l’eseguibile stesso dell’interprete.

Pro :

• Nessun modulo da distribuire insieme all’interprete.
• Non occorre dichiarare quale modulo importare per usare la singola funzione (tipo l’include del C/C++).
• Estrema interoperabilità tra libreria standard e core.

Contro:

• Uso maggiore di memoria.
• Tempi di lookup di una funzione più elevati.
• Non è possibile implementare una nuova funzione che abbia il nome di una funzione già presente nella libreria.

Esempio :

page = http_get( “www.hybris-lang.org”, “/” );
if( page && (page ~= “/<body>.+<\/body>/im”)[0] ){
print(page);
}

** Libreria standard implementata in moduli dinamici separati.

Questo è il metodo nel quale son realizzati molti dei linguaggi esistenti attualmente, il core di per se è piccolo e non gestisce le funzionalità del linguaggio, ma offre un insieme di funzioni ed oggetti per realizzarne, in questo caso tutta la libreria standard è implementata in moduli esterni che vengono caricati a scelta dall’utente in base a quello che serve, un po come quando in C scriviamo un “#include <stdio.h>” e linkiamo la libc .

Pro :

• Uso della memoria nettamente inferiore.
• Tempi di lookup di una funzione ridotti (naturalmente rispetto a quanto è grande il set completo, per capirci se il set è composto da 20 elementi la differenza nemmeno si nota).
• Possibilità di usare nomi di funzioni che sono nella libreria ma che non vengono inclusi.
• Possibilità di caricare selettivamente una o più funzioni dal singolo modulo invece di caricare tutto.

Contro :

• E’ necessario dichiarare esplicitamente quale moduli importare in base alle funzioni utilizzate.
• Oltre all’interprete stesso, vanno distribuiti i moduli dinamici della libreria standard.
• Meno interoperabilità tra core e moduli.

Esempio :

import io.network.http;
import io.console;
// oppure, per caricare selettivamente alcune funzioni dai moduli
import io.network.http.[get];
import io.console.[print];

page = get( “www.hybris-lang.org”, “/” );
if( page && (page ~= “/<body>.+<\/body>/im”)[0] ){
print(page);
}

** Soluzione ibrida, libreria esterna, preloading e lookup dinamico.

Questo è un compromesso tra le due soluzioni, la libreria standard risiede in moduli esterni, tuttavia l’interprete “è al corrente” di questi moduli e, quando trova nel codice una funzione che ancora non ha caricato, la carica dinamicamente trovando il modulo relativo.

E’ difficile stabilire esattamente i pro ed i contro di questa soluzione, poichè i tempi di lookup, memoria utilizzata, ecc dipendono completamente dallo script che va eseguito … più funzioni di moduli diversi si utilizzeranno, più cose verranno precaricate in memoria, più sarà lento il lookup.

Tutta via questo metodo consentirebbe di non dover necessariamente dichiarare gli imports di un dato script come nella seconda soluzione, quindi mantenendo la comodità della prima e, in un caso ottimale (poche funzioni usate o tante funzioni ma da pochi moduli o algoritmi poco complessi), l’efficienza della seconda.

** Conclusione

Bon, detto tutto questo, ho bisogno di consigli … la domanda è semplice :

Se voi foste degli sviluppatori che usano Hybris, quale dei tre approcci preferireste ?

Esponete qui nei commenti la vostra opinione, possibilmente motivata, in base alla quale mi aiuterete a scegliere quale approccio implementare per la 1.0 stable di Hybris.

Let me know

Related posts:

1. Hybris, e così son tutti contenti.
2. Cogito ergo sum
3. Hybris : Rivoluzionato il sistema di gestione dei tipi ed il garbage collector.

Ho appena effettuato il commit della 1.0 beta che, oltre a correggere alcuni bugs che affliggevano il lexer ed il parser di Hybris, presenta una grande novità … le strutture !

Sostanzialmente, una volta implementate quelle e trovato il modo di gestirle al meglio (non vi immaginate che casino scrivere le regole del parser XD), il passo verso l’OO è un attimo, basta qualche piccolo ritocco qua e la ed ecco che Hybris diventerà un linguaggio che supporta al 100% la programmazione ad oggetti, ma per questo, stavolta dico davvero, è il caso di aspettare il rilascio della 1.0.

Ma vediamo un po queste strutture ^^

Nella documentazione ho scritto che :

Una struttura è un tipo di dato arbitrario, ovvero che può essere definito dall’utente tramite la direttiva struct. Una struttura è identificata da un nome e da uno o più attributi, la forma più semplice per dichiarare una struttura è :

 
   struct UnNome {
      attributo_1;
      attributo_2;
   }

O, nella forma abbreviata :

 
   struct UnNome {
      attributo_1, attributo_2;
   }

Per creare una variabile del tipo che abbiamo dichiarato, useremo il nome della struttura come fosse una funzione (più o meno come i costruttori del C++) :

 
   a = UnNome();

Oppure sfruttando l'inizializzatore degli attributi :

 
   a = UnNome( "ciao", 1234 );

Che attribuirà quei valori rispettivamente a attributo_1 e attributo_2.

Per accedere ad un attributo, si può usare l’operatore -> :

 
   println( a->attributo_1 );

Vediamo un esempio più esplicativo .

 
   struct Carattere {
      simpatico;
      sveglio;
      modesto;
   }

   struct Persona {
      genere;
      nome, cognome;
      anni;

      carattere;
   }

   guy            = Persona( 'M', "Mario", "Rossi", 24 );
   guy->carattere = Carattere( "Si", "No", "Si" );

   println(guy);

   if( guy->anni >= 18 ){
      println( guy->nome." ".guy->cognome." è maggiorenne." );
   }
   else{
      println( guy->nome." ".guy->cognome." è minorenne." );
   }

   if( guy->carattere->sveglio == "Si" ){
      if( guy->carattere->modesto == "No" ){
         println( guy->nome." ".guy->cognome." è una persona arrogante." );
      }
      else{
         println( guy->nome." ".guy->cognome." è un tipo sveglio." );
      }
   }
   else{
      println( guy->nome." ".guy->cognome." è un po tonto." );
   }

La cosa più tosta da gestire è stata l’eventualità, come nell’ultimo esempio, di una struttura che a sua volta contenga una struttura … in pratica ho dovuto reimplementare un mini lookup di symboli per questa tipologia di dato … fatto quello, dopo un paio di giorni (insonni) di bestemmie, il risultato è venuto fuori quasi da solo ^^

PS : Non so perchè ma la possibilità di inizializzare gli attributi di una struttura tramite il suo dichiaratore anche se non è stato implementato alcun tipo di costruttore (del resto non è ancora concepita una cosa del genere nella logica di Hybris) mi piace da morire

Related posts:

1. Hybris v1.0 beta 3, tante le novità!
2. Hybris v1.0 beta 3, tante le novità!
3. Hybris, da ora Object Oriented!

Errata corrige : A volte son figo senza saperlo.

In questo articolo spiegavo la nuova hash table per il lookup delle variabili in memoria e, nel passaggio :

Purtroppo ci sono alcuni limiti che non mi consentono di eliminare del tutto il vecchio comportamento della classe Map, poichè oltre ad un associazione [chiave -> valore] utilizza anche altre associazioni [indice -> chiave], [chiave -> indice] e così via che non sono gestibili dalla hash table, tutta via sono fiducioso che in futuro, magari entro il rilascio (che è vicinissimo) della 1.0, troverò il metodo per risolvere o quanto meno aggirare questo problema.

Parlavo degli indici ordinali come un “limite”.

Ebbene, va fatta una piccola precisazione.

Ci sono due tipi di mappe/tabelle, disordinate nelle quali gli elementi non si trovano nella stessa sequenza in cui vengono inseriti, ed ordinate dove invece gli elementi si trovano nello stesso ordine di inserimento.

E’ ovvio che, dovendo accedere tramite indice, mi servisse una mappa ordinata e così ho provato varie implementazioni alternative per eliminare la classe che ho implementato io … ho provato std::map, tr1::*, boost::* e ho visto che, in qualsiasi caso, il mio compromesso di tenere parallelamente una tabella ed un vettore … è il più veloce!!

Quindi problema uno risolto

L’odissea dei 64bit

Fin da quando ho implementato le funzionalità per il loading dinamico delle librerie di sistema mi son trovato davanti una bella gatta da pelare.

La vecchia versione della funzione dllcall era implementata in inline assembly, poichè doveva passare argomenti arbitrari ad un puntatore a funzione generico, quindi li pushava uno ad uno in ordine inverso sullo stack e poi chiamava la funzione.

Il problema era che, essendo assmbly scritto per x86, era compatibile solo con architetture a 32 bit, di conseguenza mi son trovato costretto ad inserire un bel blocco #ifdef che escludeva quella funzione nel caso rilevasse la compilazione in un ambiente a 64bit .

Data la calling convention totalmente diversa tra x86 e ia64, reimplementare dell’altro assembly non era una grande idea, e così mi son scervellato per trovare una soluzione alternativa.

Inizialmente mi hanno suggerito le funzioni makecontext/swapcontext ma non le ho potute usare poichè volevano la lista degli argomenti della funzione per esteso, cosa che non potevo fare avendoli in un vettore di dimensione arbitraria.

Così, gira che ti rigira, ho trovato la spettacolare libffi che è proprio quello che mi serve!

Questa libreria, usata da tanti altri linguaggi tra i quali il Python, è nata appositamente per richiamare funzioni scritte in C da linguaggi di livello più alto, offrendo un substrato di conversione dei tipi a ctypes .

Dopo un po di bestemmie per capirne la documentazione (pressochè nulla, tanto per cambiare), per correggere una prima implementazione che non andava (un grazie enorme a fyskij che mi ha fatto da tester fin quando non son riuscito ad installarmi una vm ia64), ecc ecc son fiero di annunciare che ora Hybris è pienamente supportato da piattaforme a 64bit e teoricamente da qualsiasi altra piattaforma!!!

Documentazione parte 2, speravo di non doverlo fare mai più

Tanto per “staccare” un po la spina dal codice, mi son messo a buttare giù uno pseudo standard xml per documentare le funzioni di Hybris, in modo tale da poter elaborare questi file velocemente per crearne documentazioni html, pdf, libri, enciclopedie, carta igienica e quant’altro .

Così, con tanto olio di gomito, ho riscritto tutto creado il nuovo repository hybris-doc-it che, oltre a contenere gli xml suddivisi per categoria, contiene anche un paio di script per la conversione in file html che utilizzo in questo sito.

Ci sarebbe tanto altro da dire, ma son stanco e la 1.0 è vicina … alla prossima!

Related posts:

1. Cogito ergo sum
2. Spostata la documentazione di Hybris su Wiki
3. Hybris memory lookup, now Google powered!!!