THE_ALF_ a écrit 531 commentaires

Mauvaise foi spotted.

"Au contraire" comme on dit en anglais. Si aucun des éléments mathématiques présentés ne te gène, pourquoi d'autres te gênerait? Sur quelle base sélectionnerait-on de "bon" ou de "mauvais" caractères?

Il n'y a pas une unique chose appelée "maths", mais plusieurs sous ensemble, chacun ayant leur set minimal, restreint de caractère parfaitement adapté à leur contexte, avec leur grammaire. Un peu d'algèbre de base, et 1234567890-=+*/ te suffit, très bien. Mais dans d'autres contextes tu aura besoin de signes d'intégration; de symboles logiques; etc. Oui, tu pourrait réduire tous ces caractères au seul subset ASCII. Mais 1) pourquoi celui-ci plus qu'un autre, et surtout 2) ceci ne va-t-il pas soit générer des confusions (mêmes caractères pour plusieurs concepts) soit des formulation verbeuses (good old time of mathematics)

D'où un choix dans l'esprit "unicode" (ouf, retombé sur le sujet de départ, sans pirouette): un ensemble complet possédant l'ensemble des symboles, pour l'ensemble des contextes possibles (ou du moins un sous ensemble… pas sur que l'on puisse écrire des partitions de musique ou des matrices en unicode…)

Je n’oppose pas les milliers de symboles mathématiques à la prose de monsieur Jourdain, mais bien à un langage avec une grammaire et un alphabet restreint. Comme on le fait si bien avec les langages de programmation.

APL

Le concept de chaîne de caractère et de parsage est très juste, le propre d’un alphabet, c’est de pouvoir lire une langue sous la forme d’une chaîne parsable : « B-A BA ».

Parser n'est pas comprendre. J'ai eu beaucoup moins de mal en Chine avec une très mauvaise connaissance du Japonais, qu'en Finlande avec une très bonne connaissance de l'alphabet romain ☺

Sérieusement débile comme raisonnement. Est tu sur qu'il est plus facile de comprendre "neuf mille deux cent vingt cinq virgule soixante douze divisés par quatre vingt douze font environ cent virgule vingt-huit" que "9225.72/92≈100.28"?

Le fait de passer à une écriture mathématiques a au contraire été nécessaire au développements des mathématiques. Essaie de lire les écrits mathématiques les plus anciens, tu vas comprendre ta peine.

Sans parler du fait que tu sous-entends du coup qu'une écriture alphabétique de type européenne serait "plus efficace" (ou plus simple?) qu'une écriture à base d'idéogramme/logogramme/etc comme le chinois, qui a pourtant de grands avantages (représentation écrite similaire de langues différentes, par exemple).

Et je ne parles mêmes pas des musiciens, honte à eux, qui ont osé inventer un système à eux pour retranscrire la musique qui nous force à apprendre le solfège, alors qu'il était si simple d'écrire la musique en bon français… "do long ré court fa très court" ça pète quand même mieux, non?

Sérieusement, trouver le langage adéquat pour décrire un système particulier, qu'il soit mathématique, musical ou quoi que ce soit, est crucial est nécessaire. Bien sur, ce n'est plus du "prêt à penser"…

J'ai plutôt utilisé Inkscape pour les posters, qui est très pratique aussi. Après, je n'ai jamais vraiment utilisé Scribus ET l'essentiel de mes graphiques ayant été de toute manière réalisé sous Inkscape, le choix ce fait naturellement…
Ceci-dit, je penses que cela va dépendre de ce que l'on met sur le poster. Inkscape va être parfait si il y a beaucoup de graphiques, Scribus sera peut-être plus adapté sur quelque chose de plus textuel.

J'ai pas dis que c'était mieux/moins pire/etc. Le troll en question était "goto c'est mal™". Ce problème est présenté comme apportant du moulin au troll "goto", ce qui semble inadéquat: la modification du goto n'a aucune incidence dans ce cadre (on ne patche pas le goto parce que c'est mal™, mais pour initialiser correctement une variable).
Ne mélangeons pas les trolls!

Mouais, enfin bon, a voir le patch ça n'a rien a voir avec un problème de goto, mais de variables non (mal?) initialisées…

Mon Robert&Collins est pas d'accord. Un installateur est une personne; un installeur est un terme informatique. Les deux étant "installer" en anglais.

Distinction franco-française à la "programmeur vs programmateur" pour "program(m)er" ? Genre on importe en français le terme anglais dans un contexte informaticien. Puis on le francise directement parce qu'utiliser du franglais, c'est-pas-bien™. On obtient un néologisme que l'on garde afin d'éviter (ou afin de créer, selon le point de vue) la confusion avec l'ancien terme. Et voilà! Deux termes pour le prix d'un, permettant un troll tout neuf.

On est de plus en plus persuadé que la vie est quasi automatiquement créée lorsque les conditions sont bonnes (définir « bonnes » sera possible une fois qu'on aura découvert plusieurs autres formes de vie, c'est ballot).

Bah il suffit de définir un ensemble de conditions comme "bon" par "menant automatiquement à la création de la vie".
Non?

> Et la désactivation des comptes n'a rien à voir avec une punition, mais permet d'éviter l'usurpation d'identité en se faisant chopper un compte/mdp sur un site obscure qui a été visité il y a des années.

Désactiver un compte ne permet-il pas, au contraire, de créer un nouveau compte au même nom que l'ancien, ce qui faciliterai l'usurpation d'identité?

Effectivement,il faut adapter le types de polices en fonction de leur usage.

Par exemple, j'aime bien les fontes "condensed" pour intégrer du texte dans les figures. En particulier, j'utilise en général Tex Gyre Heros Condensed (http://www.fontsquirrel.com/fonts/tex-gyre-heros). Je trouve que ça donne un rendu assez propre et pro, très lisible tout en prenant assez peu de place par rapport au fontes plus classiques.

Les "gestures" à plusieurs doigts pour aller en avant, arrière, changer de bureau, etc. fonctionnent

… emacs le fait depuis une éternité, en plus riche.

Pour éviter les césures de noms propre, il y a une option \uchyph=0

Ça évite simplement la césure des mots commençant par une majuscule.

Peut-être pourrais-tu essayer d'ajuster l'espace inter-paragraphe pour faire en sorte que chaque ligne sur une page soit alignée avec une ligne sur la page opposée. Je n'ai jamais essayé sur mes documents LaTeX.

Option \flushbottom

Ce sont justes les ligatures anciennes st/ct qui semblent bizarre. En générale, il faut les activer spécifiquement. Mais toutes les autres sont à garder! Il n'y a pas que le œ, mais toutes les ligatures en ff, fl, ffi, Qu, etc.
A noter que dans l'exemple donné, les ligatures ff et fl sont bien présentes (et bien venues). Par contre, la ligature oe est manquante dans chef-d'œuvre (la ligature oe n'est pas automatique, c'est — il me semble — une question d'orthographe plutôt que de typo)

Pour les lignes trop longues, ça n'a rien a voir avec le type de document. Dès qu'une ligne est trop longue, tu perds rapidement le fil d'une ligne à l'autre, la lecture est moins fluide. J'ai en tête un nombre de 60-90 caractères par lignes pour une lecture agréable.

Pour une doc, et si tu veux un document plus compact, passe en double colonne.

En ce qui concerne les marges, c'est vrai que certains doc LaTeX abusent parfois. Je penses que ça vient souvent des réglages par défaut adaptés pour le format US plutôt que pour du A4. Perso, je n'utilises jamais les réglages par défaut de LaTeX.

Je ne trouve pas que la non justification de texte ne soit qu'une histoire de goût. Encore une fois, ça brise la facilité de lecture. Avoir un texte bien formaté, avec texte justifié et césures (un texte justifié sans césure implique de grands espaces et est moche) permet d'avoir des paragraphes visuellement clairs. On passe naturellement d'un paragraphe à un autre. Cette organisation du texte en paragraphes devient beaucoup plus floue sans justification. Pourquoi désactiver justification/césure si c'est disponible?

Pour les titres en majuscules… génération web, peut-être, mais j'ai l'impression d'entendre quelqu'un crier.

Bref, pour le "rendu honorable dans un monde où les docs sont en word"… c'est bien la source du problème. C'est clairement l'impression qui ressort du rendu. On dirait du word. Peu d'efforts pour rendre le texte lisible, pour un rendu final très peu pro.

Pour le texte de Jules Verne:
* utilise microtype pour un meilleur rendu
* j'aurais tendance à diminuer l'espacement entre paragraphes
* passe en flushbottom
* je ne suis pas fan des ligatures anciennes (st/ct), je ne garderais que les ligatures usuelles.

Éventuellement, il y a 2-3 trucs pour améliorer:
* configure les headings/foots pour être plus informatif. Le heading de la page d'ouverture de chapitre est pas top (ça répète le nom du chapitrede manière peu élégante). Met éventuellement le même style pour toutes les pages
* C'est clairement un format pour livre imprimé. Si c'est prévu pour ebook plutôt que pour l'impression, je passerais en onepage, j'enlèverais carrément les marges qui sont du coup inutiles (en général, pour mes pdf pour ebooks, je ne met que quelques mm). Et j'enlèverais le foot pour mettre les numéros de pages en heading
* Les titres de chap. sont courts et nombreux, passe en 2 (voir 3) colonnes la table des matières.

Mais bon, le rendu global est pas mal.

Enfin quand même… Pour ce qui saute carrément aux yeux, il y a des lignes de 130 caractères (peu agréable a lire, et donnes des paragraphes de 1 à 2 lignes), un texte même pas justifié, des pages souvent au deux tiers vide (voir plus), des titres entièrement en majuscules…

Je veux bien accepter que travailler avec LaTeX tend à rendre intégriste quant à la typo, mais c'est quand même plus un rendu "impression de page web" qu'un rendu pour impression de livre.

Il n'y a que moi que ça choque?

Est-ce que la doc a été créée avec Booktype? Car si c'est le cas, le rendu est plutôt bon pour le html, mais franchement dégueulasse pour le pdf.
Pourtant, tu parles d'"impression professionnelle"… Peut on avoir un exemple de rendu correct?

Ce τ day est bien entendu ridicule, plus défendu par des geeks que des nerds

http://www.thepimanifesto.com/

Comme toujours, lorsque l'on prends à partir de repository non-officiels, il faut être cohérent et faire attention lorsque des packages peuvent être présent dans différentes version à différents endroits. Aucun problème si on a bien un ensemble de package multimedia de la même source (i.e. mplayer).

Le package ffmpeg 1.0 est dispo sur http://www.deb-multimedia.org/ , si je ne m'abuse.
Donc les 2 paquets sont accessibles facilement. Certes, debian multimedia ne fait pas partie de la branche debian officielle, mais y est très bien intégrée. Bref, on a le choix.

Certes, mais prends en compte que c'est juste un exemple écris en 30 seconde pour montrer le principe.

A mon avis, c'est une méthode intéressante à utiliser lorsque l'on veut être sur du type d'une variable, et être sur que celui-ci ne change pas en cours d'exécution (éviter par exemple qu'une variable contenant un float se voit au bout d'un moment transformée en int, et donner des résultats "bizarre" lorsqu'on l'utilise dans certaines divisons, en tout cas avec Python 2).

Pour une implémentation plus propre et avoir des messages d'erreurs plus cohérents, il faudrait aussi surcharger les opérateurs d'addition, etc., pour gérer correctement les "mixs" de type. Encore une fois, c'est just un proof of concept pour avoir des variables fortement typée d'une manière raisonnablement propre.

Pour ce qui est de l'intérêt pédagogique de l'exemple, et serait-ce bon à utiliser avec des étudiants, je demanderai un joker, par contre :p

Perso, j'ai un X201s depuis 2-3 ans, et je le trouve plutôt bien solide. Un des gros intérets, c'est qu'avec la plus grande batterie (9 cells, je crois), et un environnement bien optimisé (powertop pour identifier les process trop gourmands), il tient facilement 6-8h sur sa batterie.

Pour ce qui est de trop chauffer, ce n'est pas faux. Ceci dit (bon, pareil, j'ai optimisé les déclenchements du ventilo avec thinkfan), il tourne en gros à 40-45°C/ventilo à zero en utilisation mini, et atteint les 80-90°C/ ventilo à fond lorsque le CPU tourne à 100% trop longtemps (rare). En pratique, jamais eu de problèmes (et j'utilise cet ordi plusieurs heures par jour depuis que je l'ai).

A tiens, notes que si tu peux avoir une classe plus généraliste qui prends n'importe quel type de départ, mais interdit par la suite les changement:

class Typed(object):
    def __init__(self, val):
        self._data = val
    @property
    def data(self):
        return self._data
    @data.setter
    def data(self,val):
        if type(val) is type(self._data):
            self._data = val
        else:
            raise TypeError("Donne un "+str(type(self._data)))

Pour avoir un "vrai" typage, ça va être dur directement, car tu peut toujours faire du "a = quelquechose" qui va t'effacer l'ancien a, quoiqu'il arrive.

Le moyen le plus simple est d'utiliser les property des classes:

class Tint(object):
    def __init__(self, val):
        self.data = val
    @property
    def data(self):
        return self._data
    @data.setter
    def data(self,val):
        if type(val) is int:
            self._data = val
        else:
            raise TypeError("Donne un entier")

>>> a =Tint(3)
>>> print a.data
3
>>> a.data = 4
>>> print a.data
4
>>> a.data = 4.1
(...)
TypeError: Donne un entier
>>> a.data += 3
>>> print a.data
7
>>> a.data += 4.2
(...)
TypeError: Donne un entier
>>> a.data += "toto"
TypeError: unsupported operand type(s) for +=: 'int' and 'str'
>>> b = Tint(3.2)
TypeError: Donne un entier

Pas parfait, mais surement le plus simple.

N'est-il pas plus simple de faire un ionice sur les copies lourdes? J'ai de bêtes alias "mvn='ionice -c 3 mv'" et "cpn='ionice -c 3 cp -a'" pour les mouvements lourds de fichiers, et je n'ai jamais eu de ralentissement, même sur machine peu véloces.

Les ordonnanceurs, c'est bien, mais si on peut leur indique les priorités, c'est mieux…