Indiques-moi ce que tu trouves confus sur la page http://wiki.evenja.org/doc/versus/dataflow ou mieux, comme c'est un wiki tu peux t'inscrire et apporter des améliorations.
Pour la différence, après plusieurs discussion avec des Geeks, j'ai compris où ce situe l'incompréhension, en faite à plusieurs endroit, que je vais éclaircir pendant ces prochains mois, juste pour la fin du concours. Ainsi chacun aura sa chance ;)
Participe au concours et tu peux gagner, il y a trois pris.
Le tableau "What the work ?" c'est la liste des opérations à faire… sans logique précise. Pas de logique mais l'une des 7 tâches de la page Principles du Wiki, http://wiki.evenja.org/principles/start . Ceci juste pour savoir quelle objet Evenja va être utilisé : EvenDoor, EvenBoard ou EvenPrg.
… le numéro d'appel et on démarre l'horodatage ?
Oui, cela fait partie de l'Event qui arrive dans la EvenDoor(PABX).
Pourquoi dans EvenPrgs, il n'y a que Task convert (D2-D1) et non pas convert (serial number) et convert (start timestamp) ?
Par ce que "convert" est la seul vrai opérations de travail selon le tableau "What the work ?". D2-D1, c'est ni du merge, ni du split… alors convert, il s'agit d'une conversion de donnée.
Et il n'y a que cela parce qu'il n'y a pas besoin d'ajouter autre chose (sauf erreur), je vais afficher ces détails dans quelques temps (pas mal de conférence actuellement).
Merci pour ta vrai questions.
Seulement comme je l'explique sur la page du wiki.evenja.org
Plus il y a d'entrées et sorties différentes, plus la différence avec la programmation classique est visible. Avec une entrée et une ville à choisir, c'est aussi facile que en programmation classique, mais cela va paraître plus difficile à comprendre sans tenir compte des avantages comme ajouts de fonctions sans bugs ou ralentissement.
C'est vraiment plus simple puisque le graphisme c'est exactement ce que va faire Evenja (sans aucune modification).
Si tu trouve plus simple, réponds ici-mêmes, je suis preneur.
Nous sommes en train de préparer le "Use case" d'un petit serveur web, si quelqu'un à des propositiosn avant que je fasse le "Use case" et donc directement le progamme, n'hésitez pas. ;)
Oui, j'ai répondu et je suis sûre quand le concours sera terminé tu comprendras aussi. C'est la raison du concours.
Cas 1: donnée qui se 'ressemble', peux-tu préciser ?
La donnée c'est un container EvenData. Ce container EvenData contient par exemple [Prénom, Adresse, Ville] comme informations. On décide que pour une fonctions la valeur de [Ville] est le LIEN. Quand un autre objet EvenData arrive sur le EvenBoard, le EvenBoard regarde s'il y a une linkValue déjà existante. Si c'est le cas, il insert l'une dans l'autre et envoie (sans aucun décision) vers le nœud suivant (SANS CODE SPECIFIQUE A CE CHOIX).
Cas 2: Un chat qui décide.
J'ai corrigé juste après. Le chat ne décide pas avant de rentrer dans la chambre il avait une suite de truc a faire et il continue (comme certains Dataflow). Seulement comme le EvenBoard crée un "merge" ne dépendant plus des fonctions de l'applications c'est pas du dataflow.
Normalement et sauf exceptions TRES RARE, le EvenBoard ne doit pas changer de fonctionnement.
C'est pas « pas parfait », c'est juste pas compréhensible…
Je te remercie, c'est la raison du concours
Et concernant les "félidées zombies" (que je réutiliserais), comme le dit l'expression, j'ai pas mieux. Quand je prend un exemple informatique déjà existant, c'est très difficile de changer de logique au milieu de l'explication. Les gens veulent continuer dans ce qu'ils connaissent, par expérience. Alors je donne un autre exemple plus "chat" et … les pauvres chat deviennent zombies… c'est la raison du concours
bah c'est déterministe et les variables sont fixées
et
tes données, elles doivent choisir ou elles vont ensuite, non ? Ça veut dire qu'elles doivent connaître les différents bidules ou elles peuvent aller ?
Oui est non, les variables sont déterminées, mais le mélange ou "merge" des variables n'est déterminé par aucun processus. C'est le contenu lui-même de la variable qui produit la suite, pas un processus (suite de commande) qui prend la décision selon une analyse datant peux-être d'une ancienne version du programme.
Ou en Bayesian, c'est le contenu lui-même de la variable qui produit le prochain segment, en fonction de la réalité de présence d'autre donnée et de leur contenu… existant ou pas.
Parce que c'est pas du tout une logique que nous utilisons tout les jours.
Et les gens ne comprennent que depuis une année, avant ils disaient juste que c'était IMPOSSIBLE :D
Maintenant qu'il y a les Tutos… c'est je comprend pas expliques-toi ?
Mais comme c'est une autre logique… c'est difficile d'expliquer en Anglais la langue Français, surtout ses subtilités.
Perso, quand je comprend pas un truc, je cherche comprendre et je menace pas l'auteur d'incompétence si je comprend pas.
Ceux qui comprennent comme hier soir au Hackerspace de Lausanne, FIXME, ne sont pas encore complétement dans une compréhension suffisante pour l'expliquer à d'autres ou l'utiliser.
Ayant mis au point de manière empirique pendant 6 ans le système, j'ai quand même mi trois mois à vraiment être capable de reproduire l'effet et j'ai eu pas mal de maux de têtes.
Et pourtant j'ai simplement refait le raisonnement initial avec le "Chat de Schrödinger", en tenant compte de bien mesurer les risques de chaque logique intégrée dans le projet.
Pour le cas où le chat ne trouve pas son "copain" ayant la même "link value", c'est pas une décision de chat de rester ;) C'est avant de rentré dans la room à "t-2", qu'il avait une seul suite d'idée.
Il ne fait que sa suite logique, seul la rencontre REEL à un MOMENT, a un ENDROIT avec une certaine LINK VALUE avec un autre chat (donnée) crée la suite… pas un processus prédéfini "une année" avant l'arrivé de la donnée.
Fait presque le même travail. Mais le problème avec cette manière de faire, c'est que plus l'arbre est grand plus c'est lourd à gérer. Avec Evenja, comme seul la réalité compte il n'y a que l'eefctif qui est pri en compte… donc pas de lourdeur et de traitement inutile.
Que sont ces nœuds ? Quelles différences ?
Pour chaque nœud, décris à quoi il sert… J'ai regardé ton wiki, mais ça m'éclaire vraiment pas du tout.
Je pense qu'il faut lire la doc, mêmes si c'est pas parfait…
Dans un réseau bayésien, il y a la notion de probabilités… Peux-tu m'expliquer en quoi ton système va au delà du DAG, et utilise des probabilités ? Il me semble tout ce qu'il y a de plus déterministe…
Et pour le rapport avec du quantique ?
Justement, le calcul de probabilité et "remplacé" dans Evenja par la réalité (chat vivant ou mort) et pas par une logique spécifique au programme. Ceci ce passe dans les EvenBoard, qui intègre le processus standard des logiciel merge
C'est en utilisant ma compréhension du quantique que j'y arrive,
//Ceci est une explication pas l'exactitude quantique// : Dans le cadre du chat de Schrödinger, il y a une personne qui a un moment donné ouvre la boîte.
On pourrait le traduire en "français" par : Dans la ligne du temps à un moment t on cherche à définir l'état de vie d'un chat, état réellement existant, mais sans le savoir à t-1.
Maintenant on reviens au code, en programmation "normal" quand on a deux objets que l'on souhaite "merger", on contrôle par un processus prédefini avant, en fonction de l'endroit dans le programme, des données que cela concernent, si on peu faire cette opération de "fusion". Cela complique énormément tout les codes et surtout rend les évolutions de logiciel difficile.
Avec Evenja, si on reprend l'onde quantique et sa réduction du paquet d'onde et que l'on admet que ce n'est plus quelqu'un qui "ouvre la boite", mais une autre donnée (un autre chat ;)… on obtiens en "français" :
Une donnée (une chat) arrive dans un système (une room en Evenja), elle vas dans une direction que celle elle connaît (le chat et ses idées;). Dans le cadre du "logiciel" c'est comme une onde, le processus de l'application n'ayant pas connaissance de vers où va le chat ;). La donnée arrive dans la room vers un EvenBoard… Et là seul deux cas sont possible :
- Il y a un autre chat (donnée) qui lui ressemble (link value des EvenData). Ils partent ensemble vers la suite comme une nouvelle donnée unique ou un chat ou une nouvelle onde vers on ne sait où… seul les chats ont l'info ;)
- Il n'y a pas un autre chat. Il (le chat) continue ou décide d'attendre un moment.
Je sais, c'est pas à 100% de la réduction du paquet d'onde OFFICIEL, mais c'est l'idée d'origine.
La donnée sait ou elle va, mais est stupide (comme un paquet de la poste), le processus ou application ne connaît pas la prochaine destination "super asynchrone" :D mais le facteur livre le paquet quand même, sans savoir ce que va en faire le prochain facteur ;)
Je crois pas, j'ai utilisé cette approche pour développer seul un logiciel. Logiciel qui a été utilisé par plusieurs centaines de personnes sur différent site : EZCOM.
Ce logiciel concurrençait 5 sociétés différentes, chacune avec son produit propre. Mais j'avais cette outil Evenja (précisément la version précédente en script et compilo perso) et j'y suis arrivé.
A l'origine j'ai "suivi" la logique du "chat de Schrödinger" pour faire de manière empirique que cela fonctionne… puis six ans après, après avoir fini les cinq fonctions du serveur, il m'a fallu trois mois pour réalisé le pourquoi et le comment du fonctionnement et des avantages.
Mon raisonnement est toujours associé (même collé) au "chat de Schrödinger".
Et en plus si tu regarde bien (ça risque de troller;) c'est une approche différente dans le sens où au lieu d'avoir un ou des processus qui gère la donnée (processus centrique) et souvent en mode synchrone, c'est 100% orienté autour de la donnée (data centrique) et asynchrone.
C'est pour cela que j'ai organisé le concours.
Le bon point : les discussion autour me permette de trouver des arguments compréhensible par plus de monde, les versus ajouter sur le wiki. J'espère qu'ils sont plus clair.
Effectivement dans un EvenPrg, on peux faire les deux soit fixer la prochaine destination (des vieille habitude qui persiste;) ou demander à l'EvenData la "destination" suivante et faire livré.
Dans ce cas de démonstration, c'est fixe dans le code, mais normalement c'est un paramètre dans le fichier XML qui est passé la l'EvenPrg. Ainsi chaque fonctions dans exactement le même code envoie selon les besoins à la destination appropriée.
C'est bien cela le problème, les gens comprennent, mais nous avons tellement l'habitude de faire autrement que c'est pas si facile de changer.
Après six ans d'utilisation de cette approche, j'ai mi trois mois avec des maux de têtes ;)
Pour comprendre profondément son fonctionnement et ses avantages.
A la différence suivante il n'y a que trois type de nœud : Evendoor, EvenBoard et EvenPrg.
Concernant le nœud, j'ai amélioré la page Principles du Wiki.
Concernant le pipe, il y une différence dans la class EvenBoard, ce n'est pas cette class ou un héritage de celle-ci qui décide de manière programmée le futur "pipe" à prendre pour choisir un nœud. C'est le contenu de la donnée elle-mêmes qui décide. Si tu veux comparer à du dataflow.
Pour moi, les pipes sont des liens fixe et synchrone (souvent) entre deux processus, en Evenja les liens entres les nœuds ne sont pas fixe et asynchrone, et non pas absé sur une analyse complète d'un logiciel. Mais dynamique en fonction d'un USE CASE de la donnée et selon le contenu de la donnée elle-même.
Pour le réseau Bayesian, il y a une page sur le wiki et une présentation sur le site.
Pour les dessins, si tu pouvais le faire et je corrige… Register wiki.
Un code bien conçu, dans n'importe quel paradigme ? Auquel cas il sera modulaire, donc l'ajout d'une fonction qui n'a rien a voir sera faite dans son module indépendant, éliminant d'éventuels effets de bord ?
On devrait y répondre toujours OUI.
Mais dans le processus de fabrication d'un programme, il y a l'analyse : selon le dico Examen méthodique permettant de distinguer les différentes parties d'un problème et de définir leurs rapports.
Quelqu'un va définir une structure logiciel et tout ce qui est nécessaire pour que le programme exécute les tâches qu'on lui demande. ET normalement tout vas bien.
Malheureusement dans la vie réel, au bout d'un moment, les besoins et tâches du logiciel change… c'est à ce moment que l'on recommence l'analyse (qui normalement aurai du être parfaite ;)
La première structure ou une partie, devient source de bug et de complication, alors on sort la version 2.0.
Et cela recommence. Dans la vie réel d'un programmeur, les clients demandes de choses qui peux-être (voir sûrement) n'avais pas été prévue… est c'est très souvent le cas.
Sinon les bugs n'existerais plus depuis longtemps ;)
J'arrive à refaire complètement le Kernel en C++11 Template, et c'est ce que je fait maintenant.
Cette approche est tellement simple pour moi et depuis tellement de temps que j'arrive pas à "transformer" cette connaissance de manière simple et clair pour les autres en fonctionnement actuel.
Dans le cas des modules, tu faits comment pour que tes deux modules fonctionne "en même temps" sans gérer le multi-threading des modules.
Selon la technique des modules, il y a souvent des problèmes si un des modules pose problèmes, de fiabilité. Les autres modules se retrouvent avec des difficultés pour travaillé normalement.
En plus, je crois pas (sauf erreur) qu'avec des modules tu ne peux pas faire TOUTES LES APPLICATIONS possible, cela fait longtemps que cette technique aurait été utilisée, non ?
Après je crois que c'est la notion de souscription à des services qui est apparue. Mais au bout d'un moment tu as des problèmes de temps de réponses, s'il y a trop d'inscrit au même service :)
MERCI
ça fait du bien de voir que des gens essai de faire avancer le schmilblick.
Tu as 100% raison sur tout.
Si tu regarde comment le "board" fonctionne, tu verras que la manière de lier les données est différente à d'autres logique, comme les Agents ou le Dataflow, par exemple. Et la suite du processus pour les donnée dépend 'elle-même et pas "d'un bout de code de décision".
Et c'est, je trouve, cette autre manière qui est très très intéressante.
[^] # Re: Du coup…
Posté par Fabian J. Padilla . En réponse à la dépêche Concours "Evenja Café", un nouveau paradigme de programmation. Évalué à -6.
Oui, exactement ça.
Le numéro de l'appelant est dans les données. Pour cette fonctions on décide que c'est la LinkValue entre les événements.
Si on regardes en détails… on ne mesure que du temps pour les statistiques alors toutes les autres informations qui vont dans la base de donnée sont celle qui viennent du PABX ;)
http://wiki.evenja.org/doc/usecase/hotline?&#what_we_will_produce
[^] # Re: Du coup…
Posté par Fabian J. Padilla . En réponse à la dépêche Concours "Evenja Café", un nouveau paradigme de programmation. Évalué à -6.
C'est pas très cool comme remarque, comme je l'ai indiqué sur http://wiki.evenja.org/doc/usecase/start#important , plus il y a de ports en entrée et en sortie… plus la différence est visible.
Indiques-moi ce que tu trouves confus sur la page http://wiki.evenja.org/doc/versus/dataflow ou mieux, comme c'est un wiki tu peux t'inscrire et apporter des améliorations.
Pour la différence, après plusieurs discussion avec des Geeks, j'ai compris où ce situe l'incompréhension, en faite à plusieurs endroit, que je vais éclaircir pendant ces prochains mois, juste pour la fin du concours. Ainsi chacun aura sa chance ;)
Participe au concours et tu peux gagner, il y a trois pris.
[^] # Re: Du coup…
Posté par Fabian J. Padilla . En réponse à la dépêche Concours "Evenja Café", un nouveau paradigme de programmation. Évalué à -5.
Merci pour le "Hotline".
Le tableau "What the work ?" c'est la liste des opérations à faire… sans logique précise. Pas de logique mais l'une des 7 tâches de la page Principles du Wiki, http://wiki.evenja.org/principles/start . Ceci juste pour savoir quelle objet Evenja va être utilisé : EvenDoor, EvenBoard ou EvenPrg.
Oui, cela fait partie de l'Event qui arrive dans la EvenDoor(PABX).
http://wiki.evenja.org/principles/start et aussi dans la doc.
Par ce que "convert" est la seul vrai opérations de travail selon le tableau "What the work ?". D2-D1, c'est ni du merge, ni du split… alors convert, il s'agit d'une conversion de donnée.
Et il n'y a que cela parce qu'il n'y a pas besoin d'ajouter autre chose (sauf erreur), je vais afficher ces détails dans quelques temps (pas mal de conférence actuellement).
Viens sur le http://wiki.evenja.org et chat avec nous sur xmpp:evenja@chat.evenja.org .
[^] # Re: Du coup…
Posté par Fabian J. Padilla . En réponse à la dépêche Concours "Evenja Café", un nouveau paradigme de programmation. Évalué à -6.
Merci pour ta vrai questions.
Seulement comme je l'explique sur la page du wiki.evenja.org
Plus il y a d'entrées et sorties différentes, plus la différence avec la programmation classique est visible. Avec une entrée et une ville à choisir, c'est aussi facile que en programmation classique, mais cela va paraître plus difficile à comprendre sans tenir compte des avantages comme ajouts de fonctions sans bugs ou ralentissement.
Nous avons avancer les "Use cases", par exemple, le Use case de "Hotline" est fini
http://wiki.evenja.org/doc/usecase/hotline
C'est vraiment plus simple puisque le graphisme c'est exactement ce que va faire Evenja (sans aucune modification).
Si tu trouve plus simple, réponds ici-mêmes, je suis preneur.
Nous sommes en train de préparer le "Use case" d'un petit serveur web, si quelqu'un à des propositiosn avant que je fasse le "Use case" et donc directement le progamme, n'hésitez pas. ;)
Nous préparons pour la semaine prochaine (on fait d'autres choses à côté), le "Use case" en Evenja d'un système de transactions "garantie".
http://www.uml-diagrams.org/examples/spring-hibernate-transaction-sequence-diagram-example.html
Avec "Transactions" comme il y a ce diagramme "classique", la différence sera très visible.
[^] # Re: Du coup…
Posté par Fabian J. Padilla . En réponse à la dépêche Concours "Evenja Café", un nouveau paradigme de programmation. Évalué à -5.
1 process = une tâche
Tout les logiciels du monde ne font que 7 tâches DIFFERENTES !
[^] # Re: Du coup…
Posté par Fabian J. Padilla . En réponse à la dépêche Concours "Evenja Café", un nouveau paradigme de programmation. Évalué à -7.
Oui, j'ai répondu et je suis sûre quand le concours sera terminé tu comprendras aussi. C'est la raison du concours.
La donnée c'est un container EvenData. Ce container EvenData contient par exemple [Prénom, Adresse, Ville] comme informations. On décide que pour une fonctions la valeur de [Ville] est le LIEN. Quand un autre objet EvenData arrive sur le EvenBoard, le EvenBoard regarde s'il y a une linkValue déjà existante. Si c'est le cas, il insert l'une dans l'autre et envoie (sans aucun décision) vers le nœud suivant (SANS CODE SPECIFIQUE A CE CHOIX).
J'ai corrigé juste après. Le chat ne décide pas avant de rentrer dans la chambre il avait une suite de truc a faire et il continue (comme certains Dataflow). Seulement comme le EvenBoard crée un "merge" ne dépendant plus des fonctions de l'applications c'est pas du dataflow.
Normalement et sauf exceptions TRES RARE, le EvenBoard ne doit pas changer de fonctionnement.
[^] # Re: Du coup…
Posté par Fabian J. Padilla . En réponse à la dépêche Concours "Evenja Café", un nouveau paradigme de programmation. Évalué à -7.
Je te remercie, c'est la raison du concours
Et concernant les "félidées zombies" (que je réutiliserais), comme le dit l'expression, j'ai pas mieux. Quand je prend un exemple informatique déjà existant, c'est très difficile de changer de logique au milieu de l'explication. Les gens veulent continuer dans ce qu'ils connaissent, par expérience. Alors je donne un autre exemple plus "chat" et … les pauvres chat deviennent zombies… c'est la raison du concours
et
Oui est non, les variables sont déterminées, mais le mélange ou "merge" des variables n'est déterminé par aucun processus. C'est le contenu lui-même de la variable qui produit la suite, pas un processus (suite de commande) qui prend la décision selon une analyse datant peux-être d'une ancienne version du programme.
Ou en Bayesian, c'est le contenu lui-même de la variable qui produit le prochain segment, en fonction de la réalité de présence d'autre donnée et de leur contenu… existant ou pas.
[^] # Re: Mailing list : hackerspace FixMe
Posté par Fabian J. Padilla . En réponse à la dépêche Concours "Evenja Café", un nouveau paradigme de programmation. Évalué à -6.
Parce que c'est pas du tout une logique que nous utilisons tout les jours.
Et les gens ne comprennent que depuis une année, avant ils disaient juste que c'était IMPOSSIBLE :D
Maintenant qu'il y a les Tutos… c'est je comprend pas expliques-toi ?
Mais comme c'est une autre logique… c'est difficile d'expliquer en Anglais la langue Français, surtout ses subtilités.
Perso, quand je comprend pas un truc, je cherche comprendre et je menace pas l'auteur d'incompétence si je comprend pas.
Ceux qui comprennent comme hier soir au Hackerspace de Lausanne, FIXME, ne sont pas encore complétement dans une compréhension suffisante pour l'expliquer à d'autres ou l'utiliser.
Ayant mis au point de manière empirique pendant 6 ans le système, j'ai quand même mi trois mois à vraiment être capable de reproduire l'effet et j'ai eu pas mal de maux de têtes.
Et pourtant j'ai simplement refait le raisonnement initial avec le "Chat de Schrödinger", en tenant compte de bien mesurer les risques de chaque logique intégrée dans le projet.
[^] # Re: Du coup…
Posté par Fabian J. Padilla . En réponse à la dépêche Concours "Evenja Café", un nouveau paradigme de programmation. Évalué à -4.
Petit correctif de chat :
Pour le cas où le chat ne trouve pas son "copain" ayant la même "link value", c'est pas une décision de chat de rester ;)
C'est avant de rentré dans la room à "t-2", qu'il avait une seul suite d'idée.
Il ne fait que sa suite logique, seul la rencontre REEL à un MOMENT, a un ENDROIT avec une certaine LINK VALUE avec un autre chat (donnée) crée la suite… pas un processus prédéfini "une année" avant l'arrivé de la donnée.
[^] # Re: Conférence
Posté par Fabian J. Padilla . En réponse à la dépêche Concours "Evenja Café", un nouveau paradigme de programmation. Évalué à -4.
Oui, la technique de
Fait presque le même travail. Mais le problème avec cette manière de faire, c'est que plus l'arbre est grand plus c'est lourd à gérer. Avec Evenja, comme seul la réalité compte il n'y a que l'eefctif qui est pri en compte… donc pas de lourdeur et de traitement inutile.
J'ai expliquer à ma manière ma version du chat de Schrödinger.
[^] # Re: Du coup…
Posté par Fabian J. Padilla . En réponse à la dépêche Concours "Evenja Café", un nouveau paradigme de programmation. Évalué à -5.
Je pense qu'il faut lire la doc, mêmes si c'est pas parfait…
Justement, le calcul de probabilité et "remplacé" dans Evenja par la réalité (chat vivant ou mort) et pas par une logique spécifique au programme. Ceci ce passe dans les EvenBoard, qui intègre le processus standard des logiciel merge
C'est en utilisant ma compréhension du quantique que j'y arrive,
//Ceci est une explication pas l'exactitude quantique// : Dans le cadre du chat de Schrödinger, il y a une personne qui a un moment donné ouvre la boîte.
On pourrait le traduire en "français" par : Dans la ligne du temps à un moment t on cherche à définir l'état de vie d'un chat, état réellement existant, mais sans le savoir à t-1.
Maintenant on reviens au code, en programmation "normal" quand on a deux objets que l'on souhaite "merger", on contrôle par un processus prédefini avant, en fonction de l'endroit dans le programme, des données que cela concernent, si on peu faire cette opération de "fusion". Cela complique énormément tout les codes et surtout rend les évolutions de logiciel difficile.
Avec Evenja, si on reprend l'onde quantique et sa réduction du paquet d'onde et que l'on admet que ce n'est plus quelqu'un qui "ouvre la boite", mais une autre donnée (un autre chat ;)… on obtiens en "français" :
Une donnée (une chat) arrive dans un système (une room en Evenja), elle vas dans une direction que celle elle connaît (le chat et ses idées;). Dans le cadre du "logiciel" c'est comme une onde, le processus de l'application n'ayant pas connaissance de vers où va le chat ;). La donnée arrive dans la room vers un EvenBoard… Et là seul deux cas sont possible :
- Il y a un autre chat (donnée) qui lui ressemble (link value des EvenData). Ils partent ensemble vers la suite comme une nouvelle donnée unique ou un chat ou une nouvelle onde vers on ne sait où… seul les chats ont l'info ;)
- Il n'y a pas un autre chat. Il (le chat) continue ou décide d'attendre un moment.
Je sais, c'est pas à 100% de la réduction du paquet d'onde OFFICIEL, mais c'est l'idée d'origine.
La donnée sait ou elle va, mais est stupide (comme un paquet de la poste), le processus ou application ne connaît pas la prochaine destination "super asynchrone" :D mais le facteur livre le paquet quand même, sans savoir ce que va en faire le prochain facteur ;)
Pour le wiki, ton statut viens de changer :)
[^] # Re: Brace yourselves, bullshit is ENDED
Posté par Fabian J. Padilla . En réponse à la dépêche Concours "Evenja Café", un nouveau paradigme de programmation. Évalué à -4.
Je crois pas, j'ai utilisé cette approche pour développer seul un logiciel. Logiciel qui a été utilisé par plusieurs centaines de personnes sur différent site : EZCOM.
Ce logiciel concurrençait 5 sociétés différentes, chacune avec son produit propre. Mais j'avais cette outil Evenja (précisément la version précédente en script et compilo perso) et j'y suis arrivé.
A l'origine j'ai "suivi" la logique du "chat de Schrödinger" pour faire de manière empirique que cela fonctionne… puis six ans après, après avoir fini les cinq fonctions du serveur, il m'a fallu trois mois pour réalisé le pourquoi et le comment du fonctionnement et des avantages.
Mon raisonnement est toujours associé (même collé) au "chat de Schrödinger".
Et en plus si tu regarde bien (ça risque de troller;) c'est une approche différente dans le sens où au lieu d'avoir un ou des processus qui gère la donnée (processus centrique) et souvent en mode synchrone, c'est 100% orienté autour de la donnée (data centrique) et asynchrone.
C'est pour cela que j'ai organisé le concours.
Le bon point : les discussion autour me permette de trouver des arguments compréhensible par plus de monde, les versus ajouter sur le wiki. J'espère qu'ils sont plus clair.
[^] # Re: Mailing list : hackerspace FixMe
Posté par Fabian J. Padilla . En réponse à la dépêche Concours "Evenja Café", un nouveau paradigme de programmation. Évalué à -7.
Je sais pas si "le monde entier" c'est les mots justes.
Si j'arrive à partager cette outil avec quelques Geek (non troll ;) c'est déjà pas mal.
Le concours a ce but aussi.
Dans ma petite entreprise, nous sommes 6 à travailler autour de ce projet (pas tous à 100% :).
[^] # Re: Brace yourselves, bullshit is ENDED
Posté par Fabian J. Padilla . En réponse à la dépêche Concours "Evenja Café", un nouveau paradigme de programmation. Évalué à 1.
Effectivement dans un EvenPrg, on peux faire les deux soit fixer la prochaine destination (des vieille habitude qui persiste;) ou demander à l'EvenData la "destination" suivante et faire livré.
Dans ce cas de démonstration, c'est fixe dans le code, mais normalement c'est un paramètre dans le fichier XML qui est passé la l'EvenPrg. Ainsi chaque fonctions dans exactement le même code envoie selon les besoins à la destination appropriée.
Si cela peux t'aidé, j'ai amélioré la page Principles du Wiki.
N'oublie pas le concours.
[^] # Re: Mailing list : hackerspace FixMe
Posté par Fabian J. Padilla . En réponse à la dépêche Concours "Evenja Café", un nouveau paradigme de programmation. Évalué à -2.
C'est bien cela le problème, les gens comprennent, mais nous avons tellement l'habitude de faire autrement que c'est pas si facile de changer.
Après six ans d'utilisation de cette approche, j'ai mi trois mois avec des maux de têtes ;)
Pour comprendre profondément son fonctionnement et ses avantages.
[^] # Re: Du coup…
Posté par Fabian J. Padilla . En réponse à la dépêche Concours "Evenja Café", un nouveau paradigme de programmation. Évalué à -1.
Oui pour :
A la différence suivante il n'y a que trois type de nœud : Evendoor, EvenBoard et EvenPrg.
Concernant le nœud, j'ai amélioré la page Principles du Wiki.
Concernant le pipe, il y une différence dans la class EvenBoard, ce n'est pas cette class ou un héritage de celle-ci qui décide de manière programmée le futur "pipe" à prendre pour choisir un nœud. C'est le contenu de la donnée elle-mêmes qui décide. Si tu veux comparer à du dataflow.
Pour moi, les pipes sont des liens fixe et synchrone (souvent) entre deux processus, en Evenja les liens entres les nœuds ne sont pas fixe et asynchrone, et non pas absé sur une analyse complète d'un logiciel. Mais dynamique en fonction d'un USE CASE de la donnée et selon le contenu de la donnée elle-même.
Pour le réseau Bayesian, il y a une page sur le wiki et une présentation sur le site.
Pour les dessins, si tu pouvais le faire et je corrige… Register wiki.
[^] # Re: Brace yourselves, bullshit is coming.
Posté par Fabian J. Padilla . En réponse à la dépêche Concours "Evenja Café", un nouveau paradigme de programmation. Évalué à -4. Dernière modification le 08 janvier 2014 à 23:05.
.
[^] # Re: Brace yourselves, bullshit is coming.
Posté par Fabian J. Padilla . En réponse à la dépêche Concours "Evenja Café", un nouveau paradigme de programmation. Évalué à -2.
Oui, normalement et en théorie, ce que tu écris :
Mais dans le processus de fabrication d'un programme, il y a l'analyse : selon le dico
Examen méthodique permettant de distinguer les différentes parties d'un problème et de définir leurs rapports.
Quelqu'un va définir une structure logiciel et tout ce qui est nécessaire pour que le programme exécute les tâches qu'on lui demande. ET normalement tout vas bien.
Malheureusement dans la vie réel, au bout d'un moment, les besoins et tâches du logiciel change… c'est à ce moment que l'on recommence l'analyse (qui normalement aurai du être parfaite ;)
La première structure ou une partie, devient source de bug et de complication, alors on sort la version 2.0.
Et cela recommence. Dans la vie réel d'un programmeur, les clients demandes de choses qui peux-être (voir sûrement) n'avais pas été prévue… est c'est très souvent le cas.
Sinon les bugs n'existerais plus depuis longtemps ;)
[^] # Re: Brace yourselves, bullshit is ENDED
Posté par Fabian J. Padilla . En réponse à la dépêche Concours "Evenja Café", un nouveau paradigme de programmation. Évalué à -1.
J'arrive à refaire complètement le Kernel en C++11 Template, et c'est ce que je fait maintenant.
Cette approche est tellement simple pour moi et depuis tellement de temps que j'arrive pas à "transformer" cette connaissance de manière simple et clair pour les autres en fonctionnement actuel.
C'est pour cela que j'organise le concours .
Je trouve que Ontologia et jigso s'en sorte très bien.
J'ai fait un doc Downloads documentation, et des présentations.
[^] # Re: Brace yourselves, bullshit is coming.
Posté par Fabian J. Padilla . En réponse à la dépêche Concours "Evenja Café", un nouveau paradigme de programmation. Évalué à 2.
Pour moi le lien fonctionne j'arrive bien sur http://wiki.evenja.org .
Sur la partie gauche (la sidebar), il y a un menu "Versus" et au dessous :
◾ Object Oriented Programming
◾ Dataflow
◾ Bayesian network
◾ Lustre
Merci de confirmer que tout est OK ?
[^] # Re: Brace yourselves, bullshit is coming.
Posté par Fabian J. Padilla . En réponse à la dépêche Concours "Evenja Café", un nouveau paradigme de programmation. Évalué à -3.
Dans le cas des modules, tu faits comment pour que tes deux modules fonctionne "en même temps" sans gérer le multi-threading des modules.
Selon la technique des modules, il y a souvent des problèmes si un des modules pose problèmes, de fiabilité. Les autres modules se retrouvent avec des difficultés pour travaillé normalement.
En plus, je crois pas (sauf erreur) qu'avec des modules tu ne peux pas faire TOUTES LES APPLICATIONS possible, cela fait longtemps que cette technique aurait été utilisée, non ?
Après je crois que c'est la notion de souscription à des services qui est apparue. Mais au bout d'un moment tu as des problèmes de temps de réponses, s'il y a trop d'inscrit au même service :)
[^] # Re: Brace yourselves, bullshit is coming.
Posté par Fabian J. Padilla . En réponse à la dépêche Concours "Evenja Café", un nouveau paradigme de programmation. Évalué à -4.
Merci pour le segfault, après plusieurs sde download, j'ai pas eu de retour sur le forum.evenja.org ;(
[^] # Re: Brace yourselves, bullshit is coming.
Posté par Fabian J. Padilla . En réponse à la dépêche Concours "Evenja Café", un nouveau paradigme de programmation. Évalué à -3.
Cela fait des années que je cherche un truc similaire pour m'éviter de refaire le kernel… pas trouvé.
J'ai mi quelques "versus" sur wiki.evenja.org .
Te gênes pas pour posé des questions concrète sur la logique et pas sur la meilleur manière d'utilisé "static" en C++;
[^] # Re: Brace yourselves, bullshit is ENDED
Posté par Fabian J. Padilla . En réponse à la dépêche Concours "Evenja Café", un nouveau paradigme de programmation. Évalué à 1.
MERCI
ça fait du bien de voir que des gens essai de faire avancer le schmilblick.
Tu as 100% raison sur tout.
Si tu regarde comment le "board" fonctionne, tu verras que la manière de lier les données est différente à d'autres logique, comme les Agents ou le Dataflow, par exemple. Et la suite du processus pour les donnée dépend 'elle-même et pas "d'un bout de code de décision".
Et c'est, je trouve, cette autre manière qui est très très intéressante.
T'es la bien venu au concours ;)
[^] # Re: J'ai bon ?
Posté par Fabian J. Padilla . En réponse à la dépêche Concours "Evenja Café", un nouveau paradigme de programmation. Évalué à -2.
oui tu as bom