PureBasic

J'avais prévu de migrer ma Lib en v4, mais Tailbite semble être en Stand-Bye actuellement, sans gestion des paramètres optionnels / de trop nombreux bugs je préfère ne pas me lancer dans cette migration.

PureBasic permet de générer ses Lib si l'on connait le C ou l'ASM ( ce qui n'est pas mon cas ).

Un gestionnaire de procédures pourrait faire l'affaire, mais avec trop de contraintes :
- Gérer manuellement les dépendances des procédures qui en appelent une autre.
- Gérer les structures communes.
- Obligation de protéger les variables locales.
- Autocompletion faussée avec le nom des variables locales.
- Un include augmenterais la taille finale de l'EXE surtout si je ne me sert que d'une fonction.
- Et je dois en oublier d'autre.


Bref si quelqu'un a une méthode/astuce qui permettrait de simplifier la gestion de mes bouts de code je suis preneur.

Moi aussi droopy, j'aimerais bien une solution à ce problème.

Pour rappel, à ce jour on a quoi comme solution en v4 ?

- créer une userlib en C

Oui très très bien ! Un SDK en C est un minimum.
Mais pour le néophyte bonjour la galère...

- créer une userlib en ASM

Très bien aussi ! Mais perso je laisse çà aux autres.

- créer une userlib en PB4 compilé avec TailBite

Ce que j'ai toujours fait jusqu'à présent.
C'était en une très bonne solution en v3 mais depuis la v4, TailBite accuse trop de retard/lacunes...

- créer une DLL accompagnée de son fichier .lib

Cela restera toujours une bonne alternative, avec néanmoins quelques inconvénients :
. Dépendance d'un fichier
. Coté programmeur, il faut faire le fichier d'include (wrappeur)
. L'appel d'une fonction retournant une chaine de caractères doit s'effectuer via un PeekS().

- Et enfin, utiliser la fonction IncludeFile "include.pbi"

C'est une solution convenable mais comme le rappelle Droopy, les constantes/macros/variables/structures/procédures/etc... du source inclus sont 'visibles' dans le source 'appelant'. Et dès lors les risques d'erreurs/conflits sont augmentés, le temps de compilation aussi. En fait le plus gros souci, c'est qu'il n'y a pas de notion 'code public' / 'code privé'. Alors que les userlibs et les dll ont ce principe, de fait.

J'avais pensé déjà au mois de juillet à une solution.
voir ici : http://www.purebasic.fr/english/viewtopic.php?t=22638

Mon idée serait que Fred rajoute une nouvelle commande qui ressemble à IncludeFile : IncludeLibrary.

Syntaxe : Et dans la pratique,

- IncludeLibrary inclurait le source PB4 spécifié comme IncludeFile

- SAUF QUE seules les fonctions ProcedureDLL seront visibles et appelables depuis le source appelant. Ainsi aucun risque de conflit. L'organisation et les conséquence du code dans cette configuration serait exactement les même que dans un source de DLL.

- Les données publiques (structures, constantes, macros, interfaces, ...) devront toujours être compilées avec l'option /RESIDENT pour créer un fichier 'resident'.

- Dans le source 'appelant', seul l'appel à cette commande (IncludeLibrary "nom_du_fichier.pbi") serait necéssaire. Pas besoin d'ouvrir/examiner/charger les fonctions.

Je pense aussi que la moins mauvaise solution est d'utiliser un IncludeFile.
Si l'on n'ouvre pas le fichier inclus avec JapBe on n'a pas le soucis d'autocompletion parasite pour les variables / structures

On pourrais pour chaque fonction incluse protéger avec 'protected' les variables locales.

Mais on perd l'autocompletion des procédures incluses
Est-il possible d'ajouter les fonctions de la Lib ( Fichier Inclus ) dans le fichier PBFunctionListing.txt ou APIFunctionListing.txt, pour profilter de l'autocompletion et d'un fichier d'aide accessible via F1 ?

Droopy a écrit :Je pense aussi que la moins mauvaise solution est d'utiliser un IncludeFile.
Si l'on n'ouvre pas le fichier inclus avec JapBe on n'a pas le soucis d'autocompletion parasite pour les variables / structures

On pourrais pour chaque fonction incluse protéger avec 'protected' les variables locales.

Mais on perd l'autocompletion des procédures incluses
Est-il possible d'ajouter les fonctions de la Lib ( Fichier Inclus ) dans le fichier PBFunctionListing.txt ou APIFunctionListing.txt, pour profilter de l'autocompletion et d'un fichier d'aide accessible via F1 ?

Avec jaPBe, il est possible de créer des fichiers de définitions dans le répertoire \Definitions, ce qui permet d'ajouter des Procédures/Macros/Structures/Constantes dans la liste d'autocomplétion.

Par ailleurs, je trouve que Tailbite pour PB4 ne fonctionne pas si mal que çà : toutes mes libs ont l'air de fonctionner, y compris en Threadsafe par exemple même si ma méthode (de fainéant [selon Fr34k]) qui fait appel aux SubsSystems ne plait pas à l'équipe de développement (qui n'avait qu'à inclure une option de compilation en .lib comme c'est le cas pour IBasic Pro par exemple ).

@Flype
Quels sont les problèmes avec Tailbite ? Le seul que je connaisse concerne les Quads...

Dri

gnozal a écrit : Par ailleurs, je trouve que Tailbite pour PB4 ne fonctionne pas si mal que çà : toutes mes libs ont l'air de fonctionner, y compris en Threadsafe par exemple même si ma méthode (de fainéant [selon Fr34k]) qui fait appel aux SubsSystems ne plait pas à l'équipe de développement (qui n'avait qu'à inclure une option de compilation en .lib comme c'est le cas pour IBasic Pro par exemple ).

Tout à fait d'accord...
Au passage, c'est vraiment du bon boulot ce TailBite

Un petit bémol cependant, cela concerne les "linkedlist" en paramètre qui ne sont pas encore gérées

A quand une version qui les prends en charge
Please...

Pour le threadsafe pas besoin de subsystem !!!
il suffit de recoder les fonctions en leur donnant le nom MaFonction_THREAD (idem pour unicode)

Dri

À mon avis, l'idéal serait que Tailbite soit directement intégré dans le PB IDE.

Comme ça, lorsqu'il y a des changements dans la syntaxe ça sera pris en compte dans la création des exe et des lib.

L'autre solution serait d'avoir un répertoire contenant le source de procédure pré-écrite que le compilateur fouille tout seul comme un grand (sans spécifier aucun mot clé) avant de nous dire :

Compilateur a écrit :Line 25 - MaFonction() is not a function, array, macro or linkedlist

Comment ça marcherait :

- 1 seule procédure par fichier.
- Le nom du fichier = le nom de la procédure sans les (param.f, param2.d, ...)

Exemple :
C'est ainsi que ça fonctionne avec MatLab. Bien sûr il faut faire la même chose pour les structures et pour les macros. De plus, il faut ajouter la possibilité de forcer l'éditeur à copier le code dans le source principal pour une diffusion sur le forum.

A+
Guimauve

Génial cette possibilité de JaPbe de gérer un fichier de définition
L'autocompletion fonctionne sans parasitage si l'on n'ouvre pas le fichier inclus
Reste juste le soucis ( détail ) de taille de l'exécutable / lenteur de compilation.
On bénificie de la gestion des paramètres optionnels / Passage des LinKedList en paramètre.

@Gnozal : Reste à trouver comment faire pour qu'en pressant F1 mes procédures affiche l'aide créé dans un CHM.

J'ai trouvé comment faire pour qu'en pressant F1 mon CHM s'ouvre, mais il ne s'ouvre pas à la fonction qui est sous le curseur
Si quelqu'un à une idée.

Je viens de tester TailBite 1.3 PR 18.exe et elle semble bien fonctionner.
Je vais retester avec ça.

Avec les paramètres otpionnels ?
Avec les listes chainées en paramètres ?
Etc...

Droopy a écrit :J'ai trouvé comment faire pour qu'en pressant F1 mon CHM s'ouvre, mais il ne s'ouvre pas à la fonction qui est sous le curseur
Si quelqu'un à une idée.

Regarde le CHM généré par mon utilitaire PureHELPMaker. Si ta fonction est 'MaFonction()', le CHM doit avoir une entrée 'MaFonction.html'.

Progi1984 a écrit :Avec les paramètres otpionnels ?

çà fonctionne avec l'ancienne méthode : MaFonction(), MaFonction2(), MaFonction3() ...

Ouaip, ms bon l'intéressant serait avec la nouvelle méthode !