Discussion :

[zais_ethael]

Salut à tous.
Je recherche un langage de scripting qui puisse facilement être embarqué dans une applic C++ ou C (comme le Lua), si possible open-source et gratuit, et qui puisse être utilisé dans un contexte temps réel.
Pourquoi? Mon école participe au concours Eurobot, le prof voudrait qu'une des parties du programme dictant les actions du robot puisse être plus flexible, qu'il ne soit pas nécessaire de recompiler systématiquement. Je ne saurais pas encore dire si le temps réel est à 100% nécessaire, mais je me dis que logiquement, c'est le cas typique ou on en utilisera.
Pour résumer il faudrait un langage de scripting sans garbage collector (c'est à ma connaissance la seule caractéristique qui rendre un langage incompatible avec le temps réel).
Merci à ceux qui me répondront.

[Alp]

Tu as Boost.Python et lualib qui te permettent d'intéragir respectivement avec Python et Lua dans du code C++. Je te conseille de regarder leur documentation respective pour te faire un avis.

[zais_ethael]

Sans rire, comme si je ne connaissais pas , je le marque même dans mon post.
Merci quand même pour la réponse, mais en lisant jusqu'au bout c'est bien aussi.

[JolyLoic]

Si j'ai bien compris le problème, le besoin de flexibilité vient pour la partie "intelligence" du robot, pas pour la partie "contrôle". J'ai l'impression que quel que soit le langage utilisé, on arrivera assez vite sur les algorithmes mis en oeuvre à des incompatibilités avec un temps réel pur.

Donc, plutôt qu'un langage de script temps réel, je m'orienterai plus vers une architecture qui puisse bien séparer les différents niveaux de contrôle, et n'imposerait pas de contraintes temps réel strictes au niveau le plus haut.

[Alp]

Sans rire, comme si je ne connaissais pas , je le marque même dans mon post.
Merci quand même pour la réponse, mais en lisant jusqu'au bout c'est bien aussi.

Tu ne parles que de Lua dans ton post. Bref.

Quelles sont les possibilités que tu as déjà envisagées ?
Lesquelles as-tu définitivement écarté et pourquoi ?

[zais_ethael]

Bon, en réalité le projet est assez abstrait pour le moment, en gros il y a du code auquel je n'ai pas accès parceque l'équipe de conception n'est pas encore décidée et tout ce que je sais c'est que cette partie pose un problème de flexibilité. Pour le moment, je fais le tour des possibilités avec le peu que je sais, histoire d'avoir un peu de répondant devant le prof.
Alors, qu'ai je pu envisager?
- Une archi qui séparerait cette partie du reste du code, voir un système à plugin. Mouais, pas vraiment révolutionnaire sur le gain de temps à la compilation, c'est quand même plus simple un bête fichier de script à changer tant que les perfs pures ne sont pas un gros problème (je ne pense pas que ce soit le cas).
- Un langage de scripting lambda (le Lua, plus parceque son utilisation semble fort simple qu'autre chose, de toutes façons un langage impératif ou un autre...), c'est la solution facile et il est fort peu sur que son garbage collector et la légère imprécision qu'il est susceptible d'engendrer pose un réel problème.
Néanmoins, je sens qu'en avançant cette idée on pourrait me le reprocher pour le bon motif bien connu dans le profession "les langages à garbage collector sont inutilisables sur un os temps réel" et "les robots faut que ce soit en temps réel". Voila pourquoi je cherche un langage de scripting un peu spécialisé - ou tout du moins qui pourrait servir dans ce but -.
En cherchant sur le net, on ne peut pas dire que je trouve grand chose, à part peut-être le Erlang (langage fonctionnel), réputé pouvant servir dans les applics real time. L'ennui c'est que, bien qu'il soit interprété, il semble être plus une plateforme de développement complète qu'un petit langage généraliste embarquable dans une applic, ce n'est donc pas vraiment ce que je recherche.
Comme je le dis, le langage en question importe peu tant qu'on garde la facilité d'utilisation d'un script, mais il serait appréciable pour éviter tout problème (plus hiérarchique que technique) d'avoir un beau logo "realtime certified" tatoué sur le bidule.

[screetch]

http://squirrel-lang.org/

[zais_ethael]

Je connais le squirrel, il est nottament utilisé dans code::blocks, mais en quoi est-il différent d'un autre langage du même style?

[screetch]

Squirrel is a high level imperative/OO programming language, designed to be a powerful scripting tool that fits in the size, memory bandwidth, and real-time requirements of applications like games. Although Squirrel offers a wide range of features like:
(blabla)
-automatic memory management (CPU bursts free; mixed approach ref counting/GC)
(bla)

ca me parraissait etre ce que tu demandes

c'est tres tres leger (a peu pres aussi leger que lua), efficace, et le mode de liberation de la memoire est sans pic de CPU.

[bafman]

pour info, j'ai un ami qui a bosser pendant un an au Japon sur des aibot, et il les programmait eu Lua. Donc c'est tout a fait possible de le faire avec Lua. Après, pour le problème du garbage collector, ca va surtout poser problème si le hardware du robot est plutot limité.

Et un truc important : si tu veut garder un max de perf, evite de passer par des outils comme Luabind qui te permettent effectivement de gagner du temps de developpement et du type safety, mais qui vont aussi t'ajouter un overhead à l'execution qui n'est pas forcement le bienvenu en temps réel...

[zais_ethael]

Ca me parrait interressant, comme de toutes façons je ne trouve rien de concret comme langage spécialisé je crois que je vais plutot m'engager dans cette voie.

[loufoque]

L'allocation dynamique elle-même n'est pas proscrite sur un vrai système temps-réel ?

[screetch]

je ne pense pas qu'il s'agisse de la fusee ariane...

[loufoque]

Pour du temps réel, a priori il faut que tout le code ait une limite dans sa durée d'exécution. Et quand tu fais de l'allocation dynamique, tu sais pas combien de temps ça va prendre, non ?

[epsilon68]

moi j'aime bien le scripting javascript dans Qt

[JolyLoic]

Pour du temps réel, a priori il faut que tout le code ait une limite dans sa durée d'exécution. Et quand tu fais de l'allocation dynamique, tu sais pas combien de temps ça va prendre, non ?

Je le sais à peu près autant que quand je fais un tri, un traitement/analyse d'images, un algorithme d'optimisation,...
C'est pourquoi une telle restriction posée en axiome me semble restrictive, à la limite du dogmatisme, et que je préfère partir sur l'idée d'un système à deux vitesses, en limitant le temps réel dur aux aspects gestion de la sécurité et à ce qui est très proche du hard, là où ça a du sens et où c'est faisable. Mais je n'ai pas trop l'expérience du temps réel dur.

[capitN.flam]

Tu peux aussi regarder URBI qui est un langage de script créé pour les robots il gere entre autre le parallelisme en natif et il peut s'interfacer avec à peu près n'importe quel langage!

[capitN.flam]

Je le sais à peu près autant que quand je fais un tri, un traitement/analyse d'images, un algorithme d'optimisation,...
C'est pourquoi une telle restriction posée en axiome me semble restrictive, à la limite du dogmatisme, et que je préfère partir sur l'idée d'un système à deux vitesses, en limitant le temps réel dur aux aspects gestion de la sécurité et à ce qui est très proche du hard, là où ça a du sens et où c'est faisable. Mais je n'ai pas trop l'expérience du temps réel dur.

L'allocation dynamique n'est pas déterministe c'est pour cela que l'on ne l'utilise pas en temps réel ou tout du moins on évite au maximum. Le seul endroit ou le non determinisme de l'allocation dynamique est acceptable est pendant la phase d'initialisation d'un systeme.



Pour info je suis en spécialisation GISTR (Génie Informatique des Systemes Temps Réel) à l'EPITA.

[zais_ethael]

Le Urbi a l'air très interessant, malheureusement il semblerait que le moteur d'exécution soit propriétaire et que les développeurs ne mettent à disposition que des moteurs pret à l'emploi pour certain robots grand public au lieu d'une biblio.

[capitN.flam]

Le Urbi a l'air très interessant, malheureusement il semblerait que le moteur d'exécution soit propriétaire et que les développeurs ne mettent à disposition que des moteurs pret à l'emploi pour certain robots grand public au lieu d'une biblio.

Sur ce lien: http://www.gostai.com/download.php en bas de la page tu verras que les clubs et les ecoles peuvent avoir un support gratuit pour developper leur propre moteur urbi pour leur robot. Cela ne te couterai rien ne serait ce que d'envoyer un mail pour avoir un peu plus d'info!