Shadoware.Org - Mot-clé - xml

XINX v0.10.1

Ulrich Van Den Hekke — Tue, 03 May 2011 18:46:00 +0200

Bonjour à tous,

Je suis heureux de vous annoncer la nouvelle version de XINX. Cette version apporte, en plus de la ré-écriture complète de la gestion du contenu et de la complétion, son petit lot de nouveautés et de corrections.

La version 0.10.1 est beaucoup plus stable que sa grande soeur 0.9. Un soin particulier a été apporté à la recherche des sources d'anomalie possible, ainsi que des fuites mémoires. Ces opérations ont été faites grâce à des outils tels que valgrind, mais aussi grâce aux béta-testeurs (Merci à eux).

De plus l'utilisation des pointeurs intelligents de Qt ont permis de passer plus de temps, sur la gestion des structures et moins de temps sur la gestion de la mémoire, sur des parties du code assez critiques (comme ContentView et CodeCompletion). Ils ont également permis un partage plus facile des structures entre les différents threads avec moins de contrôle de synchronisation.

Liens

Gestion Projet et Gestion des sessions

Multi-projet

XINX est maintenant capable d'ouvrir plusieurs projets en même temps. Cela permet donc plusieurs choses :

Rechercher un fichier pouvant se trouver dans plusieurs projets différents (par exemple un projet trunk et un projet branche).
Comparer des fichiers venant de plusieurs projets différents.
Ne pas basculer d'un projet à l'autre en continu, lorsque l'on travaille sur plusieurs projets en même temps.

A cause de cette gestion de plusieurs projets en même temps, toute la partie de gestion de projet de XINX a été ré-écrite (entre autre la partie concernant la session, que l'on verra ensuite).

De plus à l'ouverture du projet, l'application recherche l'ensemble des fichiers présents sur le disque afin de permettre une recherche beaucoup plus rapide. Cela a néanmoins quelques répercussions : il n'est pas possible de supprimer un dossier du projet sans fermer XINX.

Inclusion / Exclusion de chemin

Afin d'avoir une vue propre, XINX affiche déjà uniquement les fichiers qu'il est capable de gérer. Il est également possible de lui définir une liste de chemin qu'il doit ignorer.

Exemple :

WEB-INF/lib
dico
configuration

Il est possible d'utiliser des expressions régulières pour définir ces chemins.

A l'inverse il est possible d'inclure un dossier externe au projet directement dans la vue de celui-ci. L'équivalent d'un lien symbolique mais propre au projet sous XINX. Il est alors possible d'inclure dans le dossier projet, un répertoire temporaire contenant les données utilisées par les feuilles de styles, ou inclure un dossier contenant des fichiers de logs, ...

Sessions

Suite à la gestion du multi-projet, il a fallu ré-écrire le système de gestion des sessions. Il est maintenant plus proche des systèmes de session des autres applications.

Alors que sur la version 0.9 et précédente, la session était directement associée à un projet (et donc ouverte en même temps), maintenant la session est séparée de la notion de projet.

Une session peut alors désormais contenir une liste de projet ouvert, une liste de fichier ouvert (associé ou non à un projet), des signets. Plusieurs sessions différentes peuvent pointer vers un même projet mais proposer une vue (un ensemble de fichier ouvert) différente. Une session par défaut est créée pour l'utilisation courante de l'application.

Modification du système de complétion

Le système de vue contenue et de code complétion a complètement été ré-écrit. La lecture des différents imports des différents fichiers est faite en mémoire (et non plus dans une base de donnée SQL) et en parallèle (s'il y a plusieurs processeurs sur la machine). La lecture des fichiers est ainsi plus rapide. Le système a complètement été ré-écrit pour que la complétion du code soit rapide et stable en même temps.

La complétion du code affiche désormais les différentes lignes dans des catégories suivant leur emplacement (par exemple le fichier où se trouve chaque template), les snipets dans une catégorie différente...

XINX est maintenant capable également de compléter

les paramètres des templates du type call-template
les imports (proposition des différents fichiers, et des alias si le plugin Generix est activé)

et plein d'autres choses

Et plein d'autres nouveautés

Utilisation de la librairie SVN directement

Un nouveau plugin pour SubVersion a été écrit. Ce plugin utilise directement les librairies de SubVersion au lieu d'utiliser l'exécutable svn. Ce plugin est plus performant que le wrapper et ne nécessite pas l'installation d'un client SubVersion (tel que CollabNet SubVersion sous Windows ou le client svn sous linux.

L'ancien plugin est toujours disponible et utilisable.

Créer des tickets depuis XINX

Une boite de dialogue permet maintenant de créer automatiquement un compte et un ticket sur le site Internet de XINX. Vous pouvez ainsi créer facilement des demandes d'évolution, des demandes de correction, ... De plus lors de la sortie d'une nouvelle version, XINX vous informera automatiquement qu'une nouvelle version est disponible.

Dock des logs et des erreurs

Le dock d'affichage des erreurs a été amélioré pour ne plus perturber l'utilisateur en s'ouvrant de façon intempestive. Il est maintenant possible de définir que le dock doit rester fermé, un compteur affiche alors le nombre d'erreur .

Modification de la recherche

Suite à la gestion du multi-projet, XINX peut maintenant rechercher dans plusieurs projets en même temps. Il est aussi possible d'arrêter la recherche en plein milieu.

Validation d'un fichier XML

XINX peut également valider un fichier XML à partir d'un schéma. Il ne peut malheureusement pas encore valider de fichier XSL (les parseurs XSL trouvés n'arrivent pas à lire les schémas des fichiers XSLT).

Correction de bugs

Beaucoup de corrections de bug ont été faites ce qui rend cette version très stable.

Et pour la suite ?

Dans la même série, j'ai l'intention de sortir une version avec de nouveaux modèles, de la documentation, ....

Pour la version suivante, le moteur JavaScript sera amélioré pour ne plus donner d'erreur, voir proposer de la complétion plus performante.

Parseur XML

Ulrich Van Den Hekke — Sun, 31 May 2009 23:13:00 +0200

Bonjours à tous,

L'utilisation des fichiers XML est, à ce jour, un fait dans la plupart des logiciels et est fortement à la mode. Une entreprise qui ne fait pas un peu de XML est souvent has-been. On utilise alors le XML à bon ou mauvais escient.

Avantages / Inconvénients

Pourquoi utiliser les fichiers XML ? Les fichiers XML sont, pour commencer, des fichiers textes, il seront donc toujours lisibles, ce qui garantit une meilleur pérennité de l'information. Les fichiers XML sont structurés hiérarchiquement et suivent une syntaxe stricte. Ainsi le XML est lisible informatiquement par les différents langages de programmation existant, pour organiser vos données, en utilisant différents niveaux. Les fichiers XML peuvent être commenté ce qui peut améliorer la lisibilité pour un humain.

Le gros inconvénient du XML est sa verbosité. Pour chaque noeud dans la hiérarchie, il y a une balise de début, et une balise de fin contenant le nom de la balise. Le fichier est moins compact que s'il avait été écrit en binaire. Cela peut poser des problèmes comme alourdir les communications réseaux (ex: pour les webservices). Le fichier est aussi plus long à lire qu'un fichier binaire et peut contenir des erreurs.

Si le fichier n'a pas besoin d'être hiérarchique, il est possible d'utiliser une structure de fichier INI pour ses données.

Nous nous arrêterons là pour les avantages/inconvénients. L'utilisation ou non d'un fichier XML est ensuite une question (besoin, éthique, ...) à se poser pour ses données et la nécessité de pouvoir les lire autrement que par le programme lui-même.

Performance des parseurs.

Je me suis amusé à effectuer le test de lecture de différents fichiers de donnée au format XML de taille différentes par une variété de parseur XML en construisant si possible un arbre DOM. Le but est donc de créer un objet par noeud/attribut du fichier XML et de reconstituer la hiérarchie.

Les parseurs choisis pour ce test sont :

QtXml : Le module XML de la librairie Qt (de la société Nokia)
LibXml2 : Une librairie C permettant de faire du parsing XML en utilisant DOM ou SAX
LibExpat : Un parseur orienté flux (plus proche de la méthode SAX que du DOM)
SCEW : Un parseur basé sur Expat générant un arbre DOM (donc un peu plus comparable aux autre parseur).
TinyXML : Encore un autre parseur XML
Xerces-C++ : Le parseur XML d’Apache
Oracle XML Parser : Le parseur d’Oracle propriétaire utiliser dans le serveur d’application.

Pour faire cette suite de benchmark^[1], j’ai utilisé la librairie QTestLib de Nokia/Qt. Je vous offre donc en avant première le résultat de ce test :

Temps de lecture d'un fichier XML en ms
	250k	9300k	11300k
Qt DOM	41,42 ms	2184,34 ms	2648,71 ms
LibXML2	16,55 ms	710,09 ms	874,42 ms
Expat (SAX)	5,95 ms	312,02 ms	393,58 ms
Oracle	23,24 ms	928,93 ms	1135,86 ms
Scew	12,05 ms	944,37 ms	1184,46 ms
Tiny XML	28,91 ms	1101,8 ms	1369,8 ms
Xerces (Apache)	25,03 ms	742,22 ms	904,62 ms

La conclusion de ce résultat signifie que le parseur inclu dans Qt (pour la construction d'un arbre DOM) est très lent ;). Mais pour une utilisation dans une interface graphique, sur de petits fichiers, ne devrait pas poser de problème.

Enfin le parseur le plus rapide (pour les gros fichiers) est Libxml2. Le parseur C d'oracle, bien que propriétaire n'a rien d'exceptionnel (si on compte avec les problèmes présenté également ci-dessous). Peut-être que la version Java est elle plus performante.

Vous pouvez retrouver quelques graphiques ci-dessous :

Le source du benchmark

Vous pouvez trouver attaché au billet, le source de l'application ayant servi au bench. Pour la partie utilisation du Parseur Oracle, il a fallut contourner plusieurs petits problèmes. Ceci est la joie des librairies propriétaires bien documentées.

Compilation avec le XDK 9

Lors de la compilation avec le XDK 9, l'application ne dépasse pas le stade du linkage. Les méthodes sont pourtant bien dans les includes. De plus les librairies sont bien précisées pour le linkage.

La définition faite dans le projet est :

XDKPATH = xdk9
XDK_LIB = -lxmlg9 -lxml9 -lxsd9
ORA_LIB = -lcore9 -lnls9 -lunls9 -lcore9 -lnls9 -lcore9
NET_LIB = -lnsl
LIBS += -L$$XDKPATH/lib $$XDK_LIB $$ORA_LIB $$NET_LIB -lpthread
INCLUDEPATH += $$XDKPATH/xdk/include

A la suite de ça, lors de la phase de compilation, on se retrouve avec les messages d'erreurs suivants :

g++ -Wl,-O1 -o xmlparserbenchmark libxml2parser.o expatparser.o xercescppparser.o oracleparser.o qtparser.o scewparser.o tinyparser.o tinyxml.o tinystr.o tinyxmlerror.o tinyxmlparser.o xmlparserbenchmark.o moc_xmlparserbenchmark.o -L/usr/lib -lxml2 -lexpat -lxerces-c -Lxdk9/lib -lxmlg9 -lxml9 -lxsd9 -lcore9 -lnls9 -lunls9 -lcore9 -lnls9 -lcore9 -lnsl -lpthread -Lscew/scew -lscew -lQtTest -lQtXml -lQtGui -lQtCore -lpthread
oracleparser.o: In function `parseWithOracleParser(QString const&)':
oracleparser.cpp:(.text+0x82): undefined reference to `XMLParser::xmlinit(unsigned char*, void (*)(void*, unsigned char const*, unsigned int), void*, xmlsaxcb*, void*, unsigned char*)'
oracleparser.cpp:(.text+0xa8): undefined reference to `XMLParser::xmlparse(unsigned char*, unsigned char*, unsigned int)'
oracleparser.cpp:(.text+0x2b4): undefined reference to `XMLParser::getDocumentElement()'
oracleparser.cpp:(.text+0x2ca): undefined reference to `XMLParser::xmlterm()'

J'ai alors essayé de recompiler les exemples de démonstrations mais là, même problème ...

Compilation avec le XDK 10

Avec cette version du XDK, nous avons le droit à deux problèmes. Le premier est une grosse fuite mémoire (si on écrit le programme tel que décrit dans la démo), et à un problème d'initialisation du parseur.

Le code permettant de parser le fichier XML et de générer l'arbre DOM ressemble à ceci :

CXmlCtx * ctxp = 0;
try {
	ctxp = new CXmlCtx();
} catch( XmlException & e ) {
	unsigned ecode = e.getCode();
	QFAIL( qPrintable( QString("Failed to initialize XML context, error %1").arg( ecode ) ) );
}
 
Factory<CXmlCtx,xmlnode> * fp = 0;
try {
	fp = new Factory<CXmlCtx,xmlnode>( ctxp );
} catch( FactoryException & fe ) {
	unsigned ecode = fe.getCode();
	QFAIL( qPrintable( QString("Failed to create create parser, error %1").arg( ecode ) ) );
}
 
DOMParser<CXmlCtx,xmlnode> * parserp = 0;
try {
	parserp = fp->createDOMParser( DOMParCXml, NULL );
} catch( FactoryException & fe ) {
	delete fp;
	unsigned ecode = fe.getCode();
	QFAIL( qPrintable( QString("Failed to create parser, error %1").arg( ecode ) ) );
}
 
const char * fname = filename;
FileSource * isrcp = new FileSource( (oratext*) fname );
try {
	DocumentRef<xmlnode> * docrefp = parserp->parse( isrcp, FALSE );
	if( docrefp == NULL ) {
		QFAIL( qPrintable( QString("NULL document") ) );
		return;
	}
	xmlnode * np = docrefp->getDocumentElement();
	if( np == NULL ) {
		QFAIL( qPrintable( QString("Empty document") ) );
		return;
	}
	docrefp->markToDelete();
	delete docrefp;
} catch( ParserException & pe ) {
	delete parserp;
	delete isrcp;
	delete fp;
 
	unsigned ecode = pe.getCode();
	QFAIL( qPrintable( QString( "Failed to parse the document, error %1").arg( ecode ) ) );
}
//	delete parserp;
//	delete isrcp;
//	delete fp;
//	delete ctxp;

Le premier problème se situe lors de la suppression du contexte (dernière ligne, en commentaire). Si cette ligne est exécutée, alors nous avons une grosse erreur de segmentation. J'ai le problème, quels que soient les delete que je fais avant. Même en faisant le maximum de delete (soit parserp, isrcp, fp), le fait de ne pas supprimer le context (ctxp), fait qu'au bout de plusieurs itérations, nous avons une bonne fuite mémoire^[2].

Vient ensuite le second problème, celui des erreurs d'intialisation. Si le parseur est lancé plusieurs fois de suite, alors l'application affiche les erreurs suivantes à l'écran :

LPX-00202: Message 202 not found; No message file for product=XDK, facility=LPX
FAIL!  : XmlParserBenchmark::oracleParser(file250k.xml) Failed to parse the document, error 202
   Loc: [oracleparser.cpp(73)]

Aucune explication sur le pourquoi. Parfois ça marche, parfois non... Pour contourner le problème, j'ai forké le parseur pour l'exécuter isolé du reste.

pid_t pid = fork();
if( pid > 0 ) {
	waitpid( pid, (int*)0, 0 );
} else if( pid == 0 ) {
	if( ! filename.isEmpty() )
		parse( qPrintable( filename ) );
	exit( 0 );
} else {
	QFAIL( "Cannot fork" );
}

Notes

[1] Ces tests ont été réalisé dans un chroot 32-bits allant à 2,4GHz. Les temps sont une moyenne sur 100 itérations

[2] Si quelqu'un a déjà utilisé ce parseur, et qu'il sait comment il fonctionne, il peut m'écrire