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

Posté par (page perso) . Licence CC by-sa
25
7
oct.
2014

Sommaire

Bonjour nal

Pour le décideur pressé, j'ai écrit:

  • une lib en rust, compatible ABI C (c.a.d un joli .so et .h) pour manipuler du pinyin librustpiniyn
  • un moteur ibus pour taper chinois en précisant les tons, utilisant la lib du dessus ibus-pinyintone
  • un ensemble d'exemples sur comment créer des lib Rust appelables comme si c'était une lib C ffi-rust

et je me demande comment je pourrais packager les deux premiers dans un joli .deb qui va bien

Contexte

Tu as surement entendu parler de Rust, ce nouveau langage de programmation hype, tellement hype qu'il n'est pas encore stable, écrit par Mozilla.

Les promesses de Rust qui m'ont seduit:

  • (quasi) sans-runtime: rien ne se passe dans votre dos, possibilité de distribuer des binaires compilés depuis Rust sans devoir faire installer a l'utilisateur une JVM de plus
  • langage compilé: si vous pouvez le lancer le binaire il y a peu de chances que ca plante dans les 2 premières secondes parce que vous avez fait une coquille
  • langage fortement typé avec devinage automatique des types: le beurre et l'argent du beurre, pas d'arguments qui sont parfois des entiers, parfois des chaines de caractères car votre collègue incompétent a parfois fait le parseint avant, parfois après, parfois pas, tout en n'ayant pas besoin de préciser que le type à chaque fois quand c'est évident
  • possibilité d'être compatible avec l'ABI C
  • une librairie standard très complète (des primitives pour faire du code multi-tâches, un décodeur json intégré, que du bonheur)
  • des structures et des traits, pas d'héritage
  • possibilité de faire les choses de manière fonctionelle (closure etc.)
  • performance qui rivalise avec C++ (tout du moins à terme, mais c'est déjà plus ou moins le cas)
  • un compilateur très strict avec des jolis messages d'erreurs très lisibles
  • une communauté vibrante (merci #rust sur IRC)
  • un système de build et de gestion de dépendanceé simplissime (cargo build et c'est bon)

bref du coup je me suis dit que ce langage serait parfait pour moi qui aime le C++ (surtout depuis C++11) et Python, en gros le meilleur de ces deux mondes réunis.

J'ai donc fait pendant mes vacances, a l'aide d'un ami, une bibliothèque Rust pour convertir du pinyin, qui est en gros la transcription phonétique standardisée en alphabet latin du Chinois mandarin, en caractères chinois. par exemple de pouvoir convertir ni3hao3 en 你好.

La bibliothèque une fois créée sera utilisée par un moteur ibus (ibus étant le système le plus commun sous Linux pour taper des langues qui se tapent mal avec un clavier standard, ibus offrant les briques communes, capture des entrées clavier etc. , et les moteurs eux offrent la logique spécifique à une langue, par exemple on peut avoir ibus installé avec un moteur pour le chinois, et un moteur pour le japonais)

Les moteurs ibus étant le plus souvent écrits soit en C, soit en Python (ibus n'offrant les bindings que pour ces deux langages à ma connaissance, et quand bien, le peu de code d'exemple sont écrits dans l'un de ces deux langages), et ayant trouvé un exemple de template de moteur ibus-tmpl en C, il était plus simple d'avoir toute la logique en Rust (isolé dans la bibliotheque) et la glue du moteur en C pour réutiliser le code d'exemple.

Comment écrire une bibliotheque Rust, compatible ABI C, sans runtime (i.e avec un joli .so et .h a la fin)

les exemples (ainsi que d'autres plus complexes) peuvent être retrouvés sur le projet github https://github.com/allan-simon/ffi-rust

Générer un .so avec Rust

deux manières de procéder, soit directement dans le fichier Rust .rs ou en le précisant dans le fichier Cargo.toml (le "MakeFile" de rust)

pour les petits projets il suffit simplement de mettre #![crate_type = "dylib"] au début du fichier

#![crate_type = "dylib"]
pub extern fn hello_world() {
   println!("hello world");
}

(pub extern est là pour dire que la fonction doit être exportée, ainsi que pour dire au compilateur de ne pas s'inquiéter s'il ne voit pas la fonction hello_world utilisée, que ce n'est pas du code mort.)

ou dans le fichier cargo

[package]
name = "votre_lib_qui_va_bin"
version = "0.0.1"
authors = [ "Votre Nom <votre@email.com>" ]
[lib]
name = "nomdelalib"
path = "src/lib.rs"
crate-type = ["dylib"]

et cela génère dans les deux les deux un cas un fichier .so qui va bien, mais appelable que depuis un autre projet Rust

Rendre les noms de fonctions compatibles avec l'ABI C

pour pouvoir appeler la fonction Rust depuis du C, du Python etc., il faut que son nom soit prédictible, pour cela, hyper simple, il suffit de rajouter la directive #[no_mangle] au-dessus de la fonction, ce qui nous donne

#![crate_type = "dylib"]

#[no_mangle]
pub extern fn hello_world() {
   println!("hello world");
}

et voila, rien de plus rien de moins, et vous avez à présent un .so compatible ABI C, ce qui vous permet par exemple de l'appeler depuis Python en faisant

import ctypes
votrelib = ctypes.CDLL("libvotrelib.so")
votrelib.hello_world()

magique non?

faire des choses plus compliquées

Je ne rentrerais pas dans de longs détails ici, juste qu'il est assez simple de créer une lib, même très complexe depuis C en suivant les conseils ci-dessous:

  • il est assez simple d'échanger des int / string dans les deux sens entre Rust et C (avec une légère conversion a faire pour les string, comme elles finissent par \0 en C et pas en Rust)
  • pour les types plus complexes (du style HashMap etc.), essayer au maximum de tout faire en Rust, et de n'utiliser C que pour transporter le pointeur sur la structure d'un appel Rust à un autre

Si des gens sont intéressés je verrai peut-être pour écrire un guide en détails sur des exemples plus poussés (passage de callback, comment gérer la mémoire etc., comment se passer du runtime etc.)

ibus-pinyintones: pour les personnes qui apprennent le Chinois et oublient toujours les tons

pourquoi un moteur alternatif pour taper chinois

Cette partie là est un peu moins technique, vu que je pense que beaucoup moins de personnes sont intéressées sur "comment écrire votre propre moteur Ibus", donc ici le but était pour moi qui apprends le Chinois d'avoir un moyen de me forcer à me souvenir des "tons" des mots Chinois.

Pour ceux qui ne connaissent pas le Chinois, les tons sont une composante super importante du Chinois oral. Pour donner une similarité avec le Francais, lisez a voix haute "Tu viens manger." et "Tu viens manger ?", vous remarquez que pour la question on monte le ton en fin de phrase, ce qui permet a l'oral de distinguer la question de l'affirmation. Maintenant imaginez en Chinois le même concept mais syllabe par syllabe et non plus pour savoir savoir si une question est affirmative ou interrogative mais tout simplement pour savoir quel caractère Chinois c'est.

Le ton est super important en Chinois, car le nombre de sons en chinois est très limité. Cependant à la saisie sur ordinateur ou téléphone, souvent on entre la phonétique sans le ton (et le moteur de saisie se charge des ambigüités, en classant les propositions par fréquence, et en s'aidant des mots tapés avant). Cela a donc le fort désavantage de ne pas demander la connaissance du ton, ce qui fait que l'on peut parler sur Skype/mails de manière quasi parfaite, tout en étant incompréhensible a l'oral.

Caractéristique de ibus-pinyintone , différence avec les moteurs habituels

Ici il faut donc taper obligatoirement le ton

On peut taper "n3h3" ou "ni3hao3" pour avoir 你好, mais le nombre (c.a.d le ton) doit être présent. Cela demande donc un poil plus de frappes, mais cela est compensé par le fait qu'ainsi le nombre d'homonynes est très très fortement réduit et réduit le nombre de sélections manuelles que l'on a à faire avec les touches multidirectionnelles

Le prochain objectif est d'ajouter la prédiction du mot suivant, par exemple si je tape "je mange une" , que le moteur propose directement "pomme" "poire" "pizza" (ce que ne propose pas ibus-pinyin par exemple, et encore une fois, ce qui avec l'aide des tons, permettrait de rendre la prédiction plus efficace)

Demande d'aide: comment créer un paquet Debian de tout cela

Voila j'arrive à la toute fin, et le principal but de mon journal (je vous ai bien eu, en fait je voulais juste de l'aide, mais je ne voulais pas poster dans la catégorie forum) j'aimerai avoir un peu d'aide pour packager mon moteur et ma lib.

J'ai commencé à lire le guide pour packager sous debian mais voir que faire un package pour une lib est mis dans la catégorie "tâches" difficiles, et que j'avoue être un peu flemmard, si une bonne âme se sent de m'aider, j'en serais très reconnaissant.

Vers l'infi et l'au delà

A l'avenir je vais essayer de rapidement porter de nouveau les moteurs ibus que j'avais écrit il y a très longtemps pour l'anglais et le français (base sur une intégration d'aspell dans ibus), de manière à pouvoir taper les accents sur mon qwerty sans encombre et éviter les fautes de dyslexie du clavier que je fais souvent.

  • # 你很好玩

    Posté par (page perso) . Évalué à -6.

    你很好玩

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

    • [^] # Re: 你很好玩

      Posté par . É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

  • # faut pas avoir peur

    Posté par . É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 (page perso) . É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 . É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 (page perso) . É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 . É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 (page perso) . Évalué à 8.

  • # Script de build ?

    Posté par . É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 (page perso) . É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

  • # Une question

    Posté par . É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 (page perso) . É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 (page perso) . É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 (page perso) . É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 . É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 (page perso) . É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 . É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 (page perso) . É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 . É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 (page perso) . É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

          • [^] # Re: C'est sympa

            Posté par . É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 (page perso) . É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 . Évalué à 2. Dernière modification le 08/10/14 à 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 (page perso) . Évalué à 2.

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

    If you choose open source because you don't have to pay, but depend on it anyway, you're part of the problem.evloper) February 17, 2014

Suivre le flux des commentaires

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