Allan Simon a écrit 94 commentaires

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

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 ?

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.

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.

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.

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"

Le projet a l'air intéressant, cependant ça manque de capture d'ecran (de manière general, c'est la premiere chose que je recherche quand je tombe sur un nouveau projet, ou alors des examples d'entree sortie, pour une appli en ligne de commande)

spoiler: c'est en fait juste la mobylette, le patron de l'entreprise des 4 camions ayant certifié que ses camions n'étaient pas le problème (il a même prouvé sa bonne foi en offrant un paquet de cigarette à l’enquêteur)

Il y a cppcms qui offre un framework plus classique,

[mode auto-pub pour mon projet open-source]

après au dessus de cela, pour générer du code plus en "MVC" et sans prise de tête, j'ai créé cppcms-skeleton, qui permet d'avoir directement un projet structuré et automatiser certaines taches (création du CMake, création d'un nouveau contrôleur etc.)

Je l'utilise déjà sur plusieurs projets:

• un moteur wiki (qui propulse le wiki du projet tatoeba.org et un autre wiki ici, utilisant boostrap , le code est identique, juste un changement de skin

• un moteur de blog (un peu moins avancé niveau fonctionnalité, mais plus facilement installable) , j'ai une instance ici , pour mon propre blog

après pour l'instant je n'ai pas encore masse de documentation comme je suis encore plus à peaufiner le code, mais je suis plutot reactif et ça me motiverai à écrire des tutos etc.

D'ailleurs un peu de détail sur comment s'est passé cette transition, et de part cette experience, les choses que tu ferais autrement si c'était à refaire depuis le début, si tu as eu deux trois fausses routes avant d'arriver à la situation actuel etc. etc.

C'est pour ça, je vis dans un pays lointain ou personne ne me connait, donc le cercle de mon "entourage" est très restreint et j'ai fait savoir assez rapidement que je n'aimais pas du tout mais alors paaaaas du tout qu'on me prenne en photo à mon insu. (bon expliqué de manière rationnel sans évoqué les points parano , un simple 'je t'assure je n'aime vraiment pas, certains aiment pas voir les clowns, les araignées, moi c'est les appareils photos')

Ces personnes là ne parlent pas Anglais, n'ont pas accès à facebook, ne connaissent pas ma famille (et vice versa). Et avec les amis français que j'ai ici, ce sont aussi des informaticiens, et on a une stratégie de rétentions "ce qui se passe entre nous reste entre nous". Du coup tout se passe très bien, j'ai une vie sociale avec des amis geeks et non geek, et les seuls informations que l'on trouve sur moi sont pratiquement toujours d'autres professionnel (en plus j'ai un couple {nom,prénom} super courant dans le monde francophone et anglophone, donc ça brouille encore plus les pistes . Enfin on verra le jour ou je relèverai des informations classés…

Bon ma situation est particulière, du coup je serais intéressé de voir ce que font les autres personnes ici pour "limiter" la fuite d'informations les concernant, surtout celles "non filtrées"

J'ai déjà les musiques dans ma playlist "je code à 4heure du matin", car je trouve qu'elles sont comme le reste de la partie "artistiques", de très bonnes factures.

Il me semble qu'il doit y avoir des licences "vous avez juste le droit de regarder" (il me semble que c'est de base ce qui se passe si tu mets le code source à disposition sans préciser de licence, mais évidemment pour être deux fois sur, il doit y en avoir qui formalise un peu plus cela)

Je comprends que pour un premier projet, tu veuilles en garder le controle, je pense donc à la rigueur que rien que pouvoir "regarder" le code serait déjà vraiment pas mal.

Surtout que je pense que beaucoup de personnes (enfin au moins moi) ici serait beaucoup plus enclin à en parler à leur entourage (ou blog/sites perso etc.) si c'était open source/libre, ce qui je pense pourrait jouer significativement sur la popularité du jeu.

Je ne pense pas que cela soit légalement possible

Tout les contenus ne sont pas sous licence CC-by-sa, et ils ne me semblent pas que l'on cède nos droits à Linuxfr.org lorsque l'on s'enregistre vis à vis de l'ensemble du contenu qu'on serait amener à produire dessus. Du coup chacun garde tous ses droits vis à vis du contenu que lui meme produit. Je peux très bien avoir posté un commentaire, autoriser à ce qu'il soit affiché sur le site, mais pas vouloir qu'il soit inclus dans un gros package "contenus de LinuxFR" (qu'elle en serait la licence ?)

Après évidemment je ne suis pas un juriste, et si quelqu'un à plus de précision ou si j'ai dit de la merde, n'hésitez pas à me corriger.

Cela dit je serais également intéressé, dans le cas d'une API permettant d'avoir au contenu d'un site, dont une partie généré par ses utilisateurs, faut-il le prévoir explicitement dans les conditions d'utilisations ? J'imagine qu'au minimum il faut que le contenu apparaisse avec le nom de l'auteur (ou pseudonyme).

Rien à voir, mais vu qu'un commentaire précédents faisaient la remarque sans te corriger

on dit "quote" (plus ou moins "kuote" en phonétique à l'arrache) en Anglais (d'où je pense la confusion avec "côte" en Français), j'avoue avoir mis un peu de temps à comprendre.

Si je me souviens bien des autres entrées de journal/sur le forum, quand le sujet avait été abordé, il me semble qu'il compte rendre le code libre une fois la première version stable atteinte.

ou expatrier dans un pays ou il est coutume de boire cul-sec avec ses collègues, amis par politesse et ou le premier mot qu'on apprend à dire c'est "ganbei!" (cul sec)

sinon je suis d'accord qu'en se fixant des limites assez simple à suivre (par exemple je me suis fixé de ne pas boire pendant les repas, jamais à la maison et en semaine, seulement le weekend ou lors de grande occasion (anniversaire etc.) )on diminue grandement sa consommation, et en se disant que par le même coup on baisse son budget alcool, on peut plus facilement se prendre une bonne bouteille de vin par mois plutôt que un pack par semaine

Tu bosses dans quel coin, il y a moyen de te joindre en privé? L'année dernière on avait parlé de se faire une bouffe entre linuxfrien expat en Chine.

Tu l'as récupéré ou ce script ? ça m'intéresse.

Mon avis sur le "pourquoi c'est pas tant une arnaque que ça"

http://linuxfr.org/users/gnumdk/journaux/canonical-s-attaque-au-marche-chinois#comment-1440111

après oui, ton paquet proprio aura des chances de t'installer un nouveau certificat qui va bien, et le miroir officiel aura surement pas "tor", bon c'est balot pour madame michu, mais je ne pense qu'il sera tout à fait possible d'avoir le beurre et l'argent du beurre, en isolant, repackageant les .deb proprio (et/ou en faisant deux trois manip pour cleaner les merdes que le .deb aura installé/modifié) pour ceux qui ont des compétences en informatique. (i.e le mec calé en info qui installe linux pour lui ou ses amis, pourra très bien avoir une version "normal" de ubuntu , avec les paquets proprio qui l'intéresse, pour avoir à la fin une ubuntu fonctionnelle pour les besoins du pékin moyen)

Bon grâce à ce journal qui a du allumer toutes les alertes des équipements cisco du GFW (allez on en remet une couche) je sens que dans pas longtemps en Chine on aura le droit au fameux "connection reset" quand on ira sur linuxfr.org

Pour avoir installer ubuntu chez plusieurs amis chinois, oui écrire chinois, et le support du système (traduction des logiciels principaux etc.) est déjà plus que bon (enfin rien à envier à Windows ou Mac sur ce point là).

Après voilà ce qu'il manque par exemple à mes amis c'est

1. pouvoir consulter leur compte
2. pouvoir payer sur Taobao en ligne (le ebay chinois)
3. pouvoir payer leur billet de train en ligne

4. parler avec papa maman sur QQ avec la webcam (pour les amis etc. ils sont déjà passé à Weixin /QQmobile, donc le problème d'un client desktop est moins important)

   Après avec Wine, QQ passe bien, PPstream aussi, photoshop aussi donc je pense qu'ubuntu pour leur première version, aurait tout intêret à faire des packages avec le wine qui va bien, en attendant de pouvoir proposer des versions natives, si jamais cela se fait.

Oui je te rejoins sur pas mal de point mais justement

Dans le cas de red flag, c'était eux qui faisait la partie "allez on va faire un truc" et le "on doit continuer à le faire vivre" , ce qui comme toi et moi l'avons dit, vu qu'après la promotion, le suivant en a rien carré. Ça tombe dans l'oublie

Mais là, une fois passé le message officiel "ouais j'ai fait mon discours et on en profité pour allez boire du moutai avec les collègues du parti et faire des fapiaos surévalué histoire de s'en mettre dans les fouilles au meme moment", il y a une compagnie qui elle, ayant un interet financier dans l'affaire, aura un "message officiel" qu'il pourra utilisé comme argument de vente.

Pour ce qui est des versions des logicielles , oui la version officiel QQ est un désastre, ça crash de partout, ça détruit les groupes, pas de possibilités de faire de webcam (enfin de mes souvenir d'il y a 3 ans, mais le numéro de version du deb ayant pas changé…) , mais ça avait été fait comme tu l'as dit dans un contexte ou les parties en jeu était

1. Le mec du partie faisant pression, qui y connait rien à la pratique et à qui la démo suffisait
2. les mecs de chez tencent qui n'avait sûrement que très peu de compétence interne en dev linux

Là on ajoute dans l'affaire une entreprise qui a déjà une expertise sur le sujet, et de plus entre temps, tencent à du faire des versions android, mac, ipad toussa de ces différents logiciels, ce qui je pense à améliorer leur capacité à faire des softs pour plusieurs plateforme.

donc pour résumer, oui je ne pense pas que cela aura un succès retentissant, qui fera passer ubuntu à 10% de part de marché. Mais je pense que cela a beaucoup plus de chance de marcher que red flag linux, et que ça boostera un peu plus ubuntu en chine (car il faut aussi se souvenir qu'en chine, dans le AnHui par exemple, Dell et Ubuntu on des Ubuntu shops, donc là bien une collaboration entre deux compagnies, qui profitera surement de ce petit coup de pub). Donc voilà, sûrement pas une révolution, mais ça peut offrir une petite pichenette à ubuntu.

disons qu'après je pense que ce sera plus un succès que red flag linux, pour la raison que c'est supporté par une entreprise, qui a pied à l'étranger et qui s'appuie sur d'autres distrib (debian toussa). Du coup ce sera maintenu suffisamment longtemps et avec un produit déjà suffisamment prêt pour au moins atteindre le 1% d'utilisateur (ce qui est représenterait je pense déjà une progression énorme), ce qui du coup à plus de chance de percer chez madame michu (surtout que red flag n'a pas été lancé dans le meme contexte de maturité des divers logiciels linux, ou tout simplement de respect des standards des sites webs, bon je sais qu'en chine c'est pas encore cela, mais ça vient)

Je rejoins sur le fait que sur kylin, le gouvernement chinois ferra plier canonical, je disais simplement que ce sera surement sur le point "intégrer nos services sino-chinois dans le dash" plus que dans le "intégrer nos mouchards et keylogger"

Après je pense que le libre y gagnera quand même un peu, car madame michu sera toujours sur une plateforme plus ou moins fermé/controllé, mais le fait que les applications "grand public" soient portés sur linux, aideront les geeks en herbe à franchir le pas, car tout comme steam, rien ne les empechera de repackager QQ, AliWangwang etc. pour d'autres distrib (ou même la ubuntu standard) et de l'expérience que j'ai eu avec mes élèves, c'était ses applications qui permettent de parler avec papa/maman, acheter son billet de train vite fait, qui leur fait rebooter. Et évidemment on va pas rebooter juste pour une ligne de commande, et à l'inverse on lancera plus facilement une ligne de commande trop cool trouvé sur un blog geek entre deux partie de QQ games

Donc la nouvelle m'enthousiasme quand même, mais plus pour les répercurssions que cela pourra avoir (plus d'opérabilité, même juste le strict minimum, plus facile de faire passer ses amis élèves/amis au libre et à ses formidables outils), que pour le "ubuntu kylin" en lui même.