Discussion :

[Invité]

Bonjour,

Encore une petite question
Je sais, je commence à abuser. Pour moi, l'idéal serait de pouvoir intégrer directement du code C(++) dans Lazarus mais c'est impossible. Le compilateur Free Pascal est écrit en Pascal d'après ce que j'ai lu. Ceci explique certainement cela.

Mais, normalement, il est possible de créer des fonctions "Free Pascal" à partir de sources C(++) grâce à l'utilitaire h2pas : http://wiki.freepascal.org/Creating_...C_libraries/fr.

Malheureusement comme souvent, le tuto est "défectueux". D'abord le programme servant de support est trop ambitieux et inutilisable. Il aurait été plus simple d'intégrer une fonction "racine carré de".
Les explications sont incompréhensibles :

"[...] donc h2pas se lance sans erreur. Mais l'unité créée n'est toujours pas prête. Lisez plus loin.
Ajoutez ceci à la propriétéUndefines:
MPI_INCLUDED
MPIO_INCLUDE
NEEDS_MPI_FINT
MPI_BUILD_PROFILING
MPICH_SUPPRESS_PROTOTYPES
MPI_Wtime
HAVE_MPICH2G2
FOO
HAVE_PRAGMA_HP_SEC_DEF
Et ceci à la propriété Defines:
MPICH2
MPICH_NEW_MPIIO"

Ah !!! ??? Il faudrait déjà que h2pas se lance sans erreur. Mais en supposant que ce soit le cas, il est marqué : "Lisez plus loin"... Rien vu à ce sujet.

J'ai essayé sur ma fonction substRegEx développée en C (gcc). Et le résultat n'est pas concluant. Mais cela vient peut-être de la déclaration nécessaire à l'interface au niveau du C : dans le code source de la bibli, faut-il déclarer la fonction comme on le fait traditionnellement pour obtenir une librairie dynamique appelable par Lazarus ? Si tel est le cas, il y a un bug car la fonction substRegEx placée dans mylib.dll (ou mylib.so) fonctionne tout-à-fait correctement quand dans Lazarus, on charge la librairie puis déclare la fonction. Mais je ne suis pas sûr, qu'il faille déclarer la librairie ainsi car dans l'exemple fourni, il manque le fichier.h qui permet de détricoter tout le reste Est-ce que le "truc" du dessus est une réponse à ma question ?

Petit doute supplémentaire : il est marqué je ne sais plus où que l'outil H2pas n'est pas "terminé". Cela veut dire quoi exactement ? Comme l'init TregEx, un bout de code qui a le mérite d'exister mais qui reste ultra limité voire inexploitable ?

Quelqu'un a-t-il pu faire le tour de H2pas ou même produire un .pas à partir d'un bout de C(++) même minuscule ?

Une petite conclusion
Bon, les vacances scolaires se terminent dans ma zone et donc aussi le temps 100% consacré pleinement à Lazarus depuis 15 jours... [sauf quand j'ai fait des "substituts" en C(++)].

J'avais pour ambition de créer un programme de retouches de Gifs animés fonctionnant sous Windows et Linux (Gnome) [en une semaine] et d'utiliser la deuxième semaine pour examiner l'intégration de QT dans Lazarus (en comparaison avec l'excellent couple QT4/C++).

J'ai dépassé de 100% le temps "espéré" (la semaine) pour le programme de Gifs animés. J'étais parti sur une base de 6 jours compte tenu du fait qu'il y a 2 ans, pour permettre à mes élèves d'agrémenter leurs articles Joomla avec ce genre d'animations, 3 jours m'avaient été nécessaires pour réaliser un programme identique en Delphi 2007 [mon vieux Delphi 7 n'intégrant pas (disons mal) la bibli TGifImage]. Et là je dois dire, à cette époque, avec Delphi, le développement fut un vrai plaisir Comme pendant les quinze jours, j'avais décidé de travailler sous Win et Nux , sachant que la TGifImage n'existe pas en Lazarus, j'avais espéré qu'un allongement de 100% par rapport à Delphi (donc 6 jours) suffirait.

En Lazarus, sous Linux, premier soucis -mais j'ai rapidement éludé le problème-, les tests passés sous KDE -même avec le dernier Kubuntu- ne sont pas concluants. Il faudrait regarder cela de près. Il y a visiblement un problème de portabilité.
Pour en revenir au projet en lui-même, la partie fonctionnelle est réalisée [sans Drag&Drop], mais on peut récupérer les frames d'un Gif animé, y introduire des gifs simples ou même insérer une succession de frames grâce au composant de Wile64. On peut enregistrer le Gif animé obtenu par l'utilisation de Vampyre Imaging Library. Cela fonctionne bien mais la méthode est faible conceptuellement : Le composant de Wile64 n'a pas de fonction sauvegarde du Gif animé mais permet une sauvegarde de chaque frame et le Gif animé est reconstitué à partir de ces frames par Vampyre Imaging Library qui lui permet de l'enregistrer. Je crois que j'aurais pu (même dû) tout faire avec cette librairie mais je l'ai découverte après le composant de Wile64... et vu le retard pris...

Et c'est là que souvent je peste contre Lazarus. Il aurait fallu que j'intégre cette fonction au composant lui-même. L'encodage d'un Gif animé n'est pas des plus simples d'autant qu'il faut assimiler et "s'harmoniser" avec le code du développeur du composant. Quand je développe un programme "de production", je n'ai pas envie d'arrêter mon développement en cours pour modifier l'IDE et dans ce cas précis l'un de ses composants. J'ai déjà du mal avec le code en cours, si en plus, il faut que je consacre 15 jours à incorporer les fonctions nécessaires -bloquant ainsi l'avancement du programme initial, je prétends que cette nécessité limite l'utilisation de Lazarus en production en SSII et que bien qu'intrinsèquement il s'agisse de programmation dans les 2 cas, les 2 "métiers" sont incompatibles "simultanément" en production.

Sinon, toujours pour atteindre l'équivalent Delphi, j'ai voulu aussi y intégrer une fonction "log". Dans le "vieux" programme Delphi, c'est une base mySQL qui enregistre que tel élève a fait tel dessin sur tel poste à telle date. Mais comme cela ne pose pas de problème de "transplantation" sous Lazarus (j'utilise ZeosLib avec les 2 IDE), j'ai essayé une autre méthode et travaillant cette fois-ci sur l'Ubuntu. D'abord, j'ai tenté de concevoir une gestion des logs à la Linux d'où des tentatives de compression/décompression de xxx.log.y.gz (échec)... puis à la place, création d'un fichier.log.txt avec ajout de lignes à chaque utilisation puis chargement dans une StringList des dates extraites du fichier... d'où la recherche avec RegEx. Là aussi (échec). Ce qui ne veut pas dire qu'on ne peut pas produire un tel exécutable avec Lazarus. Il m'a fallut créer une librairie dynamique en C pour contourner les problèmes (le RegEx, car pour l'autre, la compression j'ai laissé tomber). Sans "troller", il y a vraiment des insuffisances... Mais pour rester positif, même avec ce genre de pratiques, le programme compilé restera plus rapide qu'un programme "interprété" en Java ou en C#. Faut bien trouver un avantage. Je ne vais pas me faire des amis. Par contre, pour le développement, il y a un peu plus d'un mois, j'ai mis beaucoup moins de temps à développer un programme équivalent en C# (juste les frames) alors que je ne suis pas un spécialiste... mais je ne sais pas s'il est portable en .mono [j'en doute même fortement : sur le papier aucun problème, mais dans la réalité... faut aller lire le (.)net]... et l'obfuscation du code resterait un vrai problème si le programme n'est pas Open Source.

En résumé, heureusement que c'était un exercice de style parce que sinon en entreprise (dans une SSII), je serais viré sauf si le Client est TRES "élastique" par rapport au délai et que la SSII n'a pas de problème de rentabilité ni de concurrence !

Plus sérieusement, le résultat fonctionne (enfin semble fonctionner sous XP et Ubuntu/Gnome) ... mais pas en utilisant seulement Lazarus. Le temps de développement est ENORME comparé à Delphi que je connais mieux que Lazarus il est vrai, mais également par rapport à C# que je maitrise peu mais donc la doc est fabuleuse comparée à celle de Lazarus. Assez problématique encore : il est vrai que Lazarus est un produit en développement mais il a quand même déjà 10 ans... et on tombe trop souvent sur des units incomplètes ou/et buggées (ou on ne tombe pas du tout parce qu'elles n'existent pas...).

En résumé

• Le programme existe malgré quelques concessions
• Le développement fut difficile à cause de bugs, de carences et d'une documentation disons moyenne. Finalement 15 jours pas toujours agréables sans être infects évidemment... pendant lesquels j'ai souvent apprécié mes incartades C++ alors que je suis un "Pascalien Natif". Au final, une qualité de l'environnement de développement (au sens large) très inférieure à ce que je ressens avec Delphi ou avec QT4/C++ et je me demande même avec ce que j'ai perçu de C# : il faudrait approfondir, mais les premiers contacts sont "engageants". C'est un ressenti donc cela ne prétend pas être objectif.
• Par contre, de manière plus pragmatique, en production, je ne pourrais pas garantir la portabilité du programme:
  
  • Windows : OK
  • Linux : que sous Gnome
  • Mac , je n'en dispose pas.
• Problème éventuellement de diffusion, notamment si le programme utilise le bit SUID de l'exécutable pour atteindre certaines fonctions -par exemple si on place les fichiers de logs dans /var/log [root pour écrire], pour respecter l'orthodoxie Linuxienne. Là, il faut faire un paquet [.deb] ou [rpm]. J'imagine mal un "InnoSetup" lazarusien pour réaliser cette opération.
• Enfin à signaler, comme on parle parfois de mauvaise volonté, le forum Lazarus fonctionne bien et est une vraie ressource. En tout cas, il l'a été pour moi et je remercie tous ceux qui m'ont aidé sur ce forum [cf tous les posts de ces 15 derniers jours].

Cordialement. Gilles