🚲 Tanguy Ortolo a écrit 12091 commentaires

Tu préfères bzip2?

Soyons modernes : XZ. Plus rapide à décompresser que bzip2, presque aussi rapide que gzip en fait.

Pour ftp, je dirais la vitesse (sur les gros fichiers) car le transfert peut être fait directement en binaire.

En HTTP aussi il me semble.

Au fait, tu numérotes vraiment tous tes titres à la main ? Tu construis vraiment tous tes sommaires à la main ?

Je viens de te montrer qu'il n'y avait aucune logique entre les noms.

C'est toi qui choisis de nommer tes macros de façon logique ou non.

Ce que "signifie" ta macro, c'est son rendu, point barre.

Exact, mais ta macro existe et a un nom. Rien que cela, c'est utile, ça ajoute une indirection logique qui apporte de la souplesse.

Tu détournes l'exemple (en babel french, les listes sont à tirets par défaut), c'est l'inverse que je veux : je peux vouloir mettre certaines listes en valeur avec des bulles, et donc me créer un environnement à cet effet.

Effectivement, ça c'est de la mise en forme physique, et ça vaudrait le coup de t'interroger sur la raison pour laquelle tu veux faire cela.

Pour « souligné dans le manuscrit », c'est tout simplement « souligné dans le manuscrit », tu rends comme l'auteur l'a donné, même si tu ne comprends pas pourquoi.

Très bien, dans ce cas, il est pertinent de nommer cette macro \soulignemanuscrit ou un truc du genre. Des fois que l'éditeur décide que finalement, ce que l'auteur a souligné, il faudrait vraiment le souligner pour respecter le choix de l'auteur, plutôt que de le mettre en italique.

Pour \etranger, super, une macro inutile (quand je parlais de piston à coulisse… ) qui voudra juste dire \textit…

Que non ! Le jour où ton éditeur décidera que les mots étrangers devraient être en oblique plutôt qu'en italique, tu seras content d'avoir défini une macro dédiée !

De plus, il y a emphase tonique (ex. "tu m'as demandé de le faire") et emphase sémantique (ex. les termes communs employés en tant que concepts philosophiques), il faudrait donc de toute urgence créer un \emphconcept et un \emphtonique pour utiliser la commande de base \emph…

Si tu fais la différence et qu'elle a vraiment une importance dans ton contexte, il pourrait être pertinent de le faire en effet, mais je doute que ce soit vraiment utile.

il faut regarder du côté de l'évolution des valeurs des marchandises au cours du temps

Ça c'est de la stratégie plus que de la gestion je dirais. Et de toute façon, à un moment tout ce qui rapporte de l'argent est bon à prendre, même si ça en rapporte peu…

Par gestion, j'entends comment démêler le sac de nouilles d'un réseau de transport pour choisir quoi envoyer où sans se prendre la tête.

Tes commandes de base ne sont ni plus ni moins "physiques" que les macros.

Si, parce que les macros, elles sont nommées et définies une fois, et utilisées plusieurs fois sans recopie de code. À toi de leur donner un nom logique, évidemment.

Si dans un environnement français, je veux avoir une liste à l'anglo-saxonne avec des items à bulles au lieu de tirets, je vais me créer la macro "listbullet", dis-moi un peu en quoi ce sera moins "physique" que "itemize" ?

Dans un environnement français, tu utilises l'environnement logique itemize, et tu le redéfinis pour qu'il utilise des tirets semi-cadratins comme puce. Excellent exemple d'ailleurs.

À l'inverse, l'italique en français ("\textit" "physique" de base) c'est déjà au moins trois sens différents : souligné dans le manuscrit, mot étranger, insistance tonique.

« Souligné dans le manuscrit », ce n'est pas une utilisation logique, donc je passe sur cet usage, libre à toi d'analyser cet exemple pour déterminer à quels usages logiques cela correspond. Mot étranger : c'est l'occasion de définir une macro \etranger. Insistance : il y a \emph pour ça.

C'est le seul critère unique, il n'y a pas d'autre "logique" et donc pas de distinction physique/logique qui tienne.

Nawak. S'il n'y avait pas de distinction qui tienne, tu n'utiliserais pas de fonctions que tu définis, mais tu utiliserais les commandes de base à chaque fois, en les recopiant à chaque endroit où tu en as besoin. Et en les modifiant à chaque endroit où tu les as utilisées si tu décides qu'en bleu c'est mieux qu'en vert, tout compte fait.

Ah, mais justement, je cherche des conseils pour la planification de lignes de transports, je ne peux pas en donner !

C'est un dans un style un peu à l'ancienne, pas évident à prendre en main mais tout à fait passionnant. En revanche, s'il y a de nombreux conseils et exemples pour la construction de croisements par exemple, je n'ai pas trouvé dans le wiki de conseils sur la gestion pratique des lignes de transport de marchandise.

Je m'explique : lorsqu'on développe son réseau, on repère par exemple une forêt, une papeterie, et construit et on achète ce qu'il faut pour transporter le bois de l'une à l'autre, puis pour transporter les biens ainsi fabriqués vers une ville, et ainsi de suite au fur et à mesure des opportunités. Vient un moment où on dispose d'un réseau étendu, avec des dizaines de véhicules différents, transportant des chargements divers dans des endroits divers, sans ordre particulier. Les production évoluent, certains lieux de production ferment ou ouvrent, et on est alors confronté à des besoins de réorganisation de ses lignes de transport. Existe-t-il des techniques pour faciliter ce travail planification des lignes de transport, en le rationalisant peut-être ?

Ces sprites 32 bits n'étaient-ils pas déjà disponibles pour les versions précédentes ?

(Au passage, par 32 bits, j'imagine qu'on entend un octet par couleur plus un canal alpha ?)

Tu réponds à côté : le fait de disposer d'un rendu visuel ou non, et de disposer de styles logiques plutôt que physiques, sont deux choses indépendantes. Il pourrait y avoir un bouton « mettre en emphase » et un autre « titre 1 », que ce serait tout à fait acceptable.

LaTeX utilise des fonctions, ou macros nommées. Tout l'intérêt est dans le nommage : on n'applique pas des instructions de mise en forme physique mais on appelle des fonctions logiques dont l'implémentation peut être redéfinie au besoin.

Dans le cadre du développement de Newton Adventure, j'utilisais jusqu'ici le format gif pour les sprites animés. Malheureusement ce format est limité à 256 couleurs par image. J'ai cherché une alternative:

Une alternative à un format d'animation compressé donc.

• mng: ce format, qui aurait du être le successeur du gif est assez compliqué et peu utilisé.

Compliqué : en quoi le format lui-même te concernerait-il ? Ce que tu utiliserais, c'est libmng, pas MNG lui-même : c'est la libmng qui a une API trop compliqué ?

Peu utilisé : très mauvais argument, en créant un nouveau format tu peux être sûr d'une chose, c'est qu'il sera encore moins utilisé, à savoir, seulement par toi.

J'ai donc créé nanim, un format:

• simple: non compressé, il stocke juste une liste d'animations, de frames et de nimages RGBA ou RGB.

Non compressé, d'accord d'accord… Mon pronostic à deux centimes : aucune chance de réussir à percer. Même GIF était compressé, et curieusement, les formats actuellement utilisés, même dans les jeux vidéos (son, images…), sont compressés.

Pour finir une nanimation (en gif malheureusement, en attendant de soumettre nanim au W3C): nanimation

Alors là, la probabilité que le W3C recommande pour le Web un format d'animation non compressé et optimisé pour le jeu vidéo est vraiment nulle, pour le coup.

Ah, et aussi, quand tu as les titres suivants : 1, 1.1, 1.2, 1.2.1, 1.2.2, 1.3, 2, 2.1, 2.2, 2.2.1, 2.2.2, 2.2.3, 3, 3.1, 3.2, 3.3 et que tu décides d'ajouter une nouvelle section entre la 1 et la 2 ? Tu renumérotes à la main ?

Et quand tu as plusieurs titres de niveau 3 ? Quand tu veux, a posteriori, changer l'aspect de tous tes titres de niveau 3 ? Quand tu veux générer un sommaire ?

Ce Use Case serait mieux rempli avec quelque chose comme Google Docs a mon avis.

Qui, jusqu'il y a peu de temps, ne disposait pas non plus de styles logiques, que de styles physiques. À l'époque, Google Docs était à peu près au niveau d'Etherpad actuellement, je dirais.

C'est sans rapport. Le fait d'éditer le balisage à la main ou de disposer d'une présentation graphique est indépendant de l'utilisation de styles physiques ou logiques.

Non, visiblement ces outils ne permettent que de faire de l'édition de texte vite fait mal fait.

Et c'est toujours fait par des gens qui n'ont jamais fait de bureautique propre on dirait. Les styles logiques, ça doit être ringard, la mode est à l'édition manuelle fastidieuse j'imagine.

Ah pardon mais l'intérêt principal de mosh est de faciliter les terminaux distant depuis un téléphone mobile, d'où l’étymologie du nom précisé dans l'article d'ailleurs!

Pas d'après la page d'accueil du projet, qui parle de mobilité, pas de téléphone.

-p 433, sauf qu'en fait non : mosh est lancé en tant qu'utilisateur et n'a donc pas le droit d'utiliser de port

Quel rapport avec un smartphone ? Une connexion micro-ondes longue portée, ce n'est pas seulement utilisé sur téléphone…

Heureusement mes enfants sont plus geek que moi et téléchargent des jeux gratuits sur Androïde Marquette.

Ce n'est pas geek, ça, ce qui le serait ce seraient qu'ils les codent, leurs jeux…

Moi j'ai plutôt une liseuse numérique et des livres numériques dessus, et c'est super pratique aussi.

Oui, mais peu importe, tu peux très facilement créer ta propre Debian Live personnalisée.