thoasm a écrit 9443 commentaires

Ben là, tu pourras toujours faire les quelques scripts, en te prenant moins la tête, et tu auras plus de possibilité pour faire tes quelques scripts.

En quoi ce shell est pensé pour faire une appli complète ? c'est l'infrastructure .NET qui l'est.

Je te laisse à tes illusions ... Tu crois que la totalité des lignes de code de ton OS préféré a été écrite sans argent ?

Ragarde la partie "techinque" avant de crier au "c'est ms donc c'est mal ou ça va l'être".


Ce dont je parle, c'est le principe de X, pas "X" lui même. Que ce soit MS qui ait implémenté en premier le principe de X correctement (à voir, on a pas encore trop de retour) ça veut pas dire que le principe de X est à jeter.

Je me marre toujours autant, donc, c'est exactement ce que je voulais dire : on l'a pas encore, et c'est MS qui le fait, donc la techo est mauvaise. Si on avait eu la même chose en libre en premier, tout le monde aurait crié au génie.

T'as pas lu les commentaires et les liens ?

je précise que perso, ça va pas réxolutionner ma façon de travailler, et que je m'en fiche un peu ( je dis ça, il y a des chances que je trouve des trucs à faire après)

Déja, le flux n'est plus un flux de caractères, c'est un flux d'objet : au lieu d'avoir une ligne texte qui représente un process, avec tout ce que ça peut comporter de merde potentielle si on utilise des grep, sed, awk, mal fichus pour récupérer les infos qu'on veut, les espaces à gérer par des escape shell, tout ça, on récupère un ensemble d'objets processus.

Ensuite, sur cet ensemble d'objet, on peut appeler des méthodes, qui vont non seulement nous donner des infos sur le processus, mais aussi de lui envoyer des ordres. Genre t'as pas besoin de récupérer le PID du process pour faire un "kill" dessus, tu appelle la méthode "kill" de l'objet process. Comme dit plus haut, tu peux facilement récupérer l'ensemble des méthodes que tu peux appliquer à ton process, pas besoin nécessairement d'apprendre 25 000 noms de commandes. Certe il existe la commande pkill ou des trucs comme ça, mais elle marche que sur les process, il faut la connaitre, etc. Là le mécanisme est plus général et plus cohérent : tu peux utiliser la même démarche avec n'importe quel type d'objet.

Un autre avantage du système : les objets peuvent être n'importe quoi : un process, une GUI d'appli, ... Tu peux sans doute lancer, arrêter de jouer une musique en appelant les bonnes méthodes du process correspondant, sans que le programme ait été pensé pour avec une commande spécialement codée ou une API. Tu peut accéder grosso modo à l'ensemble du système, niveau applis, ou niveaux plus bas.

En bref, c'est un mécanisme cohérent et unifié pour faire pleins de trucs, en évitant certains éceuils d'un shell classique.

En voyant les commentaires. On retrouve un schéma classique ici

Annonce -> "machin va faire X"
Commentaires -> "Mouah, ca va être pourri, on peut déja faire ça avec Y"
Sortie de X -> "Mouah, c'est pourri, on peut déja faire ça avec Y, en plus il avaient annoncé Z et c'est pas sorti"

...

Le temps passe -> "Cool, X sors sous Linux! on va pouvoir faire Ça Ça et Ça, ç'est super cool"


Et ça marche avec plein de trucs, GUI potable/CLI par exemple, quoi que c'est peut être pas le bon journal pour dire ça ...

Ici, on peut bien sûr remplacer X par un shell objet qui peut manipuler le système en entier, et Y par un shell "chaines de caractère et fichiers"

Quoi que, on a déja des trucs dans ce sens sous linux, que ce soit des shells objets ou des trucs comme Dbus, mais faudrait intégrer et développer un peu tout ça, et que des gens s'exatasient déja de pouvoir manipuler les applis kde en ligne de commande ou dans des scripts.

D'autre part, le fait que le brevet soit public permettait non seulement que le secret ne soit pas emporté dans la tombe, mais aussi à ne pas bloquer l'innovation : il est interdit de reproduire une invention telle quelle, mais pas de l'améliorer.

À l'origine, le brevet était fait pour qu'un artisan n'emporte pas ses secrets de fabrication dans la tombe.

C'est un peu réducteur à ma conaissance, les brevets fournissaient aussi un droit d'exclusivité sur la fabrication d'une invention pendant un certain temps pour éviter que l'inventeur ne se la fasse piquer d'entrée et ne gagne pas d'argent avec. Sauf si tu connais l'historique un peu plus en détail que moi ;)

Je propose la perf d'eau sucrée, l'alimentation c'était bien entendu du miam miam, pas de l'électricité ^^ (je vous vois venir)

Se déplacer ? suffit de brancher un système d'alimentation à tout ça, et pourquoi se déplacer après ... avec des toilettes perso, c'est bon.

J'avoue que c'est parfois un peu troublant.

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.

Ça peut sauver la vie certaines 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 ;)

(enfin, si, j'ai bien ma petite idée, mais je préfère la garder pour moi)

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 ?

Difficile de refaire l'histoire.

Je comprends vraiment pas pourquoi tu t'es fait moinsser.

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.

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.

T'as raison, ça doit être la faute des balises :)

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.

Je crois qu'il existe des algos de diff xml. L'idée me semble relativement semblable : si je me trompe pas, Hachoir manipule un arbre, comme XML.

Pourquoi ion alors qu'on peut déja splitter l'écran dans tous les sens avec emacs ? Ca fait double emploi !