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

[Sekigo Le Magnifique]

J'ai un besoin d'aide pour des choix technologique. Je voudrais afficher avec un raspberry via sa sortie composite une image avec ma position sur une carte ainsi que diverses infos textuelles pour faire un affichage dynamique a destination du publique.
Quelle est le moyen le plus facile d'y arriver (sous windows je l'aurai fais en c#) mais là je sais pas trop.
Y'a t'il possibilité de faire cela sans installer de windows manager (pour éviter de le charger avec ça si on peut s'en passer) ?
Et quelle langage ? J'avais pensé a python + pygame mais il n'a pas l'air de pouvoir se lancer en console.

Si quelqu'un a une idée brillante

Je ne connais pas rasberry pi. Mais j'avais déjà bossé sur une petite console.
Tu installes uniquement xorg. Si au jour le jour, ça te casse les burnes, tu installes openbox. Ça bouffe que dalle dans ces deux cas, et tu ne sentiras rien.
Pour le lancement dans la console (c'est à dire, sans avoir de serveur graphique, TOUT se passe dans le terminal qui est lancé au démarrage du système), tu peux utiliser le framebuffer (fbdev, un truc comme ça), mais c'est limité niveau logiciel, de mémoire.

J'avais bossé sur la dingoo A320 en amateur, en 2010, en partant du kernel et en m'aidant de Linux From Scratch. La bête avait 32Mo de ram et 360MhZ, ce qui en fait un monstre de puissance par rapport à la majorité des trucs en embarqué (avec la dingoo, on a presque un pc). J'avais réussi à compiler (en patchant comme un goret) xorg pour le lancer dessus et ça ne pénalisait pas les perfs (un peu de mémoire utilisé et du proc utilisé au lancement d'un logiciel).
Donc, avec le monstre raspberry pi, t'as pas à t'en faire. Tu utilises xorg et tu te fais plais'.
Et pygame est utilisable avec le framebuffer. Mais hormis par curiosité, je ne conseille pas, c'est un peu galère à installer et configurer (mais j'étais parti from scratch, peut-être avec une Debian, ça doit être bien plus facile). Et tu vas être limité au niveau des trucs utilisable (les trois quarts des logiciels graphique dépendent de xorg d'une manière ou d'une autre).

[rOut]

Sinon tu fais l'output de la carte en ascii art dans la console avec libcaca.

[Tomaka17]

Genre la méthode "find" ne méritait pas d'aller dans la classe String (mais elle est dans le faux-type "str" qui ne peut pas être utilisé directement !), ou encore l'algorithme générique "rechercher une valeur dans une liste de valeurs" ne mérite pas une fonction à lui tout seul.

Je crois qu'ils sont en pleine restructuration de leur strings. En fait ils sont en pleine restructuration de tout.

Pour les String et les str, en fait j'ai compris assez récemment : le type "str" est équivalent au type "[i8]" (c'est un typedef).
Et les types [] sont en fait des slices (une sorte de range), c'est à dire qu'ils contiennent simplement un pointeur vers le début ainsi qu'une longueur.

    if word.as_slice().find('-') == None { continue; }

Justement, là tu peux par exemple écrire :

    let iter = match word.as_slice().find('-') { None => continue, Some(i) => i };

[Sekigo Le Magnifique]

Sinon tu fais l'output de la carte en ascii art dans la console avec libcaca.

Rien à voir, mais ça m'a fait penser à ça :
http://doryen.eptalys.net/libtcod/features/
Une bibliothèque pour faire des rogue-likes. Mais c'est con, parce qu'il me semble que c'est utilisable seulement en utilisant SDL. Je l'avais testé il y a longtemps et je ne me souviens plus si c'est utilisable en console pure.

[rOut]

Justement, là tu peux par exemple écrire :

    let iter = match word.as_slice().find('-') { None => continue, Some(i) => i };

Ok, c'est cool mais c'est moins simple que mon if.

  let mut words = Vec::new();

  // read the standard input for words
  for result in io::stdin().lines() {
    let word = result.unwrap();

    if word.len() == 0 { continue; }
    if word.as_slice().find('\'') == None { continue; }
    if word.as_slice().find('-') == None { continue; }

    words.push(word.into_ascii_lower());
  }

---------- Post added at 21h56 ---------- Previous post was at 21h54 ----------

Rien à voir, mais ça m'a fait penser à ça :
http://doryen.eptalys.net/libtcod/features/
Une bibliothèque pour faire des rogue-likes. Mais c'est con, parce qu'il me semble que c'est utilisable seulement en utilisant SDL. Je l'avais testé il y a longtemps et je ne me souviens plus si c'est utilisable en console pure.

Oui, je crois que Tomaka avait regardé à un moment, mais c'était effectivement une fenêtre SDL dédiée. En même temps, faire un jeu en terminal, ça va être hardcore à porter sous windows.

[TiNitro]

Ce qui est primordial à mon sens, et aucune transgression n'est possible sans souci, c'est de ne jamais utiliser d'héritage public pour factoriser du code quand le principe de Liskov ne s'applique pas.

Voilà je préfère ça.

[vectra]

Ce qui est primordial à mon sens, et aucune transgression n'est possible sans souci, c'est de ne jamais utiliser d'héritage public pour factoriser du code quand le principe de Liskov ne s'applique pas.
Si, en gros, tu ne pas dire "Tous les Derived sont des Base et supportent toute leur interface" en toute confiance, il faut mieux éviter.

C'est mon cas alors mais je pense que j'ai donné un exemple catastrophique.

J'ai eu la mauvaise idée de penser à l'héritage comme un moyen détourné de ranger les méthodes d'une même classe par "paquets".

[TiNitro]

Mon point de vue plus précisément, c'est que les generics et les traits sont forcément meilleurs que l'héritage.

Pas forcément beaucoup plus clair en C++, pour cause de syntaxe péniblounette. Et surtout statique. Donc pour l'inférence de type (concrètement, j'ai un conteneur de formes, toutes les formes n'ont pas le même type final etc..) l'héritage te permet quand même de faire quelque chose d'ultra limpide en comparaison.

Comme dans tout, il s'agit d'utiliser les bons outils, sans complexifier le code pour "le principe".

---------- Post added at 22h07 ---------- Previous post was at 22h06 ----------

C'est mon cas alors
J'ai eu la mauvaise idée de penser à l'héritage comme un moyen détourné de ranger les méthodes d'une même classe par "paquets".

Effectivement, ce que tu proposais ne faisait que rajouter de la complexité...

[rOut]

C'est mon cas alors mais je pense que j'ai donné un exemple catastrophique.

J'ai eu la mauvaise idée de penser à l'héritage comme un moyen détourné de ranger les méthodes d'une même classe par "paquets".

Pas forcément beaucoup plus clair en C++, pour cause de syntaxe péniblounette. Et surtout statique. Donc pour l'inférence de type (concrètement, j'ai un conteneur de formes, toutes les formes n'ont pas le même type final etc..) l'héritage te permet quand même de faire quelque chose d'ultra limpide en comparaison.

Comme dans tout, il s'agit d'utiliser les bons outils, sans complexifier le code pour "le principe".

---------- Post added at 22h07 ---------- Previous post was at 22h06 ----------



Effectivement, ce que tu proposais ne faisait que rajouter de la complexité...

Franchement, comme je l'ai dit, ça ne fait strictement aucune différence la manière dont tu vas implémenter ton découpage. De toute manière ton exemple est juste trivial avec une classe à splitter et l'héritage est clairement utilisé pour découper le code, pas pour introduire des concepts distincts. On n'est pas en train de parler d'accoupler des chats et des canards pour faire hériter l'un de l'autre.

[TiNitro]

D'accord avec toi rOut.

[kpouer]

Tu serais pas influencé parce que la gestion objet en C++ est totalement foirée ?

[rOut]

Tu serais pas influencé parce que la gestion objet en C++ est totalement foirée ?

C'est le branlage de nouille sur un exemple aussi simple qui m'influence.

[kpouer]

Pardon, je parlais pour Tomaka, j'ai pas été clair.
Je trouvais que dire que l'héritage c'est inutile c'est peut-être un peu lié au fait que çà marche très mal en C++.

[vectra]

Dans ton cas précis, la question n'est pas à propos d'héritage multiple ou non au sein d'une architecture complexe avec des milliers de types différents. C'est savoir comment découper proprement du code s'appliquant à une structure donnée et qui ne va pas être réutilisé ailleurs (a ce que j'ai compris).

Du coup, à mon avis, peut importe. De toute manière tu vas dans tous les cas séparer les fonctions et membres de ta classe par fonctionnalité. Ensuite, que chaque fonctionnalité accède aux données de base via l'héritage ou via un paramètre, ça ne change vraiment pas grand chose (de toute manière l'héritage ce n'est rien d'autre qu'un paramètre implicite, hein).

Que tu regroupes enfin le tout dans une classe unique via héritage multiple, ou aggrégation si ça plait plus à certains, ou encore que tu regroupes le tout de manière officieuse en faisant #include de chaque header...

Ok, bien reçu.
Je me suis un peu perdu entre les différents posts.

Donc, si jamais un programmeur tombe là-dessus, il devrait comprendre ce que j'ai fait. Je me méfie, parce que j'ai naturellement tendance à avoir des idées très foir farfel out-of-the-box on va dire. L'intérêt, pour moi, c'est de me relire, d'être relisible et compréhensible par un tiers. Ma thèse va bien se finir un jour, et quelqu'un va devoir maintenir tout ce code, tôt ou tard.

[rOut]

Tu peux mettre des commentaires pour expliquer ça. Pour une fois que ça peut servir à quelque chose.

[Tomaka17]

Bon, j'ai trouvé LE truc chiant du Rust.

Quand tu codes des traits, la logique voudrait que tu puisses écrire quelque chose comme ça :

trait Container<T> {
    type I: Iterator<T>;
    fn iter() -> I;
}

C'est à dire un trait "container qui contient des T" dont la fonction iter() renvoie un objet de type I dont on sait qu'il implémente "itérateur sur T".

Sauf que tu ne peux pas définir de type à l'intérieur de tes traits, du coup t'es obligé de faire ça :

trait Container<T, I: Iterator<T>> {
    fn iter() -> I;
}

Ce qui devient un trait "container qui contient des T et qui renvoie un itérateur de type I".

On pourrait se dire que c'est pas très grâve, mais en fait si. Parce qu'au lieu d'avoir une fonction comme ça :

fn foo<T, C: Container<T>>(cnt: C);

On est obligé d'écrire la fonction comme ça :

fn foo<T, I: Iterator<T>, C:Container<T,I>>(cnt: C);

Et là c'est le cas simple.
Un autre exemple, au lieu d'écrire ça :

fn foo<D: Display>(display: &D);

Tu es obligé d'écrire ça :

fn foo<'a, T: Texture<'a>, VB: VertexBuffer<'a>, IB: IndexBuffer<'a>, ST: ShaderType, S: Shader<'a, ST>, P: Program<'a>, D: Display<T,VB,IB,S,P>(display: &D);

Et en plus tu es obligé de copier-coller ça avant 100 % des fonctions qui utilisent un Display, et de modifier toutes les définitions si jamais tu modifies ton trait "Display".

Apparemment ils ont déjà repéré le problème, mais ne vont pas le corriger à court-moyen terme parce que "la correction peut être implémentée de façon backward-compatible", et que pour l'instant la priorité absolue c'est d'avoir une version stable du langage. Toutes les features qui peuvent être ajoutées sans casser la rétrocompatibilité ne seront ajoutées qu'après la version 1.0 prévue pour la fin de l'année.

En attendant ça rend le langage extrêmement chiant à utiliser dans certains cas.

[deathdigger]

Je suis en train de faire de la programmation séquentielle en js via une appli graphique. C'est un peu déconcertant

[rOut]

En attendant ça rend le langage extrêmement chiant à utiliser dans certains cas.

S'il n'y avait que ça.

J'ai passé la soirée d'hier à rajouter des cast u8 et u16 vers uint. Et à pester sur la facheuse habitude du compilateur de te laisser croire que tu arrives au bout de la liste des erreurs de compil à corriger, pour t'en remettre une fournée quand tu pensais avoir fini.

Ou encore, à pester contre les Vec qui ne sont pas indexables avec [] directement : faut faire .get(), ou .get_mut() à la place, suivant si tu veux modifier l'élément..., pas foutu de le déduire tout seul.

---------- Post added at 20h29 ---------- Previous post was at 19h45 ----------

Tiens je découvre aussi qu'appeler une variable "_" semble mener à des résultats étranges.

J'ai un type ScopedProbe pour mesurer la performance d'un bloc de code :

extern crate time;

struct ScopedProbe {
  name : &'static str,
  start : u64
}

impl ScopedProbe {
  fn new(name : &'static str) -> ScopedProbe {
    return ScopedProbe { name: name, start: time::precise_time_ns() };
  }
}

impl Drop for ScopedProbe {
  fn drop(&mut self) {
    println !("{} took {}", self.name, time::precise_time_ns() - self.start);
  }
}

Ensuite, suivant si je fais :

fn main() {
  { let _ = ScopedProbe::new("loop");
    for num in range(0, 1000) {}
  }
}

ou bien

fn main() {
  { let p = ScopedProbe::new("loop");
    for num in range(0, 1000) {}
  }
}

Je n'ai pas du tout le même comportement. Ni l'un ni l'autre ne donne d'erreur de compil (le second me dit que p n'est pas utilisé, mais avec _p ça a l'air de bypasser la contrainte). Mais la première version me sort un temps très petit, ce qui me laisse penser qu'il construit mais détruit la variable immédiatement (!?).

[Tomaka17]

Oui, le nom "_" veut dire "ignorer le résultat", ça sert par exemple quand tu fais "match blabla { Some(_) => ... }".
J'imagine que t'es pas censé l'utiliser comme nom de variable.

Sinon je crois que les benchmarks sont intégrés au Rust : https://github.com/mozilla/rust/wiki/Doc-unit-testing (je dis "je crois" parce que ça al'air de n'être documenté nulle part sauf sur cette page)

[rOut]

Je porte juste le code d'un petit programme tel quel, pour me donner une idée de l'utilisabilité du langage et de la difficulté d'adaptation par rapport au C++ et D. D'ailleurs je vais tenter de le faire avec d'autres langages après pour voir.

Pour l'instant j'ai des perfs merdiques, mais il doit faire des copies quelque part dans mon dos (j'ai mis des & partout pourtant !).

[Tomaka17]

Il n'y a aucune copie en principe. Quand tu fais "a = b" et que b n'est pas un type natif, alors ça déplace b dans a (et tu as une erreur de compilation si tu utilises b par la suite). Pour faire une copie il faut explicitement écrire "b.clone()".

Sinon d'après les "benchmarks trouvés sur le net" (source fiable), le rust serait en moyenne à peu près à 90 % des perfs du C.
Je ne sais plus trop où j'ai lu ça, mais quelqu'un a dit que le problème serait dû au fait que rust génère du code llvm absolument dégueulasse et que du coup llvm optimise moins bien.

[TiNitro]

Je suis en train de faire de la programmation séquentielle en js via une appli graphique. C'est un peu déconcertant

C'te vent que tu as pris, mais je compatis, hein...

---------- Post added at 22h20 ---------- Previous post was at 22h19 ----------

[mode C++fanboy on]

Je trouvais que dire que l'héritage c'est inutile c'est peut-être un peu lié au fait que çà marche très mal en C++.

Qu'est-ce qui fonctionne mal ?
[mode C++ fanboy off]

[rOut]

Il n'y a aucune copie en principe. Quand tu fais "a = b" et que b n'est pas un type natif, alors ça déplace b dans a (et tu as une erreur de compilation si tu utilises b par la suite). Pour faire une copie il faut explicitement écrire "b.clone()".

Sinon d'après les "benchmarks trouvés sur le net" (source fiable), le rust serait en moyenne à peu près à 90 % des perfs du C.
Je ne sais plus trop où j'ai lu ça, mais quelqu'un a dit que le problème serait dû au fait que rust génère du code llvm absolument dégueulasse et que du coup llvm optimise moins bien.

Ouais en fait c'est bon.

Par contre je n'ai pas trouvé comment faire l'équivalent d'un move. Pour une fonction qui prend une liste de string en entrée et retourne les string classées dans des listes en sortie, en déplaçant les strings plutôt qu'en retournant des références.

[kpouer]

C'te vent que tu as pris, mais je compatis, hein...

---------- Post added at 22h20 ---------- Previous post was at 22h19 ----------

[mode C++fanboy on]

Qu'est-ce qui fonctionne mal ?
[mode C++ fanboy off]

De mémoire parce que j'en ai pas fait depuis longtemps les destructeurs non volatiles ce qui est un grand générateur de fuites mémoires par exemple, ou encore si je me souviens bien il y avait le coup de
Fille extends Maman

Maman a une méthode pouet() que Fille surcharge.
Tu as un objet de type Fille, mais si tu le met dans une variable de type Maman et que tu appelle pouet(), c'est celle de Maman qui est appelée et non celle de la fille ce qui va à l'encontre de toute logique objet.

[rOut]

Les destructeurs peuvent être virtuels si tu les définis tels quel. Ce n'est pas nécessaire par contre, pour ne pas payer le cout dans le cas d'une classe non polymorphique, ou si tu es certain que les objets ne vont pas être détruits via un pointeur du type de le classe de base. Tout oubli va plutôt te péter à la gueule que faire des fuites mémoire à mon avis.

Pareil, si tu ne déclares pas ta fonction comme virtuelle, elle ne l'est pas par défaut, et tu ne paies pas le prix. Contrairement à d'autres langages.

[Tomaka17]

...

En C++ le programmeur doit explicitement dire au compilo "quand tu appelles cette fonction tu dois vérifier si elle n'a pas été surchargée par le fils". Lorsque tu sais que ta classe n'est dérivée par rien du tout, tu ne lui dis pas.

La raison c'est que ce système a quand même un coût niveau perf non-négligeable, du coup le C++ a préféré proposer les perfs maximales plutôt que de respecter par défaut l'orientation objet partout. C'est pas parce que le C++ n'a pas voulu faire d'orientation objet, c'est juste par pur souci d'optimisation.
D'ailleurs c'est pour ça que le C++ a du succès, parce que ça reste un des seuls langages orienté sur les performances plutôt que sur la simplicité d'apprentissage.

C'est aussi un des seuls langages où je serais capable de traduire n'importe quel code C++ en assembleur, car presque tous les autres langages ont ce petit côté "automatique" qui fait que tu ne sais pas trop comment est l'assembleur produit et que tu ne peux pas optimiser autant que tu le voudrais.

Par contre je n'ai pas trouvé comment faire l'équivalent d'un move. Pour une fonction qui prend une liste de string en entrée et retourne les string classées dans des listes en sortie, en déplaçant les strings plutôt qu'en retournant des références.

Si tu prends un "type entier" comme paramètre plutôt qu'un pointeur (par exemple si tu prends un Vec<String> et pas un &Vec<String>), alors tu move le vecteur en entrée.
Ensuite toutes les fonctions membres du vecteur comme "remove", "pop", etc. font un move de l'objet supprimé (en l'occurence la string) et te le renvoient.

Tu peux probablement aussi manipuler le paramètre directement (il faut rajouter un petit "mut") et le renvoyer une fois trié.

[TiNitro]

ouais voilà, comme l'ont expliqué mes 2 collègues, en C++ tu peux faire autrement, et ça engendre une complexité certaine (le coup du destructeur que j'avais oublié de déclarer virtuel et qui leak ça m'est arrivé au début et je ne la referais pas).

Et c'est comme ça pour presque tout.

[kpouer]

En C++ le programmeur doit explicitement dire au compilo "quand tu appelles cette fonction tu dois vérifier si elle n'a pas été surchargée par le fils". Lorsque tu sais que ta classe n'est dérivée par rien du tout, tu ne lui dis pas.

La raison c'est que ce système a quand même un coût niveau perf non-négligeable, du coup le C++ a préféré proposer les perfs maximales plutôt que de respecter par défaut l'orientation objet partout. C'est pas parce que le C++ n'a pas voulu faire d'orientation objet, c'est juste par pur souci d'optimisation.
D'ailleurs c'est pour ça que le C++ a du succès, parce que ça reste un des seuls langages orienté sur les performances plutôt que sur la simplicité d'apprentissage.

C'est aussi un des seuls langages où je serais capable de traduire n'importe quel code C++ en assembleur, car presque tous les autres langages ont ce petit côté "automatique" qui fait que tu ne sais pas trop comment est l'assembleur produit et que tu ne peux pas optimiser autant que tu le voudrais.

Je comprend bien mais du coup ça fait une implémentation objet merdique (si encore les compilateurs faisaient des checks ce serait honnête, mais comme il ne le font pas). A la limite si on veut faire de la perf autant faire du C.

[vectra]

En C++, avec toutes les nouvelles versions de la norme, est-ce qu'on a enfin des paramètres nommés?

MyFunctionCall({ xPosition: 20, yPosition: 50, width: 100, height: 5,
                 drawingNow: true });

<=>

MyFunctionCall({ width: 100, height: 5, xPosition: 20, yPosition: 50,
                 drawingNow: true });

L'intérêt du truc, c'est de pouvoir s'appuyer à fond sur les valeurs par défaut des paramètres optionnels, et surtout de ne pas devoir fixer toutes ces valeurs en séquence si on a le malheur de vouloir changer uniquement la valeur du dernier paramètre optionnel.

Je trouvais génial d'utiliser ça en Common Lisp, ça permet de faire des fonctions à la fois très versatiles et très propres.


Edit: il semblerait que ceci soit une réponse possible, mais pas encore intelligible / facile à ce stade:

http://www.boost.org/doc/libs/1_55_0...tml/index.html

[rOut]

Si tu prends un "type entier" comme paramètre plutôt qu'un pointeur (par exemple si tu prends un Vec<String> et pas un &Vec<String>), alors tu move le vecteur en entrée.
Ensuite toutes les fonctions membres du vecteur comme "remove", "pop", etc. font un move de l'objet supprimé (en l'occurence la string) et te le renvoient.

Tu peux probablement aussi manipuler le paramètre directement (il faut rajouter un petit "mut") et le renvoyer une fois trié.

Passer le paramètre ça marche mais c'est ensuite, pour move les éléments hors du vecteur que ça chie. Manipuler le paramètre d'entrée ça ne m'intéresse pas.

En gros j'ai un Vec<String> en entrée et un Vec<Vec<String>> en sortie, et je veux move les Strings de l'un vers l'autre en les classant. En C++ comme en D, je peux accéder à une des string du vecteur d'entrée, et les move vers l'un des vecteurs de sortie sans modifier le vecteur d'entrée (ie: les positions des autres strings dedans).

Pour faire ça je ne vois que get, (les autres: remove_swap et remove modifient les positions des autres string), mais pas moyen à priori (?) de move le résultat de get qui est une référence.

---------- Post added at 00h15 ---------- Previous post was at 00h13 ----------

Après c'est pas très grave, mais je trouve ça un peu dommage de ne pas pouvoir avoir de sémantique valeur pure et de devoir passer par des références (avec lifetimes nommées qui plus est pour indiquer que les String de sortie sont la prolongation des String d'entrée !).