Perso je jette un coup d'oeil rapide dans ma boite à spam régulièrement pour vérifier les nouveaux spam, et je marque le dossier "lu" pour distinguer les nouveaux des anciens facilement.
En général on distingue très facilement le sujet d'un spam et un vrai mail, grâce à l'expéditeur, tout ça. Mais ça marche pas à tout les coups, j'ai dû laisser passer des vrais mails une ou deux fois.
Pas faux. Cela dit si malgré le contexte d'antagonisme absolu est-ouest de la guerre froide, ça a fini sans une grosse mêlée générale, la dissuasion n'y est sans doute pas pour rien. Après, c'est sûr, la situation a bien changée depuis.
PS : le HS dans une news de plus de 250 commentaires c'est normal, et de toute façon plus personne ne les lit - sauf discussion en cours ;)
Qui te dis que ces guerres (ou d'autres plus ou moins semblables) n'auraient pas eu lieu, plus une tripotée d'autre, sans la dissuasion de l'arme nucléaire ?
Hum, je suis pas sûr de ça, le graphe en lui même à pas nécessairement besoin d'être changé AMHA, seules les valeurs des variables (des intervalles si c'est traîté comme ça) ont besoin d'être modifiées en fonction des cas rencontrés.
Bon, ok il reste clairement une exponentielle là dedans, mais je comprends pas pourquoi elle est nécessairement dans le graphe lui même.
D'ailleurs, ici on a pris le cas des conditionelles, qui est simple, mais on fait comment dans le cas des boucles ? on déroule tout au fur et à mesure ? on peux pas savoir "à priori" combien on devra en dérouler, si on construit au fur et à mesure, ni même si l'algo se termine dans le cas de boucles potentiellement infinies.
On comprend vite que sur un programme ou sous-programme non-trivial, la combinatoire est explosive.
Pas moi en tout cas : sur ton exemple, on a 3 blocs de codes, et 3 noeuds et 6 arcs, en O(2*n) en fonction du nombre de ligne de code au pire, linéaire donc.
Si ce schéma est imbriquée dans d'autres structures, il ne sera pas reproduit dans mon idée des graphes de flots en tout cas.
bloc A'
while ( cond1) do
/* Ton bloc if */
done
bloc B'
ca rajoute deux noeuds, 3 arcs, c'est tout.
Je vois donc pas ce qui peut êxploser de ce côté, sauf si il y a reproduction de ces structures quand ce sont des fonctions, genre inlining en C++.
Donc je crois pas que le graphe en soit bouffe tant d'espace.
L'analyse de flot, qui est censée traiter tous les chemins possibles c'est évidemment différent. Dites moi si (où sûrement ;) ) je me trompes.
Posté par thoasm .
En réponse au sondage XML est.
Évalué à 2.
La complexité du développement web est aujourd'hui telle que l'on ne peut même pas disposer d'outils d'analyse automatique des erreurs. Quand on voit le résultat, eh bien oui, on est en droit de se poser des questions.
Exact, c'est un peu facile de se faire rétorquer ensuite un truc du style "libre <> gratuit" "argument technique toussa" certe, mais le proprio à des arguments économiques indiscutables ... (pour le développeur par exemple)
Il doit me manquer un truc, parce là je comprends pas ce qui peut faire exploser la taille.
Genre pourquoi il y a duplication des sous-graphes ? à priori il suffirait de faire un arc d'un graphe vers un autre pour un appel de fonction par exemple, sans rien dupliquer du tout. Un genre d'inlining dans le graphe ? Les boucles qui sont déroulées si possible ? Il y a peut être des trucs du genre SSA (Single assignment si je me trompe pas), création d'une variable à chaque affectation ?
D'autre part, je vois pas pourquoi l'instanciation des objets ferait augmenter la taille du graphe, dans un langage classique à priori c'set juste l'instanciation de la mémoire et l'appel au constructeur (en simplifiant), pas de quoi exploser, donc. C'est en rapport avec le modèle par prototype, peut-être ? Comment les objets interviennent dans ce graphe ?
Pour la granularité, l'assembleur par exemple à une granularité très fine, et pourtant on a pas des exécutables de 512 megs ?
D'accord avec toi, sauf que l'analyse de flot ne permet pas seulement à mon avis de détecter du code mort, mais aussi de détecter les erreurs potentielles, cf l'exemple de la division par 0 donné plus haut.
Question plus technique : c'est quoi qui bouffe de l'espace dans Lisaac ? les propriétés trouvées (genre n pair), qu'on est obligé de garder parce qu'on sait pas si elles serons utiles ou pas ? (question naïve sans doute, j'y connais pas grand chose) ? Je pense pas que le graphe de flot en lui même prenne autant de place ... ? Le moteur d'inférence ?
Il y a des chances que les performances ne soient pas améliorées dans l'histoire, c'est sûr : les algorithmes de détections de ce type de propriétés ne se font pas forcément, du point de vue de la complexité algorithmique, aussi rapidement que les autres, sauf peut-être à rechercher des propriétés relativement triviales.
Ils vont peut-être devoir changer d'ordre de grandeur l'algorithme, ce qui n'est à priori pas bon pour le temps d'exécution. Je pense pas que le "10x" soit significatif, ils donnent ça comme un vague ordre de grandeur dans la description du projet.
Je pense pas que ce type d'algo nécessite forcément de stocker tout l'arbre en mémoire, on doit pouvoir s'en sortir avec un parcours 'à la demande'.
En tout cas, un algo de diff binaire générique est "à plat" à priori. Il doit tenter d'aligner au mieux les sous-séquences communes sources et cibles) et ne tient pas du tout compte de la structure arborescente de ton fichier. Dans ce cas, pas besoin de hachoir.
J'aimes les gens aux idées bien arrêtées et les dialogues de sourds.
Et qui avancent des trucs, et répondent à la contradiction en réavancant le même truc, c'est vachement constructif.
Cela dit je suis un peu dans le même esprit que toi, j'irai pas aller fouiller les mailing lists kde, gnome, freedesktop ou les distribs rien que pour un troll idiot.
Dans un cas comme dans l'autre, perso je maintiens que ce n'est pas forcément une mauvaise chose, et tu ne pourras pas me convaincre du contraire (c'est une façon de mettre fin à la discussion).
Chapeau l'argumentation, c'est parce que ça vient de windows que c'est mal ? Sachant que sur un Desktop, tout le monde à peu prêt a ces répertoires, pourquoi pas les mettres par défaut ? Ca permet de faire des trucs genre préconfigurer le logiciel de musique, mettres des icones appropriées, ou des choses comme ça, des trucs "user friendly" (le vilain mot). Et si t'es pas content, tu changes ^^.
Sans doute. Mais il sera certainement plus intéressé par les conclusions et les softs du projet que par le projet lui même (un peu de mauvaise foi, certe).
Ce que je vois 'à priori' sur la qualité, c'est par exemple la qualité du code. Utiliser et concevoir des outils de preuves de programmes pour rechercher des propriétés comme "pas de segfault" dans le code.
Mais tu à raison, le projet semble bien plus vaste, ils vont sans doute mettre des équipes de recherche en labo et/ou en r&d dans les entreprises sur des domaines relativement larges (de l'ihm à la preuve formelle de programme, recherche de bugs, ...)
Le troll à ses périodes, lui aussi. En temps normal, il sort le vendredi, c'est sûr. Mais on peux observer une recrudescence de trolls, plus ou moins périodiquement, pour le trollus politicus par exemple.
Il sort relativement peu en période normale, mais parfois il s'excite. Par exemple, tous les 5 ans, il a une période d'activité, de reproduction intense, qui dure environ de 6 mois à 1 an. Ça commence doucement, puis il agit de plus en plus. Il agit de plus en plus, jusqu'envirion vers Avril ou son activité atteint son paroxysme. Après il disparait plus ou moins de la circulation, même s'il a des "rechutes".
À cette période, il est suffisament hardi pour sortir un autre jour de la semaine que le vendredi.
Faut voir ça du point de vue de l'europe politico-économique : les lls sont une chance de développer une vraie industrie du logiciel à l'échelle Européenne, dans un monde plutôt dominé par les États-unis de ce côté. (Enfin Pierre-Jarillon le dirait sans doute mieux que moi ;) )
[^] # Re: .
Posté par thoasm . En réponse au journal tuer le troll. Évalué à 3.
[^] # Re: URL
Posté par thoasm . En réponse au journal Tomtom One new edition + linux. Évalué à 2.
[^] # Re: Faux positifs...
Posté par thoasm . En réponse au journal Spamassassin/Bogofilter : net avantage à second !. Évalué à 5.
En général on distingue très facilement le sujet d'un spam et un vrai mail, grâce à l'expéditeur, tout ça. Mais ça marche pas à tout les coups, j'ai dû laisser passer des vrais mails une ou deux fois.
Ça peut sauver la vie certaines fois.
[^] # Re: Incompatibilité GPL
Posté par thoasm . En réponse à la dépêche Novell et Microsoft main dans la main !. Évalué à 1.
PS : le HS dans une news de plus de 250 commentaires c'est normal, et de toute façon plus personne ne les lit - sauf discussion en cours ;)
[^] # Re: Franchmant
Posté par thoasm . En réponse au journal Bill Gates recommande Ubuntu. Évalué à -9.
[^] # Re: Incompatibilité GPL
Posté par thoasm . En réponse à la dépêche Novell et Microsoft main dans la main !. Évalué à 3.
Difficile de refaire l'histoire.
[^] # Re: Franchmant
Posté par thoasm . En réponse au journal Bill Gates recommande Ubuntu. Évalué à -9.
[^] # Re: Compilation lente <=> Analyse de flot
Posté par thoasm . En réponse à la dépêche Lancement du projet GlobalGCC. Évalué à 2.
Bon, ok il reste clairement une exponentielle là dedans, mais je comprends pas pourquoi elle est nécessairement dans le graphe lui même.
D'ailleurs, ici on a pris le cas des conditionelles, qui est simple, mais on fait comment dans le cas des boucles ? on déroule tout au fur et à mesure ? on peux pas savoir "à priori" combien on devra en dérouler, si on construit au fur et à mesure, ni même si l'algo se termine dans le cas de boucles potentiellement infinies.
[^] # Re: Compilation lente <=> Analyse de flot
Posté par thoasm . En réponse à la dépêche Lancement du projet GlobalGCC. Évalué à 2.
Pas moi en tout cas : sur ton exemple, on a 3 blocs de codes, et 3 noeuds et 6 arcs, en O(2*n) en fonction du nombre de ligne de code au pire, linéaire donc.
Si ce schéma est imbriquée dans d'autres structures, il ne sera pas reproduit dans mon idée des graphes de flots en tout cas.
bloc A'
while ( cond1) do
/* Ton bloc if */
done
bloc B'
ca rajoute deux noeuds, 3 arcs, c'est tout.
Je vois donc pas ce qui peut êxploser de ce côté, sauf si il y a reproduction de ces structures quand ce sont des fonctions, genre inlining en C++.
Donc je crois pas que le graphe en soit bouffe tant d'espace.
L'analyse de flot, qui est censée traiter tous les chemins possibles c'est évidemment différent. Dites moi si (où sûrement ;) ) je me trompes.
[^] # Re: une immondice infame
Posté par thoasm . En réponse au sondage XML est. Évalué à 2.
T'as raison, ça doit être la faute des balises :)
[^] # Re: Sur le laboratoire OpenSource de microsoft
Posté par thoasm . En réponse au journal Microsoft et Suse main dans la main. Évalué à 0.
[^] # Re: Compilation lente <=> Analyse de flot
Posté par thoasm . En réponse à la dépêche Lancement du projet GlobalGCC. Évalué à 3.
Genre pourquoi il y a duplication des sous-graphes ? à priori il suffirait de faire un arc d'un graphe vers un autre pour un appel de fonction par exemple, sans rien dupliquer du tout. Un genre d'inlining dans le graphe ? Les boucles qui sont déroulées si possible ? Il y a peut être des trucs du genre SSA (Single assignment si je me trompe pas), création d'une variable à chaque affectation ?
D'autre part, je vois pas pourquoi l'instanciation des objets ferait augmenter la taille du graphe, dans un langage classique à priori c'set juste l'instanciation de la mémoire et l'appel au constructeur (en simplifiant), pas de quoi exploser, donc. C'est en rapport avec le modèle par prototype, peut-être ? Comment les objets interviennent dans ce graphe ?
Pour la granularité, l'assembleur par exemple à une granularité très fine, et pourtant on a pas des exécutables de 512 megs ?
[^] # Re: Compilation lente <=> Analyse de flot
Posté par thoasm . En réponse à la dépêche Lancement du projet GlobalGCC. Évalué à 4.
Question plus technique : c'est quoi qui bouffe de l'espace dans Lisaac ? les propriétés trouvées (genre n pair), qu'on est obligé de garder parce qu'on sait pas si elles serons utiles ou pas ? (question naïve sans doute, j'y connais pas grand chose) ? Je pense pas que le graphe de flot en lui même prenne autant de place ... ? Le moteur d'inférence ?
[^] # Re: Compilation lente
Posté par thoasm . En réponse à la dépêche Lancement du projet GlobalGCC. Évalué à 2.
Ils vont peut-être devoir changer d'ordre de grandeur l'algorithme, ce qui n'est à priori pas bon pour le temps d'exécution. Je pense pas que le "10x" soit significatif, ils donnent ça comme un vague ordre de grandeur dans la description du projet.
[^] # Re: Intéréssant
Posté par thoasm . En réponse à la dépêche Hachoir version 0.6. Évalué à 2.
En tout cas, un algo de diff binaire générique est "à plat" à priori. Il doit tenter d'aligner au mieux les sous-séquences communes sources et cibles) et ne tient pas du tout compte de la structure arborescente de ton fichier. Dans ce cas, pas besoin de hachoir.
[^] # Re: Intéréssant
Posté par thoasm . En réponse à la dépêche Hachoir version 0.6. Évalué à 2.
[^] # Re: Normal
Posté par thoasm . En réponse au journal Distributions Linux, vers un éclatement des formats de paquetages ?. Évalué à 5.
[^] # Re: Mon avis à moi...
Posté par thoasm . En réponse au journal Distributions Linux, vers un éclatement des formats de paquetages ?. Évalué à 1.
Et qui avancent des trucs, et répondent à la contradiction en réavancant le même truc, c'est vachement constructif.
Cela dit je suis un peu dans le même esprit que toi, j'irai pas aller fouiller les mailing lists kde, gnome, freedesktop ou les distribs rien que pour un troll idiot.
Dans un cas comme dans l'autre, perso je maintiens que ce n'est pas forcément une mauvaise chose, et tu ne pourras pas me convaincre du contraire (c'est une façon de mettre fin à la discussion).
[^] # Re: Mon avis à moi...
Posté par thoasm . En réponse au journal Distributions Linux, vers un éclatement des formats de paquetages ?. Évalué à 1.
[^] # Re: Mon avis à moi...
Posté par thoasm . En réponse au journal Distributions Linux, vers un éclatement des formats de paquetages ?. Évalué à 3.
[^] # Re: \o/ \o/
Posté par thoasm . En réponse au journal un FAI soit-disant ""Free"" bafoue la GPL !. Évalué à 2.
Après recherche rapide sur le net, il y a ça chez Inventel ( un des firmware ) : http://www.inventel.com/gateway/gpl_software/
[^] # Re: Qualité de l'encodage...
Posté par thoasm . En réponse à la dépêche L'UE co-finance un observatoire de la qualité des logiciels open source.. Évalué à 2.
[^] # Re: Preuves scientifiques?
Posté par thoasm . En réponse à la dépêche L'UE co-finance un observatoire de la qualité des logiciels open source.. Évalué à 5.
Ils prévoient plus d'un an sur les deux de définition précise du projet, bibliographie et spécification ...
http://www.sqo-oss.eu/about/activities
Ce que je vois 'à priori' sur la qualité, c'est par exemple la qualité du code. Utiliser et concevoir des outils de preuves de programmes pour rechercher des propriétés comme "pas de segfault" dans le code.
Mais tu à raison, le projet semble bien plus vaste, ils vont sans doute mettre des équipes de recherche en labo et/ou en r&d dans les entreprises sur des domaines relativement larges (de l'ihm à la preuve formelle de programme, recherche de bugs, ...)
[^] # Re: pfff
Posté par thoasm . En réponse au journal Qui a dit ?. Évalué à 9.
Il sort relativement peu en période normale, mais parfois il s'excite. Par exemple, tous les 5 ans, il a une période d'activité, de reproduction intense, qui dure environ de 6 mois à 1 an. Ça commence doucement, puis il agit de plus en plus. Il agit de plus en plus, jusqu'envirion vers Avril ou son activité atteint son paroxysme. Après il disparait plus ou moins de la circulation, même s'il a des "rechutes".
À cette période, il est suffisament hardi pour sortir un autre jour de la semaine que le vendredi.
[^] # Re: Les développeurs européens.
Posté par thoasm . En réponse à la dépêche L'UE co-finance un observatoire de la qualité des logiciels open source.. Évalué à 7.