PyroTokyo a écrit 71 commentaires

J'ai testé mais on dirait que même sans update, Aptitude semble modifier le cache d'une façon ou d'une autre.
Je viens de tester sur mon Raspberry PI sous raspbian, et je n'ai pas eu le problème, donc c'est peut être un bug dans sid…

Si on me dit que du "make install" violent peut casser l'harmonie des sphères célestes dans mon système, oui, mais là on parle quand même des 2 applications les plus utilisées pour la gestion de paquets sous Debian. Ou alors je surestime grandement l'utilisation d'aptitude dans la communauté ? C'est possible aussi…

Dans ce cas, vu qu'apt a l'air d'être là pour rester de toute façon, qu'on déclare aptitude hors-jeu officiellement et qu'on en parle plus. Parce que mettre le boxon dans le cache de l'outil par défaut, c'est pas glop.

D'ailleurs je ne me souviens pas avoir eu de soucis particuliers du temps d'apt-get ?
A vue de nez, je dirais quand même que le fautif est aptitude, car apt semble pouvoir désinstaller correctement les paquets installés par son cousin.

D'ailleurs, si quelqu'un connait un autre moyen de faire des requêtes un peu évoluées en CLI autrement que sur aptitude, je suis preneur !
Parce que ça, c'est bien puissant !

Etant au Japon je serais intéressé de savoir !
J'avais bien entendu parler de 2 ou 3 boites qui font du Haskell pour la finance sur Tokyo, mais à part ça…
Sinon, j'ai entendu que Rakuten recherchait pas mal de 'data scientists' pour faire du data mining, du machine learning, etc. Sur le papier, ça avait l'air sympa, mais par contre c'est vraiment côté salaire que ça ne suivait pas de mon point de vue…

Bon, je me réponds à moi même, car je n'ai pas assez lu la doc on dirait
Python doc

If strict is False (True is the default), then control characters will be allowed inside strings. Control characters in this context are those with character codes in the 0-31 range, including '\t' (tab), '\n', '\r' and '\0'.

Donc il suffit de faire

json.load(f,strict=False)

et ça marche comme il faut.

Au temps pour moi, je n'avais pas vu le problème sous ce jour là. Effectivement cela nécessite de tripatouiller un peu le contenu du fichier avant. Même si c'est pas la mort, c'est pas idéal je le reconnais…

J'ai l'impression qu'on mélange un peu tout là. Des statistiques descriptives, du machine learning, des tests…
Donc pour mettre les choses au clair :

• plus la taille de ton échantillon est grande, plus on peut avoir des estimateurs précis : une moyenne calculée sur 1.000.000 d'échantillons est intuitivement plus "fiable" qu'une moyenne sur 10. Et ça se démontre avec sa variance (cf. théorème central limite).

• un test statistique par définition, c'est "est-ce que mon hypothèse est vraie, et avec quelle probabilité ?"
  Donc oui, si tu augmentes la taille de ton échantillon, tu es en mesure d'être plus discriminant.
  Ex: Hypothèse: plus de la moitié des Français a un accès à la fibre optique.
  Si ton échantillon est petit, genre 10 personnes, tu seras en mesure d'apporter une réponse, mais avec un gros risque d'erreur. H est vraie avec une proba de 50% par exemple.
  Si tu interroges tout le monde, l'erreur passe à 0. Effectivement, c'est tout blanc ou tout noir du coup, mais je ne vois pas le problème, vu qu'en général on veut quand même un moyen de décision, pas juste un "ça dépend"

• Grands nombres pour machine learning, oui et non.
  Non parce que le sur-apprentissage, ça existe et c'est un problème… Par contre si la taille de ton jeu d'apprentissage est trop petite, on n'apprend rien, logique…

Donc oui, on peut faire des stats, parfois étonnamment précises, avec de petits jeux de données, mais dire que plus on a de données plus ça brouille tout, là non…

Quant à la phrase "tout devient normal, on ne voit plus rien", j'ai pas compris… tu parles du théorème central limite ? Je vois mal en quoi "on ne voit plus rien". Au contraire.

Avec des triples quotes ça fonctionne correctement, ou alors je n'ai pas compris le problème.

import json
a={
    "value": "plop",
    "desc": """uaiodufo sjfofjue oifjiof hdofhof sjfohssfohd fodhdso fhjsfhuosjhsdkjfhsdjkfh
    oweiruweoiruweour iow""",
}
b=json.dumps(a)

me renvoie bien

{"desc": "uaiodufo sjfofjue oifjiof hdofhof sjfohssfohd fodhdso fhjsfhuosjhsdkjfhsdjkfh\n    oweiruweoiruweour iow", "value": "plop"}

Merci pour la réponse, c'est effectivement plus clair.
Une chose en amenant une autre, j'ai commencé à lire plus en détail sur ce "monomorphism reduction", et je suis tombé sur d'autres choses que je ne trouve même pas mentionnées dans les livres du genre "Real World Haskell", à savoir scoped types, pattern type definition, etc… Ce dernier me laisse particulièrement perplexe aussi: il est dit que c'est complètement orthogonal au type definition que j'utilise d'habitude, mais j'ai beaucoup de mal à voir la valeur ajoutée. Quoi qu'il en soit, c'est un peu la jungle dans toutes ces extensions GHC !

OK, j'y vois un peu plus clair effectivement…
Il faut donc spécifier une signature quand cette restriction est active…
Mais dans ce cas, pour ceci ne marche pas ?

let sum' = foldl' (+) 0 :: Num a => [a] -> a
:t sum'
sum' :: [Integer] -> Integer

Il faut absolument passer par le style déclaratif plutôt que par une expression ?

Je viens de faire un test sous Arch, avec ghc 7.8.3, et il semblerait que cette spécialisation n'ait pas lieu. Les 2 écritures restent équivalentes.
Donc c'est peut-être dû à ghc 7.6.2 ?

Encore une fois, je ne connais PAS UN SEUL japonais qui prefera lire sa langue en romaji plutot qu'en kanji… anomalie statistique ???

Donc en gros, on en conclut que parmi les gens qui ont un bon niveau d'anglais, un bon nombre lisent le journal en anglais… Ça me paraît pas terrible comme conclusion ^{^}

(soupir) oui je sais, c'est une des choses qui me manquent le plus au boulot…

Après vu comment c'était dit, le commentaire laissait entendre que c'était sinon une majorité, au moins une bonne grosse minorité…
Si on veut s'amuser au détriment des mouches, sur un pays de 120 millions d'habitants, 1/10000 ça fait quand même "un bon nombre" qui reste très marginal.
Personnellement, je suis plutôt d'accord que le niveau moyen en anglais est très bas, malgré la multitude d'écoles de langues et la foison de profs d'anglais autoproclamés pour qui ça représente un visa de travail. C'est fou la quantité d'argent que brasse ce business en dépit du peu de résultats…

Personnellement en termes simplicité, j'ai toujours été ébahi par l'espagnol. Bien sûr il y a des exceptions, comme partout, mais côté prononciation et orthographe je n'ai jamais eu de surprises, malgré les abondants emprunts à l'arabe.
C'est clair qu'à côté, le français et l'anglais c'est le joyeux bazar.
L'italien a l'air assez régulier aussi, mais ne le parlant pas, je ne peux pas me prononcer.

C'est vrai que quand on fait abstraction des niveaux de politesse par exemple, ça devient tout de suite beaucoup plus simple.
Mon père s'y est mis pour pouvoir baragouiner un peu avec son petit fils. Réaction d'un quinquagénaire qui n'a pas été à la fac après 3 mois : "bon, faut retenir les mots, mais il y a presque pas de grammaire du tout alors ? Chouette !".

Quant à l'assertion selon laquelle les japonais préfèrent lire en caractères latins, j'ai de TRÈS gros doutes à ce sujet. Pour la simple raison que le japonais devient imbitable, du fait des très nombreux homophones. Je dirais même plus, ça leur prendrait considérablement plus de temps de lire en romaji qu'en kanji, pour ceux qui y arriveraient en tout cas.
Quant à lire en anglais, ahem, désolé, j'ai ri ^{^}

Personnellement, je comprends un peu… étant au Japon, sur un laptop japonais, si je veux vraiment écrire correctement, je dois passer par un layout US international.
Sauf que voilà, le qwerty japonais, c'est pas vraiment encore pareil, toute la ponctuation est chamboulée, et au bout d'un moment, soit tu retiens de tête le layout US, soit tu switches toutes les 2 secondes quand tu veux une ponctuation.
Si on ajoute à ça que je travaille 50/50 en anglais et japonais, effectivement, j'écris parfois sans accents. C'est pas une excuse…

PS: US international c'est quand même super pratique quand j'écris en español, je sais pas comment je faisais avant. Si quelqu'un sait comment avoir des touches mortes avec un layout japonais sous Win7 (boulot oblige) je suis preneur ! Parce que bon, taper à l'aveugle, c'est pas vraiment ça quand même.

Merci je ne savais pas !
J'étais resté sur mon expérience KDE on Windows qui n'avait pas été très concluante à l'époque, et je ne visite que très rarement les sites des applications que j'utilise (tout est dans les dépôts, donc pas besoin de regarder…)

Je parlais de KMyMoney au cas où il y aurait confusion… Grisbi tourne effectivement sur Windows.

Via Kde for Windows ? Sinon je vois pas…

Qu'est-ce que tu reproches à KMyMoney exactement ? Ça fait un peu gratuit comme affirmation je trouve ^{^}
J'utilisais Grisbi vers 2006/1007, donc ça commence à dater un peu, et j'ai migré sur KMyMoney peu après, parce que je trouvais l'interface plus dépouillée et intuitive (les gouts tout ça).
Effectivement, peut être qu'il manque certaines choses sans lesquelles un pro de la compta ne saura pas dormir, mais pour gérer mes comptes en euros, dollars et yens, ma foi ça me suffit amplement.
Après, c'est dommage que je doive utiliser une VM pour le faire tourner sur l'un de mes postes Windows, mais bon, on est sur Linuxfr après tout !

D'ailleurs, je peux vous dire que ce manque de flexibilité de Doors vis à vis des autres outils nous a permis de vendre du Reqtify assez facilement à des utilisateurs Doors, grâce au connecteur qui prend en compte l'exportation et la synchro.

Par exemple:
spec en PDF (ou autre) => lecture et analyse dans Reqtify => export dans DOORS

Si le doc de spec est mis à jour, pas de soucis, on le réanalyse, et au prochain export c'est synchronisé.

Ça permet aussi de faire des choses sympathique,
comme par exemple du mirroring entre 2 bases de données, comme Doors et Enovia pour une transition un peu plus douce :)

Presque !
PLM

Dans un monde parfait oui… en pratique, Toyota te dit "on file les specs en version papier démerdez-vous".
Mais effectivement on voit une certaine tendance à l'utilisation de bases de données pour le stockage d'exigences, avec tous les systèmes PLM de chez Siemens, PTC-Integrity, Dassault Systemes, etc…

Je n'ai jamais utilisé Doors donc effectivement mes connaissances sont lacunaires. J'ai cité Word et Excel comme exemples parmi les plus fréquemment utilisés, mais on peut aussi partir sur des fichiers PDF, des fichiers Rhapsody, des modèles Simulink, etc…

En gros ce que nous disent les commerciaux IBM, c'est "migrez toutes vos données sous Doors, et ensuite restez dessus". Alors oui mais non, quand tu reçois tes specs clients en PDF (oui, ça sux) ou en .doc ou je ne sais quoi (des fois en papier, c'est pour dire), tu n'as pas envie de tout reimporter dans Doors à chaque fois !

Pour ce qui est des styles, effectivement on peut s'en servir, mais ce n'est pas obligatoire. Disons que ça aide à discriminer plus facilement. Si ton exigence s'appelle REQ1 et que tu le trouves à la fois dans le corps de texte et ailleurs avec un style donné, ça t'évitera d'avoir des matchs incorrect avec un regexp du type ^REQ\d+ par exemple.