thoasm a écrit 9456 commentaires

Bon, si le coup d'état est une solution, faut y aller ! et surtout faire mieux après.

Tu sais, rien n'interdit à un ministre de l'écologie : ministre -> besoin de comprendre la politique, et écologie -> besoin de comprendre ... l'écologie, de s'entourer de gens compétents en science/écologie/...

Sinon, comment tu veux éviter de te faire bouffer par tel autre ministre qui a besoin de soux pour calmer des profs pas contents ou pour boucher le trou de la sécu ?

En même temps, dans un système démocratique, la seule manière de changer un système c'est de jouer le jeu dudit système ...

T'as bu trop de kiklenny ... kileklinny ... bière toi

Parce que ça peut être utile et pratique ?

Les devs, ils deviendrons des dinausores ou ils comparerons à l'usage ce qui est le plus pratique à utiliser pour ce qu'ils ont à faire.
Wait & see donc.

Non, je n'ai pas de problème avec les chaines de caractères en C, c'est juste particulièrement lourd à manipuler dans ce langage (Honnêtement, je crois pas connaître pire, d'après des retours que j'ai eu appliquer une regexp en C c'est d'une lourdeur totale, par exemple, pour concaténer deux chaines il faut appeler une fonction, se demander si la fonction en question alloue elle même la mémoire ou si elle attends la place nécessaire préallouée ... Alors qu'en shell, tu feras pas grand chose sans manipuler des chaines de caractères.

Pour la compilation : cet exemple était certe pourri, j'avais prévenu ;) Mais je déteste pas faire des trucs un peu élaboré avec un shell, ou utiliser des boucles for ou des trucs dans ce genre. Ce qui est frustant dans ce cas, c'est le nombre de tricks qu'il faut se rappeler pour faire marcher le bouzin correctement alors que c'est 5 lignes de code ... je pense perso que l'approche "une entité du SE", un fichier par exemple, est un objet, avec immédiatement et facilement accessible tout ce qu'on voudrait en savoir, comparée à l'approche "une entité est une chaîne" avec des commande à taper et des lignes de textes de descriptions accessibles à partir de commande qui prennent en paramètre l'identifiant chaine de l'entité qu'il faut parser derrière est bien meilleure.


Pour le séparateur par défaut, le changer, c'est du bricolage, et oui, je savais qu'on pouvait le faire. C'est de la trituration mentale de se demander à chaque fois dans quel cas ça va foirer et ce qu'il faut faire pour y remédier, mettre des quotes, utiliser $@ etc.


Je me jette pas à corps perdu dans cet outil, j'ai déja dit que je m'en foutais un peu. D'ailleurs j'utilise pas windows.

Sur les fonctions et attributs, là tu te plantes : on a déja dit que grâce à l'introspection des objets, tu pouvais connaître en ligne toutes les méthodes que tu peux leur appliquer, type shell completion, éventuellement avec la doc j'imagine. Le genre de trucs qui peuvent faciliter la vie.


Mais après, si "ça sert à rien, on pouvait déja faire ça avec Y" et "on pouvait faire ça en C aussi", j'ai plus rien à ajouter à mon premier post, rendez-vous dans quelques temps ;)

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