Le topic de la programmation, string, chaînes, cuir et compagnie

**FB74** · 14/04/2015, 09h58

DARPA creating software that won't need upgrades for a century

Software upgrades and outdated applications that don't work on new platforms are just a fact of life for people who use computers and other devices.

DARPA, however, wants to change that by making software systems that can run for over a century without getting updates from their developers and despite upgrades in hardware.

Pentagon's mad science department has recently announced that it has begun a four-year research to figure out what algorithms are necessary to create software that "can dynamically adapt to changes." The agency calls the project "Building Resource Adaptive Software Systems or BRASS," and it knows it won't be easy. In fact, DARPA's expecting to build everything from the ground up. In return, though, we could see a whole new list of programs with longer lifespans that are easier to maintain.

"The goal of the Building Resource Adaptive Software Systems program (BRASS) is to realize foundational advances in the design and implementation of long-lived, survivable and complex software systems that are robust to changes in the physical and logical resources provided by their ecosystem," part of its official description says. The agency has started accepting research proposals for every aspect of the project, from which it'll find the most promising to fund.

DARPA is hoping that BRASS will ultimately lead to military computers and machines that don't need to stop running for upgrades, as the process can be costly. Sounds a bit terrifying, considering the project aims to build software that can evolve on its own, much like those villainous programs in movies that gained sentience as time went on.

**Møgluglu** · 14/04/2015, 10h24

Envoyé par vectra

Le site de PaulEmploie vient de partir en rideau, désolé...
Je vais voir si je retombe dessus plus tard. C'est sur Grenoble en tous cas, et je suis pas qualifié du tout, mais j'aurais bien aimé glisser mon CV pour voir

edit:

Tu peux tenter : il doit y avoir 3 gus en france qui ont toutes les compétences requises et ceux-là ont déjà un boulot. C'est plus une lettre au Père Noël qu'un profil de poste qu'ils ont écrit.

Après, c'est une startup, donc tu es là pour en chier et ton CDI est vraiment à durée indéterminée.

Envoyé par FB74

DARPA creating software that won't need upgrades for a century

C'est pas déjà le cas de la majorité des softs actuels, dont on a perdu le code il y a 40 ans et qu'on n'arriverait pas à recompiler de toute façon ?

**Sp1d3r** · 14/04/2015, 11h03

Merci la compatibilité ascendante du x86.

**Møgluglu** · 14/04/2015, 14h40

Pour ceux qui voudraient jouer avec des Jetson TK1, il y a un concours de reconnaissance d'image sur plateforme basse-conso à la conf DAC 2015 :
http://lpirc.net/

Et Nvidia peut fournir le matos :
http://devblogs.nvidia.com/parallelf...hallenge-jets/
(bon, faut payer les 180$ d'inscription d'abord...)

**vectra** · 14/04/2015, 14h58

Ca fait presque le coût d'une Tesla (d'occase)

Ca peut s'avérer très sympa si on est éligible à un défraiement des frais de transport. Rien que pour le voyage...

**Møgluglu** · 14/04/2015, 15h11

Envoyé par vectra

Ca peut s'avérer très sympa si on est éligible à un défraiement des frais de transport. Rien que pour le voyage...

Le jour où j'ai voulu faire appel à ce genre de financement, on m'a poliment expliqué que si j'étais pas étudiant boursier dans une université américaine, je pouvais oublier. Faut pas déconner non plus.

Donc pour rentrer dans tes frais t'as pas le choix, faut gagner le concours (et rafler les deux prix annexes) pour revenir avec 1400$ et un gros GPU en plus du Jetson. Aller, au boulot.

**vectra** · 14/04/2015, 15h37

Mail que je viens de recevoir d'une "revue" omicsonline:

Dear Dr. Vectra,

Greetings from the Journal of Lovotics!!

We had a glance on your research work which is very impressive and we strongly believe that this potential research in the field of Robotics would be beneficial to the people working in this field.

As part of our continuing mission to enrich the sharing of ideas between Human-Robot Love scientific communities around the world, LOVOTICS Journal invites contributions from researchers related to Advanced Robotics, Human-robot interactions, multi-robot systems and Artificial Intelligence, On your research interest (related to robotics) etc.,

Papers related to but not limited to all fields of intelligent robotics, Robotics for Mechanism & Control, Robotics for Application, Nano/Micro Robotics & Mechatronics, etc are welcome.

Thus on behalf of LOVOTICS Journal, we invite you to present your view on your research as a short note/ mini review/ full review, Research articles, case reports, Opinion, Technical note for our upcoming issue.

Manuscript can be submitted directly on the editorial portal at http://www.editorialmanager.com/engineeringjournals/ or you can simply send as an attachment to editor.lovotics@omicsonline.com

We would truly gratify and appreciate receiving your submission on or before April 24th, 2015,

We are waiting for your Quick and positive reply.

For any other queries please feel free to contact us.

With thanks
Kate Williams,
Assistant Managing Editor
Editor-in-Chief
LOVOTICS

**JudaGrumme** · 14/04/2015, 17h01

Bonjour !

Mon petit DFDJ special programmation, je vous laisse ca la:

Code:

void foo(param bar)
{
    assert(1==0);

    return;
}

En prod, evidemment

**vectra** · 14/04/2015, 17h16

C'est une fonction qui sert à déboguer

Quand tu l'appelles, ça arrête le programme

Comme ça tu sais que les conditions pour l'atteindre ont été remplies.
Quoi? Un déboquoi?

**Sp1d3r** · 15/04/2015, 10h40

Si NDEBUG est défini, cette fonction ne fait rien.

**vectra** · 15/04/2015, 10h50

Je vais faire pleurer des gens, mais tant pis.
J'ai redéfini une macro ASSERT et MSG_ASSERT, qui recopie assert et est insensible à NDEBUG.

Ca me permet de stopper le programme avec un beau message lorsqu'une erreur irrécupérable survient, dès lors que je ne vois pas en quoi une exception pourrait améliorer quoi que ce soit, ni comment il serait possible de corriger cela en release. Par exemple, plus de mémoire, plus de place sur le disque détectée avant ou après le calcul, etc.

J'ai rien compris ou bien?

**Møgluglu** · 15/04/2015, 11h00

Envoyé par vectra

Ca me permet de stopper le programme avec un beau message lorsqu'une erreur irrécupérable survient, dès lors que je ne vois pas en quoi une exception pourrait améliorer quoi que ce soit, ni comment il serait possible de corriger cela en release. Par exemple, plus de mémoire, plus de place sur le disque détectée avant ou après le calcul, etc.

Tu n'es pas seul, Arianespace fait aussi comme ça pour afficher des beaux messages d'erreurs dans le ciel.

**Tramb** · 15/04/2015, 11h02

Envoyé par vectra

Je vais faire pleurer des gens, mais tant pis.
J'ai redéfini une macro ASSERT et MSG_ASSERT, qui recopie assert et est insensible à NDEBUG.

Ca me permet de stopper le programme avec un beau message lorsqu'une erreur irrécupérable survient, dès lors que je ne vois pas en quoi une exception pourrait améliorer quoi que ce soit, ni comment il serait possible de corriger cela en release. Par exemple, plus de mémoire, plus de place sur le disque détectée avant ou après le calcul, etc.

J'ai rien compris ou bien?

Alors déjà quand tu écris une macro, préfixe par VECTRA, genre VECTRA_ASSERT. Sinon un jour tu t'en mordras les doigts ou un mec qui te reprendra ton code te défoncera les rotules.

Par contre, les asserts c'est plus pour les erreurs de logique interne, ton programme doit pouvoir tourner sans eux (et donc regagner de la perf). Pour valider tes datas ou pour les conditions exceptionnelles, il y a d'autres mécanismes (exceptions, codes d'erreur ou abort en général).

**vectra** · 15/04/2015, 11h35

J'utilise parfois les exceptions, mais uniquement lorsqu'il y a possibilité de rattraper le coup et de reprendre la boucle.
Là, quand j'utilise mes MSG_ASSERT, c'est effectivement la métaphore de la fusée qu'elle est bonne: si c'était pas implémenté avant le compte à rebours, le vol est condamné. Je devrais plutôt voir abort ou codes d'erreur donc?

Ce qui est important, c'est d'indiquer à l'utilisateur un message d'erreur suffisament indicatif, et aussi d'indiquer à quelle ligne de code et sur quelle condition il faut porter ses efforts. Vu la masse énorme de données statiques et dynamiques que le programme gère, le nombre de conditions aberrantes est très important. Je gère presque toutes les conditions statiques que je peux (assez de place disque ou de mémoire libre au démarrage, vérification de la cohérence des paramètres physiques), mais ça fait déjà beaucoup de code rien que pour ça.

A titre d'info, j'ai un cahier complet détaillant le rapport du vol 501. C'était intéressant de mémoire... et bonjour les erreurs et raccourcis pour économiser du pognon (en gros, aucun test n'avait été réalisé sur le composant critique avec les données adaptées à ariane 5).

**rOut** · 15/04/2015, 11h45

Pourquoi ne pas utiliser assert tout court ?

NDEBUG c'est justement là pour être sûr de pouvoir virer tous les asserts quand tu ne veux plus les avoir, mais t'as pas besoin de le définir pour ton développement de tous les jours.

**vectra** · 15/04/2015, 13h09

C'est justement ça que je comprends pas. A moins de mettre un test dans le corps d'une boucle, ça devrait ne rien coûter de les garder?
D'autant que chaque fois d'une condition est remplie, le programme *doit* s'arrêter immédiatement, surtout en prod, et ça serait plus que gentil de préciser pourquoi.

Histoire de pouvoir relancer une acquisition valide dès que possible et d'indiquer aux utilisateurs-experts (CPC) comment faire.

**Tramb** · 15/04/2015, 14h01

Bah le truc quand tu programmes défensivement, c'est que des assertions t'en fous partout, y compris dans le corps de tes boucles, pour essayer de gauler tes *erreurs de programmation*.
Si les inputs sont ill-formed et que tu le détectes, en général tu reportes ça différemment.
Itou pour un disque plein.
C'est pas la même sémantique entre dire "je suppose que ça est tout le temps vrai parce que sinon j'ai commis une erreur de programmation" et "houla normalement, fopen renvoie jamais NULL".
Premier cas : assertions (dégageables dans tes builds finaux), second cas : exceptions, retours d'erreurs, message + abort etc...

Et utiliser assert, pourquoi pas, mais ça manque un peu de features définies, par défaut, suivant ton CRT et co.

Edit : Après tu peux te renseigner sur le design by contract qui formalise les notions de préconditions et de postconditions.

**JudaGrumme** · 15/04/2015, 16h07

Ce qui me gene particulierement c'est que l'assert ne donne aucune indication sur l'endroit ou il se produit, si ? Ici on peut se retrouver avec le programme qui pete completement sans avoir aucune indication sur l'endroit d'ou ca peut bien venir...
Puis bon le return apres l'assert(0)...

Edit : Ah ben si en fait.

**vectra** · 15/04/2015, 16h21

J'ai simplement recopié la définition de la macro assert, avec les directives qui renvoient le nom de fichier et le numéro de ligne, et j'ai vaguement modifié pour faire un affichage de message.
C'est simplement un assert en prod

Mais bon, y'a moyen de faire ça de manière plus carrée avec un abort et un message.

Le gros problème est que y'a pas assez de frontières entre les devs et les utilisateurs, et aucun cahier des charges. Le chef veut "que ça marche", pour le reste démerde...

**Tramb** · 15/04/2015, 16h37

Envoyé par JudaGrumme

Ce qui me gene particulierement c'est que l'assert ne donne aucune indication sur l'endroit ou il se produit, si ? Ici on peut se retrouver avec le programme qui pete completement sans avoir aucune indication sur l'endroit d'ou ca peut bien venir...
Puis bon le return apres l'assert(0)...

Edit : Ah ben si en fait.

Bah c'est ce que je voulais dire: Le niveau de reporting d'un assert est undefined, donc suivant ton runtime C tu auras une backtrace ou pas, ça continuera ou pas (ça doit appeler abort en théorie mais tu peux avoir une message box ou autre)

**rOut** · 15/04/2015, 16h46

If NDEBUG is not defined, then assert checks if its argument (which must have scalar type) compares equal to zero. If it does, assert outputs implementation-specific diagnostic information on the standard error output and calls std::abort. The diagnostic information is required to include the text of expression, as well as the values of the standard macros __FILE__, __LINE__, and the standard variable __func__.

C'est normalement spécifié un minimum.

**Tramb** · 15/04/2015, 16h56

Ouais m'enfin un operator[] qui te dit out of bounds sans backtrace avec juste le nom du fichier de ton container et la ligne, tu peux un peu te le foutre au derche

Edit: j'ai beaucoup entendu dans mes précédents boulots "ouais y a une fonction qui crashe, c'est AssertHandler" et "je pense que les vectors (enfin le parfum maison) sont pétés ils arrêtent pas d'asserter".
Les deux sont authentiques

**vectra** · 15/04/2015, 19h25

Adhésion gratos à la IEEE Signal Processing Society.
J'ai vu viteuf, y'a moyen de choper un an d'abo à la revue IEEE Signal Processing je crois.

http://www.gdr-isis.fr/uploads/image...%20(Paper).pdf

**Forseti** · 15/04/2015, 22h43

Envoyé par Tramb

Tu m'étonnes

En gros ça veut dire : on veut un gourou et on va le payer au lance-pierres, probablement.

Edit de Vectra: Ah non ça veut juste dire, bon ok en vrai si t'es un killer on s'en fout des deux ans d'xp.

Ils ont de l'espoir quand même. Perso ça me donne pas envie de postuler ce genre d'annonce pour les "génies"... même si c'est assez courant.

**vectra** · 16/04/2015, 02h08

J'm'en fous de balancer un CV, mais écrire une LM sachant que j'ai pas les cahouètes, c'est grave dur

J'aime pas écrire les LMs de toute manière...

Sinon j'ai reçu une belle (trop?) propale d'un chasseur de tête sur Grenoble, visiblement pour un client qui fait des jeux 3d sur mobiles même si c'est pas clairement dit.
Mon CV est prêt mais la LM s'annonce bien bien merdique...

**newbie06** · 16/04/2015, 10h25

Envoyé par Møgluglu

Tu peux tenter : il doit y avoir 3 gus en france qui ont toutes les compétences requises et ceux-là ont déjà un boulot. C'est plus une lettre au Père Noël qu'un profil de poste qu'ils ont écrit.

C'est qui les deux autres ?

**Nattefrost** · 16/04/2015, 14h58

Yo là-dedans, certains d'entre-vous ont ils utilisé GTK pour faire des GUI (peut importe le langage) ?
J'avoue que je suis un peu paummé. Je suis habitué aux layouts table et absolu (c'est pareil en tcl/tk) mais alignment je galère à comprendre comment ça marche.
Quel layout utilisez vous?

Autrement ça fait du bien d'avoir un toolkit plus riche -et plus joli- que tk

.

**vectra** · 16/04/2015, 15h13

Y'a aussi QT qui marche très bien.
Je trouve que c'est de loin le plus propre des systèmes de GUI (que je connaisse), et notamment un système facilement portable Nunux/OuinOuin/etc.

En tous cas, tcl/tk, plus jamais. Je manque peut-être de méthode, mais depuis ma dernière appli-spaghetti et la difficulté à communiquer avec des API C, no way. Qt se marie bien plus facilement, à mon sens, avec des API externes.

**Nattefrost** · 16/04/2015, 15h34

Pas de soucis non plus pour GTK niveau portabilité mais c'est vrai que j'me suis posé la question puisque Qt comme GTK sont dispos pour Python et C# ( et c'est les deux langages que j'utilise le plus).

Enfin même tkinter qui est simple j'ai mis un bon moment à connaître les bases donc j'me dis que ça va prendre au moins autant de temps pour GTK.
WPF est propre aussi mais bon, c'est justement pour m'en écarter que je cherche des alternatives.

**vectra** · 16/04/2015, 15h40

Paillesoune et Sicharpe.
Je sais pas trop... Je dirais que ça dépend vraiment de ce que tu veux interfacer en fait, et des libs dont tu vas avoir besoin.

tcl/tk est parfait pour des petits trucs ou des applis à lancer en aveugle. C'est lorsque ça se complique que ça devient ingérable dans les cas qui me concernaient (images).

Discussion: Le topic de la programmation, string, chaînes, cuir et compagnie

Outils de la discussion

Règles de messages