Je l'ai aussi changé, parce que ce dialogue hyper mal fait m'énerve depuis longtemps, mais FireFox plante à chaque fois que je sauve quoi que ce soit.
Suis-je tout seul à avoir ce problème ?
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
Mais c'est un débat très secondaire, je suis bien conscient de pinailler sur des détails.
Moi je veux un SQL objet, rien d'autre, je veux pouvoir y mettre des sous requêtes, des group by, etc...
De plus, SQL, tout le monde connaît.
C'est exactement ce que j'aurais à lui reprocher:
- avec un garbage collector certains te prétendent que tu n'as plus à penser à la mémoire, c'est faux! (c'est même plus difficile de contrôler sa mémoire avec un GC!). Il faut évidemment relativiser, peu d'application de nos jours sont réellement tracassée par leur mémoire...
Effectivement, dans certains cas particuliers un Gc peu poser des problèmes.
Fort bien.
Je peu paraître extrémiste, mais je pense qu'il faut en finir avec la gestion à la main de la mémoire, il faut en finir avec les pointeurs.
Il est certes jouissif pour certains de jouer avec, mais, dans le cadre d'un gros projet de plusieurs centaines de milliers de lignes, il faut en finir, c'est un facteur de bug beaucoup trop important.
Je pense d'autre part que c'est au compilateur de gérer finement la mémoire, car un être humain ne pourra jamais le faire aussi bien, en tout cas à partir d'une certaine taille. Demander à un humain de gérer les emplacements mémoire de chaque données, à la main, pour que celle-ci se trouve contigue en mémoire afin d'accélerer le cache est très vite beaucoup trop complexes.
J'ai d'autres exemples de ce style.
Comme tu le dit, la mémoire n'est plus un problème pour la plupart des applications.
Je dirai même que c'est le boulot de compilateur de gérer celle-ci correctement, après analyse de flot.
- avec la prog objet, certains vendent le fait que l'analyse compte (et vive UML et autre formalisme) et que l'implémentation est un détail... c'est à nouveau faux. (ça amène des design élégant, mais jamais implémenté, ou des design "génrique" ne proposant pas de solution concrète dans un cas pratique)
Je ne m'occupe pas de méthode design pour le moment. Je m'occupe de créer un (des, car d'autres suiveront) langage(s) permettant d'exprimer le mieux et le plus vite possible l'intuition du développeur, que celui-ci ne soit pas obligé de se plier à des circonlocutions typiquement informaticienne pour implémenter des concepts évident pour un être humain normalement constitué.
Si tu prend une bataille navale, le concept "un croiseur envoie un message à tous les croiseurs de son équipe, dans un rayon de 400km" devient très vite un bordel immonde (et encore c'est un exemple très simple.
Il te faut parcourir une collection, trier selon l'équipe (un test) si ce n'est pas déjà fait, vérifier le type, calculer le module des positions, et le cas échéant appeler une méthode que tu devra avoir pensé pour répondre à un problème très précis (genre "aidez moi, j'ai plus de fioul").
Ce genre de chose ça me gonfle.
C'est en devant programmer ce truc précis, lors d'un projet en formation, que les idées à la base de cette publi (il n'y pas tout d'ailleurs) me sont venues car j'en avai plus que marre d'écrire 1500 boucles, en java qui plus est, où tu dois récupérer et caster ce que contiennent tes vectors.
Bref. Avec une requête SQL, un foreach, et surtout le concept de messages conditionnels en multicast, c'est réglé en 5 lignes.
Après, après... Quand j'aurai le langage fonctionnel qui aura le mérite de commencer à me satisfaire (parce que je serai satisfait qua quand on balancera les spécifs à la machine et qu'il programmera pour nous, on y arrivera un jour qu'on le veuille ou non), là je penserai peut être à réfléchir (ou trouver des gens pour ça) aux méthodes de formalisations type UML adaptée à ce langage.
Mais tout d'abord il faut commencer par le compilateur.
- en C# tu peux déjà appeler un delegate de façon asynchrone, mais s'ils ont pensés au perf (pool de thread etc), tu as des cas explosifs (genre le delegate qui appelle des delegate etc...). Dans certains cas, ça passe par un message, à nouveau tu te retrouves parfois avec un appel bloqué qui attends des dizaines de messages avant de poursuivre!
D'après le peu que j'en ai compris, le delegate est
1/ un sous-concept de messages entre objet
2/ un bricolage conçu pour contourner les limites de l'objet à classe.
Lisaac est un langage objet à prototype.
Dans un objet que tu écris, tu définis le parent, comme une variable (dans la section INHERIT)
Comme tout est objet vivant, tu peu définir finement qui est ton parent, et tu peux même en changer à l'exécution quand tu le désir.
Donc pas besoin de delegate pour dérouter des messages vers des parents comme l'explique : http://csharpro.developpez.com/page10.php
Tu fait
section INHERIT
+ mon_parent : TYPE_PARENT := TYPE_PARENT;
section PUBLIC
- toto <-
(
mon_parent.method;
);
- tu présentes un formalisme comme étant le truc qui permet de ne pas "avoir de problème" c'est vrai dans un monde théorique (et encore), un formalisme peut être vu comme un langage plus éloigné de la machine et plus proche de l'humain, cela ne le rend pas complet, correct, et surtout cela ne facilite pas forcément les choses. (pense à certains design pattern exprimé en qq mots, qq lignes de codes, et un schéma UML incompréhensible! Cependant, UML n'est pas le seul formalisme, il en existe sans doute de plus adapté selon le cas).
C'est effectivement le plus gros problème. C'est pour cela qu'il faut réfléchir au maximum à une abstraction qui nécessite le moins possible de comprendre ce sur quoi elle s'appuie (comme tcp s'appuie sur ip) pour s'assurer de la maîtriser correctement.
C'est un gros travail.
Ce que nous proposons dans cette publi n'est qu'un modèle et il n'est pas certains que l'implémentation en soit fidèle.
Je pense néanmoins que le fait chaque thread sera dans un monde clot au niveau des données facilitera pas mal les choses.
Après c'est à voir, je pense particulièrement à l'émergence qui est un phénomène structurel.
C'est là que les méthodes joueront leur rôles. Elle sont d'ors en conception dans des labos.
- Dans le même ordre d'idée, je ne pense pas que masqer l'existence de thread soit souhaitable, même le thread, qui est déjà une abstraction ne peut en général pas être utilisée tel quel, un développeur doit se demander comment se comporte son CPU (surtout sur un système multi-proc) s'il veut être efficace. Je ne doute pas de l'intéret d'une telle abstraction dans certains cas (je pense notemment au business rules engine), mais je me pose des questions sur la pertinence de mettre cela dans le langage même.
la pertinence de le mettre dans le langage même consiste à proposer l'absraction pour les "certains cas" dont tu parles.
Un type qui fait une GPAO, un ERP, a autre chose à faire que de se prendre la têtes avec des priorités dans des threads.
Après n'oublie pas que ce qui est proposé est extension du langage que ce soit bien clair ! :-)
Rien ne t'empêche de ne pas utiliser les agents (bref de programmer en objet classique), de gérer toi même tes threads à la main, etc...
Ce que l'on présente dans cette publi, c'est une fonctionnalitée suplémentaire ! Rien d'autres.
Ceux qui jugeront utile de l'utilser l'utiliseront, les autres non. Tu as le choix.
Concernant l'impact sur les performances, les thread ont un coût (dépendant de l'os et de la façon dont tu fais cela, par exemple, par défaut sous windows, chaque nouveau thread à un tas dédiés de 1Mo!), et encore plus si tu ne partages pas la mémoire, un deepcopy sera coûteux en temps et en mémoire!
Enfin ta recherche me semble de toute façon intéressante, je suis impatient de pouvoir tester les premières implémentation!
Pour le coût, on s'adaptera aux OS existants bien que la fnalité de ce langage est de tourner sur IsaacOS qui sera un OS temps réel à terme et intégralement objet.
Pour l'implémentation ça risque de prendre du temps, surtout si messieurs les chercheurs tardent à donner le poste que Benoit Sonntag mérite...
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
Je pense qu'il ya possibiité d'obtenir de bonnes perfs sur le système de requêtes en optimisant celle-ci d'une part (coupes dans l'arbre, compilation inline de l'algo de calcul de la requête) et d'autre part en réorganisant les données de tel façon qu'on puisse retrouver assez vite les données.
Dans un contexte ou tout est compilé (ie que des micro objets), on pourrait utiliser l'analyse de flot pour organiser des indexs prévus pour "coller" à la requête.
Quand au thread, je vois pas de problèmes de perfs.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
Concernant le "SQL/Objet", je comprends l'intéret, c'est aussi ce qui se fait en autre en C# 3.0 il me semble (avec sans doute quelques différences qui m'échappe), et si c'est bien pensé, et applicable aussi bien aux données externes qu'internes, ça devrait en effet grandement simplifié la façon de penser des programmes (avec par contre le danger de mélanger les couches et de créer des composants fortement couplés sans même s'en rendre compte). Permets-moi juste de préciser que c'est surtout du sucre syntaxique tournant autour des lambdas expressions et l'utilisation de fonction en first class object.
Premièrement, je ne me suis pas gêné pour le mettre, parce que j'y ai pensé tout seul (SQL est mon "langage" de prog préféré). J'ai découvert, à l'occasion d'unjournal de TImaniac que C#3 l'incluerait. Bien que ça ne me plaise pas dans la forme retenue.
Je veux SQL intégré dans le langage, car j'en ai plus que marre de passer mon temps à parcourir des collections pour tester tel ou tel critères.
Deuxièmement, c'est effectivement du sucre syntaxique qui nécessite une modification du compilo (c'est pour ça qu'on l'a mis), mais qui simplifie la vie. C'est ça qui compte.
Concernant l'aspect massivement multithread, je suis perplexe, j'ai l'impression que ça permettrait d'éviter la complexité syntaxique de ce genre de construction, mais j'ai un doute sur la simplication réelle, au contraire j'ai peur que cela rende un programme extrèmement complexe à comprendre. Quelle mécanismes existent-ils pour gérer les effets de bord? Dans tous les langages, c'est le problème, encore plus dans les langages objets (et leur idée de "remplacer un composant par un autre", pense par exemple à java et le fait que toute les méthodes soit virtuelles).
C'est déjà très complexe de faire un modèle objet single thread, gérer plus de 3 threads interdépendantes est vite un enfer... je n'oserais pas proposer à mon équipe de dev d'utiliser ce genre de chose, je vois déjà les cascades de threads créées sans même s'en rendre compte ;)
Mais le modèle est justement conçu pour que tu n'ais pas à penser aux threads" TU devra penser en terme d'agent vivant, sur le qui vive, attendant des évènement extérieurs.
C'est dans l'émergence de comportements que tu risque effectivement d'avoir quelques problèmes, surtout si ton agent réagit directement à des évènements extérieur.
Mais grâce au système de message (message synchrone objet classiq ou message asynchrone du type boite au lettre (le point 3/)), tu pourras rendre tes agent un tant soi peu "cognitif", limiter leur réactivité, et ainsi avoir des comportements émergeants limités.
Il existe (la méthode VOYELLE par ex) des formalismes permettant de ne pas avoir de problème, il est certain qu'il sera nécessaire de bien les formaliser avant de lacher un tel langage dans l'industrie, mais je pense que si quelques règles de base sont bien appliquée, tu n'aura pas de problème car, comme je le répète plus haut :
1/ Les threads sont autonomes et travaillent sur des données qui ne se balladent pas entre threads : toutes les données échangées se feront par copie, de sorte qu'il n'y ai pas de conflit
2/ C'est le compilateur qui gère tous les monitors et autres problème de synchro. Pour le programmeur, il ya des processus indépendants qui s'envoient des messages.
Enfin, as-tu des données sur les perf de ce langage? Je me doute que c'est encore expérimental, mais est-ce théoriquement possible de faire quelque chose de compétitif? (à savoir: le classique trade-off entre temps de dev et hardware nécessaire)
Pour le moment le compilateur n'étant pas implémenté, on en sait rien.
Par contre, sache que lisaac (l'actuel) est certainement le langage objet le plus performant au monde, il va beaucoup plus loin qu'Eiffel dont il est un descendant (et en même temps un sur ensemble) :-)
voir : http://isaacos.loria.fr/li_speed.html
Je ne sais pas ce que ça donnera, mais connaissant Benoit Sonntag, je prévoit que ça ira très très vite... ;-)
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
Je veux bien croire que le jargon aide à exprimer ses pensées en peu de mots, mais l'économie de mots a un coût, pour le lecteur, lorsqu'il s'agit de comprendre. Il n'y a pas de honte à utiliser une ou deux phrases à la place de mots comme ontologisation hein :)
Il s'agit plus de flemme que de honte. J'adore les phrases denses et concises, sans doute parce que j'ai horreur de perdre mon temps.
Tapper m'ennuie, alors vive les préfixes et les suffixes. Après je vais peut être parfois trop loin...
- On passe progressivement d'une représentation des données à une description des données. Par exemple (simpliste) le champ "size" d'un objet "array" peut-être représenté par un entier (non distinguable des autres entiers), ou bien décrit comme étant la taille du tableau (et donc pas un entier quelconque). La description implique entre autres que le champ size a une influence sur le nombre d'itérations d'un parcours du tableau, sur la place qu'occupe ce tableau en mémoire, etc. Si l'on se contente de représenter les données sans les décrire, alors c'est au programmeur d'interpréter leur signification dans sa tête.
- Ça serait bien que ce passage de représentation à description ne soit pas limité aux données, mais soit aussi appliqué au traitement des données. Là j'avoue que j'ai du mal à trouver rapidement un exemple pertinent, mais j'ai l'impression que ça revient à dire: ça serait bien que l'on puisse programmer des design patterns. Pour l'instant on ne peut pas les programmer, ce sont des concepts que le programmeur doit adapter à sa situation, mais avec des langages de plus haut niveau, ça serait possible.
Imagine, que tu utilise dans ton programme une liste chainée de couple de réels
{(3.5,5.4),(8.4,8.6),...}.
Imaginons que dans toutes les manipulations que tu effectue dessus, il se trouve que tu respectes les axiomes d'espaces vectoriels (ie. dans ta tête lorsque tu programmes, ta liste chainée est une liste de vecteurs).
Tu additionne tes couples, tu utilises des matrices, etc...
Un "prépocesseur" détecte alors que ta liste chainée est une liste de vecteurs d'un espace vectoriel. Il te propose d'emblée tout un tas de fonctions, il vérifie que ton code ne contient pas d'erreurs mathématiques, etc...
Par exemple, si tu modélise des agents sur un terrain (de foot par exemple), et que tu décris ceux-ci par des vecteurs, tu auras automatiquement la possibilité de leur donner une direction en radian, en degré, et un module.
Si tu modélise un balon, il suffira de le définir comme objet physique doté d'une masse (le type OBJET_MASSIQUE) et il analysera le contexte d'utilisation de ton balon pour toi, te proposant calcul de trajectoire, etc...
C'est plutôt vers cette idée.
Programmer, c'est créer de toutes pièces une structure cohérente (Coherens "qui tien ensemble"). Un truc issu de ton cerveau que tu crée à partir de rien, à part les primitives offertes par ton langage.
Là, par reconnaissance de forme, l'environnement de dev détecte les objets que tu veux décrire et t'assiste en t'offrant des structures toutes faites.
On aura une réprésentation standard du concept de client, d'entreprise, d'employé, de pièce, etc... Avec à chaque fois des propriétés et des contraintes.
C'est entre "écrire de la lib" et "concevoir un moteur de reconnaissance de forme".
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
- Pour qu'un langage/paradigme soit adopté, il faut entre autre, qu'il apporte quelque chose, j'ai du mal à résumer les avantages de ce que tu présentes! comment résumerais-tu cela toi?
1/ Possibilité d'écrire des applications multithreadées assez facilement. Du fait que Lisaac reste un langage objet, on pourra utiliser les fonctionalités agent au minimum : par exemple, les clauses de déclanchement de comportement ne seront activés que pour la réception de messages (voir 3/).
Tu n'as plus à te préoccuper de mutex et autres monitors
2/ L'intégration d'un SQL/Objet dans le langage qui devient en passant persistant. Imagine que lors du développement d'une GPAO, tu as besoin d'écrire une fonction "réapro" te renvoyant l'ensemble des pièces que l'on doit racheter (le seuil de quantité minimal dans le stock a été enfoncé).
- list_reapro : SET[PIECE] <-
(
+ result : SET[PIECE] := SET[PIECE].create; // on créé un ensemble de pièces
result := select refs from stock where qte<seuil // on liste les pièces
//stock est une collection d'objets pièces.
result // on les renvoient
);
Là le compilateur, te vérifie le typage, gère la BDD pour toi (on architecturera la chose de sorte que l'on puisse interfacer tout SGBD avec)
Les requêtes peuvent se faire sur des objets ou des agents présent en mémoire : tu n'as plus à parcourir des collections afin de récupérer les infos que tu y veux.
Avec un tel système, en faisant un select bien sentie, tu peux sélectionner une liste de thread (des agents) correspondant à des critères précis, récupérer la liste de ceux-ci et leur envoyer un message.
Par exemple dans un logiciel de son multipiste, tu veux couper toutes les pistes utilisant l'effet phaser.
Tu généralise ton code :
- coupe_piste_selon_filtre_actif typefiltre : FILTRE volume_under volum : INTEGER <-
// ce header permet de couper toutes les pistes utilisant un filtre, dont le niveau sonore est en dessous de volum
(
// un filtre est un calcul effectué en temps réel sur flux son : equaliseur, disto
//phaser, etc...
+ list_soundagent : AGENT;
list_soundagent := select_agent from list_agent_playing where filtre_actif.type = typefiltre and volume<= volum;
list_soundagent.foreach {
x : AGENT;
x.mute;
};
);
C'est un exemple trop simple pour que cela soit vraiment intéressant, mais imagine des requêtes beaucoup plus complexes, où le fait de programmer la requêtes à la main en faisant une boucle listant une collection (ce qui suppose de prévoir les bonnes méthodes public te renvoyant les informations voulues, te facilitant la tâche, etc... ) n'est plus utile.
Tu peux gagner un temps fou !
3/ Les messages asynchrones seront fortement implantés dans le langage. Tu pourras envoyer des messages particulier, attendre un reply, demander la liste historique des messages de tel objet ou tel agent, etc...
Dans le modèle, les primitives présentés suffisent à permettre de définir, dans la librairie, un service de messages très complet.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
Normalement, il n'y aura pas à gérer certains des problèmes classiques des thread.
En effet le compilateur compilera le code de sorte que chaque thread gère un espace mémoire étanche : Toutes les données seront transmises en copie (via le deepclone), et le respect des priorités sera automatiquement "géré" par le compilateur.
Après, un interpréteur ne ferai pas de mal.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
Je crois que tu as raison et que je trouverai intelligent de faire interpréteur carrément. Il irait 100 fois moins vite que le code compilé, mais il aurait au moins le mérite de permettre un véritable debugging.
Avec une constante de temps divisé par 1000 ou 10000 on pourrait surement simuler du temps réel, même sous linux et windows.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
Je te répond partiellement parce qu'il faut que je réfléchisse à ta contribution très intéressantes et que ce système de clauses est plutôt celui de Benoit. J'avai conçu au début un système de comportement stéréotypés sur plusieurs slots qui était pas très réaliste et surtout mal intégré à l'aspect prototype.
Sache seulement, qu'a priori, puisqu'il ne s'agit que d'un modèle, ce langage est essentiellement conçu pour tourner sur IsaacOS, et que le destin d'IsaacOS est d'être un système temps réel. C'est aussi un OS où la notion de processus n'existe pas, un processus n'est que l'association à l'instant T d'objets travaillant ensembles.
Donc imagine que le système peut donner la main à n'importe quel thread n'importe quand.
Pour le reste, il faut que j'y réfléchisse.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
Je le répète, ce modèle n'est pas un nouveau langage c'est un ajout de primitives aux compilateurs. :-)
Tu peux parfaitement utiliser Lisaac en tant que langage objet classique.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
Il faut savoir que ce langage est un "add-on" à Lisaac qui est un langage objet à prototype, qui lui-même est maîtrisable en deux jours par un bon codeur en Java/C++/Eiffel.
Donc on garde la plupart du temps les spécificités d'un langage objet classique.
Après il faut savoir, que matériellement un agent est un thread, et que les clauses auxquels il réagit sont des bêtes et très basiques booléens.
Donc on pourra mettre des print un peu partout pour surveiller ce qui se passe.
Seul les clauses fonctionnent en temps réel, elle sont appelés régulièrement, ou plutôt testées régulièrement, c'est un peu comme si on écrivait un code où on créerait n thread pour n objets d'une collection qu'on activerait régulièrement pour tester des booléen et lancer des méthodes.
Je veux dire que ce que créera le compilateur, ça sera des thread qui testeront régulièrement des booléen, je vois pas trop de problèmes de debugging, surtout que je pense qu'il va falloir définir une constante de temps (j'ai pas mis toutes mes idées dans le texte et je suis accompagné d'un gardien vigilent quand à la rigueur nécessaire du modèle).
Après, plus tard, il me semble qu'il serait intéressant de mettre un petit moteur logique dans le compilateur pour vérifier qu'il y a cohérence.
Malgré tout, je pense qu'il va falloir attendre l'implémentation pour le savoir ;-)
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
J'en ai rien à f***. Il s'agit pour moi de trouver un boulot, j'estime que c'est plus important que de suivre une règle qu'en enfreignant je ne dérange personne.
Si je portais préjudice à qqun, là d'accord, ça me dérangerai.
Ma limite à moi est : tant que mon action ne dérange personne, je ne vois pas pourquoi je me generai.
Autrement dit : la liberté des uns s'arrête ou commence les autres.
Pour poursuivre l'examen philosophique, en trouvant un boulot, je couterai moins cher aux assedics, donc j'aide la société.
Je choisis quoi ? Suivre une règle stupide ou aider la société ?
Moi j'ai choisi.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
De quel compatibilité parles-tu ? Une compatibilité binaire, ie. faire tourner des binaires windows sous linux (possible) ou inversement (plus difficile, cygwin ?) ou le moins de problème quand à la cohabitation ?
Question cohabitation, si tu veux partager des favoris entre logiciel, ça risque d'être assez difficile, et ce même en mettant une partition en Fat32 pour de bons échanges.
Après sous windows, tu auras du mal à lire des partitions Linux.
Je ne crois pas que ce soit un problème de distrib, mais un problème de configuration et d'intégration entre les deux.
Pour un débutant, je conseille Mandriva/KDE, les autres sont trop complexes et spartiate à mon goûts, Ubuntu y compris...
Ah zut, je viens de lacher un troll..
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
1/ Création d'une licence globale de 7 (?) Euros pour télécharger légalement de la musique.
---> Si cette licence n'est pas payée et qu'on détecte un téléchargement de musique en P2P on utilise le système de riposte gradué de RDDV, un mail tout d'abord, un recommendé ensuite, puis des amendes.
Quand aux trafiquants, le tarif prévu par le ministre me semble une bonne chose.
De cette manière, on incite tout en se donnant un baton : l'internaute à le droit de télécharger, mais il doit payer la licence.
2/ Une organisation étatique indépendante (du gouvernement), munie d'un collège de dirigeants éligible une seule fois (comme à l'ARCEP) pour x années est chargée de collecter les fonds, d'évaluer à qui ils doivent être reversés.
---> Cette organisation diffuse des albums officiels sur les P2P, et grâce aux hash, détecte la popularité des téléchargement.
---> redistribu équitablement, modulo une fonction log pour lisser un peu et soutenir la création (comme le propose nicO) aux interprètes, producteurs, auteurs, etc...
de sorte à soutenir des petits labels indépendants, des petits studios, etc..
---> les frais de fonctionnement de l'organisation doivent, de par la loi, et sur surveillance de la Cour des Comptes, ne jamais dépasser 5 % des fonds perçus.
3/ Les FAI perçoivent la licence globale, en reversent x % (x> 90) à l'organisation étatique, et garde le 100-x pour financer la traque des internautes n'ayant pas payés la licence globales. Tout ceci sous la responsabilité de l'organisation conçue plus haut.
On peut aussi confier la traque à une entreprise privé, mais c'est ennuyeux question vie privé. Un FAI est cencé connaître votre adresse, numéro de compte, etc...
Voilà, qu'en pensez vous ?
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
Un album est réalisé par un/des artiste(s), auteurs, interprète, producteurs.
Le producteur paye l'administratif, l'ingé son, les musiciens addtionnels, etc.. c'est son boulot.
Une part des droits d'auteurs lui reviennent, avec la licence globale. L'autre part revient aux auteurs, interprète, etc...
C'est une structure très bien adaptée aux labels indépendants.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
D'après http://www.liberation.fr/page.php?Article=347971 , le CA de la vente de musique en France étant de 2 Milliards d'euros.
En considérant, à la louche, que 20 % du chiffre tombe dans les mains des créateurs, ce qui est un chiffre très optimiste, on tombe sur 400 millions d'euros.
Or 7.8.10^6.12 = 672 millions.
8 milions d'internautes, sur 12 mois.
Conclusion, le système suffit à rémunérer les artistes.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: C'est pas GNOME...
Posté par Ontologia (site web personnel) . En réponse au message firefox 1.5 et les fenetres "save as" et "open file". Évalué à 2.
Suis-je tout seul à avoir ce problème ?
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
# QQ idées
Posté par Ontologia (site web personnel) . En réponse au message bzip2-1.0.3-3mdk.i586.rpm. Évalué à 2.
2/ essaye avec l'option --no-verify-rpm
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: Pas tout compris
Posté par Ontologia (site web personnel) . En réponse au journal Le langage de mes rêves. Évalué à 3.
Ca m'intéresse qu'est ce qui ne te plait pas? que proposes-tu de mieux/différent?
C'est la syntaxe qui ne me plaît pas. je la trouve compliqué.
Certes on peut faire
c'est un sucre syntaxique qui ne me plait pas.
Mais c'est un débat très secondaire, je suis bien conscient de pinailler sur des détails.
Moi je veux un SQL objet, rien d'autre, je veux pouvoir y mettre des sous requêtes, des group by, etc...
De plus, SQL, tout le monde connaît.
C'est exactement ce que j'aurais à lui reprocher:
- avec un garbage collector certains te prétendent que tu n'as plus à penser à la mémoire, c'est faux! (c'est même plus difficile de contrôler sa mémoire avec un GC!). Il faut évidemment relativiser, peu d'application de nos jours sont réellement tracassée par leur mémoire...
Effectivement, dans certains cas particuliers un Gc peu poser des problèmes.
Fort bien.
Je peu paraître extrémiste, mais je pense qu'il faut en finir avec la gestion à la main de la mémoire, il faut en finir avec les pointeurs.
Il est certes jouissif pour certains de jouer avec, mais, dans le cadre d'un gros projet de plusieurs centaines de milliers de lignes, il faut en finir, c'est un facteur de bug beaucoup trop important.
Je pense d'autre part que c'est au compilateur de gérer finement la mémoire, car un être humain ne pourra jamais le faire aussi bien, en tout cas à partir d'une certaine taille. Demander à un humain de gérer les emplacements mémoire de chaque données, à la main, pour que celle-ci se trouve contigue en mémoire afin d'accélerer le cache est très vite beaucoup trop complexes.
J'ai d'autres exemples de ce style.
Comme tu le dit, la mémoire n'est plus un problème pour la plupart des applications.
Je dirai même que c'est le boulot de compilateur de gérer celle-ci correctement, après analyse de flot.
- avec la prog objet, certains vendent le fait que l'analyse compte (et vive UML et autre formalisme) et que l'implémentation est un détail... c'est à nouveau faux. (ça amène des design élégant, mais jamais implémenté, ou des design "génrique" ne proposant pas de solution concrète dans un cas pratique)
Je ne m'occupe pas de méthode design pour le moment. Je m'occupe de créer un (des, car d'autres suiveront) langage(s) permettant d'exprimer le mieux et le plus vite possible l'intuition du développeur, que celui-ci ne soit pas obligé de se plier à des circonlocutions typiquement informaticienne pour implémenter des concepts évident pour un être humain normalement constitué.
Si tu prend une bataille navale, le concept "un croiseur envoie un message à tous les croiseurs de son équipe, dans un rayon de 400km" devient très vite un bordel immonde (et encore c'est un exemple très simple.
Il te faut parcourir une collection, trier selon l'équipe (un test) si ce n'est pas déjà fait, vérifier le type, calculer le module des positions, et le cas échéant appeler une méthode que tu devra avoir pensé pour répondre à un problème très précis (genre "aidez moi, j'ai plus de fioul").
Ce genre de chose ça me gonfle.
C'est en devant programmer ce truc précis, lors d'un projet en formation, que les idées à la base de cette publi (il n'y pas tout d'ailleurs) me sont venues car j'en avai plus que marre d'écrire 1500 boucles, en java qui plus est, où tu dois récupérer et caster ce que contiennent tes vectors.
Bref. Avec une requête SQL, un foreach, et surtout le concept de messages conditionnels en multicast, c'est réglé en 5 lignes.
Après, après... Quand j'aurai le langage fonctionnel qui aura le mérite de commencer à me satisfaire (parce que je serai satisfait qua quand on balancera les spécifs à la machine et qu'il programmera pour nous, on y arrivera un jour qu'on le veuille ou non), là je penserai peut être à réfléchir (ou trouver des gens pour ça) aux méthodes de formalisations type UML adaptée à ce langage.
Mais tout d'abord il faut commencer par le compilateur.
- en C# tu peux déjà appeler un delegate de façon asynchrone, mais s'ils ont pensés au perf (pool de thread etc), tu as des cas explosifs (genre le delegate qui appelle des delegate etc...). Dans certains cas, ça passe par un message, à nouveau tu te retrouves parfois avec un appel bloqué qui attends des dizaines de messages avant de poursuivre!
D'après le peu que j'en ai compris, le delegate est
1/ un sous-concept de messages entre objet
2/ un bricolage conçu pour contourner les limites de l'objet à classe.
Lisaac est un langage objet à prototype.
Dans un objet que tu écris, tu définis le parent, comme une variable (dans la section INHERIT)
Comme tout est objet vivant, tu peu définir finement qui est ton parent, et tu peux même en changer à l'exécution quand tu le désir.
Donc pas besoin de delegate pour dérouter des messages vers des parents comme l'explique : http://csharpro.developpez.com/page10.php
Tu fait
- tu présentes un formalisme comme étant le truc qui permet de ne pas "avoir de problème" c'est vrai dans un monde théorique (et encore), un formalisme peut être vu comme un langage plus éloigné de la machine et plus proche de l'humain, cela ne le rend pas complet, correct, et surtout cela ne facilite pas forcément les choses. (pense à certains design pattern exprimé en qq mots, qq lignes de codes, et un schéma UML incompréhensible! Cependant, UML n'est pas le seul formalisme, il en existe sans doute de plus adapté selon le cas).
C'est effectivement le plus gros problème. C'est pour cela qu'il faut réfléchir au maximum à une abstraction qui nécessite le moins possible de comprendre ce sur quoi elle s'appuie (comme tcp s'appuie sur ip) pour s'assurer de la maîtriser correctement.
C'est un gros travail.
Ce que nous proposons dans cette publi n'est qu'un modèle et il n'est pas certains que l'implémentation en soit fidèle.
Je pense néanmoins que le fait chaque thread sera dans un monde clot au niveau des données facilitera pas mal les choses.
Après c'est à voir, je pense particulièrement à l'émergence qui est un phénomène structurel.
C'est là que les méthodes joueront leur rôles. Elle sont d'ors en conception dans des labos.
- Dans le même ordre d'idée, je ne pense pas que masqer l'existence de thread soit souhaitable, même le thread, qui est déjà une abstraction ne peut en général pas être utilisée tel quel, un développeur doit se demander comment se comporte son CPU (surtout sur un système multi-proc) s'il veut être efficace. Je ne doute pas de l'intéret d'une telle abstraction dans certains cas (je pense notemment au business rules engine), mais je me pose des questions sur la pertinence de mettre cela dans le langage même.
la pertinence de le mettre dans le langage même consiste à proposer l'absraction pour les "certains cas" dont tu parles.
Un type qui fait une GPAO, un ERP, a autre chose à faire que de se prendre la têtes avec des priorités dans des threads.
Après n'oublie pas que ce qui est proposé est extension du langage que ce soit bien clair ! :-)
Rien ne t'empêche de ne pas utiliser les agents (bref de programmer en objet classique), de gérer toi même tes threads à la main, etc...
Ce que l'on présente dans cette publi, c'est une fonctionnalitée suplémentaire ! Rien d'autres.
Ceux qui jugeront utile de l'utilser l'utiliseront, les autres non. Tu as le choix.
Concernant l'impact sur les performances, les thread ont un coût (dépendant de l'os et de la façon dont tu fais cela, par exemple, par défaut sous windows, chaque nouveau thread à un tas dédiés de 1Mo!), et encore plus si tu ne partages pas la mémoire, un deepcopy sera coûteux en temps et en mémoire!
Enfin ta recherche me semble de toute façon intéressante, je suis impatient de pouvoir tester les premières implémentation!
Pour le coût, on s'adaptera aux OS existants bien que la fnalité de ce langage est de tourner sur IsaacOS qui sera un OS temps réel à terme et intégralement objet.
Pour l'implémentation ça risque de prendre du temps, surtout si messieurs les chercheurs tardent à donner le poste que Benoit Sonntag mérite...
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: Pas tout compris
Posté par Ontologia (site web personnel) . En réponse au journal Le langage de mes rêves. Évalué à 2.
Je pense qu'il ya possibiité d'obtenir de bonnes perfs sur le système de requêtes en optimisant celle-ci d'une part (coupes dans l'arbre, compilation inline de l'algo de calcul de la requête) et d'autre part en réorganisant les données de tel façon qu'on puisse retrouver assez vite les données.
Dans un contexte ou tout est compilé (ie que des micro objets), on pourrait utiliser l'analyse de flot pour organiser des indexs prévus pour "coller" à la requête.
Quand au thread, je vois pas de problèmes de perfs.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: Pas tout compris
Posté par Ontologia (site web personnel) . En réponse au journal Le langage de mes rêves. Évalué à 2.
Premièrement, je ne me suis pas gêné pour le mettre, parce que j'y ai pensé tout seul (SQL est mon "langage" de prog préféré). J'ai découvert, à l'occasion d'unjournal de TImaniac que C#3 l'incluerait. Bien que ça ne me plaise pas dans la forme retenue.
Je veux SQL intégré dans le langage, car j'en ai plus que marre de passer mon temps à parcourir des collections pour tester tel ou tel critères.
Deuxièmement, c'est effectivement du sucre syntaxique qui nécessite une modification du compilo (c'est pour ça qu'on l'a mis), mais qui simplifie la vie. C'est ça qui compte.
Concernant l'aspect massivement multithread, je suis perplexe, j'ai l'impression que ça permettrait d'éviter la complexité syntaxique de ce genre de construction, mais j'ai un doute sur la simplication réelle, au contraire j'ai peur que cela rende un programme extrèmement complexe à comprendre. Quelle mécanismes existent-ils pour gérer les effets de bord? Dans tous les langages, c'est le problème, encore plus dans les langages objets (et leur idée de "remplacer un composant par un autre", pense par exemple à java et le fait que toute les méthodes soit virtuelles).
C'est déjà très complexe de faire un modèle objet single thread, gérer plus de 3 threads interdépendantes est vite un enfer... je n'oserais pas proposer à mon équipe de dev d'utiliser ce genre de chose, je vois déjà les cascades de threads créées sans même s'en rendre compte ;)
C'est en effet un énorme problème (comme le souligne "Joel on software" : http://french.joelonsoftware.com/Articles/LeakyAbstractions.(...) ).
Mais le modèle est justement conçu pour que tu n'ais pas à penser aux threads" TU devra penser en terme d'agent vivant, sur le qui vive, attendant des évènement extérieurs.
C'est dans l'émergence de comportements que tu risque effectivement d'avoir quelques problèmes, surtout si ton agent réagit directement à des évènements extérieur.
Mais grâce au système de message (message synchrone objet classiq ou message asynchrone du type boite au lettre (le point 3/)), tu pourras rendre tes agent un tant soi peu "cognitif", limiter leur réactivité, et ainsi avoir des comportements émergeants limités.
Il existe (la méthode VOYELLE par ex) des formalismes permettant de ne pas avoir de problème, il est certain qu'il sera nécessaire de bien les formaliser avant de lacher un tel langage dans l'industrie, mais je pense que si quelques règles de base sont bien appliquée, tu n'aura pas de problème car, comme je le répète plus haut :
1/ Les threads sont autonomes et travaillent sur des données qui ne se balladent pas entre threads : toutes les données échangées se feront par copie, de sorte qu'il n'y ai pas de conflit
2/ C'est le compilateur qui gère tous les monitors et autres problème de synchro. Pour le programmeur, il ya des processus indépendants qui s'envoient des messages.
Enfin, as-tu des données sur les perf de ce langage? Je me doute que c'est encore expérimental, mais est-ce théoriquement possible de faire quelque chose de compétitif? (à savoir: le classique trade-off entre temps de dev et hardware nécessaire)
Pour le moment le compilateur n'étant pas implémenté, on en sait rien.
Par contre, sache que lisaac (l'actuel) est certainement le langage objet le plus performant au monde, il va beaucoup plus loin qu'Eiffel dont il est un descendant (et en même temps un sur ensemble) :-)
voir : http://isaacos.loria.fr/li_speed.html
Je ne sais pas ce que ça donnera, mais connaissant Benoit Sonntag, je prévoit que ça ira très très vite... ;-)
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: Et le langage humain de mes rêves...
Posté par Ontologia (site web personnel) . En réponse au journal Le langage de mes rêves. Évalué à 2.
Il s'agit plus de flemme que de honte. J'adore les phrases denses et concises, sans doute parce que j'ai horreur de perdre mon temps.
Tapper m'ennuie, alors vive les préfixes et les suffixes. Après je vais peut être parfois trop loin...
- On passe progressivement d'une représentation des données à une description des données. Par exemple (simpliste) le champ "size" d'un objet "array" peut-être représenté par un entier (non distinguable des autres entiers), ou bien décrit comme étant la taille du tableau (et donc pas un entier quelconque). La description implique entre autres que le champ size a une influence sur le nombre d'itérations d'un parcours du tableau, sur la place qu'occupe ce tableau en mémoire, etc. Si l'on se contente de représenter les données sans les décrire, alors c'est au programmeur d'interpréter leur signification dans sa tête.
- Ça serait bien que ce passage de représentation à description ne soit pas limité aux données, mais soit aussi appliqué au traitement des données. Là j'avoue que j'ai du mal à trouver rapidement un exemple pertinent, mais j'ai l'impression que ça revient à dire: ça serait bien que l'on puisse programmer des design patterns. Pour l'instant on ne peut pas les programmer, ce sont des concepts que le programmeur doit adapter à sa situation, mais avec des langages de plus haut niveau, ça serait possible.
Imagine, que tu utilise dans ton programme une liste chainée de couple de réels
{(3.5,5.4),(8.4,8.6),...}.
Imaginons que dans toutes les manipulations que tu effectue dessus, il se trouve que tu respectes les axiomes d'espaces vectoriels (ie. dans ta tête lorsque tu programmes, ta liste chainée est une liste de vecteurs).
Tu additionne tes couples, tu utilises des matrices, etc...
Un "prépocesseur" détecte alors que ta liste chainée est une liste de vecteurs d'un espace vectoriel. Il te propose d'emblée tout un tas de fonctions, il vérifie que ton code ne contient pas d'erreurs mathématiques, etc...
Par exemple, si tu modélise des agents sur un terrain (de foot par exemple), et que tu décris ceux-ci par des vecteurs, tu auras automatiquement la possibilité de leur donner une direction en radian, en degré, et un module.
Si tu modélise un balon, il suffira de le définir comme objet physique doté d'une masse (le type OBJET_MASSIQUE) et il analysera le contexte d'utilisation de ton balon pour toi, te proposant calcul de trajectoire, etc...
C'est plutôt vers cette idée.
Programmer, c'est créer de toutes pièces une structure cohérente (Coherens "qui tien ensemble"). Un truc issu de ton cerveau que tu crée à partir de rien, à part les primitives offertes par ton langage.
Là, par reconnaissance de forme, l'environnement de dev détecte les objets que tu veux décrire et t'assiste en t'offrant des structures toutes faites.
On aura une réprésentation standard du concept de client, d'entreprise, d'employé, de pièce, etc... Avec à chaque fois des propriétés et des contraintes.
C'est entre "écrire de la lib" et "concevoir un moteur de reconnaissance de forme".
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: Pas tout compris
Posté par Ontologia (site web personnel) . En réponse au journal Le langage de mes rêves. Évalué à 3.
1/ Possibilité d'écrire des applications multithreadées assez facilement. Du fait que Lisaac reste un langage objet, on pourra utiliser les fonctionalités agent au minimum : par exemple, les clauses de déclanchement de comportement ne seront activés que pour la réception de messages (voir 3/).
Tu n'as plus à te préoccuper de mutex et autres monitors
2/ L'intégration d'un SQL/Objet dans le langage qui devient en passant persistant. Imagine que lors du développement d'une GPAO, tu as besoin d'écrire une fonction "réapro" te renvoyant l'ensemble des pièces que l'on doit racheter (le seuil de quantité minimal dans le stock a été enfoncé).
Là le compilateur, te vérifie le typage, gère la BDD pour toi (on architecturera la chose de sorte que l'on puisse interfacer tout SGBD avec)
Les requêtes peuvent se faire sur des objets ou des agents présent en mémoire : tu n'as plus à parcourir des collections afin de récupérer les infos que tu y veux.
Avec un tel système, en faisant un select bien sentie, tu peux sélectionner une liste de thread (des agents) correspondant à des critères précis, récupérer la liste de ceux-ci et leur envoyer un message.
Par exemple dans un logiciel de son multipiste, tu veux couper toutes les pistes utilisant l'effet phaser.
Tu généralise ton code :
C'est un exemple trop simple pour que cela soit vraiment intéressant, mais imagine des requêtes beaucoup plus complexes, où le fait de programmer la requêtes à la main en faisant une boucle listant une collection (ce qui suppose de prévoir les bonnes méthodes public te renvoyant les informations voulues, te facilitant la tâche, etc... ) n'est plus utile.
Tu peux gagner un temps fou !
3/ Les messages asynchrones seront fortement implantés dans le langage. Tu pourras envoyer des messages particulier, attendre un reply, demander la liste historique des messages de tel objet ou tel agent, etc...
Dans le modèle, les primitives présentés suffisent à permettre de définir, dans la librairie, un service de messages très complet.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: ça fonctionne
Posté par Ontologia (site web personnel) . En réponse au message dumper le flux des Jt (de TF1). Évalué à 2.
Moi j'ai fait ça :
Le script wcat
#/bin/sh
wget -q -O - $1
Le script eRadio :
#!/bin/sh
echo 'Nom du fichier cible : '$1-`date | awk '{print $1"-"$3"-"$2"-"$6}'`.rm
echo adresse source $2
echo ligne de commande :
echo mplayer -nosound -noframedrop -dumpfile /home/montaigne/Documents/Emissions/$1-`date | awk '{print $1"-"$3"-"$2"-"$6}'`.rm -dumpstream $2
mplayer -nosound -noframedrop -dumpfile /home/montaigne/Documents/Emissions/$1-`date | awk '{print $1"-"$3"-"$2"-"$6}'`.rm -dumpstream $2
Quand à chercher l'adresse, en général, il faut chercher les asf, asx, mms, .rm, rpm, rtsp . Tu finis pas trouver
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: C'est interressant, mais...
Posté par Ontologia (site web personnel) . En réponse au journal Le langage de mes rêves. Évalué à 2.
En effet le compilateur compilera le code de sorte que chaque thread gère un espace mémoire étanche : Toutes les données seront transmises en copie (via le deepclone), et le respect des priorités sera automatiquement "géré" par le compilateur.
Après, un interpréteur ne ferai pas de mal.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: C'est interressant, mais...
Posté par Ontologia (site web personnel) . En réponse au journal Le langage de mes rêves. Évalué à 4.
Avec une constante de temps divisé par 1000 ou 10000 on pourrait surement simuler du temps réel, même sous linux et windows.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: C'est pas mal du tout ton truc. Mais j'ai un gros doute...
Posté par Ontologia (site web personnel) . En réponse au journal Le langage de mes rêves. Évalué à 2.
donc un processus est assimilable à un (auto)bus transportant des informations entre objets ?
D'après ce que je sais, c'est à dire par grand chose, tout se fait en VFT.
Pour le futur j'en sais rien, je réfléchi pas trop au bas niveau d'Isaac, c'est pas ma compétence.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: C'est pas mal du tout ton truc. Mais j'ai un gros doute...
Posté par Ontologia (site web personnel) . En réponse au journal Le langage de mes rêves. Évalué à 3.
Sache seulement, qu'a priori, puisqu'il ne s'agit que d'un modèle, ce langage est essentiellement conçu pour tourner sur IsaacOS, et que le destin d'IsaacOS est d'être un système temps réel. C'est aussi un OS où la notion de processus n'existe pas, un processus n'est que l'association à l'instant T d'objets travaillant ensembles.
Donc imagine que le système peut donner la main à n'importe quel thread n'importe quand.
Pour le reste, il faut que j'y réfléchisse.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: Et la marmotte...
Posté par Ontologia (site web personnel) . En réponse au journal Le langage de mes rêves. Évalué à -1.
Ah oui ! J'oublie que dans notre société les rôles s'inversent !
Bon je -> []
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: Un exemple...
Posté par Ontologia (site web personnel) . En réponse au journal Le langage de mes rêves. Évalué à 3.
section HEADER
+ name := HELLO_WORLD;
- category := MACRO;
section INHERIT
- parent_object:OBJECT := OBJECT;
section PUBLIC
- make <-
(
"Hello world !\n".print;
);
Je le répète, ce modèle n'est pas un nouveau langage c'est un ajout de primitives aux compilateurs. :-)
Tu peux parfaitement utiliser Lisaac en tant que langage objet classique.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: C'est interressant, mais...
Posté par Ontologia (site web personnel) . En réponse au journal Le langage de mes rêves. Évalué à 4.
Il faut savoir que ce langage est un "add-on" à Lisaac qui est un langage objet à prototype, qui lui-même est maîtrisable en deux jours par un bon codeur en Java/C++/Eiffel.
Donc on garde la plupart du temps les spécificités d'un langage objet classique.
Après il faut savoir, que matériellement un agent est un thread, et que les clauses auxquels il réagit sont des bêtes et très basiques booléens.
Donc on pourra mettre des print un peu partout pour surveiller ce qui se passe.
Seul les clauses fonctionnent en temps réel, elle sont appelés régulièrement, ou plutôt testées régulièrement, c'est un peu comme si on écrivait un code où on créerait n thread pour n objets d'une collection qu'on activerait régulièrement pour tester des booléen et lancer des méthodes.
Je veux dire que ce que créera le compilateur, ça sera des thread qui testeront régulièrement des booléen, je vois pas trop de problèmes de debugging, surtout que je pense qu'il va falloir définir une constante de temps (j'ai pas mis toutes mes idées dans le texte et je suis accompagné d'un gardien vigilent quand à la rigueur nécessaire du modèle).
Après, plus tard, il me semble qu'il serait intéressant de mettre un petit moteur logique dans le compilateur pour vérifier qu'il y a cohérence.
Malgré tout, je pense qu'il va falloir attendre l'implémentation pour le savoir ;-)
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: chinois
Posté par Ontologia (site web personnel) . En réponse au journal Rassurez vous ça marche sous windows !. Évalué à -3.
Euh, bon ok... Je --> []
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
# Karma
Posté par Ontologia (site web personnel) . En réponse au message Journal public. Évalué à 3.
Et supérieur à 1, pour poster un journal privé.
J'invite les éventuels responsables qui lirait ce post à le spécifier dans la page de soumission d'un journal.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: swi-prolog
Posté par Ontologia (site web personnel) . En réponse au message Swi-prolog et gprolog. Évalué à 2.
Existe t-il un interpréteur, un vrai, un tout simple ? J'ai pas besoin d'une usine à gaz pour tester ce langage avec emacs et compagnie...
On a l'impression que les interpréteurs n'existent plus de nos jours.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: C'est pas joli-joli
Posté par Ontologia (site web personnel) . En réponse au message Aspirer un site avec plein de JavaScript. Évalué à 0.
Si je portais préjudice à qqun, là d'accord, ça me dérangerai.
Ma limite à moi est : tant que mon action ne dérange personne, je ne vois pas pourquoi je me generai.
Autrement dit : la liberté des uns s'arrête ou commence les autres.
Pour poursuivre l'examen philosophique, en trouvant un boulot, je couterai moins cher aux assedics, donc j'aide la société.
Je choisis quoi ? Suivre une règle stupide ou aider la société ?
Moi j'ai choisi.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
# Quel compatibilité ?
Posté par Ontologia (site web personnel) . En réponse au message Quelle distribution choisir pour la meilleur cohabitation windows/linux ??. Évalué à 1.
Question cohabitation, si tu veux partager des favoris entre logiciel, ça risque d'être assez difficile, et ce même en mettant une partition en Fat32 pour de bons échanges.
Après sous windows, tu auras du mal à lire des partitions Linux.
Je ne crois pas que ce soit un problème de distrib, mais un problème de configuration et d'intégration entre les deux.
Pour un débutant, je conseille Mandriva/KDE, les autres sont trop complexes et spartiate à mon goûts, Ubuntu y compris...
Ah zut, je viens de lacher un troll..
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
# En synthèse...
Posté par Ontologia (site web personnel) . En réponse au journal [DADVSI]Une solution à proposer aux députés ?. Évalué à 2.
1/ Création d'une licence globale de 7 (?) Euros pour télécharger légalement de la musique.
---> Si cette licence n'est pas payée et qu'on détecte un téléchargement de musique en P2P on utilise le système de riposte gradué de RDDV, un mail tout d'abord, un recommendé ensuite, puis des amendes.
Quand aux trafiquants, le tarif prévu par le ministre me semble une bonne chose.
De cette manière, on incite tout en se donnant un baton : l'internaute à le droit de télécharger, mais il doit payer la licence.
2/ Une organisation étatique indépendante (du gouvernement), munie d'un collège de dirigeants éligible une seule fois (comme à l'ARCEP) pour x années est chargée de collecter les fonds, d'évaluer à qui ils doivent être reversés.
---> Cette organisation diffuse des albums officiels sur les P2P, et grâce aux hash, détecte la popularité des téléchargement.
---> redistribu équitablement, modulo une fonction log pour lisser un peu et soutenir la création (comme le propose nicO) aux interprètes, producteurs, auteurs, etc...
de sorte à soutenir des petits labels indépendants, des petits studios, etc..
---> les frais de fonctionnement de l'organisation doivent, de par la loi, et sur surveillance de la Cour des Comptes, ne jamais dépasser 5 % des fonds perçus.
3/ Les FAI perçoivent la licence globale, en reversent x % (x> 90) à l'organisation étatique, et garde le 100-x pour financer la traque des internautes n'ayant pas payés la licence globales. Tout ceci sous la responsabilité de l'organisation conçue plus haut.
On peut aussi confier la traque à une entreprise privé, mais c'est ennuyeux question vie privé. Un FAI est cencé connaître votre adresse, numéro de compte, etc...
Voilà, qu'en pensez vous ?
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: Prix Hard Discount ?
Posté par Ontologia (site web personnel) . En réponse au journal [DADVSI]Une solution à proposer aux députés ?. Évalué à 2.
Un album est réalisé par un/des artiste(s), auteurs, interprète, producteurs.
Le producteur paye l'administratif, l'ingé son, les musiciens addtionnels, etc.. c'est son boulot.
Une part des droits d'auteurs lui reviennent, avec la licence globale. L'autre part revient aux auteurs, interprète, etc...
C'est une structure très bien adaptée aux labels indépendants.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: Prix Hard Discount ?
Posté par Ontologia (site web personnel) . En réponse au journal [DADVSI]Une solution à proposer aux députés ?. Évalué à 3.
En considérant, à la louche, que 20 % du chiffre tombe dans les mains des créateurs, ce qui est un chiffre très optimiste, on tombe sur 400 millions d'euros.
Or 7.8.10^6.12 = 672 millions.
8 milions d'internautes, sur 12 mois.
Conclusion, le système suffit à rémunérer les artistes.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: /var/www/html
Posté par Ontologia (site web personnel) . En réponse au message page d'aceuille "its works". Évalué à 2.
chown permet de changer d'user, chgrp de froupe, chmod d'attributs.
Tu peux prendre aussi la bonne habitude de lire la doc sur ce site :
http://lea-linux.org/cached/index/Admin-index.html
et pour le cas qui nous intéresse :
http://lea-linux.org/cached/index/Admin-admin_env-permission(...)
Lea-linux est pas désagréable à lire, contraîrement au man...
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: Processus ?
Posté par Ontologia (site web personnel) . En réponse au journal Les mandriva serait-elle espionnées par Mandriva ?. Évalué à 5.
USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
root 1 0.0 0.1 1564 536 ? S 14:31 0:01 init [5]
root 2 0.0 0.0 0 0 ? SN 14:31 0:00 [ksoftirqd/0]
root 3 0.0 0.0 0 0 ? S< 14:31 0:00 [events/0]
root 4 0.0 0.0 0 0 ? S< 14:31 0:00 [khelper]
root 5 0.0 0.0 0 0 ? S< 14:31 0:00 [kthread]
root 7 0.0 0.0 0 0 ? S< 14:31 0:00 [kacpid]
root 75 0.0 0.0 0 0 ? S< 14:31 0:00 [kblockd/0]
root 107 0.0 0.0 0 0 ? S 14:31 0:00 [pdflush]
root 108 0.0 0.0 0 0 ? S 14:31 0:04 [pdflush]
root 110 0.0 0.0 0 0 ? S< 14:31 0:00 [aio/0]
root 109 0.0 0.0 0 0 ? S 14:31 0:00 [kswapd0]
root 699 0.0 0.0 0 0 ? S 14:31 0:00 [kseriod]
root 786 0.0 0.0 0 0 ? S< 14:31 0:00 [reiserfs/0]
root 918 0.0 0.0 1560 500 ? S<s 14:31 0:00 udevd -d
root 1109 0.0 0.0 0 0 ? S 14:31 0:00 [khubd]
root 1426 0.0 0.0 0 0 ? S 14:31 0:00 [scsi_eh_0]
root 1428 0.0 0.0 0 0 ? S 14:31 0:00 [usb-storage]
root 2405 0.0 0.1 1584 524 ? Ss 14:31 0:00 /sbin/ifplugd -b -i eth0
rpc 2496 0.0 0.1 1684 584 ? Ss 14:31 0:00 portmap
root 2520 0.0 0.1 1732 644 ? Ss 14:31 0:03 syslogd -m 0
root 2528 0.0 0.2 2452 1332 ? Ss 14:31 0:00 klogd -2
root 2580 0.0 0.1 1684 600 ? Ss 14:31 0:00 /usr/sbin/acpid
root 2626 0.0 0.1 1692 728 ? Ss 14:31 0:00 rpc.statd
root 2746 0.0 0.5 5800 2724 ? Ss 14:31 0:00 cupsd
root 2914 0.0 0.0 0 0 ? S 14:31 0:00 [kgameportd]
xfs 3113 0.0 0.4 4288 2512 ? Ss 14:32 0:00 xfs -port -1 -daemon -droppriv -user xfs
70 3138 0.0 0.2 2224 1200 ? Ss 14:32 0:00 dbus-daemon-1 --system
root 3163 0.0 0.5 4136 2688 ? Ss 14:32 0:16 hald
root 3358 0.0 0.1 2736 744 ? S 14:32 0:00 /usr/bin/kdm -nodaemon
root 3359 0.0 0.1 2796 672 ? Ss 14:32 0:01 nifd -n
root 3400 2.1 10.1 56512 52292 tty7 SLs+ 14:32 7:51 /etc/X11/X -deferglyphs 16 :0 -auth /var/run/xauth/A:0-Zl1R
root 3417 0.0 0.3 3556 1600 ? S 14:32 0:00 -:0
nobody 3475 0.0 0.2 11416 1132 ? Ssl 14:32 0:00 mDNSResponder
daemon 3518 0.0 0.1 1808 608 ? Ss 14:32 0:00 /usr/sbin/atd
ntp 3587 0.0 0.7 4032 4032 ? SLs 14:32 0:00 ntpd -A -u ntp:ntp
root 3627 0.0 0.1 2140 852 ? Ss 14:32 0:00 xinetd -stayalive -reuse -pidfile /var/run/xinetd.pid
clamav 3728 0.0 0.2 4456 1412 ? Ss 14:32 0:00 /usr/bin/freshclam --config-file=/etc/freshclam.conf --quie
501 3788 0.0 0.2 2996 1476 ? Ss 14:32 0:00 /bin/sh /usr/bin/startkde
root 3814 0.0 0.5 5516 2612 ? Ss 14:32 0:00 proftpd: (accepting connections)
501 3910 0.0 0.1 2588 744 ? S 14:32 0:00 /usr/bin/dbus-launch --exit-with-session --auto-syntax
501 3911 0.0 0.1 2132 876 ? Ss 14:32 0:00 dbus-daemon-1 --fork --print-pid 8 --print-address 6 --sess
501 3949 0.0 3.1 22920 16440 ? S 14:32 0:14 /usr/bin/perl /usr/bin/net_applet
501 3970 0.0 0.5 6388 2700 ? Ss 14:32 0:00 s2u --daemon=yes
root 4020 0.0 1.1 8184 5988 ? Ss 14:32 0:00 /usr/bin/perl /usr/share/webmin/miniserv.pl /etc/webmin/min
root 4054 0.0 0.6 8708 3224 ? Ss 14:32 0:00 smbd -D
root 4062 0.0 0.6 8892 3304 ? S 14:32 0:00 smbd -D
501 4069 0.0 0.2 2988 1464 ? S 14:32 0:00 /bin/sh /usr/bin/startkde
501 4073 0.0 1.3 17508 6736 ? S 14:32 0:00 gnome-volume-manager
root 4079 0.0 0.4 6176 2096 ? Ss 14:32 0:00 nmbd -D
501 4166 0.0 0.7 5520 3900 ? S 14:32 0:00 /usr/lib/gconfd-2 13
501 4167 0.0 1.6 23036 8756 ? Ss 14:32 0:00 kdeinit Running...
501 4195 0.0 1.6 22468 8412 ? S 14:32 0:00 dcopserver [kdeinit] --nosid
root 4204 0.0 0.0 1544 440 tty1 Ss+ 14:32 0:00 /sbin/mingetty tty1
root 4205 0.0 0.0 1548 444 tty2 Ss+ 14:32 0:00 /sbin/mingetty tty2
root 4206 0.0 0.0 1544 436 tty3 Ss+ 14:32 0:00 /sbin/mingetty tty3
root 4207 0.0 0.0 1548 444 tty4 Ss+ 14:32 0:00 /sbin/mingetty tty4
root 4208 0.0 0.0 1548 444 tty5 Ss+ 14:32 0:00 /sbin/mingetty tty5
root 4209 0.0 0.0 1544 436 tty6 Ss+ 14:32 0:00 /sbin/mingetty tty6
501 4224 0.0 1.9 24720 9912 ? S 14:32 0:00 klauncher [kdeinit]
501 4273 0.0 2.8 28356 14920 ? S 14:32 0:03 kded [kdeinit]
501 4275 0.0 0.2 2596 1392 ? S 14:32 0:03 /usr/lib/gam_server
501 4281 0.0 2.2 24772 11816 ? S 14:32 0:00 kaccess [kdeinit]
501 4289 0.0 1.5 29736 8124 ? S 14:32 0:01 /usr/bin/artsd -F 9 -S 4096 -d -s 1 -m artsmessage -c drkon
501 4292 0.0 0.0 1540 340 ? S 14:32 0:00 kwrapper ksmserver
501 4295 0.0 2.2 24412 11456 ? S 14:32 0:00 ksmserver [kdeinit]
501 4299 0.0 3.0 27412 15508 ? S 14:32 0:06 kwin [kdeinit] -session 117f0000010001093898165000000291500
501 4306 0.0 3.1 30916 16120 ? S 14:32 0:02 knotify [kdeinit]
501 4317 0.0 3.2 28404 16532 ? S 14:32 0:06 kdesktop [kdeinit]
501 4330 0.0 0.1 2544 844 ? S 14:32 0:00 xsettings-kde
501 4333 0.1 3.6 30640 18976 ? S 14:32 0:43 kicker [kdeinit]
501 4334 0.0 1.8 23580 9648 ? S 14:32 0:00 kio_file [kdeinit] file /home/montaigne/tmp/ksocket-montaig
501 4345 0.0 3.1 28052 16104 ? S 14:32 0:02 konsole [kdeinit] -session 117f0000010001105998851000000425
501 4358 0.0 3.2 28612 16736 ? S 14:32 0:06 konsole [kdeinit] -session 117f0000010001117214254000000450
501 4359 0.0 2.9 37228 15132 ? Sl 14:32 0:02 nautilus --sm-config-prefix /nautilus-hpoPa4/ --sm-client-i
501 4362 0.0 4.7 37968 24472 ? S 14:32 0:06 konqueror [kdeinit] -session 1014cd7d2d40001135760380000000
501 4363 0.0 2.7 27212 14288 ? S 14:32 0:01 korgac --miniicon korganizer
501 4368 0.0 0.5 5436 2908 ? Ss 14:32 0:00 /usr/lib/bonobo-activation-server --ac-activate --ior-outpu
501 4369 0.0 3.1 26872 16324 ? S 14:32 0:04 kjots -session 1014cd7d2d4000113456508500000041930011_11359
501 4370 0.1 3.0 28260 15556 ? S 14:32 0:26 /usr/bin/gaim --session 1014cd7d2d4000113568948300000042930
501 4371 0.0 3.5 32916 18452 ? S 14:32 0:01 konqueror [kdeinit] --preload
501 4375 0.0 1.8 24328 9660 ? S 14:32 0:00 kalarmd
501 4380 0.0 0.7 9188 3780 ? Sl 14:32 0:00 /usr/lib/gnome-vfs-daemon --oaf-activate-iid=OAFIID:GNOME_V
501 4394 0.0 0.3 3272 1932 pts/1 Ss+ 14:33 0:00 /bin/bash
501 4396 0.0 0.3 3280 1952 pts/2 Ss+ 14:33 0:00 /bin/bash
501 4398 0.0 0.3 3268 1944 pts/3 Ss+ 14:33 0:00 /bin/bash
501 4408 0.0 0.3 3268 1932 pts/4 Ss+ 14:33 0:00 /bin/bash
501 4412 0.0 0.3 3268 1932 pts/5 Ss+ 14:33 0:00 /bin/bash
501 4424 0.0 0.1 2120 704 ? S 14:33 0:00 /usr/lib/mapping-daemon
501 4426 0.0 0.3 3276 1952 pts/6 Ss 14:33 0:00 /bin/bash
501 4436 0.0 0.3 3276 1936 pts/7 Ss+ 14:33 0:00 /bin/bash
501 4440 0.0 0.3 3276 1932 pts/8 Ss+ 14:33 0:00 /bin/bash
501 4472 0.0 0.3 3268 1932 pts/9 Ss+ 14:33 0:00 /bin/bash
501 4474 0.0 0.3 3272 1936 pts/10 Ss+ 14:33 0:00 /bin/bash
501 4504 0.0 0.3 3272 1932 pts/11 Ss+ 14:33 0:00 /bin/bash
501 4508 0.0 0.3 3268 1944 pts/12 Ss+ 14:33 0:00 /bin/bash
501 4530 0.0 0.3 3280 1944 pts/13 Ss 14:33 0:00 /bin/bash
501 4574 0.0 0.3 3272 1932 pts/14 Ss+ 14:33 0:00 /bin/bash
501 4638 0.0 0.3 3276 1936 pts/15 Ss+ 14:33 0:00 /bin/bash
501 5048 0.0 0.2 2492 1220 ? S 15:41 0:00 /bin/sh /home/montaigne/Softs/firefox/firefox
501 5051 0.0 0.2 3044 1516 ? S 15:41 0:00 /bin/sh /home/montaigne/Softs/firefox/run-mozilla.sh /home/
501 5056 10.4 12.2 142688 62936 ? Sl 15:41 31:44 /home/montaigne/Softs/firefox/firefox-bin
501 5153 2.9 4.7 29992 24408 ? S 16:33 7:30 /usr/bin/perl /usr/sbin/net_monitor
501 8138 0.0 0.2 2476 1172 ? S 17:46 0:00 /bin/sh /usr/local/RealPlayer/realplay /home/montaigne/Docu
501 8143 0.2 2.6 56540 13520 ? Sl 17:46 0:31 /usr/local/RealPlayer/realplay.bin /home/montaigne/Document
501 8145 0.0 1.3 22204 7136 ? S 17:46 0:00 /usr/local/RealPlayer/realplay.bin /home/montaigne/Document
501 8146 0.0 1.3 22204 7136 ? S 17:46 0:00 /usr/local/RealPlayer/realplay.bin /home/montaigne/Document
501 10576 0.0 0.2 2308 1088 pts/6 S+ 18:26 0:00 bc
root 14844 0.0 0.2 2572 1212 pts/13 S 19:40 0:00 su
root 14849 0.0 0.5 3736 2592 pts/13 S 19:40 0:00 bash
root 16602 0.0 0.1 2592 828 pts/13 R+ 20:45 0:00 ps aux
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker