Thomas Douillard a écrit 9175 commentaires

Tu peut construire à la mimine ta valeur, et faire un "get-process ma_valeur_construite_a_la_mimine" j'imagine ... et si le process existe pas, get-process doit te l'indiquer. (j'ai cru entendre parler d'exceptions)

je le fais en c

Tu passes du bash au C directement ? La vache. C'est complètement orthogonal du point de vue gestion des chaines de caractères, et d'un tas d'autres choses d'ailleurs. Ça explique bien des choses ;)

Et pour ton fichier de compilation séquentiel
Pourquoi pas un truc du genre

a_compiler = { fichiers compilables du répertoire }

Pour chaque fichier de a_compiler
Si fichier.est_lisible() alors
fichiers_objets.ajouter = fichier.compiler()
fin si
fin pour

executable = fichiers_objets.lier()

avec la gestion des erreurs, et tout ? j'adorerai faire ça ... sans avoir à gérer mon ensemble de fichier comme une chaine de caractère bash dans laquelle un espace dans le nom de fichier foutra la merde ou connaitre la manpage de "test" par coeur pour savoir si un fichier est plus récent qu'un autre ...

Ok, c'est complètement farfelu comme exemple, c'est surement pas réalisable cash, vaut mieux faire un makefile, mais c'est pour donner une idée.

Et de renchérir : surtout quand la qualité bash/ksh/... vs cmd.exe, completion, efficacité du shell a longtemps été un sujet de raillerie de la part des linuxiens vis à vis de windows. Là sur le shell lui même ils ont pas grand chose à envier, au contraire.

Ton commentaire ressemble surtout à celui d'un mec vexé qui veut pas perdre la face. "oué, ok il ont sorti un truc bien. Mais quand même". Et ça, c'est parce que c'est MS, j'en suis profondément persuadé.

... Sauf que c'est pas des fonctionnalités qu'on parle, c'est du principe du shell. Imagine les fonctionnalités des commandes combinées avec le shell lui même ?

Ça ça existe déja, c'est ipython je crois. Mais iphython ce n'est pas encore tout à fait ça: il manque notament l'accès "de base" a pleins d'objets système, applis, ... pour pouvoir scripter tout ça et accéder à pleins de trucs, de piper des objets (cf les exemples), ...

Ca n'a rien a voir avec les fonctionnalités ou le nombre de commande, c'est simplement un moyen d'accéder à ces fonctionnalités.

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 :)