Discussion :

[mig73]

Bonjour,
je souhaiterais savoir quel est le langage de scripts le mieux adapté à mon applicaton:

Une carte électronique embarquée (OS: Linux RTAI) recoit des trames (depuis des canaux de type CAN plus précisement), celles ci sont stockées en temps réel dans une sorte de fichier tampon.
L'utilisateur lambda doit pouvoir, a l'aide d'un langage simple, définir quelles trames il souhaite conserver ou non, en fonction des critères qu'ils souhaitent.

L'objectif est donc de realiser un script qui "interprete" les commandes triviales issues d'un utilisateur, et executent en consequence les fonctions filtrant les trames souhaitées.

Il ya donc un travail de traitement de chaine de caractère, d'analyse de fichiers textuels, de l'interfacage graphique et on peut envisager de l'interrogation de base de donnée, des CGI... dans le futur.

Voila pourquoi il nous semble interessant d'utiliser un langage de scripts
L'architecture du soft n'est pas du tout mise en place, nous en sommes seulement au choix d'un langage parmis Perl, Python, Tcl/Tk entre autres, en fonction des critères suivants:

• Portabilité des applications. Il faut prendre en compte le coté developpement croisé, puisque le code sera embarqué sur la carte.
• Taille du code généré: on dispose d'environ 32 Mo de mémoire.
• Performances du langage
• Disponibilité (open source ...)
• Prise en main (facilité d'adaptation lorsqu'on connait deja quelques langages de programmation)
• Développement sous environnement graphique ou non
• Souplesse, modularité du code pourqu'il soit portable facilement dans d'autres appications

En tenant compte de ces critères, pouvez vous m'orienter dans le choix d'un langage de scripts?

N'hésitez pas à me faire partager vos différentes experiences ou ouvrir le débat sur le sujet.

Merci beaucoup

[chaval]

salut
dans ce genre de projets, utilises des langages compilés. le C serait une bonne idée, je pense

[zul]

Je ne suis pas bien sur de ce que tu entend par langage de script : cette notion semble assez vague. Il a l'air de s'agir ici d'un langage de haut niveau interptré d'après tes propositions. Dans ce cadre là, je choisirai ruby pour sa robustesse et son design agréable.

Ensuite dans le contexte, je suis assez d'accord avec chaval : les interpreteurs "standard" de ces langages ne sont pas réellement viable sur une plateforme embarquée ( j'ai une jornada 720, et avec 32M de ram, je t'assure que c'est pas la joie pour faire tourner perl, python ou ruby ). Je préconiserai donc un langage compilé de ton choix : le C me semblant le plus adapté en général dans l'embarqué.

[GLDavid]

Hello

Je sais, je vais pas être objectif mais bon
J'ai opté bien sûr pour Perl. Perl est quand même plus pratique pour extraire de l'information venant de fichiers logs parfois assez complexe.
Pour être franc, j'utilise pour l'admiistration système aussi bien des scripts shell (bash) que Perl. Dans la mesure du possible, j'opte pour perl pour sa souplesse, sa rapidité et sa richesse. Maintenant, si c'est des scripts Unix stricts, alors, un bon vieux script shell, pourvu que je n'ai pas à parser de l'information.

@++

[mig73]

Ensuite dans le contexte, je suis assez d'accord avec chaval : les interpreteurs "standard" de ces langages ne sont pas réellement viable sur une plateforme embarquée ( j'ai une jornada 720, et avec 32M de ram, je t'assure que c'est pas la joie pour faire tourner perl, python ou ruby ). Je préconiserai donc un langage compilé de ton choix : le C me semblant le plus adapté en général dans l'embarqué.

En quoi est il difficile de faire tourner perl, python etc ? est ce au niveau de la re-compilation (cross-compilation) des sources de l'interpréteur ?

Enfin, utiliser un langage non compilé est un choix en terme de souplesse dans l'utilisation finale de l'application: on pourrait enrichir le code, simplement en editant notre script, sans necessité de recompilation. J'avais omis de le dire en effet.

[zul]

La lenteur et le poids en mémoire de l'interpréteur sont à mon avis les gros problèmes. Mes derniers essais remontaient tout de fois à un ou deux ans, mais j'ai trouvé que ca mettait toujours des plombes à se lancer et à executer le moindre petit truc ( dans mon cas, le plus long etait de lancer l'interpreteur, pas d'executer le code ). Peut-etre que dans ton cas, cela irait. Je vous conseille tout de fois de tester avant de commencer un quelconque developpement.