reno a écrit 3886 commentaires

Effectivement je m'était trompé sur le cas avec plusieurs sorties, il faut utiliser un tuple de données donc tu as:
entree1 -> … -> entreeN -> (sortie1, sortie2, …, sortieM)
mais ce que j'aimerais avoir moi c'est:
(entree1, … , entreeN) -> (sortie1, sortie2, …, sortieM)
ça rend l'affichage du type des entrées et des sorties identiques.

C'est possible, mais il faudrait que tu m'explique en quoi je ne sais pas de quoi je parle!
Quand je définis une fonction f(x:int, y:int)->int et que l'interpréteur affiche
f: x:int -> y:int -> int (pas la vrai syntaxe d'OCaml) donc comme une fonction de fonction qui retourne un résultat alors qu'on lui a donné une fonction qui prend 2 valeurs et retourne un résultat.
Certes mathématiquement c'est la même chose, mais visuellement je trouve le choix d'OCaml (et d'Haskell) moins lisible..

Je me demande si le valideur averti du problème de version: il devrait commencer par ça..

J'ai toujours du mal avec les langages qui préfèrent les math aux utilisateurs, je m'explique: pour moi une fonction a des entrées et des sorties mais sous prétexte qu'il y a la curryfication, au lieu d'avoir des fonction avec plusieurs entrées et plusieurs sorties, on a: fonction: entree1 -> entree2 -> … sortie1 -> sortie2 (1)
Beurk, ce n'est pas parce que la curryfication existe qu'il faut la montrer systématiquement!

1: par exemple si on tape le programme du dessus dans l'interpréteur OCaml on a en sortie:
val process_file : (in_channel -> 'a) -> string -> 'a = < fun >
mais la fonction dans le code du programme avait des entrées et des sorties, pourquoi l'interpréteur n'affiche pas:
val process_file : ((in_channel -> 'a), string) -> ('a = < fun >)
ça serait beaucoup plus fidèle au code..

Quand tu es un abattoir, tu as 3 options:
1-ne pas faire de halal: tu perds environ 7.5% du marché.
2-faire du halal pour tous (sans le dire): 7.5% de marché potentiel en plus.
3-avoir 2 filières séparée, même marché que (2) mais à priori plus cher.

Je ne suis pas expert mais ça me parait logique que les abattoirs choisissent (1) ou (2).
(1) dans les régions où il y a peu de musulmans mais personne n'en parle, (2) dans les autres et là ça fait débat..

1) Les être humains sont lents par rapport à des processus.
2) Chrome me parait bien plus réactif que Firefox donc le multi-processus n’empêche donc pas de faire un browser réactif..

tu t'échines à voir la séparation en processus distincts comme la recette ultime de la performance.

Tu te trompes, pour moi les 2 intérêts principaux sont: 1) la sécurité ET 2) la réactivité.

(1) est aussi important que (2).

La séparation en processus n'est pas la recette ultime de la performance mais au moins ça nettoie simplement les ressources quand on ferme un onglet: ça n'est plus un problème avec FF mais ça l'a été pendant très longtemps.

Alors les multiple sens de The Hurd, je te les laissent.

Oui, c'est vrai, quand tu as une action sur l'interface, en général, tu ne veux pas que le navigateur réponde instantanément.

N'importe quoi, je faisais remarque que dans un OS, les processus communiquent souvent entre eux par contre dans un navigateur web, les sites web ne communiquent pas entre eux (enfin rarement), ça n'est pas très compliqué de voire la différence non?

Une autre remarque: Hurd est un noyau, pour les noyau la vitesses des IPCs est extrêmement importante, les noyaux monolithiques ont donc un avantage important.
Dans un navigateur web, la situation est totalement différente..

T'es tu demandé si séparer en processus n'avait pas des inconvénients ?

J'y ai réfléchi effectivement.

Comme une consommation mémoire plus élevée,

C'est a peu près le seul réel inconvénient, mais note que Chrome te permet aussi de tout mettre dans le même processus, donc quand tu as une mémoire très restreinte, tu peux le configurer de la sorte: pouvoir avoir un processus par site web, n'implique pas forcément d'utiliser un processus par site web..
Et il y a beaucoup de machines avec beaucoup de RAM ou utiliser un peu plus de mémoire n'est pas un gros problème.

une moins grande souplesse dans l'écriture des addons

De toute manière, il faudrait 2 niveaux d'addons: une API interne qui peut tout faire mais avec lesquels tu n'as pas la sécurité et une API externe qui est dans un processus séparé: moins de souplesse mais tu as la sécurité.
Chrome ET Firefox sucks tout les deux car ils n'ont pas ces 2 niveaux.

plus d'optimisations/codes en fonction de l'OS, etc.

Oui euh Chrome est plus performant que Firefox donc visiblement ils ont réussi a surmonter l'obstacle.

Tout dépend des cas et surtout de l'architecture.

Ce qui est rigolo c'est que le sujet initial de l'article Firefox a toujours une architecture pourrie rapport à Chrome car ils n'ont pas le support d'un processus par site web et qu'ils ont renoncé à travailler sur le sujet car ça ferait trop de changements..

Il y a un communiqué de presse de Digia qui semble indiquer que oui.
En théorie, c'est comme si on renommait TrollTech en Digia, en pratique ce ne sont plus les mêmes chefs, plus la même époque (y a t'il toujours un marché pour du support Qt maintenant qu'il est LGPL?)..

Il peut se tromper mais est rarement un menteur.

Hum, il y a les deux: regarde la religion Mormone, la religion Scientologue, Machiavel (et d'autres) qui poussait pour une religion d'état pour mieux controler le peuple, les papes qui avaient un conportement tout sauf Chretien mais qui en retirait tout les bénéfices, etc la liste est longue..

Le père Noel me dérange beaucoup moins que les contes pour enfants qui glorifient les castes (noblesses, princes, etc).

Haskell avec sa lazyness par défaut pose des problèmes coté performance: j'ai lu ça dans un papier qui donnait un retour d'expérience sur haskell dans la "vrai vie"

Pourquoi pas C#? Son principale problème est que c'est un langage qui vient de Microsoft, qui, étant donné ses actions dans le passé n'est pas digne de confiance, autrement c'est un bon langage je trouve, tu lui reproche quoi?

Note que des langages à typage statique bien conçu j'en connais assez peu finalement : Ada, Ocaml/F#, C#.

Je ne compte pas Scala et D car ils ne détectent pas par défaut les débordements entier.

Ce que je trouve très intéressant dans le dev de LibreOffice c'est que les gars sont parti d'une base de départ énorme, bien "bordélique" (commentaires en Allemand, code mort, etc) mais plutôt que de se dire on va tout réécrire(1), ou bien on va faire des plugins pour tous les nouveaux développements(1), ils attaquent le problème de front (cf le blog de Meeks) et là je suis super impressionné!
Ce que je ne comprends pas trop, c'est pourquoi ce style de développement "progressif" ça marche pour LO, mais pas pour les environnements de bureau..

1:comme c'est trop souvent le réflexe dans le monde du logiciel libre (bon pas uniquement)

C'est quoi "default(none)"?

Bah, justement l’intérêt principal de la "langue Unix" est sa productivité (son inconvénient principal est sa difficulté d'apprentissage).

Moui, pas convaincu, les GUI ont vraiment tout balayé sur leur passage (pour les utilisateurs pas pour les admins) et le mode texte d'Unix s'est retrouvé bien isolé, pas convaincu qu'on retrouve jamais la "langue" Unix.

Quelqu'un a parlé d'Etoilé (sur osnews) comme les GUI 'à la Unix' mais je ne suis pas vraiment convaincu.

Et je vois 2 gros problèmes pour le mode texte sous Unix:
1) les GUI comme dit ci dessus qui le concurrence

2) le manque d'évolution: VMS avait une syntaxe plus logique que celle du shell Unix, pourquoi un équivalent n'a t'il pas été adopté? PowerShell est pour moi une évolution logique du shell, mais il n'a pas été crée sous Unix..

Les artworks ont ceci de particulier qu'il sont difficilement réutilisables (telles des briques) comme du code source.

Faux:
1) tu peux réutiliser les artworks en changeant l'histoire, le style du jeux: cf les mods.
2) tu peux changer les paysages/décor et garder les personnages ou vice versa.
3) tu peux "mangaifier", cartoniser des personnages (même de façon partiellement automatique)

Bref tu as parlé beaucoup trop vite.

On interdit pas le fork sur le code source, qui est le coeur du jeu.

Le code source est le coeur du jeu?
Euh ça dépend beaucoup du jeux! Dans beaucoup de jeux la réalisation des graphismes prend plus de temps que pour réaliser le moteur du jeu!

Donc non, un jeux dont les graphismes ne sont pas libre n'est un pas un jeu qui respecte l'esprit du libre: Doom3, Quake sont d'autre jeux qui ont des graphismes propriétaire et un moteur avec des sources libres, ça n'en fait pas des jeux "libre", des moteurs de jeux libre OK.

Pas moi, sur Solaris il y avait une application sur le bureau CDE qui ne fonctionnait pas en déport d'affichage(!), beurk!

Hum, le sandboxing dans les navigateurs n'est pas spécifique à Flash, c'est juste un design de bon sens pour la majorité des plugins d'un navigateur: Firefox n'est pas un exemple à suivre au niveau design.

J'ai la même analyse mais ça n'en fait pas une remarque honnête pour autant: everybody != Valve.

À quoi ça sert d'afficher les applications qui ne font pas de son dans le mixeur de son ?

Pourquoi c'est modéré positivement ça??
Firefox peut beeper, jouer de la musique et même un beep c'est un son!