je me greffe dans la conversion pour suggérer slitaz sur l'aspire one. Très bon support matériel. Définitivement plus rapide qu'une Lubuntu. Beaucoup plus cohérent qu'une Puppy Linux. La derniere release candidate est sorti en mai. Il n'y a pas beaucoup de jeux la dessus par contre.
Félicitations! te voilà immédiatement promu "project owner" de HandBaller. C'étais pas dur de trouver ton profil.
"msgbus" a été ma première source d'inspiration (cf. credits sur la page projet). Mais j'avais alors besoin d'une solution fiable qui marche tout de suite pour ce sur quoi je travaillais. C'était il y a 3 ans et msgbus était encore en développement.
C'est alors que thttpd s'est rappelé à mes bons souvenirs. On le trouvait dans plein de distrib Linux embarqué et c'est lui qui faisait tourner le site des pages perso de mon FAI de l'époque.
J'avais déja jeté un coup d'oeil au code avant. Alors voila, ca m'a pris quoi... 1 jour, pour trouver où et quoi patcher pour transformer thttpd en un bus à messages.
Ca m'a pris un peu plus longtemps à mettre au point le flux de push. Mais finalement j'ai pu utiliser ce travail dans une maquette pour avoir un feedback temps-réel de tout ce qui se passait à l'extérieur d'un moteur de Firefox 3 en kiosque (via un XmlHttpRequest avec multipart=true). Succès total.
thttpd n'a pas libevent. Mais il dispose de sa propre logique de scruptation d'I/O qui semble tout à fait au fait de la technologie.
Au départ HandBaller ne fonctionnait qu'en multipart. Mais WebKit est monté en puissance, et j'ai bien vu qu'il fallait que je me mette au long polling. Ca tombait bien, thttpd embarque aussi une solution de timers et de pattern matching légère... alors j'ai décidé de tout refaire. L'architecture actuelle repose sur des micro boîtes à messages (une pour chaque agent) qui persistent quelques secondes entre 2 requêtes de long pooling ou lors d'une coupure d'une connection de push.
J'ai essayé de joindre les développeurs de msgbus en septembre sans succès. Je leur avais proposé de partager nos expériences. Et surtout je leur ai demandé de l'aide. J'arrive pas à faire marcher le multipart/x-mixed-replace comme il faut en HTTP/1.1 et le mode chuncked comme décrit dans la page projet de msgbus.
Voilà, voilà. Sinon, pour te décourager, voici les principaux défauts de HandBaller.
- le pattern matching qui sert à la souscription aux messages est trop souple, je suis obligé de passer en revue toutes les souscriptions pour voir si un message matche, sans pouvoir faire de haché... HandBaller n'est donc pas vraiment scalable, la complexité du reroutage d'un message étant en o(n).
- HandBaller ne supporte pas les connections keep-alive. Donc le long-pooling est coûteux. J'aimerais bien que Webkit se mette au multipart/x-mixed-replace ou à la balise HTML5 de "server side DOM event".
Et parce que la variété c'est bien, voici un autre projet dédié à l'auto-hébergé et à l'embarqué:
"HandBaller" est un bus HTTP minimaliste codé en C, une sorte d'APE en beaucoup plus simple.
Ami bidouilleur, HandBaller sera tout juste suffisant pour pousser dans votre application web des messages envoyés par des scripts shell ou autres programmes résidents sur votre serveur.
"Out of the box", HandBaller peut relayer des messages entre deux instances d'une applications web, comme un routeur de JSON. Parfait pour auto-héberger un système de tchat.
HandBaller a d'abord été pensé pour brancher du web (disons un portail dans un navigateur en mode kiosque) avec des sources d'évènements de la machine hôte, du LAN et d'aileurs. Par exemple, si vous faites tourner un gestionnaire de scoubidou sur votre machine et que vous développer un vue-mêtre de scoubidou à afficher dans un navigateur (genre un gadget iGoogle).
Je me la joue, mais si quelqu'un veut m'aider à mettre une hashtable par ci par là, ou à porter ma démo sous IE, ou à déboguer ce fichu mode Push/Multipart avec les balises image, heu... ben... je... serais très content.
Alors bon, je ne suis pas sûr de trouver une analogie entre ces travaux et le système Entrelacs. Non pas que ces approches ne soient pas intéressantes, mais plutôt qu'elles sont "orthogonales" par rapport à la question de la représentation de l'information.
En fait, n'importe quel langage peut prendre place dans un système Entrelacs: concernant un langage fonctionnel, il peut être non typé, typé dynamiquement ou statiquement, typé simplement ou fortement. Un langage peut aussi offrir, comme le suggèrent les travaux que tu m'as recommandés, une algèbre des types permettant de démontrer par la preuve mathématique la sécurité du code. Bref, on peut faire ce qu'on peut déjà faire dans un système traditionnel.
Mais lire des articles sur les sujets que tu m'a conseillés m'a surtout permis d'identifier un peu mieux en quoi les aptitudes d'un langage peuvent être étendues par le choix d'une représentation des connaissances par des flèches.
Si l'on parle d'un langage comme Lisp par exemple. Et bien il s'agit d'un langage connu pour homogénéiser la syntaxe concrète et la syntaxe_abstraite d'une expression. Cela permet entre autres choses, de déclarer des macros qui modifient en profondeur l'interpréteur du langage. Cela peut permettre aussi de recréer de nouvelles fonctions qui viennent compléter ou remplacer des fonctions existantes.
Toutefois, même si les syntaxes abstraites et concrètes sont homogènes, elles restent fondamentalement séparées dans un système traditionnel, puisque que que la syntaxe abstraite correspond à la représentation en mémoire vive de l'arbre-expression du programme tandis que la syntaxe concrète est rattachée aux fichiers source du même programme dans le file system.
Or ces derniers échappent à la modification par le programme. C'est une opération trop complexe dans un système traditionnel. Un logiciel Lisp ne peut donc pas pratiquer l'intercession (Réflexion) au niveau de la syntaxe concrète. En d'autres termes, un agent Lisp peut modifier son propre programme une fois chargé en mémoire, mais il ne peut pas modifier le programme originel (le fichier source), ni les autres programmes du système. L'intercession n'est pas pérenne. La méta-programmation (des programmes qui manipulent des programmes) reste alors une technologie couteuse, et la réflexivité du langage Lisp une curiosité.
Entrelacs, en fusionnant tous les formats d'information structurées et tous les niveaux mémoires dans un espace unique pour tout le système, élimine cette contrainte arbitraire (même si elle peut être réintroduire plus tard pour des raisons de sécurité). C'est à dire qu'un langage à la Lisp dans Entrelacs peut facilement être enrichi d'opérateurs permettant à un programme, non seulement d'accéder à une représentation syntaxique de lui-même, mais aussi de modifier cette expression de façon pérenne.
Par ailleurs, on propose souvent en exercice de fabriquer rapidement un interpréteur Lisp en Lisp, histoire de démontre que Lisp est un peu la mère de tous les langages. Toutefois, l'état de l'interpréteur qui anime un programme est rarement lui-même accessible par le dit-programme.
Il est vrai que les langages fonctionnels permettent souvent de manipuler la continuation courante, de la mémoriser et de la restaurer. Mais Entrelacs permettrait sans peine à un programme de récupérer tout l'état de l'interpréteur à l'instant présent: la continuation, mais aussi l'environnement courant et l'expression courante, le tout sous la forme de flèches, c'est à dire des entités de premier ordre, manipulables par le programme. Le programme pourrait donc stocker tout ou une partie de cet état, le modifier, et enfin le réinjecter dans l'interpréteur. Par exemple, un agent pourrait faire une "sauvegarde immédiate" de lui-même exactement comme le font certains jeux vidéo.
Bon, je vais m'arrêter, c'est épuisant de parler dans le vide abyssal d'internet. Le but de ce forum était au départ d'arrêter de déblatérer tout seul dans mon coin. C'est un peu raté pour l'instant.
Quoi qu'il en soit, merci encore pour le coup d'oeil.
oh merci pour ce commentaire positif, je désespérais un peu. Je vais fouiller Internet à la recherche de ces références. Est-ce que je peux te poser des questions sur ce que je ne comprends pas, en vérité, mes bagages académiques ne sont pas bien lourd.
Une flèche est approximativement une paire de pointeurs. Mais le développeur ou l'utilisateur n'a pas à le savoir: Il y a un ramasse-miettes et une gestion automatique des niveaux mémoires.
Tout ce que l'être humain a à faire est à importer les flèches qui exprime son besoin. C'est pas bien plus différent que de poser ou de streamer un fichier, ou de saisir un programme ou des données.
On pouvait déja dire que les interpréteurs transforme le code source en "arbres", les objet en "peigne", ça ne change rien au développement. Autant que je sache, les paires de pointeurs sont aussi beaucoup employées dans la compilation de langages fonctionnels.
Le brainfuck est une blague d'informaticien, toutefois c'est vrai que les opérateurs de base de cette nouvelle VM sont a priori très peu nombreux. Je t'assure que ca ne me fait pas plaisir d'inventer encore un nouveau langage. Mais pour une fois, ça vaut le coup, ça permet d'accéder à la puissance de ce nouveau mode paradigme. Je n'ai pas dis qu'il fallait directement développer dans ce langage, c'est juste une VM. Et puis dans un premier temps, je vois surtout ça comme une glue pour lier les opérateurs de consultation/édition des données avec des "callbacks" vers l'extérieur du système.
La "mémoization" ne consiste pas à deviner ce que veut le programmeur. C'est juste que si le résultat d'un calcul est dans le cache, on ne le refait pas. Toutes les infras complexe à la J2EE emploient ce genre de pools et de caches à tous les étages. Ici, c'est une fonctionnalité transparente.
C'est vrai qu'il n'y a pas de proto. Le gain annoncé est pour l'instant anticipé. Je n'aurai pas du utiliser le mot "Puissant". Je ne voulais pas dire que le système allait affiché le dernier jeu 3D du moment, mais plutôt qu'il allait rendre des services très utiles.
Concernant le proto, il s'agirait d'un serveur sous Linux avec une API réseau basé sur HTTP. Mais je bloque un peu sur la réalisation du langage, la machine à états et les transitions du moteur. Je me serais bien passé d'un tel développement. Le reste me paraît prêt pour passer à la conception détaillée et la réalisation: le stockage disque, le cache RAM, le ramasse-miettes, etc. Pour l'implémentation du serveur HTTP, j'ai aussi ma petite idée.
Pour ta conclusion, je choisirai la première version :)
Dans le détail, il y a donc un système de stockage spécialement inventé pour stocker ces briques élémentaires d'information que sont les flèches. Le tout avec cache, ramasse-miettes et persistence fiable et "transparente" sur disque.
Cet espace stocke aussi les infos de connectivité qui permet de parcourir/chercher les flèches de n'importe quelle façon.
Le même espace stocke aussi des blocs de données arbitraires (disons les pixels d'une image ou une chaîne de caractères), ces données peuvent à la fois être référencée ou servir de référence dans la construction de flèches.
Ah oui, il y aussi une théorie derrière qui prétend que ces blocs de données sont aussi des flèches, et que leur stockage par le système ne renie pas le principe premier "Tout est flèche". Ca c'est pour le spectacle.
Sinon, tu es peut-être passé à coté de l'idée que chaque flèche identifiable n'est présente qu'une seule fois dans tout l'espace de stockage, un peu comme si la valeur approximative du nombre PI n'était présente qu'une seule fois dans toute l'image disque d'un Linux opérationnel et que tous les programmes/données pointent sur cette valeur.
La solution technique consiste à placer ces flèches à des emplacements déterminés par un haché. Le système exploite par ailleurs plusieurs autres stratégies habituellement employées dans la conception de tables de hachage.
Une fois stockée, une flèche peut être dé-référencée et disparaître mais il va sans dire qu'elle ne peut être modifiée. C'est pas comme une valeur dans une variable. En fait, c'est comme si des objets mathématiques pures (des nombres, des paires et toutes les constructions dérivées) étaient mappés un-pour-un à des id dans le système.
Pour que le tout soit exploitable efficacement, le système embarque aussi le moteur d'un langage adapté à la situation. C'est une sorte de Lisp des flèches, sachant que le code source et l'état d'exécution du moteur sont sous la forme de... je te laisse deviner... oui des flèches.
Selon mon humeur, ce moteur/langage dédié est soit un simple interpréteur de requêtes à la SQL initiées par des logiciel tiers, soit la base d'une machine virtuelle prête à animer toute les applications de l'utilisateur. En tout cas, je crois qu'il sera capable de faire des choses incroyables grâce aux flèches, notamment de "mémoizer" tous les calculs qui peuvent l'être. Du genre: tu développes un gestionnaire d'images qui génère des miniatures, et sans rien lui dire, le système économise le calcul d'une miniature s'il a déjà été fait.
Au final, cela introduit une approche qui fait sauter une espèce de "verrou mental", à savoir le principe du "registre mémoire" sur lequel sont basées toutes les technos actuelles. En gros, ce système de flèches est à la réprésentation des connaissances ce que le "Lambda Calcul" est au calcul informatique, une sorte de théorie jusqu'au-boutiste qui débouche sur des technologies puissantes.
Le gain pour l'utilisateur, c'est de pouvoir réaliser simplement des choses qui paraissent énormes aujourd'hui, comme au hasard:
* avoir ses données indexées nativement par le système, prêtes à être cherchées, filtrées, explorées, manipulées dans tous les sens.
* disposer après un reboot de tout l'état d'une application et de son historique, comme "l'hibernation" mais en mieux. Les applications sont comme perpétuellement démarrées et on oublie définitivement des concepts moisis tels que... les fichiers.
* pouvoir nativement manipuler et cloner n'importe quoi n'importe où dans tout le système en mode zero-copy, un échantillon vidéo de 100 giga cité à pleins d'endroits ne prenant jamais plus de place.
* pouvoir nativement versionner le système à la sauce "Apple Time Machine"/"subversion"/"git".
* pouvoir nativement abstraire/virtualiser le système et y faire s'exécuter les agents logiciels douteux pour tout abandonner en cas de problème.
* etc.
Coté développeur, l'approche aboutie aussi à des conséquences intéressantes:
* Dans une conception orientée objet, ce qui identifie un "slot" dans un objet n'est plus un terme (un nom, un symbole...). Ca peut être n'importe quoi, par exemple une image. Le plus bizarre, c'est que la liaison entre un slot et sa valeur peut elle même servir de matériel pour construire d'autres objets.
* Dans une tagsonomie, le tag et la chose à étiqueter peuvent être n'importe quoi dans le système, et notamment une relation tag/item prééexistante. On peut donc typer des relations, lever des ambiguïtés...
* Dans une base de données, on peut construire, enrichir et changer son modèle de données sans jamais prévoir de "schéma".
* Un programme peut manipuler un programme, comme dans un langage réflexif comme Lisp, mais il peut vraiment le faire au plus bas niveau, de sorte que le comportement d'une application peut s'auto-modifier pour de bon et reconstruire de toutes pièces des pans de programmes plus adaptés aux besoins de l'utilisateur.
* les frontières entre le développeur et l'utilisateur, l'administrateur, etc. sont largement floutées, notamment parce qu'il n'y a définitivement plus aucune distinction en termes de représentation entre un conteneur et son contenu, entre un programme et ses données.
bon, heu ca fait un peu plus de 2 paragraphes, je vais peut-être m'arrêter là.
[...]
`-E'
`--export-dynamic'
When creating a dynamically linked executable, add all symbols to
the dynamic symbol table. The dynamic symbol table is the set of
symbols which are visible from dynamic objects at run time.
If you do not use this option, the dynamic symbol table will
normally contain only those symbols which are referenced by some
dynamic object mentioned in the link.
If you use `dlopen' to load a dynamic object which needs to refer
back to the symbols defined by the program, rather than some other
dynamic object, then you will probably need to use this option when
linking the program itself.
You can also use the version script to control what symbols should
be added to the dynamic symbol table if the output format supports
it. See the description of `--version-script' in VERSION.
[...]
... tu formates ta clef en fat32. Dessus, un fichier image d'un linux configuré avec un serveur ftp ou samba tout prêt en accès sur un FS crypté, (le tout apparaît en deux fichiers images sur FAT32, un pour le root_fs, l'autre pour la partoche cryptée).
Tu exécutes cette image de Linux avec un truc de virtualisation style vmware, pour Win32, Linux et MAC.
Donc quand tu veux accéder à ton système cripté par linux sous windows, tu démarres vmware ou équivalent, et après quelques secondes de boot, tu as un serveur ftp ou un partage Windows qui apparaît sur ton réseau local. Sauf que tout ça se retrouve dans le fichier de partoche cryptée.
je connais pas la ligne de commande de lynx, mais comme c'est une application style "curse" prévue pour s'exécuter de façon interactive dans un terminal, il faut nécessairement une option (s'il elle existe) pour la faire marcher de force sans être connectée à un terminal.
je pencherais pour l'option -dump ... je crois. Sinon, rajoutes lui -term=VT100, ça lui faira plaisir.
et redirige toute la sortie de lynx dans /dev/null, ça plait pas trop à "cron" si les commandes produisent des traces.
de toute façon, il y a d'autres outils pour pêter des requêtes http, curl? wget?
au moment de monter ta partition FAT32 dans ton linux, tu pouvais choisir (une option dans /etc/fstab) les droits (complétement bidons) données par Linux aux fichiers dans cette partition. Et de fait, t'aurais pu faire en sorte que tous les fichiers/dossiers présents et futurs soient 777.
Ceci-dit, t'aurais eu sans doute d'autres problèmes.
Il sait que tu déclares comme grandes vérités de vastes hypothèses ?
c'est ca. En général, je commence ma tirade par "je suis sûr que", mais des fois j'oublie.
Je répète qu'il ne s'agit pas d'un débat technique mais plutôt d'une "déconnade" avec un ami autour de ce thème: http://www.ecosociete.org/t37.html ... quelquechose que j'ai voulu partager avec les lecteurs de Linuxfr. Mais grace à toi, je ne ferai plus cette erreur: je vais tout de suite me défenestrer.
Au départ, il s'agissait d'un mail à quelqu'un qui me connait bien et qui sait très bien à quoi s'en tenir.
Je crois que je l'ai posté ici à cause du dernier paragraphe et de la référence à la "simplicité volontaire".
Pour ma défense, je viens de comprendre que le rôle des journaux sur linuxfr a l'air de changer. J'étais pas au courant qu'il s'agit de participer à l'élaboration d'une base de connaissances collectives.
Mais moi aussi j'ai déja de multiple ressources. Pseudo-code et tout ca.
Donc ce que je cherche, c'est un LL qui ait déja codé cet algo en l'ayant bien fait.
Cet algo est peut-être dans une librairie genre SDL, ou peut-être dans un vieux projet comme ce bon vieux Xwindows.... mais je ne sais pas où chercher.
Je vais peut-être faire un papier ici à ce sujet, tant ce logiciel relationnel est intéressant aussi bien d'un point de vue technique que heu... pas technique.
"Mon ordinateur n'est pas intelligent"
D'accord sur ce point.
"les [quelques systèmes biologiques cités en exemple] ne sont pas intelligents"
Heu, comme ton ordinateur? Tu ne fais pas une différence quand même?
"A moins d'avoir une idée de l'intelligence qui sorte *totalement* de la notion *généralement* admise."
Totalement? généralement? Mais la plupart des gens donnent une intelligence aux chiens, aux mauvaises herbes (celles de mon jardin, halalala)... même l'intelligence attribuée aux populations de virus devient populaire!
" il faut bien synthétiser *La* solution"
"synthétiser" = formuler avec des mots? Pourquoi il "faut"? Sais-tu qu'un joueur d'échecs professionel est incapable d'expliquer par des mots le choix d'une coup par rapport à une autre?
"...discerner la contribution de chacun..."
Mais c'est souvent inutile... à moins que tu penses qu'il soit nécessaire *d'imposer* par autoritarisme une solution sur les autres... C'est là où je voulais en venir en parlant d'opinions politiques, troll ou pas troll.
"\"automagiquement\""
Les guillemets n'escusent pas ce terme méprisant. Si tu ne vois pas comment un système de décision décentralisé peut avoir un comportement cohérent à l'échelle du système, ce n'est pas la peine de te moquer d'une vision adverse.
"[la discussion traite de] l'écriture d'une encyclopédie"
Selon moi, la discussion traite de la possibilité de trouver une solution collective à un problème de cohérence collective (la cohérence étant ici dénommée "ligne éditoriale"). Bref, un problème généralisable.
"...phrase pontifiante et autoritaire."
Cette remarque a un ton condescendant, d'accord. Mais pour le discours pontifiant... c'est l'hôpital qui se moque de la charité: Tu dénonces la comparaison avec une fourmillière, mais tu n'apportes aucun argument sinon ton indignation (nous ne sommes pas des fourmis). Or, pour en revenir sur le sujet, pourquoi Wikipédia aurait t'elle besoin d'un "sentiment" ou d'un "programme" (sous-entendu imposé par le groupe sur l'individu)?
"patrick_g" n'a peut-être pas eu le bon comportement en effacant la contribution adverse. Après tout, la contribution effacée était élément de définition reconnu pour un groupe, quand bien même patrick_g n'en fait pas parti.
En représailles, son travail risque d'être effacer lui aussi. De fil en aiguille, cette page va peut-être se casser la gueule, Patrick va arrêter d'écrire des articles, le contributeur de faire des remarques subjectives et non signées... et voilà. Ce n'est pas très efficace à l'échelle d'une personne, mais Wikipédia convergera quand même en un état homogène. C'est toute la force d'un wiki wiki web.
Après tout, une fourmilière "planifie" un déménagement après un coup de pied, bien que chaque fourmi n'ait vécu que des "évenements factuels"...
je ne vois dans ce commentaire qu'une suite d'affirmations partiales.
"Il n'y a pas de "super intelligence" chez les fourmis."
ben si. Voyons pourquoi:
"Il y a émergence de certains comportement collectifs qui produit des motifs comportementaux qui paraissent plus haut niveau",
Ils ne "paraissent" pas "haut niveau", ils le *sont*: Ils sont d'un niveau de complexité supérieure à la somme de la complexité des problèmes résolus individuellement.
"mais l'intelligence du tout n'est pas supérieure à la somme de l'intelligence des parties."
ben si. C'est la caractéristiques des RAN (réseaux associatifs non linéraires). Les fourmilières, le système immunitaire, les réseaux neuronaux et le marché économique sont des exemples de RAN.
"L'intelligence implique une conscience de l'intelligence,"
Il y a une vie après Kant.
"ce qui n'est pas le cas de l'"intelligence collective" des fourmis."
C'est un point de vue antropomorphique. Ce n'est pas parce qu'il n'y a pas de verbalisation des état mentaux, qu'il n'y a pas d'état mentaux. Or, à partir du moment où une part de ces états mentaux sert à modéliser l'entité qui les supporte (réflexivité) c'est déja un un début de conscience.
Ou alors seul l'homme est "conscient" grace au langage, mais une telle définition de la conscience n'apporte vraiment rien au schmilblick.
"Une colonie de fourmis est incapable de résoudre un problème de maths"
La colonie de mon jardin résout tous les matins le problème du voyageur de commerce
"Une colonie de fourmis est incapable d'inventer un dispositif"
La fourmilière en elle même, c'est pas un dispositif?
"ou de comprendre le problème posé dans le journal ci-dessus."
Une personne sans éducation ne comprendrait peut-être pas ce problème. Il n'est pas forcément nécessaire de le comprendre pour le résoudre. Par exemple, la simple compétition entre des projets d'édition collective amenera peut-être à résoudre ce problème sans même qu'une personne bien-pensante n'impose sa solution.
"Si elle n'a pas conscience de former un organisme intelligent, elle n'est donc pas intelligente."
Tu es si pressé de défendre ta haute opinion de l'intelligence "intellectuelle" que tu ne comprendras peut-être jamais la notion d'intelligence collective. Et je ne parle même pas de tes opinions politiques.
A ceux qui dénoncent "l'énormité" des questions pour lesquelles "seuls des extrémistes répondent de travers", je les conseille quand même de sortir de leur bulle, ces questions "énormes" illustrent un mode de pensée plus que répandu (je n'ose pas proposer ces questions au boulot, d'ailleurs) !
Dans l'idée de ce référentiel 2D, je classe les opinions selon les dogmes qui les fondent. Entre autres:
centralisme et hiérarchisme
- concentrer l'activité de la communauté est nécessaire dans certains cas (recherche, éducation, c'est selon)
- une structure hiérarchique (national, supra-gouvernmentale, c'est selon) qui contraint les choix individuels (interdiction, taxe...) est nécessaire
traditionalisme, communautarisme
- on ne remet pas en question la tradition
- comportement marginal=comportement anormal
utilitarisme linéaire, productivisme
- la fonction d'utilité optimale de l'humanité est la somme des fonctions d'utilité optimales de chaque individu
- l'humanité a pour premier but d'optimiser la transformation des ressources naturelles à son profit
techoscientisme
- l'humanité est l'élue du monde vivant
- l'humanité est investie d'une mission (la colonisation spatiale, la transformation des gènes, la croissance infinie, c'est selon)
- la complexification des systèmes d'origine humaine (techonologie ou autre) est une condition du progrès
économisme
- les indicateurs économiques et le bien être humain évoluent de concert
- le prix de revient d'un bien reflête le coût réel de sa production
- Les lois du marché (sous les hypothèses de votre choix) contribue à optimiser la transformation des ressources naturelles au profit de l'humanité
- le capitalisme est amoral
Je t'invite à chercher une autre explication de l'algo parce que le papier que j'ai trouvé via google n'est pas clair du tout.
"on préferera des triangles pour faciliter les calculs" :
aucune raison de triangulariser les polygônes. Avec la technique du balayage, un polygone peut avoir plein d'arêtes.
En fait, on sait si un point sur la ligne de balayage est à l'intérieur du polygône quand le nombre d'arêtes intersectées par la portion gauche de la ligne de balayage est impair. C'est l'un des points clefs de cette méthode.
Donc, une fois qu'on connait les intersections entre les arêtes et la ligne de balayage, il suffit de parcourir les intersections de gauche à droite pour obtenir de façon incrémentale le plus haut polygône visible entre 2 intersections.
"Les polygônes ne doivent pas se superposer" :
au contraire, c'est quand il y beaucoup de poly les uns sur les autres qu'on voit l'avantage du balayage vis à vis de la méthode du peintre.
Quand on balaye l'écran, on gère de façon incrémental une liste des arêtes actives, c'est à dire celles qui intersectent la ligne de balayage. C'est seulement pour ces arêtes qu'on calcule les intersections avec la ligne, les autres sont ignorées (et si on sait en plus ignorer les poly qui sont à l'extérieur de l'écran, c'est encore mieux).
Le x des intersections en cours s'obtient très simplement quand on fait un calcul incrémental par rapport à la ligne de balayage précédente. Le mieux est d'appliquer l'algo de Bresenham qui ne nécessite que des additions et des comparaisons d'entiers.
"il faudra pour chaque pixel tester quels sont les polys presents.
Si trop se superposent, il faut tous les tester a chaque pixel."
alors là pas du tout. c'est toute la différence entre cette technique et l'affichage un à un des polys. Car une fois qu'on connaît 2 intersections successives sur la ligne de balayage, on sait que tous les pixels entre les 2 n'appartiennent qu'à un seule surface, celle du poly visible le plus haut (ou le fond bien-sûr).
Donc, on part de la gauche, on va d'intersection en intersection, on met à jour le compteur de parité pour le polygône de l'arête intersectée, et selon le cas, on retire ou on rajoute ce polygone à une liste des polygônes en cours de peinture. Si la liste est triée en profondeur, la surface à afficher est celle du polygône en tête de liste.
Finalement, c'est une technique *très* intéressante parce que tous les calculs peuvent être fait en incrémental... on ne fait que des petites modifs d'une ligne de balayage à l'autre grâce à ce que l'auteur du papier appelle la "cohérence" de l'image.
[^] # Re: Photo d'un Pentium2 180Mo
Posté par Sylvain Garden (site web personnel) . En réponse à la dépêche LinuxConsole 2.4 . Évalué à 0.
je me greffe dans la conversion pour suggérer slitaz sur l'aspire one. Très bon support matériel. Définitivement plus rapide qu'une Lubuntu. Beaucoup plus cohérent qu'une Puppy Linux. La derniere release candidate est sorti en mai. Il n'y a pas beaucoup de jeux la dessus par contre.
[^] # Re: HandBaller
Posté par Sylvain Garden (site web personnel) . En réponse à la dépêche Nouvelle version de APE (Ajax Push Engine). Évalué à 3.
"msgbus" a été ma première source d'inspiration (cf. credits sur la page projet). Mais j'avais alors besoin d'une solution fiable qui marche tout de suite pour ce sur quoi je travaillais. C'était il y a 3 ans et msgbus était encore en développement.
C'est alors que thttpd s'est rappelé à mes bons souvenirs. On le trouvait dans plein de distrib Linux embarqué et c'est lui qui faisait tourner le site des pages perso de mon FAI de l'époque.
J'avais déja jeté un coup d'oeil au code avant. Alors voila, ca m'a pris quoi... 1 jour, pour trouver où et quoi patcher pour transformer thttpd en un bus à messages.
Ca m'a pris un peu plus longtemps à mettre au point le flux de push. Mais finalement j'ai pu utiliser ce travail dans une maquette pour avoir un feedback temps-réel de tout ce qui se passait à l'extérieur d'un moteur de Firefox 3 en kiosque (via un XmlHttpRequest avec multipart=true). Succès total.
thttpd n'a pas libevent. Mais il dispose de sa propre logique de scruptation d'I/O qui semble tout à fait au fait de la technologie.
Au départ HandBaller ne fonctionnait qu'en multipart. Mais WebKit est monté en puissance, et j'ai bien vu qu'il fallait que je me mette au long polling. Ca tombait bien, thttpd embarque aussi une solution de timers et de pattern matching légère... alors j'ai décidé de tout refaire. L'architecture actuelle repose sur des micro boîtes à messages (une pour chaque agent) qui persistent quelques secondes entre 2 requêtes de long pooling ou lors d'une coupure d'une connection de push.
J'ai essayé de joindre les développeurs de msgbus en septembre sans succès. Je leur avais proposé de partager nos expériences. Et surtout je leur ai demandé de l'aide. J'arrive pas à faire marcher le multipart/x-mixed-replace comme il faut en HTTP/1.1 et le mode chuncked comme décrit dans la page projet de msgbus.
Voilà, voilà. Sinon, pour te décourager, voici les principaux défauts de HandBaller.
- le pattern matching qui sert à la souscription aux messages est trop souple, je suis obligé de passer en revue toutes les souscriptions pour voir si un message matche, sans pouvoir faire de haché... HandBaller n'est donc pas vraiment scalable, la complexité du reroutage d'un message étant en o(n).
- HandBaller ne supporte pas les connections keep-alive. Donc le long-pooling est coûteux. J'aimerais bien que Webkit se mette au multipart/x-mixed-replace ou à la balise HTML5 de "server side DOM event".
# HandBaller
Posté par Sylvain Garden (site web personnel) . En réponse à la dépêche Nouvelle version de APE (Ajax Push Engine). Évalué à 5.
< autopromo humilité="aucune" >
Et parce que la variété c'est bien, voici un autre projet dédié à l'auto-hébergé et à l'embarqué:
"HandBaller" est un bus HTTP minimaliste codé en C, une sorte d'APE en beaucoup plus simple.
Ami bidouilleur, HandBaller sera tout juste suffisant pour pousser dans votre application web des messages envoyés par des scripts shell ou autres programmes résidents sur votre serveur.
"Out of the box", HandBaller peut relayer des messages entre deux instances d'une applications web, comme un routeur de JSON. Parfait pour auto-héberger un système de tchat.
HandBaller a d'abord été pensé pour brancher du web (disons un portail dans un navigateur en mode kiosque) avec des sources d'évènements de la machine hôte, du LAN et d'aileurs. Par exemple, si vous faites tourner un gestionnaire de scoubidou sur votre machine et que vous développer un vue-mêtre de scoubidou à afficher dans un navigateur (genre un gadget iGoogle).
* http://code.google.com/p/handballer/ : les sources et la démo
* http://tinyurl.com/yzp9smr : la doc de quelques pages
< /autopromo >
Je me la joue, mais si quelqu'un veut m'aider à mettre une hashtable par ci par là, ou à porter ma démo sous IE, ou à déboguer ce fichu mode Push/Multipart avec les balises image, heu... ben... je... serais très content.
[^] # Re: euhhh
Posté par Sylvain Garden (site web personnel) . En réponse au message projet "Entrelacs". Évalué à 2.
En fait, n'importe quel langage peut prendre place dans un système Entrelacs: concernant un langage fonctionnel, il peut être non typé, typé dynamiquement ou statiquement, typé simplement ou fortement. Un langage peut aussi offrir, comme le suggèrent les travaux que tu m'as recommandés, une algèbre des types permettant de démontrer par la preuve mathématique la sécurité du code. Bref, on peut faire ce qu'on peut déjà faire dans un système traditionnel.
Mais lire des articles sur les sujets que tu m'a conseillés m'a surtout permis d'identifier un peu mieux en quoi les aptitudes d'un langage peuvent être étendues par le choix d'une représentation des connaissances par des flèches.
Si l'on parle d'un langage comme Lisp par exemple. Et bien il s'agit d'un langage connu pour homogénéiser la syntaxe concrète et la syntaxe_abstraite d'une expression. Cela permet entre autres choses, de déclarer des macros qui modifient en profondeur l'interpréteur du langage. Cela peut permettre aussi de recréer de nouvelles fonctions qui viennent compléter ou remplacer des fonctions existantes.
Toutefois, même si les syntaxes abstraites et concrètes sont homogènes, elles restent fondamentalement séparées dans un système traditionnel, puisque que que la syntaxe abstraite correspond à la représentation en mémoire vive de l'arbre-expression du programme tandis que la syntaxe concrète est rattachée aux fichiers source du même programme dans le file system.
Or ces derniers échappent à la modification par le programme. C'est une opération trop complexe dans un système traditionnel. Un logiciel Lisp ne peut donc pas pratiquer l'intercession (Réflexion) au niveau de la syntaxe concrète. En d'autres termes, un agent Lisp peut modifier son propre programme une fois chargé en mémoire, mais il ne peut pas modifier le programme originel (le fichier source), ni les autres programmes du système. L'intercession n'est pas pérenne. La méta-programmation (des programmes qui manipulent des programmes) reste alors une technologie couteuse, et la réflexivité du langage Lisp une curiosité.
Entrelacs, en fusionnant tous les formats d'information structurées et tous les niveaux mémoires dans un espace unique pour tout le système, élimine cette contrainte arbitraire (même si elle peut être réintroduire plus tard pour des raisons de sécurité). C'est à dire qu'un langage à la Lisp dans Entrelacs peut facilement être enrichi d'opérateurs permettant à un programme, non seulement d'accéder à une représentation syntaxique de lui-même, mais aussi de modifier cette expression de façon pérenne.
Par ailleurs, on propose souvent en exercice de fabriquer rapidement un interpréteur Lisp en Lisp, histoire de démontre que Lisp est un peu la mère de tous les langages. Toutefois, l'état de l'interpréteur qui anime un programme est rarement lui-même accessible par le dit-programme.
Il est vrai que les langages fonctionnels permettent souvent de manipuler la continuation courante, de la mémoriser et de la restaurer. Mais Entrelacs permettrait sans peine à un programme de récupérer tout l'état de l'interpréteur à l'instant présent: la continuation, mais aussi l'environnement courant et l'expression courante, le tout sous la forme de flèches, c'est à dire des entités de premier ordre, manipulables par le programme. Le programme pourrait donc stocker tout ou une partie de cet état, le modifier, et enfin le réinjecter dans l'interpréteur. Par exemple, un agent pourrait faire une "sauvegarde immédiate" de lui-même exactement comme le font certains jeux vidéo.
Bon, je vais m'arrêter, c'est épuisant de parler dans le vide abyssal d'internet. Le but de ce forum était au départ d'arrêter de déblatérer tout seul dans mon coin. C'est un peu raté pour l'instant.
Quoi qu'il en soit, merci encore pour le coup d'oeil.
[^] # Re: euhhh
Posté par Sylvain Garden (site web personnel) . En réponse au message projet "Entrelacs". Évalué à 1.
[^] # Re: euhhh
Posté par Sylvain Garden (site web personnel) . En réponse au message projet "Entrelacs". Évalué à 1.
Tout ce que l'être humain a à faire est à importer les flèches qui exprime son besoin. C'est pas bien plus différent que de poser ou de streamer un fichier, ou de saisir un programme ou des données.
On pouvait déja dire que les interpréteurs transforme le code source en "arbres", les objet en "peigne", ça ne change rien au développement. Autant que je sache, les paires de pointeurs sont aussi beaucoup employées dans la compilation de langages fonctionnels.
Le brainfuck est une blague d'informaticien, toutefois c'est vrai que les opérateurs de base de cette nouvelle VM sont a priori très peu nombreux. Je t'assure que ca ne me fait pas plaisir d'inventer encore un nouveau langage. Mais pour une fois, ça vaut le coup, ça permet d'accéder à la puissance de ce nouveau mode paradigme. Je n'ai pas dis qu'il fallait directement développer dans ce langage, c'est juste une VM. Et puis dans un premier temps, je vois surtout ça comme une glue pour lier les opérateurs de consultation/édition des données avec des "callbacks" vers l'extérieur du système.
La "mémoization" ne consiste pas à deviner ce que veut le programmeur. C'est juste que si le résultat d'un calcul est dans le cache, on ne le refait pas. Toutes les infras complexe à la J2EE emploient ce genre de pools et de caches à tous les étages. Ici, c'est une fonctionnalité transparente.
C'est vrai qu'il n'y a pas de proto. Le gain annoncé est pour l'instant anticipé. Je n'aurai pas du utiliser le mot "Puissant". Je ne voulais pas dire que le système allait affiché le dernier jeu 3D du moment, mais plutôt qu'il allait rendre des services très utiles.
Concernant le proto, il s'agirait d'un serveur sous Linux avec une API réseau basé sur HTTP. Mais je bloque un peu sur la réalisation du langage, la machine à états et les transitions du moteur. Je me serais bien passé d'un tel développement. Le reste me paraît prêt pour passer à la conception détaillée et la réalisation: le stockage disque, le cache RAM, le ramasse-miettes, etc. Pour l'implémentation du serveur HTTP, j'ai aussi ma petite idée.
Pour ta conclusion, je choisirai la première version :)
[^] # Re: euhhh
Posté par Sylvain Garden (site web personnel) . En réponse au message projet "Entrelacs". Évalué à 2.
Dans le détail, il y a donc un système de stockage spécialement inventé pour stocker ces briques élémentaires d'information que sont les flèches. Le tout avec cache, ramasse-miettes et persistence fiable et "transparente" sur disque.
Cet espace stocke aussi les infos de connectivité qui permet de parcourir/chercher les flèches de n'importe quelle façon.
Le même espace stocke aussi des blocs de données arbitraires (disons les pixels d'une image ou une chaîne de caractères), ces données peuvent à la fois être référencée ou servir de référence dans la construction de flèches.
Ah oui, il y aussi une théorie derrière qui prétend que ces blocs de données sont aussi des flèches, et que leur stockage par le système ne renie pas le principe premier "Tout est flèche". Ca c'est pour le spectacle.
Sinon, tu es peut-être passé à coté de l'idée que chaque flèche identifiable n'est présente qu'une seule fois dans tout l'espace de stockage, un peu comme si la valeur approximative du nombre PI n'était présente qu'une seule fois dans toute l'image disque d'un Linux opérationnel et que tous les programmes/données pointent sur cette valeur.
La solution technique consiste à placer ces flèches à des emplacements déterminés par un haché. Le système exploite par ailleurs plusieurs autres stratégies habituellement employées dans la conception de tables de hachage.
Une fois stockée, une flèche peut être dé-référencée et disparaître mais il va sans dire qu'elle ne peut être modifiée. C'est pas comme une valeur dans une variable. En fait, c'est comme si des objets mathématiques pures (des nombres, des paires et toutes les constructions dérivées) étaient mappés un-pour-un à des id dans le système.
Pour que le tout soit exploitable efficacement, le système embarque aussi le moteur d'un langage adapté à la situation. C'est une sorte de Lisp des flèches, sachant que le code source et l'état d'exécution du moteur sont sous la forme de... je te laisse deviner... oui des flèches.
Selon mon humeur, ce moteur/langage dédié est soit un simple interpréteur de requêtes à la SQL initiées par des logiciel tiers, soit la base d'une machine virtuelle prête à animer toute les applications de l'utilisateur. En tout cas, je crois qu'il sera capable de faire des choses incroyables grâce aux flèches, notamment de "mémoizer" tous les calculs qui peuvent l'être. Du genre: tu développes un gestionnaire d'images qui génère des miniatures, et sans rien lui dire, le système économise le calcul d'une miniature s'il a déjà été fait.
Au final, cela introduit une approche qui fait sauter une espèce de "verrou mental", à savoir le principe du "registre mémoire" sur lequel sont basées toutes les technos actuelles. En gros, ce système de flèches est à la réprésentation des connaissances ce que le "Lambda Calcul" est au calcul informatique, une sorte de théorie jusqu'au-boutiste qui débouche sur des technologies puissantes.
Le gain pour l'utilisateur, c'est de pouvoir réaliser simplement des choses qui paraissent énormes aujourd'hui, comme au hasard:
* avoir ses données indexées nativement par le système, prêtes à être cherchées, filtrées, explorées, manipulées dans tous les sens.
* disposer après un reboot de tout l'état d'une application et de son historique, comme "l'hibernation" mais en mieux. Les applications sont comme perpétuellement démarrées et on oublie définitivement des concepts moisis tels que... les fichiers.
* pouvoir nativement manipuler et cloner n'importe quoi n'importe où dans tout le système en mode zero-copy, un échantillon vidéo de 100 giga cité à pleins d'endroits ne prenant jamais plus de place.
* pouvoir nativement versionner le système à la sauce "Apple Time Machine"/"subversion"/"git".
* pouvoir nativement abstraire/virtualiser le système et y faire s'exécuter les agents logiciels douteux pour tout abandonner en cas de problème.
* etc.
Coté développeur, l'approche aboutie aussi à des conséquences intéressantes:
* Dans une conception orientée objet, ce qui identifie un "slot" dans un objet n'est plus un terme (un nom, un symbole...). Ca peut être n'importe quoi, par exemple une image. Le plus bizarre, c'est que la liaison entre un slot et sa valeur peut elle même servir de matériel pour construire d'autres objets.
* Dans une tagsonomie, le tag et la chose à étiqueter peuvent être n'importe quoi dans le système, et notamment une relation tag/item prééexistante. On peut donc typer des relations, lever des ambiguïtés...
* Dans une base de données, on peut construire, enrichir et changer son modèle de données sans jamais prévoir de "schéma".
* Un programme peut manipuler un programme, comme dans un langage réflexif comme Lisp, mais il peut vraiment le faire au plus bas niveau, de sorte que le comportement d'une application peut s'auto-modifier pour de bon et reconstruire de toutes pièces des pans de programmes plus adaptés aux besoins de l'utilisateur.
* les frontières entre le développeur et l'utilisateur, l'administrateur, etc. sont largement floutées, notamment parce qu'il n'y a définitivement plus aucune distinction en termes de représentation entre un conteneur et son contenu, entre un programme et ses données.
bon, heu ca fait un peu plus de 2 paragraphes, je vais peut-être m'arrêter là.
# info ld
Posté par Sylvain Garden (site web personnel) . En réponse au message Problème d'exécution d'une librairie dynamique. Évalué à 3.
`-E'
`--export-dynamic'
When creating a dynamically linked executable, add all symbols to
the dynamic symbol table. The dynamic symbol table is the set of
symbols which are visible from dynamic objects at run time.
If you do not use this option, the dynamic symbol table will
normally contain only those symbols which are referenced by some
dynamic object mentioned in the link.
If you use `dlopen' to load a dynamic object which needs to refer
back to the symbols defined by the program, rather than some other
dynamic object, then you will probably need to use this option when
linking the program itself.
You can also use the version script to control what symbols should
be added to the dynamic symbol table if the output format supports
it. See the description of `--version-script' in VERSION.
[...]
[^] # Re: apache 2 installé, mais ne démarre pas en tant que service
Posté par Sylvain Garden (site web personnel) . En réponse au message sarge: désinstallation, puis réinstallation de apache: problèmes!. Évalué à 2.
google trouve par exemple: http://www.debian-administration.org/articles/28
# solus à la mode ...
Posté par Sylvain Garden (site web personnel) . En réponse au message Système de fichier crypté multi-OS ?. Évalué à 6.
Tu exécutes cette image de Linux avec un truc de virtualisation style vmware, pour Win32, Linux et MAC.
Donc quand tu veux accéder à ton système cripté par linux sous windows, tu démarres vmware ou équivalent, et après quelques secondes de boot, tu as un serveur ftp ou un partage Windows qui apparaît sur ton réseau local. Sauf que tout ça se retrouve dans le fichier de partoche cryptée.
je sais pas si je suis bien clair. Tant pis.
# lynx en tâche de fond?
Posté par Sylvain Garden (site web personnel) . En réponse au message update IP<-->mydomain avec CRON. Évalué à 2.
je connais pas la ligne de commande de lynx, mais comme c'est une application style "curse" prévue pour s'exécuter de façon interactive dans un terminal, il faut nécessairement une option (s'il elle existe) pour la faire marcher de force sans être connectée à un terminal.
je pencherais pour l'option -dump ... je crois. Sinon, rajoutes lui -term=VT100, ça lui faira plaisir.
et redirige toute la sortie de lynx dans /dev/null, ça plait pas trop à "cron" si les commandes produisent des traces.
de toute façon, il y a d'autres outils pour pêter des requêtes http, curl? wget?
# ca aurait pu...
Posté par Sylvain Garden (site web personnel) . En réponse au message pb: "could not start kstartupconfig" - mandriva 2007. Évalué à 2.
Ceci-dit, t'aurais eu sans doute d'autres problèmes.
[^] # Re: Technique
Posté par Sylvain Garden (site web personnel) . En réponse au journal Gmail et simplicité volontaire. Évalué à 1.
c'est ca. En général, je commence ma tirade par "je suis sûr que", mais des fois j'oublie.
Je répète qu'il ne s'agit pas d'un débat technique mais plutôt d'une "déconnade" avec un ami autour de ce thème: http://www.ecosociete.org/t37.html ... quelquechose que j'ai voulu partager avec les lecteurs de Linuxfr. Mais grace à toi, je ne ferai plus cette erreur: je vais tout de suite me défenestrer.
[^] # Re: Technique
Posté par Sylvain Garden (site web personnel) . En réponse au journal Gmail et simplicité volontaire. Évalué à 1.
Au départ, il s'agissait d'un mail à quelqu'un qui me connait bien et qui sait très bien à quoi s'en tenir.
Je crois que je l'ai posté ici à cause du dernier paragraphe et de la référence à la "simplicité volontaire".
Pour ma défense, je viens de comprendre que le rôle des journaux sur linuxfr a l'air de changer. J'étais pas au courant qu'il s'agit de participer à l'élaboration d'une base de connaissances collectives.
Donc, fini la déconnade?
[^] # Re: Technique
Posté par Sylvain Garden (site web personnel) . En réponse au journal Gmail et simplicité volontaire. Évalué à 2.
[^] # Re: Technique
Posté par Sylvain Garden (site web personnel) . En réponse au journal Gmail et simplicité volontaire. Évalué à 3.
# WatRend
Posté par Sylvain Garden (site web personnel) . En réponse au journal recherche code "extended polygon scan-conversion". Évalué à 1.
[^] # Re: AET
Posté par Sylvain Garden (site web personnel) . En réponse au journal recherche code "extended polygon scan-conversion". Évalué à 1.
Mais moi aussi j'ai déja de multiple ressources. Pseudo-code et tout ca.
Donc ce que je cherche, c'est un LL qui ait déja codé cet algo en l'ayant bien fait.
Cet algo est peut-être dans une librairie genre SDL, ou peut-être dans un vieux projet comme ce bon vieux Xwindows.... mais je ne sais pas où chercher.
# et ça?
Posté par Sylvain Garden (site web personnel) . En réponse à la dépêche GNU LilyPond 2.4.0. Évalué à 1.
# skyblog?
Posté par Sylvain Garden (site web personnel) . En réponse au sondage Mon site web perso est. Évalué à 1.
Je vais peut-être faire un papier ici à ce sujet, tant ce logiciel relationnel est intéressant aussi bien d'un point de vue technique que heu... pas technique.
[^] # Re: drôle d'opinion
Posté par Sylvain Garden (site web personnel) . En réponse au journal Wikipedia et les idéologies.. Évalué à 0.
D'accord sur ce point.
"les [quelques systèmes biologiques cités en exemple] ne sont pas intelligents"
Heu, comme ton ordinateur? Tu ne fais pas une différence quand même?
"A moins d'avoir une idée de l'intelligence qui sorte *totalement* de la notion *généralement* admise."
Totalement? généralement? Mais la plupart des gens donnent une intelligence aux chiens, aux mauvaises herbes (celles de mon jardin, halalala)... même l'intelligence attribuée aux populations de virus devient populaire!
" il faut bien synthétiser *La* solution"
"synthétiser" = formuler avec des mots? Pourquoi il "faut"? Sais-tu qu'un joueur d'échecs professionel est incapable d'expliquer par des mots le choix d'une coup par rapport à une autre?
"...discerner la contribution de chacun..."
Mais c'est souvent inutile... à moins que tu penses qu'il soit nécessaire *d'imposer* par autoritarisme une solution sur les autres... C'est là où je voulais en venir en parlant d'opinions politiques, troll ou pas troll.
"\"automagiquement\""
Les guillemets n'escusent pas ce terme méprisant. Si tu ne vois pas comment un système de décision décentralisé peut avoir un comportement cohérent à l'échelle du système, ce n'est pas la peine de te moquer d'une vision adverse.
"[la discussion traite de] l'écriture d'une encyclopédie"
Selon moi, la discussion traite de la possibilité de trouver une solution collective à un problème de cohérence collective (la cohérence étant ici dénommée "ligne éditoriale"). Bref, un problème généralisable.
"...phrase pontifiante et autoritaire."
Cette remarque a un ton condescendant, d'accord. Mais pour le discours pontifiant... c'est l'hôpital qui se moque de la charité: Tu dénonces la comparaison avec une fourmillière, mais tu n'apportes aucun argument sinon ton indignation (nous ne sommes pas des fourmis). Or, pour en revenir sur le sujet, pourquoi Wikipédia aurait t'elle besoin d'un "sentiment" ou d'un "programme" (sous-entendu imposé par le groupe sur l'individu)?
"patrick_g" n'a peut-être pas eu le bon comportement en effacant la contribution adverse. Après tout, la contribution effacée était élément de définition reconnu pour un groupe, quand bien même patrick_g n'en fait pas parti.
En représailles, son travail risque d'être effacer lui aussi. De fil en aiguille, cette page va peut-être se casser la gueule, Patrick va arrêter d'écrire des articles, le contributeur de faire des remarques subjectives et non signées... et voilà. Ce n'est pas très efficace à l'échelle d'une personne, mais Wikipédia convergera quand même en un état homogène. C'est toute la force d'un wiki wiki web.
Après tout, une fourmilière "planifie" un déménagement après un coup de pied, bien que chaque fourmi n'ait vécu que des "évenements factuels"...
[^] # drôle d'opinion
Posté par Sylvain Garden (site web personnel) . En réponse au journal Wikipedia et les idéologies.. Évalué à 0.
"Il n'y a pas de "super intelligence" chez les fourmis."
ben si. Voyons pourquoi:
"Il y a émergence de certains comportement collectifs qui produit des motifs comportementaux qui paraissent plus haut niveau",
Ils ne "paraissent" pas "haut niveau", ils le *sont*: Ils sont d'un niveau de complexité supérieure à la somme de la complexité des problèmes résolus individuellement.
"mais l'intelligence du tout n'est pas supérieure à la somme de l'intelligence des parties."
ben si. C'est la caractéristiques des RAN (réseaux associatifs non linéraires). Les fourmilières, le système immunitaire, les réseaux neuronaux et le marché économique sont des exemples de RAN.
"L'intelligence implique une conscience de l'intelligence,"
Il y a une vie après Kant.
"ce qui n'est pas le cas de l'"intelligence collective" des fourmis."
C'est un point de vue antropomorphique. Ce n'est pas parce qu'il n'y a pas de verbalisation des état mentaux, qu'il n'y a pas d'état mentaux. Or, à partir du moment où une part de ces états mentaux sert à modéliser l'entité qui les supporte (réflexivité) c'est déja un un début de conscience.
Ou alors seul l'homme est "conscient" grace au langage, mais une telle définition de la conscience n'apporte vraiment rien au schmilblick.
"Une colonie de fourmis est incapable de résoudre un problème de maths"
La colonie de mon jardin résout tous les matins le problème du voyageur de commerce
"Une colonie de fourmis est incapable d'inventer un dispositif"
La fourmilière en elle même, c'est pas un dispositif?
"ou de comprendre le problème posé dans le journal ci-dessus."
Une personne sans éducation ne comprendrait peut-être pas ce problème. Il n'est pas forcément nécessaire de le comprendre pour le résoudre. Par exemple, la simple compétition entre des projets d'édition collective amenera peut-être à résoudre ce problème sans même qu'une personne bien-pensante n'impose sa solution.
"Si elle n'a pas conscience de former un organisme intelligent, elle n'est donc pas intelligente."
Tu es si pressé de défendre ta haute opinion de l'intelligence "intellectuelle" que tu ne comprendras peut-être jamais la notion d'intelligence collective. Et je ne parle même pas de tes opinions politiques.
# une autre projection
Posté par Sylvain Garden (site web personnel) . En réponse au journal Politique en deux dimensions.. Évalué à 1.
Dans l'idée de ce référentiel 2D, je classe les opinions selon les dogmes qui les fondent. Entre autres:
centralisme et hiérarchisme
- concentrer l'activité de la communauté est nécessaire dans certains cas (recherche, éducation, c'est selon)
- une structure hiérarchique (national, supra-gouvernmentale, c'est selon) qui contraint les choix individuels (interdiction, taxe...) est nécessaire
traditionalisme, communautarisme
- on ne remet pas en question la tradition
- comportement marginal=comportement anormal
utilitarisme linéaire, productivisme
- la fonction d'utilité optimale de l'humanité est la somme des fonctions d'utilité optimales de chaque individu
- l'humanité a pour premier but d'optimiser la transformation des ressources naturelles à son profit
techoscientisme
- l'humanité est l'élue du monde vivant
- l'humanité est investie d'une mission (la colonisation spatiale, la transformation des gènes, la croissance infinie, c'est selon)
- la complexification des systèmes d'origine humaine (techonologie ou autre) est une condition du progrès
économisme
- les indicateurs économiques et le bien être humain évoluent de concert
- le prix de revient d'un bien reflête le coût réel de sa production
- Les lois du marché (sous les hypothèses de votre choix) contribue à optimiser la transformation des ressources naturelles au profit de l'humanité
- le capitalisme est amoral
houla, j'en suis déja à cinq dimenssions
# oooohhh je savais pas que ç'était autant répandu
Posté par Sylvain Garden (site web personnel) . En réponse au journal reconnaissance de musique fredonnée. Évalué à 1.
http://www.soft411.com/software/voice-to-midi.html(...)
[^] # Re: "moteur 2D" dit le titre de l'article
Posté par Sylvain Garden (site web personnel) . En réponse au journal moteur graphique 2D. Évalué à 1.
"on préferera des triangles pour faciliter les calculs" :
aucune raison de triangulariser les polygônes. Avec la technique du balayage, un polygone peut avoir plein d'arêtes.
En fait, on sait si un point sur la ligne de balayage est à l'intérieur du polygône quand le nombre d'arêtes intersectées par la portion gauche de la ligne de balayage est impair. C'est l'un des points clefs de cette méthode.
Donc, une fois qu'on connait les intersections entre les arêtes et la ligne de balayage, il suffit de parcourir les intersections de gauche à droite pour obtenir de façon incrémentale le plus haut polygône visible entre 2 intersections.
"Les polygônes ne doivent pas se superposer" :
au contraire, c'est quand il y beaucoup de poly les uns sur les autres qu'on voit l'avantage du balayage vis à vis de la méthode du peintre.
Quand on balaye l'écran, on gère de façon incrémental une liste des arêtes actives, c'est à dire celles qui intersectent la ligne de balayage. C'est seulement pour ces arêtes qu'on calcule les intersections avec la ligne, les autres sont ignorées (et si on sait en plus ignorer les poly qui sont à l'extérieur de l'écran, c'est encore mieux).
Le x des intersections en cours s'obtient très simplement quand on fait un calcul incrémental par rapport à la ligne de balayage précédente. Le mieux est d'appliquer l'algo de Bresenham qui ne nécessite que des additions et des comparaisons d'entiers.
"il faudra pour chaque pixel tester quels sont les polys presents.
Si trop se superposent, il faut tous les tester a chaque pixel."
alors là pas du tout. c'est toute la différence entre cette technique et l'affichage un à un des polys. Car une fois qu'on connaît 2 intersections successives sur la ligne de balayage, on sait que tous les pixels entre les 2 n'appartiennent qu'à un seule surface, celle du poly visible le plus haut (ou le fond bien-sûr).
Donc, on part de la gauche, on va d'intersection en intersection, on met à jour le compteur de parité pour le polygône de l'arête intersectée, et selon le cas, on retire ou on rajoute ce polygone à une liste des polygônes en cours de peinture. Si la liste est triée en profondeur, la surface à afficher est celle du polygône en tête de liste.
Finalement, c'est une technique *très* intéressante parce que tous les calculs peuvent être fait en incrémental... on ne fait que des petites modifs d'une ligne de balayage à l'autre grâce à ce que l'auteur du papier appelle la "cohérence" de l'image.