foobarbazz a écrit 464 commentaires

Oui, possible que genre le réseau de SFR soit entièrement en IPv4 sauf une route chelou qui est empruntée par toutes les connexions IPv6.

Je connaissais la seconde, et je m'en servais régulièrement.

Mais en apprenant l’existence de la première, le comprend pourquoi une construction du type command | emacs - n'a pas de sens pour un emacsien. Puis que pour eux, il n'y a rien en dehors d'emacs. Pour un emacsien, emacs c'est le processus 0.

Je dois être un utilisateur de vi au fond, c'est juste que je suis tombé dans emacs quand j'étais petit.

(Sérieusement, il est arrivé une période dans ma vie où j'ai dû apprendre à me servir sérieusement d'un vrai éditeur de texte, il s'est posé la question emacs vs vi. Et étant utilisateur bépo, j'ai naturellement choisi emacs. En effet, pas besoin de foutre en l'air la config par défaut pour que ce soit utilisable.

Ils ont pas osé l'ambassadeur pour le digital, en ces temps où les mains aux fesses sont tant stigmatisés, ça aurait été politiquement très maladroit. Mais je suis sûr qu'ils en mourraient d'envie !

Au malandrin qui m'a moinsé, dis moi comment tu fais !

Même ça ça marche pas ! emacs <(echo foobarbazz)

Emacs sucks…

J'aimerais pouvoir faire echo foobarbazz | emacs -.

Les poissons respirent bien sous l'eau, hein ? :)

Breaking news ! Marie-Antoinette se porte très bien et elle moule sur LinuxFR :-)

C'est vrai… Ça serait pas un problème de pas avoir de quoi se payer le chauffage l'hiver si on voyait pas des mauvais œil les enfants morts de froid et si on y avait jamais eu accès de toute façon.

L'objectif politique, ça serait d'augmenter ou de maintenir la croissance.

Oui… Enfin, c'est triste comme objectif politique. Comme tu le dis, c'est juste un indicateur. Typiquement, il est calculé à partir du PIB, et un PIB, ça ce traficote. Genre les espagnols qui se disent "aller, c't'année, on ajoute les putes et les dealers de crack dedans", ça leur fait une belle jambe, et à ma connaissance, le calcul des année précédentes n'est pas impacté par la modification, et ça fait de la croissance qui ne signifie rien, sinon qu'on est en train d'ajouter des pommes et des pommes au crack.

C'est comme pour le chômage. Faire baisser le chômage est un objectif politique absurde. Vous voulez faire baisser les chiffres du chômage ? Exterminez les chômeurs. L'objectif sera atteint, mais je suis pas sûr que les gens seront plus heureux pour autant. Parce que le problème, c'est pas le chômage, c'est la pauvreté. Et radier les chômeurs ou les faire bosser 20h par semaine ne les sort pas de la pauvreté.

On dirait qu'ils ne réalisent pas que le temps que les salariés passent à des conneries sont des heures payées, et que demander à quelqu'un qui coûte 20€ de l'heure à la boite (soyons optimiste) de consacrer 1h à une activité non productive, ça revient à balancer par la fenêtre 20€.

Les coûts d’opportunité…

Le petit truc qui m'a soufflé dans Faust, c'est le module de documentation automatique.

En matière d'installation artistique, la pérennité est une vraie problématique. Une installation faite à un moment donné sera très très compliquée à remettre en place 100 ans plus tard. Pour ça, Faust propose un module qui va générer un pdf qui va décrire la sémantique du programme. Et il sera ainsi possible de le réimplémenter dans le langage qui sera standard dans 100 ans.

Hypermétropie décelée dans l'enfance (autour de 6 ou 7 ans si mes souvenirs sont bons). J'ai porté des lunettes jusqu'à 12/13 ans sans que ma vue s'améliore (avec toujours un écran en face de moi).

Depuis que je ne les porte plus, par négligence, je suis encore plus souvent devant un écran et ma vue s'est améliorée…

Moi aussi, ça m'a fait exactement pareil. Et maintenant, je suis myope ^{^}

T'es sérieux ? Si tu troll tu es excellent.

Sinon… Je sais pas trop quoi dire… C'est autant insensé physiquement qu'économiquement.

Dans un monde parallèle les vases brisés ont plus de valeur que les vases entiers. Du coup, certains se sont fait une spécialité de briser des vases, et des gens achètent des vases brisés à prix d'or. Avec cet argent, les briseurs de vases peuvent racheter des vases neuf.

Il y a une règle d'or en économie, qui semble tomber sous le sens, mais par les temps qui courent elle mérite d'être redite : La destruction ne créé JAMAIS de richesse. Devoir produire deux vases pour en avoir un est absurde. Produire deux fois de l'énergie pour en avoir besoin une fois l'est tout autant.

il est evident que c'est uniquement un ponzi scheme

La spéculation et la pyramide de ponzi sont deux choses très similaires, mais pas exactement identique. J'ai envie de dire qu'à l'échelle macroscopique, une bulle spéculative est une pyramide de ponzi, mais c'est tout. Les transferts d'argents sont similaires, mais la mécanique est radicalement différente.

Dans le cas de la pyramide de ponzi, l'investissement des premiers est amorti directement par les suivants. Dans une bulle spéculative, l'investissement des premiers est amortie par le fait qu'il existe d'autres personnes qui pensent qu'il est toujours intéressant d'investir.
Une autre grosse différence, c'est que les mécanisme des pyramide de ponzi sont secrets (ou au moins dur à voir), là, c'est clair comme de l'eau de roche, le mécanisme c'est l'offre et la demande. Celui qui entre dans une pyramide de ponzi l'ignore. Là, personne n’investit dans du bitcoin sans comprendre par quels mécanismes leur investissement est susceptible de leur rapporter de l'argent.

Et c'est faire un mauvais procès d'intention aux concepteurs du bitcoins… Alors, certes, ils se sont enrichis, mais ça leur a coûté leur projet, monnaie et spéculation ça va pas bien ensemble.

Ils ne mettent pas de limite dans l'appareil, la physique et la loi s'en chargent.

Je vous dis merde :-) Cet acharnement et cette mauvaise foi n'honore personne.

Et là, je ne parle que de la mémoire; discutons un peu du temps d'exécution. En Python (comme dans beaucoup de langages dynamiques), les ensembles pairs/valeurs du JSON sont représentés par des dictionnaires, qui ont un accès O(1) (amorti). Cependant, c'est un accès O(1) à un pointeur sur l'élément voulu. En temps normal, en s'en fiche complètement, une indirection de plus ou de moins, ça ne changera pas grand chose.
Et si c'était maintenant 15 000 indirections? Soudainement le temps d'accès explose…

Je ne comprend pas bien de quoi tu parle… Le boulot d'un parseur json c'est de prendre une chaîne au format json et d'en faire une structure qui permet de se balader dans l'arbre que cette chaîne représentait. Et c'est tout. Et oui, cet arbre devra probablement être entre encodé autrement pour des temps d'accès efficace. Mais c'est pas le problème du parseur.

Ceci étant, la question n'est pas tant de comparer les tailles respectives de la RAM et du fichier incriminé. On peut exploser la RAM tout en étant apparament bien des ordres de grandeur en dessous de sa taille, les zip bombs (ou bombes de décompression ) en étant un bon exemple. Après tout, le fichier original est un ZIP valide, et ne fait que 42 Ko. Quel insensé pourrait oser venir parler de limites physiques? Eh bien celui qui sait que ce fichier, une fois décompressé, fait 4.5 Po (pétaoctets)…

Oui, un autre très bon exemple, c'est pas le problème de la lib qui dézippe, c'est celui de celui qui l'utilise !

c'est vrai que ce genre de concept n'est pas forcément facile à appréhender

Ça ça ressemble beaucoup à de la condescendance que je trouve un chouia déplacée. Mais peut être que je me trompe.

Très prosaïquement, je vois des vois des gens qui sont à la limite de me sortir des arguments de la théorie de l'information pour justifier qu'un parser json ne soit pas capable de parser un fichier json valide qu'un humain pourrait écrire à la main en 15 minutes… C'est techniquement possible facilement, et sans coût, de parser TOUS les fichiers json, avec pour seule limite la mémoire de la machine. Le faire, ne coûte strictement rien (sinon un code un chouia plus compliqué, avec un "push foo" à la place d'un "call bar").

Et qu'est-ce qui ce passe quand le parser json est utilisé dans un contexte un peu compliqué ? Avoir une centaine d'appel de fonction sur la pile c'est pas extra-ordinaire, dans ce cas le parseur va foirer à une profondeur de 30 ? C'est toujours ok, parce qu'il y a forcement une limite ?

En temps normal, en s'en fiche complètement, une indirection de plus ou de moins, ça ne changera pas grand chose.
Et si c'était maintenant 15 000 indirections? Soudainement le temps d'accès explose…

Pourquoi est-ce que l'argument que tu dis à propos des temps d'accès ne vaut pas pour l'utilisation de la pile ?
« En temps normal, un appel de plus ou de moins sur la pile, on s'en fou, imagine maintenant que c'est 1000 ? Soudainement on a un stack overflow. »

Pitié… Non, sérieux, c'est ridicule :-)

En attendant, est-ce que le vendeur de ta voiture t’a prévenu que son moteur ne peut pas fonctionner sans oxygène ? C’est quand même une limite très importante !

Analogie foireuse. Là on ne parle pas de la voiture qui cesse de fonctionner sans oxygène, mais de la voiture qui cesse de fonctionner arbitrairement au delà de 1500m d'altitude, parce que le constructeur s'est dit "1500m c'est bien, il faut bien mettre une limite". Non, il faut pas. Et guess what ? les constructeurs ne le font pas. Mieux, les injections s'adaptent au manque d'oxygène, la puissance baisse, mais le moteur continue de marcher tant que c'est possible.

Sauf que là, la limite est plusieurs ordres de grandeurs en dessous de la limite physique (la taille d'une pile contre la taille de la mémoire vive).

Non. Correction : tu étais bien content d'avoir suffisamment de mémoire (et de swap) pour pas que ça plante.
Que ce soit Chrome ou Firefox, quand y a plus de mémoire pour créer des noeuds DOM afin de représenter ton HTML à l'écran, et bien… il n'y a plus de mémoire. Et ça te pète à la figure ou ça t'affiche rien. point barre.

Évidement, on ne peut pas attendre qu'un programme fasse quelque chose d'impossible. Mais ce n'est pas de ça dont je parle…
Je parle d'un cas où il y a largement assez de mémoire pour encoder l'arbre… Où même, on ne se pose même pas la question tant les données sont petites. On parle d'un fichier de 27ko dans ce thread !

Un programme foire sur un fichier de 27ko alors qu'il y a potentiellement 16Go de mémoire sur la machine, et vous me parlez de limite physique et tout ?

J'arrête là, c'est un échange parfaitement insensé.

Je vais donner un cas très typique d'utilisation d'un fichier JSON avec un arbre très profond : Utiliser un fichier json pour encoder un arbre très profond, tout simplement.

Donc tu as un cas d’utilisation avec des arbres profonds pas profonds ? cqfd.

Wat?

Moi ça me choque pas qu’un programme te dise honnêtement « je suis pas conçu pour ce genre de cas » et s’arrête.

Non, c'est pas du tout ok de s'arrêter pour quelque raison que ce soit. Si il y a ce genre de limite, a minima elle doivent être clairement écrite dans la doc.

Ce qui me choquerait c’est que ça segfaulte salement.

Là dessus on est d'accord, c'est encore pire.

D’une manière générale, c’est pas une mauvaise pratique de fixer des limites.

Si… Et c'est particulièrement vrai dans le cas d'une bibliothèque où celui qui l'écrit n'a absolument aucune idée de la manière dont elle va être utilisée. Et c'est encore pire si celui qui l'utilise n'a absolument aucune idée du genre de limite qui peut s'y trouver.

Je suis un peu sur le cul en lisant les commentaires ici…

Une fonction prétend parser le json, on est en droit d'attendre qu'elle sache parser le json. Il n'y a pas à ergoter sur la légitimité de l'usage de certains fichiers json…

Vous vous êtes déjà retrouvé dans un cas particulier, à avoir un usage atypique d'un outil, et faire un rapport de bug parce que celui ci ne se comportait pas comme il était supposé le faire ?

Je vais donner un cas très typique d'utilisation d'un fichier JSON avec un arbre très profond : Utiliser un fichier json pour encoder un arbre très profond, tout simplement.

Moi par exemple, ya pas très longtemps j'ai fais un truc vite fait mal fait pour qui générait des fichiers HTML à partir d'objets fractales. Ils n'étaient pas très profond à cause de l’explosion combinatoire, mais ils étaient ridiculement gros (plusieurs dizaines de méga de code HTML par fichier). J'étais bien content que chromium et firefox étaient suffisamment bien fait pour s'en accommoder, et ça m'aurait prodigieusement gonflé que l'un d'eux plante parce qu'un dev se serait dit un jour "C'est bon, un fichier html de plus de 10Mo n'a d'usage légitime dans une application réelle, c'est ok si ça crash dans ce cas là".

La remarque de Thomas ramène à la réflexion : est-ce qu’un arbre très profond a un sens dans une application réelle ?

Oui… La faire planter en exploitant le fait qu'elle utilise un parseur json foireux :-)

Pour rendre mes fonctions tail-rec, j'ajoutais juste un accumulateur dans mes arguments. Mais ca n'est pas toujours possible. CPS permet de repousser un peu les limites, c'est ca?

Oui, c'est ça. C'est un peu ce que fait Haskell spontanément. L'idée, c'est qu'au lieux de faire grossir ton calcul sur la pile, avant de l'évaluer, tu le fais grossir sur le tas.

En haskell parce que c'est plus lisible (pour moi) :

data A = N A A | F -- un arbre avec des Noeuds et des Feuilles

size a = let size' (N a b) k = size' a (\ra -> ra + 1 + size' b k)
             -- c'est là qu'est la magie, au lieu d'empiler le second appel pour l'arbre droit, on va le rajouter dans la pile
             -- dans une continuation, ça veut dire : ok, d'abord je fais l'appel sur sous arbre gauche, et quand j'aurais le resultat ra, je pourrais m'occuper du b
             size' F k = k 0 -- le cas de base, on a une continuation qui attend la taille du sous arbre qu'on traite, ici 0
         in size' a id -- initialisation, on veut la taille de l'arbre a, qu'on va renvoyer tel quel

Mais quand je vois les exemples wikipedia, j'ai l'impression que ca rend la lecture quand mem plus compliquee. Ca ne vaut pas le coup de repasser au style imperatif dans ces cas la?

Et oui, le style CPS est imbitable :-). C'est pour ça qu'Haskell est fantastique.

Qu'est-ce que tu veux faire exactement ?

Il y a plein de manière de faire ça…

Ça me fait penser à une phrase de Woody Allen :

J'ai lu « Guerre et Paix » en 20 minutes. Ça parle de la Russie.

Non, c'est sur que de reporter le problème de stationnement sur les autres usagers de la voie publique n'est pas un souci.

Il y a toujours moyen de se garer là où ça ne gène personne. Même si parfois il faut faire 100 ou 200m de plus.

J'aime bien les ronds points moi. Je suis motard, les lignes droite c'est chiant, les courbes induites par les rond point sont très agréables à prendre. Droite… changement d'angle rapide pour suivre le rond point, et re changement d'angle rapide pour sortir, tout en ouvrant en grand pour sentir l'arrière légèrement partir… Miam !

Un jour je vais me vautrer à force de faire ça, mais c'est tellement agréable…