TImaniac a écrit 6420 commentaires

Il y a beaucoup de cas comme ça.
Vi vi je suis d'accord, cependant quid de l'intégration avec tout ce qui touche à l'accélération 3D, les shaders, les décodeurs H264 toussa ?
Non parcque de manière générale, notamment pour les jeux, dès qu'un truc est consommateur de calcul, ce travail est délégué à un composant dédié à ce type de traitement.
Le CPU reste la solution de secours "générique".

Tu définis ton objet en tant que parallelisable, et chaque appel non bloquant (ie, ne retournant pas de valeurs) est exécuté en parallèle. Le compilateur te garanti la gestion des synchronize, qui est transparente pour toi.
Tu peux montrer un exemple, ca semble intéressant.

Par contre tu peux facilement mettre dans un module toute la partie calcul, qui bénéficiera de l'optimisation globale
Effectivement, mais faudra toujours faire un compromis entre séparation/module et recherche des perfs.

Enfin, l'objectif est de fournir un langage de haut niveau pour la programmation paralèlle sans souçi
Ca me paraît important ça effectivement. Lisaac apporte quoi pour la programmation parallèle ?
L'algo d'optimisation global cherche-t-il par exemple à paralléliser ce qui peut l'être ? Quels sont les outils à la disposition du programmeur pour guider le compilo dans ce travail ? Quels avantages/apports par rapport à l'existant ?

Pour la mémoire, il est vrai que la consommation est importante, mais quand on regarde une compilation de source Lisaac, on se rend compte que GCC consomme autant de mémoire
Bon bah c'est cool, c'est que ca a bougé depuis les dernières stats que t'avais donné (qui faisaient peur).

Pour les modules qui fouttent en l'air l'optimisation globale, c'est vrai. Mais il n'y a pas de solution miracle.
D'où ma question : partant de ce constat, l'optimisation globale est-elle vraiment pertinente au regard du coût qu'elle engendre ? (notamment temps de compilation et mémoire utilisée pendant la compilation)

* Le lisaac dispose d'un gestionnaire de mémoire
Je sais très bien que Lisaac propose la gestion mémoire. Je critiquais seulement l'absence de gestion des modules et de la configuration.
Ces autres qualités que tu décris sont très bien, mais il manque des choses beaucoup plus basiques, c'est ca que je voulais rappeler.

déconnexion d'un agent, erreur d'un agent, coupure réseaux, refus de traiter une demande, etc... on peut en avoir plein.
Autant de situation complexe qu'il faut effectivement les gérer. Des situations qui deviennent courantes dans les architectures complexes et distribuées... qui font qu'elles ne sont plus exceptionnelles et ne sont donc pas gérées par les exceptions. La gestion de ce type d'erreur doit faire pleinement parti des fonctionnalités du logiciel.

Donc oui, la gestion des erreurs devra être **relativement** efficace. Les exceptions sont pour l'instant suffisantes, rien n'empêche d'essayer de trouver autre chose pour le future.
Soit les erreurs sont gérés par le code "métier", et dans ce cas elles ne sont pas gérés par les exceptions qui doivent être réservées aux comportements exceptionnels et non prévu. Donc non, leur efficacité n'est pas la priorité (même si c'est toujours mieux).

Dès que t'as une erreur, tu passes dans un état chargé de traiter l'erreur.
Oué rien à voir avec un comportement exceptionnel donc.
Enfin se pose toujours le problème de la séquentialité : dans certains cas il n'est pas du tout envisageable de continuer l'exécution du programme là où il était rendu (il peut être continué par ailleur sans doute), tu proposes quoi si tu ne veux pas de rupture dans la séquentialité ?

Vous voulez tout faire mieux que tout le monde, et au final y'a rien d'utilisable qui sort. C'est dommage, y'a peut être des concepts intéressant dans Lisaac, mais inexploitable en l'état à toujours vouloir repousser les limites de l'état de l'art.
Quand Ontologia avait commencé à parler de Lisaac, il avait mis en avant les perfs liées aux optimisations globales faites par le compilateur. Pourquoi ne pas partir de cet apport pour essayer de faire un langage"quasi-industriel" ? Ne serais-ce que pour valider que c'est utilisable au quotidien l'optimisation globale. C'est justement là que ca devient intéressant : faire en sorte que ce soit utile pour tout le monde.

C'est bien pour la transparence, mais pour la sécurité ? Déjà qu'il est relativement facile de voir ce que fait un patch et que je vois toujours pas l'intérêt qu'il y a à cacher ce genre de corrections, c'est où le problème niveau sécurité pour l'utilisateur final que le patch corrige plus de faille qu'il n'y en a de connu ?

Les exceptions te cassent la séquentialité, le while non.
Bah oué, en même temps c'est leur objectif : le programme fait face à une situation exceptionnelle et non prévue, et il ne sait pas quoi faire : il lève une exception et casse la séquentialité plutôt que de continuer comme si de rien n'était au risque de faire des conneries.
Ca vaut ce que ca vaut, mais ca me paraît acceptable. T'as un meilleur comportement face à une telle situation ?

Parceque tu parles de débat, mais tu ne le fais pas plus avancé que mon collègue ou moi...
Oué mais moi je viens pas poster un journal pour dire "oué nous on va inventer (c'est même pas on va chercher, non, on va inventer) un truc ouachement mieux parcque l'existant il est pourri". Alors pas la peine de renvoyer la balle, je pensais que vous aviez quelque chose d'intéressant à apporter. Je sais pas, peut être élaborer sur ce qui se cache derrière l'utilisation d'un jeu de règles ?

peut en fait être remplacé par "arrête de saouler, on cherche".
Ben j'ai envie de dire, arrêtez de nous saouler avec Lisaac tant que vous avez rien à dire à part nous informer que votre réunion de l'été dernier c'était cool.

Tu vois, on cherche, pour faire quelque chose de mieux.
L'objectif est louable, c'est d'ailleur assez excitant. M'enfin vous avez pas l'air de savoir ce que vous chercher effectivement à résoudre comme problème. Tu dis : les exceptions c'est mal, ca casse la séquentialité. Ok admettons, mais alors commencez par définir à quels critères doit coller un système de gestion idéal des erreurs. Bref, définissez l'objectif. De ce que je dois en déduire, un des critères c'est que les ce système idéal ne doit pas casser la séquentialité. Je propose de discuter de ce critère (cf début de mon post), ca me paraît intéressant.

Tu peux pas demander à 1 personne de faire les choses comme 200 ingénieurs d'une multinationale qui a plus de moyen que la recherche publique française...
Je suis bien d'accord. C'est pourquoi cela me paraît d'autant plus prétentieux que d'annoncer "nous on fait mieux qu'eux" alors que la comparaison est totalement faussée vu que vous faites abstraction de la plupart des contraintes auxquelles doivent faire face les langages "industriels".

Oh oui, les exceptions sont extrêmement consommatrice de ressource, c'est bien connu... c'est vrai qu'un jump, ça doit mettre ton processeur à genoux...
Peut être que c'est pas qu'un jump (GOTO) ?
Faut-il le rappeler, mais les exceptions sont censés être rares et être levées que dans des situations exceptionnelles ? Les perfomances sont-elles donc le critère primordial pour définir un gestionnaire d'erreur ?

De plus, la gestion d'erreur n'est PAS élémentaire. Les modules ne sont PAS non plus élémentaires.
Je dis pas que leurs conception/implémentation est élémentaire, je dis que ce sont des fonctionnalités élémentaires des langages modernes, des fonctions indispensables pour qu'un langage soit utilisable de nos jours. Comme la gestion mémoire, la sécurité, etc. Faire l'impasse dessus lors de la conception d'un langage amène à Lisaac : on se focalise sur les perfs en oubliant le reste, et on se congratule en regardant des benchs. Après on constate qu'il manque des trucs "élémentaires" pour en faire un vrai langage qui puisse espérer sortir d'un labo. On commence par se rassurer en disant : c'est normal, ca répond à un marché de niche (comprendre les utilisateurs qui n'ont pas besoins des choses élémentaires et uniquement des perfs). Ensuite on se dit que la gestion des erreurs c'est pas si mal, même dans l'embarqué, que la modularité c'est pas si mal dès qu'on travaille en équipe, et là on s'apercoit que les perfs "pures" c'est gentil mais ca sert à rien tout seul et que peut être qu'il aurait fallu y penser dès le départ.

on va bientôt refaire les shootout benchmark. tu verras par toi même.
Les shootout c'est pas la vrai vie, les shootouts se focalisent uniquement sur les perfs et pas sur les autres choses "élémentaires" qui font qu'un langage est de qualité.

Sinon, t'as déjà codé en Lisaac ?
Quand y'aura tous les trucs de base, oué pourquoi pas.

Pour les exceptions : c'est des GOTOS, et les GOTOS, c'est mal
Pour moi les exceptions offrent une sémantique beaucoup plus riche que les gotos, ont un usage beaucoup plus spécialisé, et n'ont au final pas grand chose à voir avec. Nan parcque sinon si on va par là, une boucle while, c'est un GOTO conditionnel non ?

Après il est vrai que la gestion des erreurs fait parti des défis...
C'est pour ca qu'il me semble intéressant d'en discuter. Les exceptions je suis bien d'accord que c'est pas la panacée, mais en attendant c'est ce qu'il se fait de mieux. Donc voilà, si on peut faire avancer le débat là dessus plutôt que de faire des rapides raisonnements à 2 francs 'exception = goto donc cmal'

Si tu aimes ça, restes sur C++ (qui est quand même une surcouche super crade au C ).
On est d'accord, mais y dit qu'il voit pas le rapport.

Les modules cassent l'optimisation globale : oui, c'est donc un défi a relevé. Si t'es motivé tu peux le faire.
Je vois que t'es aussi enclin à répondre aux questions que ton collègue : quel intérêt de venir nous dire "on s'est réuni et on a discuter de la modularité' si tout ce que vous avez à dire au final c'est "oué ca sera fait, plus tard, t'as qu'à le faire si t'es motivé" ?

Je te rappelle aussi que le Lisaac est **principalement** développé par une seule personne. Pas par une équipe de 200 ingénieurs de chez microsoft (qui se font battre par le Lisaac sur le terrain des performances, soit dit en passant)
Voilà tout est résumé dans cette phrase, notamment entre les parenthèses. On à affaire à des chercheurs qui se branle la nouille sur un langage révolutionnaire-parcquil-est-plus-performant-que-ce-que-font-ces-connards-de-ricains. Les perfs "brutes" c'est gentil, mais Lisaac est un langage qui ne propose pas de gestion des erreurs, qui ne propose pas de gestion des modules, bref des choses élémentaires qui ont directement un impact sur les perfs : alors revenez avec un langage un minimum complet, après on refera les benchs et on comparera les perfs avec ce que fait MS (ou autre hein, y'a pas que MS).
Ou alors arrêtez la prétention à 2 francs, les communiqués publicitaires vides de contenus intéressants, et montrez nous ce qui nous (moi en tout cas) intéresse : des critiques ettayés de l'existant, des idées d'améliorations possibles, avec exemples à l'appui, etc.

alors qu'il prend de son temps pour raconter ce qu'il se passe derrière la scène.
Mes questions sont justement là pour essayer d'avoir les infos intéressantes de ce qui s'est dit "derrière la scène". Parcque là on a un enième teaser marketing de Lisaac par Ontologia sans aucun détail qui permettrait de se dire : tiens il est sorti des idées intéressantes de ce rendez-vous, des idées techniques nouvelles, etc.
Désolé d'essayer de trouver un sujet de discussion technique dans ce journal.

Porter OpenGL dans un langage, c'est difficile point.
N'importe quoi. C'est un travail purement technique, sans doute long con et chiant en fonction de la lib à binder, mais je vois pas ce qu'il y a d'impressionnant là dedans. Si c'était si compliqué, y'a longtemps que les API OpenGL auraient été retravaillés pour être bindés plus facilement. Et la très grande majorité des langages ont leurs bindings OpenGL. C'est que c'est pas si compliqué.

Preuve que tu n'as pas lu mon journal jusqu'au bout, je cite :
Bof, tu mets des mots techniques à la suite sans aucune explication, sans aucun raisonnement, et tu ne réponds pas à ma question : quels sont les critiques que vous avez apportez aux exception ? Que faut-il donc changer ? A partir de là on peut étudier les alternatives en regardant ce qu'elles améliorent par rapport à l'existant.
Désolé mais j'ai lu les slides, et ca m'aide pas non plus à comprendre votre critique des exceptions.

C'est pas dans les premières priorités.
Je te rappelle, que Lisaac a pour le moment vocation à être un langage de niche, et pas du tout un concurrent de Java.
Excuse du peu, mais Lisaac se veut un langage pour faire un OS, et les exceptions existent aussi en C# (que certains utilisent pour faire un OS), en C++ (dont l'utilisation dans les OS n'est plus à démontrer).
Donc voilà, je me doute que c'est dans les priorité, mais j'aimerai savoir si vous avez avancé sur le sujet, parcque dans les derniers débats que j'avais eu, la notion de module avait l'air de foutre en l'air la notion d'optimisation global offerte par le compilo...

Dispo dans la prochaine version du compilateur, qui devrait sortir au cours du premier semestre 2009
C'est cool, mais concrêtement ?

Sérieux, tu réponds totalement à côté de la plaque en n'aucune réponse à mes questions : je connais toujours pas les critiques aux exceptions, j'en sais pas plus sur la gestion des modules et de la configuration. Ca sert à quoi de parler de tout ca dans un journal si t'as pas envi d'en parler ?

le fantastique binding OpenGL
l'impressionnant port OpenGL
Y'a quoi de fantastique et d'impressionnant dans ce port OpenGL ?

Vous semblez critiquez la notion d'exception, pourquoi pas, mais où sont les arguments/raisonnement ?
Une piste alternative ?

la compilation de module
Alors ?

la gestion de la configuration des librairies
Alors ?

Clubic a effectivement du mal à traduire l'anglais. D'ailleur je comprends même pas comment on peut citer clubic en référence, c'est vraiment du journalisme informatique à 2 balles bourré d'aproximations et de contre-vérités, enfin bon. Le passage qui explique clairement les intentions de MS vis-à-vis de l'interopérabilité :
"Extending the ODF spec might have been a pragmatic approach to addressing gaps in the spec in the short term. But we felt that it would not be good for the ODF ecosystem in the long term since other applications wouldn’t be able to read those extensions (unless those products also implemented the same extensions we do) – and we don’t see that approach as promoting interoperability or the best experience for ODF users. We also don’t want to be accused of “co-opting” ODF and “polluting” the cyberspace with many ODF files that don’t adhere to the standard. We think it is better to evolve ODF with the community in the OASIS Technical Committee and/or the appropriate SC34 Working Group."
Grosso merdo ils sont conscients qu'ils vont se faire lyncher s'ils respectent pas le standard.

Ne pas faire de publicité sur le "trop" grand nombre de failles "avant", ce qui pourrait faire peur sur le "après"?
En même temps n'importe quel pirate peut décompiler les patchs pour voir ce qu'ils modifient exactement, et ainsi remonter à la faille.
Non MS a beaucoup plus intérêt à dire "hop voilà un patch qui corrige telle ou telle faille, donc c'est important installez là."
Sinon c'est dangereux : je publies un patch en douce, les gens voient pas l'intérêt de l'installer, et ca fini par retomber à la gueule de MS si la faille est exploitée après coup. Là dessus je doute qu'il y es un intérêt à cacher quoique ce soit.

Oui oui, plein de monde pensent encore que la sécurité par l'obscurité est une bonne sécurité.
Je ne prétend pas ca. Je suis d'accord avec toi que la sécurité par l'obscurité n'est pas une bonne sécurité. Mais l'inverse ne me semble pas vraie non plus : la transparence n'est pas un gage de sécurité.

désolé mais un logiciel a beau être libre, open-source, avec un processus de dev "transparent", ca n'empêche pas moins qu'une faille exploitable "officielle" n'a été corrigée qu'au bout d'1 mois. Et je vois absolument pas en quoi le côté "transparent" du mode de dev de Firefox a aidé à améliorer la sécurité des utilisateurs de Firefox pendant cette période.
La seule chose qui a permis à ces utilisateurs d'être épargné, c'est le peu d'intérêt qu'on montré les personnes malveillantes à exploiter cette faille.

Après moi j'ai essayé d'être factuel en avançant des faits et des temps de réactivité, chacun est libre de juger.

Jor t'insinuerai que le nombre de vulnérabilité dans Firefox est correct parcque c'est un logiciel open-source ?
Foutaise !
Si c'était si facile de détecter les failles en auditant les sources pour avoir un nomber correct de faille, bah y'aurait pas de faille, suffirait d'auditer le code avant de publier. Si c'était si facile de détecter des failles, ca se saurait.
C'est de plus à double-tranchant : si avoir le code source permet d'avoir plus de transparence et de détecter plus de faille, c'est valable également pour les personnes avec des intentions malveillantes.

qu'il n'y en a pas corrigées en silence
Et ? quel intérêt aurait Microsoft à cacher une faille identifiée et corrigée ?

d'autres découvertes mais pas encore corrigées
je vois pas en quoi le modèle de Firefox améliore cela. Y'a rien du tout qui te garantie que des gens ne trouvent pas des failles dans Firefox et gardent l'info pour eux.

Alors oui, la transparence est un atout pour un logiciel, c'est un des atouts des logiciels libres, mais en matière de sécurité, ca n'apporte pour moi pas grand chose.
Le danger vient de ceux qui exploitent une faille : eux font pas dans l'open-source.
Pour l'instant la seule chose qui rend Firefox plus "sûr" c'est ses parts de marché : avec 20%, ca reste 3 fois moins que IE. Une personne mal intentionnée cherchera donc dans un premier temps à exploiter les failles de IE plutôt que celles de Firefox.
Les stats ci-dessous montre clairement qu'il y a le même nombre de failles exploitables dans IE que dans Firefox, que niveau réactivité à la correction, c'est pas mieux.

Ok alors regardons depuis firefox 3 l'état des lieux avec IE7 (soit depuis le mois de juin).
On a :
Firefox 3 : 8 vulnérabilités dont 6 très critiques.
IE 7 : 6 vulnérabilités dont 4 très critiques et 1 extrêmement critique.
Franchement c'est exactement le même ordre de grandeur.
Parmis toutes ces failles, seule 1 a été exploitée, la dernière pour IE dont on parle actuellement.
On d'un côté un navigateur qui met 10 jours pour fournir une rustine alors que la faille est activement exploitée
C'est 7 jours. Après il y a eu une volonté évidente de nuire : la faille a été divulguée juste après la livraison de patch et sans prévenir MS au préalable.
Niveau réactivité, Firefox n'est pas beaucoup mieux, si on prend ce problème (hautement critique) :
http://secunia.com/advisories/30761/
Il a été identifié le 19 juin.
Il a été corrigé dans firefox 3.0.1 sorti le... 17 juillet.

Avec un FF qui a dans les 20% de part de marché, on ne peut plus dire "c'est parce qu'il n'est pas connu"
ca reste pas moins que IE reste pour le coup la cible prioritaire pour ceux qui veulent exploiter une faille.

Bref, ca me semble être un argument très peu crédible la sécurité.

L'avis général dans la communauté Java est très mitigé. Pour beaucoup cette première version est vraiment pas à la hauteur de la concurrence. Exemple de réactions :
http://www.lemondeinformatique.fr/actualites/lire-sun-javafx(...)

Tout comme la faille IE est corrigée par le patch http://www.microsoft.com/france/technet/security/bulletin/ms(...)
C'est vraiment malhonnête de pointer du doigt une faille d'un logiciel concurrent en conseillant d'utiliser un autre logiciel qui a des problèmes similaires.
Firefox a suffisament d'atouts face à IE pour qu'il ne soit pas nécessaire d'utiliser ce genre d'argument.

En même temps, si le problème, c'est comme tu l'énonces "rien n'est étiqueté, on sait pas si on bouffe indirectement des OGMs ou pas", on peut largement considérer qu'ils jugent avant tout le niveau d'information apporté aux consommateurs, ce n'est pas de l'anti-OGM primaire (même un pro-OGM pourrait exiger une transparence dans l'information, mais bizzarement, ils sont contre, mais c'est un autre débat).
Donc du coup, une entreprise qui répond pas, c'est clairement une entreprise qui ne joue pas la transparence niveau information, elle est donc en tout logique étiqueté en rouge.
Après franchement, tu parles de diffamation, et tu ne fais que démontrer que leur classement est fait en total transparence puisqu'il est parfaitement expliqué la nature du classement. Si diffamation il y a, elle est de ton côté quand tu remets en cause leur honnêté intellectuelle.
Que leur critère de coloriage te plaise pas (critère ici == niveau de communication), c'est une chose, que ca te fasse chier qu'ils fassent de la contrepub à un de tes potes qui tiens une fromagerie, c'est encore autre chose, mais ta façon de descendre leur plaquette me paraît totalement contradictoire.

ON TE PARLE DE LA BRANCHE DE DEVELOPPEMENT INSTABLE DE FEDORA
T'es vraiment du mal, je répondais à la phrase :
"comme dit plus haut, Fedora c'est dès le départ une distro "bleeding-edge", rien d'étonnant à ce que la stabilité ne soit pas la priorité"
Concernant le fait que c'est dans la branche "testing", je l'ai déjà dis et je le répète, je comprends tout à fait qu'un tel problème arrive.
Et arrête tes comparaisons avec windows, c'est pas le sujet.

Et puis bon le plus drôle dans l'histoire, c'est que même "instable" c'est pas assez politiquement correct. Sur le site de Fedora :
"Fedora is a Linux based operating system that provides users with access to the latest free and open source software, in a stable, secure and easy to manage form. "

j'appelle ma branch de developpement devel, pas instable. et quand j'ai un problème de ce genre, je parle pas de stabilité.

Ah c'est pour ca que tu reponds a un message parlant du fait que c'est la partie instable de la distribution qui a ete pointe par le journal?
bah oui. Justement pour dire que l'argument "instable" donc "faut s'y attendre" est bidon. C'est pas un problème de stabilité, c'est un problème fonctionnel critique et au final un gros manque de qualité.
Ca s'explique très bien vu le contexte de Fedora, mais faut dire les choses comme elles sont et appeler un chat un chat.

Tu n'as rien compris au message auquel tu reponds point barre.
T'as rien compris à ce que j'ai dis, comme d'hab, point barre.

Comparons des pommes avec des pommes et des oranges avec des oranges.
Y'a que toi qui fait des comparaisons de merde, moi je compares rien, y'a rien à comparer, juste un constat : c'est pas un problème de stabilité.

Non son problème est qu'il a eu du mal à trouvé la doc pour faire en sorte que x.org est le comportement auquel il était habitué.
Sa carte graphique n'a pas changé, c'est x.org qui a changé. faudrait pas dire n'importe quoi.

oué enfin là c'est plutôt dis the computer is the network.

Toi non plus y'en a rien comprendre.
Je ne critiques pas Fedora et ce qu'elle vise et ce qu'elle est. Je dis juste que le problème dont on parle dans ce journal n'est pas un problème de stabilité mais un problème de qualité.
Moi la stabilité, c'est quand ma machine a des comportements parfois aléatoire, une appli qui plante de temps en temps. Quand par contre tu fais une update qui rend ta machine inutilisable, là c'est pas de la stabilité, c'est un bug fonctionnel critique. C'est un problème de qualité qui n'est pas de la stabilité.

rien d'étonnant à ce que la stabilité ne soit pas la priorité
Moi ça me fait marrer l'utilisation du terme "stabilité", on dirait du politiquement correct. Pourquoi ne pas dire les choses franchement :
rien d'étonnant à ce que la qualité ne soit pas la priorité
Voir d'être encore plus honnête :
ils n'ont pas les moyens de faire de la qualité