Journal Bref j'ai créé une bibliothèque Rust et un moteur ibus (et je cherche comment les packager)

• # 你很好玩

  Posté par ʭ ☯ le 07 octobre 2014 à 15:38. Évalué à -6.

  

  你很好玩

  ⚓ À g'Auch TOUTE! http://afdgauch.online.fr

  • [^] # Re: 你很好玩

    Posté par zebra3 le 07 octobre 2014 à 17:04. Évalué à 9.

    

    Ouais c'est pas faux.

    Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur

    • [^] # Re: 你很好玩

      Posté par BAud (site web personnel) le 07 octobre 2014 à 17:34. Évalué à 6.

      

      c'est 好玩 que tu n'as pas compris ?

      • [^] # Re: 你很好玩

        Posté par CHP le 07 octobre 2014 à 18:04. Évalué à 3.

        

        Pinaise, je joue trop à Kerbal Space Program :

        好 : j'y vois une fusée et sa tour de lancement…

        • [^] # Re: 你很好玩

          Posté par Spyhawk le 07 octobre 2014 à 21:34. Évalué à 1.

          

          Happy 0.25 :)

• # faut pas avoir peur

  Posté par NeoX le 07 octobre 2014 à 16:00. Évalué à 2.

  

  J'ai commence a lire le guide pour packager sous debian mais voir que faire un package pour une lib est mis dans la categorie "taches" difficile, et que j'avoue etre un peu flemmard, si une bonne ame se sent de m'aider, j'en serais trs reconnaissant.

  oui alors c'est vrai que certains tutos font peur.

  mais pour simplifier un .deb c'est une archive contenant :
  - une arborescence qui reprend celle que tu auras sur ton systeme
  - quelques dossiers contenant des fichiers decrivant les dependances et les scripts qui seront lancés lors de l'installation ou de la desintallation.

  sur certains OS, tu peux meme te contenter de decompresser le .deb plutot que de l'installer pour voir comment il est fait.

  du coup quand je voulais faire mes petits packages pour installer certains fichiers automatiquements,
  j'avais une arborescence de base et les quelques scripts debian pour generé le paquet.

  • [^] # Re: faut pas avoir peur

    Posté par Allan Simon (site web personnel) le 07 octobre 2014 à 16:39. Évalué à 1.

    

    merci, en fait ici le but se serait non seulement de creer un .deb, mais un .deb depuis les sources pour pourquoi pas essayer de le pousser pour rentrer dans les repos （je pense que les deux paquets rentreraient bien dans les cases de "contrib" pour debian)

    sinon en effet pour creer un paquet pour son usage personnel, je viens de demander sur #debian, et on m'a parler de checkinstall qui simple permettre facilement d'avoir un petit .deb pour installer "comme ca"

    • [^] # Re: faut pas avoir peur

      Posté par barmic le 07 octobre 2014 à 16:43. Évalué à 3.

      

      je pense que les deux paquets rentreraient bien dans les cases de "contrib" pour debian

      Pourquoi "contrib" ? Il ne me semble pas y avoir de dépendance vers du logiciel propriétaire (selon la DSFG).

      Pour rappel contrib, c'est pour les logiciels qui sont libre mais qui dépendent de logiciels non libre. Ce n'est pas comme AUR d'Arch ou les PPA d'Ubuntu.

      Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

      • [^] # Re: faut pas avoir peur

        Posté par Allan Simon (site web personnel) le 07 octobre 2014 à 16:49. Évalué à 1.

        

        il me semble que le compilateur rust n'est pas encore dans main? (uniquement pour cela), mais oui maintenant que tu le dis, j'imagine que assez rapidement ce sera le cas.

        • [^] # Re: faut pas avoir peur

          Posté par barmic le 07 octobre 2014 à 16:59. Évalué à 4.

          

          En effet je ne le trouve pas, mais il n'est pas non plus dans contrib donc ton paquet n'a pas sa chance (en l'état). Il semble que l'équipe qui s'en occupe travail avec un PPA spécifique.

          Par contre j'ai dis une connerie tu peut quand même faire intégrer ton paquet je pense (ou du moins une version "-bin"). Tanguy pourra probablement t'en parler mieux que moi.

          Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

    • [^] # Re: faut pas avoir peur

      Posté par Michaël (site web personnel) le 07 octobre 2014 à 18:05. Évalué à 8.

      

      Tu as du rater cette passionnante discussion:

      https://linuxfr.org/users/chat_de_sorciere/journaux/pourquoi-ecrire-un-package-debian-est-il-si-complique

• # Script de build ?

  Posté par Croconux le 07 octobre 2014 à 17:01. Évalué à 3.

  

  Salut,

  créer un package Debian n'est pas si compliqué que ça. Le guide du mainteneur explique en détail à quoi sert chaque morceau et comment gérer les différents cas particuliers mais si ton package n'est pas trop compliqué, tu auras peu de choses à faire.

  Il existe l'utilitaire dh_make pour créer un squelette de paquet. En gros si ton paquet peut se builder avec un classique configure && make && make install tu n'as presque rien à faire. dh_make te génère le répertoire debian avec des stubs et/ou exemples de fichiers à compléter (ou supprimer si tu n'en as pas besoin dans ton cas) et il n'y a plus qu'à compléter (license, auteur, etc).

  Le fichier rules est en gros un makefile avec une série de cibles standard (clean, build, binary, install,…). Dans les cas simples, il y a des règles toutes faites que dh_make prérempli au maximum à partir de ce qu'il a trouvé dans ton tarball. Il est possible de surcharger des morceaux si nécessaire.

  C'est un système très complet qui permet de gérer des cas complexes. Ca peut effrayer les débutants mais on n'est pas obligé de tout utiliser. Par contre le jour où on a un paquet un peu compliqué à gérer et qu'on cherche une solution dans la doc on se rend compte que c'est déjà prévu.

  • [^] # Re: Script de build ?

    Posté par Cyril Brulebois (site web personnel) le 12 octobre 2014 à 03:02. Évalué à 3.

    

    dh_make peut effectivement faire un peu peur parce qu'il génère plein de fichiers.

    Dans ton cas précis, tu auras principalement besoin de :

    • debian/changelog : descriptif des changements mais aussi définition de la version.
    • debian/compat : probablement '8' ou '9', pas pertinent de passer du temps là-dessus.
    • debian/control : tu auras ici plusieurs « stanzas », la première définissant le paquet source (nom, dépendances de build, mainteneur, etc.), les suivantes définissant les paquets binaires (nom, architecture, dépendances, description, etc.). Tu auras probablement envie d'avoir un -dev pour le .h et un autre paquet pour la bibliothèque. Attention aux changements futurs : en cas d'incompatibilité binaire (changement d'ABI) ton SONAME doit changer et le paquet être renommé en conséquence. On peut imaginer librustpinyin-dev et librustpinyin0 (en imaginant que tu fournisses libpinyinengine0.so) pour commencer.
    • debian/copyright : je ne te fais pas de dessin.
    • debian/rules : cf. ci-dessous.

    Vu les informations données dans le README.md, tu pourrais probablement commencer par ce qui suit (en faisant attention à bien utiliser des tabulations plutôt que des espaces) :

        #!/usr/bin/make -f
        %:
            dh $@

    Cela permet d'avoir plein de choses gérées de façon automatique. Tu peux ainsi te concentrer sur ce qui a besoin d'être spécifique. Comme le système de build est particulier, il te faudra probablement commencer par :

            override_dh_auto_configure:
                # Do nothing
    
            override_dh_auto_build:
                cargo build

    Concernant la ventilation des fichiers parmi les paquets binaires, le plus simple est probablement de lister les fichiers voulus dans debian/librustpinyin-dev.install et debian/librustpinyin0.install

    Le canal #debian-mentors et la liste de diffusion debian-mentors@ sont les bons endroits pour poser des questions supplémentaires.

    Debian Consultant @ DEBAMAX

    • [^] # Re: Script de build ?

      Posté par Allan Simon (site web personnel) le 15 octobre 2014 à 06:23. Évalué à 1.

      

      parfait, merci pour l'explication detaille, je vais regarder cela ce soir a tete reposee.

• # Une question

  Posté par reno le 07 octobre 2014 à 17:28. Évalué à 5.

  

  Pour moi, Rust c'est Ada++: un langage très strictement typé dont les types incluent même la durée de vie des variables, hors je vois que pas mal de gens tapent sur Ada car ils trouvent le compilateur 'trop strict', donc c'est comment Rust en pratique?

  Pas trop dur de satisfaire le compilateur pour la gestion des 'durée de vie'?

  • [^] # Re: Une question

    Posté par Allan Simon (site web personnel) le 07 octobre 2014 à 19:11. Évalué à 8.

    

    non pas dur du tout, en fait pour la lib en question, il n'y meme aucune, zero, nada specification de duree de vie, le compilateur gere tout tout seul.

    Grosso modo, mais attention je suis neophyte en C++ et rust donc si des personnes plus experimentees peuvent confirmer, je suis preneur:

    • pour tous les cas facile, rust se debrouille tres bien sans aucune indication supplementaire par exemple si tu fais

    fn create_vector_of_string() -> Vec<String> {
    
        let mut myvector = Vec::with_capacity(10);
    
        for i in range(0, 10u) {
            let i_as_string = i.to_string();
            myvector.push(i_as_string);
        }
    
        return myvector;
    }
    
    fn main() {
        for string in create_vector_of_string().iter() {
            println!("{}", string);
        }
    }

    ici rust est intelligent et devine que myvector a pour unit but d'etre passer en valeur de retour, et donc ne sera pas "copier" (en C++ si je me trompe pour avoir la meme chose on aurait du passer myvector en tant que parametre par reference ?)

    pareil pour i_as_string ce qui en c++ aurait du forcer l'utilisation de fonction special de std::vector introduite uniquement recemment

    l'exemple un peu plus poilu que j'ai en tete, pour ma lib par exemple qui communique avec C et donc pour laquelle rust a un moment "perd de vue" les donnees, typiquement le probleme est resolu en faisant

    fn new_complex_object () -> Box<ComplexObject> {
       // code qui construit et retourne une nouvelle instance de complexe object
    } 
    
    fn use_complex_object (instance: &ComplexObject) {
       // utilisation en read only de ComplexObjet
    }
    
    fn free_complex_object (instance: Box<ComplexObject) {
      let _ = instance;
    }

    deja en conversion C, Box et & ont la meme transposition en pointeur, la difference etant uniquement pour rust, Box offrant la garantie qu'on ai le seul a posseder ce pointeur, ce qui veut dire que:

    Pour mon new, je dis "le morceau de code qui recupera ma Box en sera le seul et unique detenteur, moi je m'en lave les mains"

    Pour mon use je dis "je peux utiliser l'objet temporairement, mais je dois le rendre intacte a celui qui me l'a passe"

    et pour mon free je dis "on me passe l'objet et j'en deviens l'unique detenteur, vu que je n'en fais rien, alors je peux le detruire et liberer sa memoire sans creer d'effet de bord"

    Apres evidemment il y a des cas plus complexes, mais des lors

    • soit en effet on doit utiliser des indicateurs de duree de vie, et ca deviens un poil plus complique, mais une fois que le compilo dit que c'est ok, on est sur que ca marche, alors qu'en C / C++ on a pas besoin de le preciser pour la bonne et unique raison que personne est la pour verifier nos optimisations de magie noire, donc ca peut tres bien nous peter a la gueule
    • soit on clone a gogo les objets pour eviter le probleme, certe c'est moins efficaces (plus lent/plus consomatteur de source) mais apres avoir eu son programme qui nous crash 20 fois a la gueule on aurait surement fini par faire pareil en C++

    En gros pour moi, Rust n'a que des avantages sur C++ a part evidemment les desavantages du a sa jeunesse (i.e pas encore stable, compilateur n'ayant pas encore recu tout l'amour du monde sur lapartie "optimization pour faire du code rapide comme l'eclair"), surtout du fait qu'on peut tout a fait utiliser les librairies C existanstes depuis Rust.

    • [^] # Re: Une question

      Posté par TeXitoi (site web personnel) le 15 octobre 2014 à 00:04. Évalué à 2.

      

      create_vector_of_string en plus simple (et aussi efficace):

      fn create_vector_of_string() -> Vec<String> {
          range(0u, 10).map(|i| i.to_string()).collect()
      }

      ici rust est intelligent et devine que myvector a pour unit but d'etre passer en valeur de retour, et donc ne sera pas "copier" (en C++ si je me trompe pour avoir la meme chose on aurait du passer myvector en tant que parametre par reference ?)

      En fait, en C++, ça donne dans ce cas la même chose, c'est la RVO.

      pareil pour i_as_string ce qui en c++ aurait du forcer l'utilisation de fonction special de std::vector introduite uniquement recemment

      Rust gère les types affines, appelé en C++11 "move". Mais en rust, c'est réellement intérgé : lorsqu'on a mové un objet, si on essaye de l'utiliser ensuite, le compilo te le dit (erreur).

      Box offrant la garantie qu'on ai le seul a posseder ce pointeur

      Pour les gens connaissant le C++11, Box<T> en rust, c'est en gros la même chose que std::unique_ptr<T> qui peut pas être à nullptr (l'équivalent strict de std::unique_ptr<T> est Option<Box<T>>, qui est d'ailleurs directement compatible avec T* en C).

      Pour mon use je dis "je peux utiliser l'objet temporairement, mais je dois le rendre intacte a celui qui me l'a passe"

      &T et à peut près équivalent à T const& en C++ (si on pinaille, c'est plus proche de T const* qu'on peut pas mettre à nullptr).

      et pour mon free je dis "on me passe l'objet et j'en deviens l'unique detenteur, vu que je n'en fais rien, alors je peux le detruire et liberer sa memoire sans creer d'effet de bord

      En fait, l'objet est mové dans la fonction, puis détruit à la sortie de la fonction car personne ne peut y référencer. On peut même simplifier le code à

      fn free_complex_object (instance: Box<ComplexObject) { }

      Oui, juste une fonction vide, d'ailleurs, c'est exactement l'implémentation de drop, les génériques en moins : http://doc.rust-lang.org/0.12.0/src/core/home/rustbuild/src/rust-buildbot/slave/dist2-linux/build/src/libcore/mem.rs.html#348

      mais attention je suis neophyte en C++ et rust donc si des personnes plus experimentees peuvent confirmer, je suis preneur

      J'ai un peu formalisé certains trucs et fait les parallèles avec C++, mais sinon, je confirme, c'est très bien ce que tu dis là ;)

      • [^] # Re: Une question

        Posté par Allan Simon (site web personnel) le 15 octobre 2014 à 06:21. Évalué à 1.

        

        exact, merci pour les precisions, pour la fonction "free" vide, oui pas bete, maintenant que tu le dis c'est evident en fait.

        pour la creation de lib, je pense refaire un article plus detaille et corrige, car apres discussion sur #rust, utiliser des fonctions du crate std depuis C est Undefined Behaviour (par exemple mon println!()) sauf a initiliaser le runtime et a prendre beaucoup de precaution.

• # C'est sympa

  Posté par Spyhawk le 07 octobre 2014 à 19:03. Évalué à 5.

  

  C'est sympa, d'avoir codé ton propre IME. Néanmoins, je voulais souligner qu'il est possible de taper du pinyin avec les tons via {iBus,fcitx}-rime, modèle Terra Pinyin.

  • [^] # Re: C'est sympa

    Posté par Allan Simon (site web personnel) le 07 octobre 2014 à 19:42. Évalué à 2.

    

    en effet, je ne connaissait pas merci, et pourtant je promets que j'avais cherche (peut-etre pas assez)

    bon tres bien, je vais voir le fichier de donnee et comment ils arrangent ca, voir ce que je peux reutiliser （l'idee d'utiliser < / \ - pour les tons et bonnes, meme si j'imagine que du coup c'est plus dur de faire le lien dans sa tete < => 3eme ton) . Cependant j'avoue continuer sur ma lancee pour les raisons suivantes:

    • rime ne me semble pas supporter la prediction du prochain mots (tout comme ibus-pinyin)
    • les dependances me semble un peu enorme (boost, kyotokabinet, une lib pour parser le yaml et d'autres)
    • la base de code pour rime est enorme aussi (bon vu le nombre de feature ca me semble normal, mais je suis plus un tool une tache, quitte a avoir plein de tool, mais des lors on peut avoir des lib communes)
    • on peut taper sans tons, et tout comme utiliser vim avec les touches directionnelles activer, ce n'est qu'en suprimmant la voie de facilite qu'on se force a adopter les bons reflexes (mon avis personnelle）

    surtout que mon but serait de pouvoir reutiliser ma lib de base pour ensuite creer juste les bindings graphique pour creer un IME egalement pour android et voir windows (ce que rust a terme me permettra, surtout partant du fait que je n'utilise que la lib standard， bon je viens de regarder, visiblement rime fourni la meme pour windows et macosx, flute), ce que je serais incapable de faire avec librime.

    En tout cas merci, du coup je sais que j'ai plus interet a specialiser mon IME pour faire la frappe avec ton de maniere efficace, plutot que d'essayer de reintegrer la frappe sans tons etc. ce qui ne ferai que creer un clone de rime.

    • [^] # Re: C'est sympa

      Posté par Spyhawk le 07 octobre 2014 à 20:47. Évalué à 4.

      

      j'ai plus interet a specialiser mon IME pour faire la frappe avec ton de maniere efficace, plutot que d'essayer de reintegrer la frappe sans tons

      C'est discutable. Forcer l'usage des tons est louable, mais en pratique le ton que tu tapes n'est pas celui que tu prononces (ton sandhi, ni3hao3 c'est en fait ni2hao3). Si l'objectif final est d'apprendre la prononciation correcte, obliger à taper faux n'est peut être pas pertinent. En faire une option est sans doute une bonne idée.

      Dans tous les cas, je t'encourage à continuer dans ton projet! Je préfère fcitx à iBus, mais qui sait peut être que quelqu'un fera un port dans l'avenir :)

      • [^] # Re: C'est sympa

        Posté par Allan Simon (site web personnel) le 07 octobre 2014 à 22:12. Évalué à 2.

        

        Certes mais tu seras d'accord avec moi que le ton sandhi est quelque chose que l'on fait "automatiquement", et cela assez tot dans l'apprentissage du Chinois, et la norme est de ne pas l'ecrire mais de faire le sandhi "dans sa tete" (je viens de regarder dans les livres pour enfants Chinois avec Pinyin ils font pas le ton sandhi). Je justifierai cela et ma position que ce n'entrave pas le but de prononcer correctement dans le sens ou le ton sandhi est reserve a des cas tres particulier, et que du coup il faut mieux que je tape "ni3hao3" et me dire "ok 你 c'est 3eme ton" et ajouter la surcharge de temps de cerveau pour faire la convertion ni3hao3 "ma langue fera ni2hao3" si je dois le prononcer. plutot que de taper ni2hao3 et ne plus me rapeller si c'est ni2 de base ou ni2 par ce qu'il y a un ton sandhi

        grosso modo ma vision de la chose est qu'ainsi dans mon cerveau je memorise "caractere avec ce sens => ce ton de base" que je peux ensuite reutiliser partout (par exemple autre usage du caractere dans une situation sans ton sandhi)

        et pour l'oral appliquer le ton sandhi seulement a la sortie de ma bouche. i.e un peu comme on en programmation on n'echape les donnees qu'a l'affichage et on evite de garder en memoire les version echapees
        (desole d'avoir fait un peu long, c'etait plus pour m'aider a clarifier ma propre position qu'essayer de te convaincre)

        apres pour le "en faire une option", comme je disais, le probleme pour moi, grand feignasse devant l'eternel, c'est que je vais aller a la solution de facilite, par exemple tout a l'heure j'ai pris 10 secondes a retrouver que 自己 c'etait 43, mais maintenant je m'en souviens car j'ai pris ces 10 secondes, sinon j'aurai simplement fait "bouaf pas le temps, je suis presser faisons sans les tons" et a la fin on perd l'utilite (car des lors je ne te taperai les tons que lorsque ca ne me fais pas perdre de temps, c.a.d quand je les sais, c.a.d quand j'ai pas besoin de les taper…) un peu comme le numero de son colloc, pour lequel on se dit "je dois l'apprendre par coeur un jour si mon tel a plus de batteri et que je dois lui telephoner pour lui de mettre les clef sous le paillason" et on ne le fait jamais car on appuie juste sur "colloc" , alors que si on avait ete forcer mecaniquement a le taper ne serais-ce que 2/3 fois, on l'aurait retenu

        tout cela pour dire, je pense qu'ici mon moteur est vraiment pour un cas particulier "personne voulant se forcer a taper les tons" (peut-etre qu'il n'y a que moi， vu que j'ai remarque que je suis aussi assez seul a avoir remapper les touches directionnelles dans vim sur echape pour devoir utiliser hjkl）. et que pour les autres, ibus-rime avec terra pinyin comme tu me l'as fait decouvrir, rempli deja ce role de moteur plus versatile.

        Dans tous les cas, je t'encourage à continuer dans ton projet! Je préfère fcitx à iBus, mais qui sait peut être que quelqu'un fera un port dans l'avenir :)

        hm ? port de mon moteur sur fcitx ? ou d'autre chose ?

        • [^] # Re: C'est sympa

          Posté par Spyhawk le 07 octobre 2014 à 22:34. Évalué à 2.

          

          (desole d'avoir fait un peu long, c'etait plus pour m'aider a clarifier ma propre position qu'essayer de te convaincre)

          En effet, beacoup plus court aurait suffit à me convaincre :)

          hm ? port de mon moteur sur fcitx ? ou d'autre chose ?

          Oui, sur fcitx.

      • [^] # Re: C'est sympa

        Posté par GG (site web personnel) le 07 octobre 2014 à 22:16. Évalué à 2.

        

        Et si on installe fcitx, qu'on veut pouvoir saisir du pinyin ou du zhouyin (taiwan), quelles sont les éléments à installer ou pas, pour éviter que dans Libreoffice et d'autres logiciels on ne puisse plus saisir le ^ (l'accent circonflexe)?

        Merci

        Pourquoi bloquer la publicité et les traqueurs : https://greboca.com/Pourquoi-bloquer-la-publicite-et-les-traqueurs.html

        • [^] # Re: C'est sympa

          Posté par Spyhawk le 07 octobre 2014 à 22:37. Évalué à 2.

          

          Il suffit de sortir du mode pinyin/zhuyin, je ne suis pas sûr de comprendre ton problème (je n'utilise pas LibreOffice).

          • [^] # Re: C'est sympa

            Posté par Allan Simon (site web personnel) le 08 octobre 2014 à 08:54. Évalué à 1.

            

            il me semble que les ^ etait bouffe par certain IME (par exemple ibus-pinyin il y a longtemps le faisait, je ne sais plus si c'etait le cas tout le temps , ou juste en etant en mode anglais , i.e avec shift, ou meme en le desactivant, avec control space)

            • [^] # Re: C'est sympa

              Posté par Spyhawk le 08 octobre 2014 à 12:22. Évalué à 2. Dernière modification le 08 octobre 2014 à 12:23.

              

              Oui, j'ai eu pas mal de souci de ce genre avec iBus à l'époque. C'est l'une des raisons qui m'a fait changer pour fcitx, mais pas la seule.

              Sinon, si t'as accès à une machine Windows, tu devrais jeter un oeil au fonctionnement de l'IME Microsoft Office 2010. Ironiquement, avec la version traditionnelle, il est possible de taper (en simplifié) en pinyin avec les tons optionnellement (via les chiffres). C'est globalement la solution la plus intuitive et efficace que j'ai trouvée dans le cadre de l'apprentissage du Mandarin. Par contre, c'est effectivement pas disponible sous Linux, et encore moins open source.

• # Promotion en dépêche ?

  Posté par palm123 (site web personnel) le 08 octobre 2014 à 07:48. Évalué à 2.

  

  J'ai corrigé 2/3 typos, en passant.

  ウィズコロナ

  • [^] # Re: Promotion en dépêche ?

    Posté par BAud (site web personnel) le 08 octobre 2014 à 07:57. Évalué à 1.

    

    Je ne la vois pas encore dans l'espace de Redaction ;-) (ni de modération d'ailleurs).

  • [^] # Re: Promotion en dépêche ?

    Posté par Allan Simon (site web personnel) le 08 octobre 2014 à 08:52. Évalué à 1.

    

    j'ai rien contre, meme si a la base c'etait plus une question de forum enrober dans du "je-raconte-mavie".

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.