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 "interprète" 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

Je pense à Perl ou à Python, mais tu as intérêt à sélectionner sévèrement les modules.

--
On ne prête qu’aux riches, et on a bien raison, parce que les autres remboursent difficilement.
-+- Tristan Bernard (1866-1947) -+-

Je ne vais pas m'aventurer là où je ne connais pas grand chose, mais selon ce qu'il y a à faire tenir sur la carte, le shell peut être une possibilité.

Question perfs, le perl sera je pense plus performant que le shell.
L'avantage du shell, c'est que de toute manières, tu en auras un d'embarqué, donc ça laissera plus de place sur ta carte pour mettre autre chose éventuellement plus tard.

Quand au choix du langage pour la facilité de programmation, à partir du moment où on sait programmer dans language séquentiel, c'est juste une histoire de syntaxe à apprendre.

Pour la modularité, tu peux écrire un script principal, et différents modules dans des scripts annexes que tu appelles à partir du script principal.

Etant donné que tu fais des scripts, les applis n'auront qu'à appeler les scripts avec les bon paramètres, donc à partir du moment où restes cohérent dans ce que tu utilises (même version de l'interpreteur), ça ne posera pas plus de problèmes que cela.

[troll]Pour créer les scripts, tu peux utiliser un excellent éditeur nommé vim. [/troll]
Pour le tcl/tk, perl, python ou ruby, il y a peut être des éditeurs qui font de la complétion pour les fonctions, mais comme je ne connais pas grand chose de ses 2 langages, je vais me taire!

Reste l'histoire des performances et de la taille du code+interpréteur, mais pour ça, je n'en sais rien!

Tu as lu les docs. Tu es devenu un informaticien. Que tu le veuilles
ou non. Lire la doc, c'est le Premier et Unique Commandement de
l'informaticien.
-+- TP in: Guide du Linuxien pervers - "L'évangile selon St Thomas"

Rappel: pour ce qui est d'embarquer un shell, busybox EST la référence.

_{Fred --
jeune padawan}

oudoubah a écrit :

Merci oudoubah, ta réponse est forte intéressante.
Pour le moment, il semble que ce soit le bon vieux shell soit le plus adapté, d'apres vos différents posts.

Néanmoins, pour la question de l'espace mémoire, l'intrépeteur Perl ne semble pas très lourd.

Léa (Fred) a écrit :

Je suis parfaitement d'accord avec toi, d'autant plus que busybox est déjà present sur la carte.

La question que je me posais était: "est ce interessant d'utiliser un langage plus évolué, type Perl ou Python, qui semblent être très performants dans le traitement de chaine de caractères, ou de fichiers textuels ?

sous SHELL, nous allons utiliser notamment l'editeur de flux sed, qui est certes très puissant, mais parfois lourd à manipuler lorsque les traitements sont nombreux.

Pour un langage de script rapide, ceux bâtis au dessus d'une machine virtuelle à code octets _{qui n'est généralement pas la JVM} sont efficaces, par exemple Lua ou Ocaml.

Sinon, il y a aussi Ruby.

Python et Tcl sont lents. Et Perl n'est pas très agréable à coder.

En bref, je conseille de regarder Ocaml, Lua, Ruby. Ocaml pourrait être intéressant, si le filtrage des trames CAN pouvaient s'y exprimer par du pattern matching usuel d'Ocaml.


----

Basile STARYNKEVITCH _{où on trouve mon mél}

Membre de l'APRIL « promouvoir et défendre le logiciel libre » - adhérez vous aussi à l'APRIL!

_{N.B. N'hesitez pas à consulter aussi mes contributions antérieures.}

Basile STARYNKEVITCH a écrit :

ah non ah non ah non ! soyons rigoureux : du python mal codé est très lent. Du python utilisé correctement permet de réduire énormément le temps de développement. C'est sûr que du gros calcul n'a pas de sens en python (mais du gros calcul n'a de sens qu'en C ou en APL alors ...)

Basile STARYNKEVITCH a écrit :

ça c'est subjectif : perl est très fun à coder (mais pas autant que python)


------- <br />
La meilleure façon de prédire le futur, c'est de l'inventer ~ Alan Kay

tuxfanch a écrit :

J'ai travaillé plus d'un an à temps plein au CEA à comparer les différents langages de scripts (pour piloter des calculs scientifiques), et avec plusieurs mesures et inspection détaillée des interprètes je suis arrivé à cette conclusion (de plus, le ramasse-miettes par comptage de référence de Python est inefficace et peu robuste).


Bien sûr, n'importe quel programme mal codé est lent. Mais prend un algorithme non trivial, code-le en Python (après l'avoir appris) puis en Ocaml (après l'avoir appris) et tu verras la différence. Bien sûr, c'est plusieurs semains ou mois de travail.

Par contre, Python comme Perl (et aussi un peu Ruby) sont interfacés à beaucoup de bibliothèques. A cet égard, Ocaml est moins complet, mais grandit petit à petit.

je ne peux pas en dire plus ici (car les détails de mon travail appartiennent à mon employeur).

Par contre, je suis un peu vexé par ce que tu prétends être mon manque de rigueur.

----

Basile STARYNKEVITCH _{où on trouve mon mél}

Membre de l'APRIL « promouvoir et défendre le logiciel libre » - adhérez vous aussi à l'APRIL!

_{N.B. N'hesitez pas à consulter aussi mes contributions antérieures.}

Basile STARYNKEVITCH a écrit :

Merci pour tes informations. Tu me conseilles donc au choix 3 langages différents de ceux proposés initialement. Puisque tu sembles bien les connaître, peux tu répondre à mes interrogations:

• Sont ils libres de droits ?
• S'appliquent t'ils dans le cadre de mon application (contraintes de l'embarqué...) ?
• Sont ils facilement portables sur une cible spécifique ?
• J'ai très peu de connaissance sur les machines virtuelles à code octets, peux tu m'eclairer la dessus ?

Merci

Note préalable : je ne connais quasimment rien en programmation, tout ce que je dis ici est totalement subjectif, probablement incomplet, mais sans aucune véléité guerrière.

Basile STARYNKEVITCH a écrit :

D'un autre côté, qu'un langage dont le développement est soutenu par le CEA s'en sorte mieux dans les tests menés au CEA...

Bon, j'arrête la mauvaise foi... après avoir pas mal recherché sur Ocaml, il ressort effectivement que côté efficacité il joue dans la même cour que le C. La syntaxe est sympa, le compilateur facile à installer (enfin, ce serait plus sympa s'il y avait une variable type "DESTDIR" tout de même... ), et la détection des erreurs est assez explicite pour qu'on ne cherche pas 50.000 ans où ça pèche.

Donc niveau "j'ai le plus gros benchmark", je pense qu'il est beaucoup mieux placé que python (pas étonnant d'un côté puisque -- si je ne m'abuse -- il permet une compilation en langage natif), sauf à compter sur un apport massif de choses comme psyco. Maintenant, je mettrais tout de même quelques bémols.

En premier, lieu Ocaml est visiblement pensé pour la programmation fonctionnelle. Donc si on vient du shell, c'est un changement culturel auquel il faut s'adapter, ce qui peut augmenter l'investissement en temps nécessaire.

En deuxième lieu, circonstantce agravante du premier point, la documentation d'Ocaml est tout de même peu étendue. Il y a quantité de documentation sur Python en toutes langues, mais très peu de choses sur Ocaml et quand il y en a quasi-uniquement en anglais (en plus la syntaxe Ocaml a visiblement continué à évoluer, ce qui fait que certaines docs doivent être prises avec précaution).

Vous me direz que l'anglais est la langue de l'informaticien, et que c'est donc un faux grief... certes, mais ça signifie aussi une chose : il n'y a pas de communauté d'utilisateurs Ocaml, même dans son pays natal. Et là àmha on touche au gros point noir : vous trouverez Python n'importe où et Ocaml nulle part. Python est beaucoup mieux implanté qu'Ocaml, et pour preuve, cherchez donc des programmes en ocaml ? allez citons-en... 5 ! mldonkey, Coq, unisson, hevea, et... le cinquième, il faut le chercher.

Si j'avais une seule différence à retenir entre Ocaml et Python, elle serait là. Pas vraiment au niveau des capacités des langages, puisque je ne peux avoir qu'une analyse de seconde main, mais sur la politique de développement de chacun. Dès le départ, Python c'est voulu ouvert et séduisant pour les programmateurs, car ils ont -- àmha encore -- compris l'ampleur du problème : persuader quelqu'un d'investir du temps pour découvrir un nouveau langage et refaire ce qu'il sait déjà faire avec celui-ci.

À l'inverse Ocaml semble avoir jouer la carte grandes écoles &cie, en se moquant complètement de renforcer sa base d'utilisateurs. Résultat : comme dit, il n'y a quasiment pas de soft en Ocaml, pas de base documentaire digne de ce nom, et là où n'importe quelle distribution proposera python, il faudra probablement se mettre en quête d'Ocaml.

Si je voulais être ironique, je dirais que c'est une stratégie à la française : ils ont investi dans un langage dont je ne pense franchement pas qu'ils aient à rougir, mais à vouloir dédier l'excellence aux gens excellents (oui, oui, c'est un peu ironique...), ils se retrouvent à faire la danse de la pluie en attendant qu'un industriel veuille bien s'emparer de leur merveille. Sur le papier Ocaml surpasse donc Python, mais côté support communautaire et dynamisme à long terme, il me paraît bien mal parti s'il continue comme ça (surtout que pour les grosses applis et l'embarqué, il y a déjà des choses comme ADA). Et je dis ça vraiment avec frustration et déception, parce que le peu que j'ai goûté des deux (Ocaml et Python), je ne vois pas vraiment de raisons autres de lâcher plus Ocaml que Python.

En conclusion, réfléchissez certes aux performances, mais aussi au support que vous pouvez obtenir et à la disponibilité des ressources documentaires.

Autrement, pour donner une utilité à ce long post, les deux langages (ie compilateurs et bibliothèques de base) sont libres et FSF-orthodoxes. + d'infos -> [caml.inria.fr] et [python.org]

Si python est lent tel quel, il est très rapide avec Psyco si on fait attention à coder de manière efficace [psyco.sourceforge.net]. Pour de l'embarqué, par contre, ce n'est surement pas l'idéal.

J'ai vu tourner des interpéteurs Perl 5 compilés spécialement pour sur des machines embarquées, ça m'a l'air de vraiment bien marcher, et je ne pense pas que coder en Perl soit désagréable : comme il supporte n'importe quelle syntaxe, c'est très facile de s'y adapter, il a le meilleur sustème d'expressions régulières trouvables ... Son gros défaut est de vite devenir fouilli quand le programme dépasse les 500-1000 lignes, mais ce n'est pas forcément ce qu'on demande à un langage de script.

Sinon tu peux aussi aller voir du côté de Io est assez intéressant ... je ne connais pas les autres alors je ne peux pas te donner mon avis.

[catwell.info]

Concernant Ocaml vs Python, il est indéniable que Python est bien plus répandu. Toutefois, il existe une communauté Ocaml (pas uniquement académique, je connais des industriels qui codent en Ocaml, et des startup qui en vivent). Par contre, il existe bien plus que 5 applications codées en Ocaml. Par exemple, sur ma Debian/Sid, il y a 161 paquets mentionnant caml [packages.debian.org]

Il existe une base de données des programmes écrits en Ocaml, le Caml Hump en [caml.inria.fr]

je ne sais pas ce qu'est CAN (je crois que c'est un bus [en.wikipedia.org] pour l'embarqué dans l'automobile), mais je pensais éventuellement à Ocaml puisque le souci initial est de filtrer des paquets. Une solution envisageable en Ocaml serait peut-être de transcrire chaque paquet en des structures de données filtrables par Ocaml, et d'écrire des choses du genre de (je mets en français les variables ou constantes (en majuscules) de ton application, et en anglais les mots clés et noms prédéfinis d'Ocaml)


tu vois le genre de code qu'on peut écrire; n'hesites pas à demander des explications complémentaires; l'intérêt du filtrage (pattern-matching), c'est que x est ici une variable locale au pattern Can_Allumer_Clignotant x et que l'expression match tout entière ci-dessus ressemble à un paquet de règles, et s'écrit concisément (mieux qu'avec des if imbriqués)


Ocaml a une autre particularité: il se compile (comme Java, Lua, et Perl6 notamment) en du code octets (bytecode [en.wikipedia.org] ) portable, lequel est interprété par une machine virtuelle simple. Pour ton application, l'intérêt pourrait être de compiler sur un gros PC (windows ou linux) le script, et de le transférer sur ton système embarqué qui n'exécute que la machine virtuelle avec ton code octet.

Celà étant, malgré ma sympathie pour Ocaml, tu prends le langage qui te convient le mieux.

Sur les aspects légaux, je ne suis pas juriste, mais tous les langages dont on parle ici sont libres (au sens de [opensource.org] et fournis dans Debian). Pour un vrai conseil juridique, paye un homme de loi (avocat, ....) contre lequel ta société pourra éventuellement se retourner en cas de problème, ou bien fait comme tout le monde: lis les licences, fais les relire par la direction juridique de ta société, et prend tes responsabilités _{en pratique, le risque légal lié aux logiciels libres est presque nul, et souvent inférieur au risque des logiciels propriétaires} Les entreprises qui souhaitent utiliser Ocaml avec une licence très permissive (qui permet d'étendre et de modiifer le compilateur et l'interprète de manière propriétaire) le peuvent en adhérant au consortium Ocaml. Les autres peuvent utiliser librement le compilateur et l'interprète (donc développer des applications propriétaires).


J'ai juste quelques éléments à te donner

si ton système est scriptable, fournis aux clients finaux la possibilité de scripter à leur convenance. Pour celà, il est très utile de fournir aux clients les sources qui permettent de comprendre et étendre les scripts. Dans ton cas (avec Python, Lua, ou Ocaml) tout le code C spécifique au scriptage de ton application (çàd la glue entre l'interprète et tes primitives applicatives en C) et tout le code dans le langage de script (Python, Lua, Ocaml).

un système scriptable sera toujours un jour utilisé de manière bizarre (càd imprévue par les concepteurs).... les scripts des utilisateurs sont ammenés à grossir (il est inévitable que certains dépasseront le millier de lignes).... C'est une loi sociale (pas informatique) ou psychologique qu'Ousterhout (créateur de Tcl) a oubliée.


----

Basile STARYNKEVITCH _{où on trouve mon mél}

Membre de l'APRIL « promouvoir et défendre le logiciel libre » - adhérez vous aussi à l'APRIL!

_{N.B. N'hesitez pas à consulter aussi mes contributions antérieures.}

Basile STARYNKEVITCH a écrit :

Et Python ...

Pour ce qui est de la vitesse des différents langages, j'ai trouvé un site permettant de faire des comparatifs : [shootout.alioth.debian.org].
J'ai cru réver en voyant les performances d'Ocaml (il battait le C sur certains programmes), puis j'ai pensé à regarder l'implémentation utilisée ... "The Objective Caml native-code compiler, version 3.09.0", ouf, c'était du compilé ! Je n'ai pas trouvé de tests sur de l'Ocaml interprété, ça m'intéresserait si quelqu'un avait un lien (ceux du CEA sont-ils consultables ?).

[catwell.info]

AlSim a écrit :

Non (mon boulot est allé sur /dev/null puis j'ai demandé et obtenu une mutation) mais il y a dans les archives de la mailing list d'Ocaml des mesures utiles.

----

Basile STARYNKEVITCH _{où on trouve mon mél}

Membre de l'APRIL « promouvoir et défendre le logiciel libre » - adhérez vous aussi à l'APRIL!

_{N.B. N'hesitez pas à consulter aussi mes contributions antérieures.}

Sur le site indiqué par AlSim, il y a aussi

comparaison de Ocaml bytecode vs Lua: [shootout.alioth.debian.org]

Ocaml bytecode vs Python:
[shootout.alioth.debian.org]

etc...

----

Basile STARYNKEVITCH _{où on trouve mon mél}

Membre de l'APRIL « promouvoir et défendre le logiciel libre » - adhérez vous aussi à l'APRIL!

_{N.B. N'hesitez pas à consulter aussi mes contributions antérieures.}

Intéressant, je n'avais pas vu ...
Ca montre que Python (je suppose que c'est purement interprété, pas le bytecode) ne peut pas rivaliser contre le bytecode Ocaml ... Mais par contre, avec Psyco si : [shootout.alioth.debian.org]

[catwell.info]

Basile STARYNKEVITCH a écrit :

Et 1307 pour Python (sur freshmeat on joue à 19 vs 1100+), pour donner une idée du différentiel d'implantation... mais bon, je ne voulais pas dire qu'il n'y avait que 5 logiciels pour Ocaml (heureusement !), juste que c'était pas évident de trouver quelque chose qui justifie d'installer le compilateur (exemple -> [linuxfr.org]).

Pour la communauté active sur le net, à par les listes de discussion, c'est tout de même restreint... et pareil pour la documentation (qui, à l'inverse saute pratiquement dans les bras pour python).

En fait, il est intéressant de voir comment ce langage est perçu dans les débats entre développeurs : [linuxfr.org] et [linuxfr.org]
Àmha, c'est là qu'on voit qu'il y a problème dans la politique de promotion... ceux qui y ont touché en font plutôt un bon rapport (ie qui donne envie de s'y mettre), mais on a l'impression qu'à part dans un contexte académique personne ne l'a croisé autre part. Dommage...

Pour les licences d'Ocaml, les bibliothèques sont LGPL (allégée) et le compilateur sous QPL légèrement allégée (mais contrairement à ce que j'ai dit, pas FSF orthodoxe, pourtant j'aurais parié...) : [caml.inria.fr]. Pour l'annecdote, Xavier Leroy (père du langage) est l'auteur des linuxthreads pour le noyau 2.4... on peut donc supputer que c'est un acteur un peu engagé dans le libre.

Basile STARYNKEVITCH a écrit :

Il me semble que python se compile aussi en bytecode java...

Basile STARYNKEVITCH a écrit :

Encore une preuve s'il en était besoin qu'on ne fait pas comprendre ce que l'on croit qu'on dit par écrit ! ... c'était à prendre au 51ème degré (je me suis -certes- mal exprimé). Toutes mes excuses pour t'avoir vexé !


Mais je n'en défend pas moins mon langage préféré :
Python n'est absolument pas fait pour faire du calcul lourd. Pour cela, il est manifestement très lent.
Bon, maintenant imaginons un projet informatique industriel pour, par exemple, une minuscule centrale d'acquisition (une sorte de gros volmètre multivoies) :

• On écrit le driver en C, parce que c'est ultra spécifique (mettons 10 jours de dev pur)
• On interface la librairie driver dans l'API python (1 jour parce qu'il fait beau et qu'on prend le temps d'aller se ballader)
• On développe l'IHM avec pyQT (QTdesigner + pyuic) (2 jours parce qu'on sait très bien qu'il faudra déplacer 50 fois les quelques boutons de l'IHM)

Moralité : les noyaux de calculs n'ont pas à être écrit en python, je suis bien d'accord que c'est de la connerie. Mais les développement d'IHM, en python, ça trace. On va aussi vite qu'avec du visual studio sauf que l'intégration de librairies tierces va beaucoup (mais alors franchement beaucoup) plus vite. Et puis les unittests c'est du bonheur. Et puis la portabilité ça déchire aussi (jython pour java, ironpython pour .net ...). Et ça fait du code facile à maintenir, nécessairement propre et clair. Bref, I love python.

Cela dit, embarquer du python ça s'est déjà fait et ça se fait encore dans les téléphones (les series 60, notamment chez Nokia). Have fun !


------- <br />
La meilleure façon de prédire le futur, c'est de l'inventer ~ Alan Kay

C'est marrant que personne ne parle de Lua, [www.lua.org] -il a une licence libre MIT ou similaire- et il me semble qu'il vise, plus explicitement que Python ou Ocaml, à être embarqué.

Lua est assez rapide dans son implémentation; son code est très portable. C'est plutot un language à objets (ou à prototypes, en fait à slot, un peu comme Python). Lua vise d'abord à être facilement extensible.


----

Basile STARYNKEVITCH _{où on trouve mon mél}

Membre de l'APRIL « promouvoir et défendre le logiciel libre » - adhérez vous aussi à l'APRIL!

_{N.B. N'hesitez pas à consulter aussi mes contributions antérieures.}