Michaël a écrit 2929 commentaires

Il existe des outils nommés Interix ou Microsoft Windows Services for Unix distribués par Microsoft et gratuits, qui permettent (ou permettaient, je ne sais pas si ça marche sur les nouveaux systèmes) d'avoir un environnement de type Unix sous Windows. Cet environnement est supporté par PKGSRC, le système de package de NetBSD depuis 2004, ce qui signifie qu'en plus de Bash on avait un bon paquet de programmes libres utilisables. Et je l'avais beaucoup utilisé vers 2007-2008 je crois. C'était de mémoire assez lent (genre comme Cygwin) mais j'avais compilé tout un bazar sans aucun problème.

• https://www.netbsd.org/docs/software/packages.html#platforms
• https://en.wikipedia.org/wiki/Interix

Non. Ce que tu décris ici est un type qui n'est pas habité. Un type phantome c'est tout autre chose. Un type phantome est un paramètre qui est présent dans le type mais n'intervient pas dans sa définition. Par exemple:

Ah oui, je me suis un peu emmêlé les pinceaux en confondant le paramètre avec les valeurs qu'il prend – qui sont en pratique des types qui n'ont pas de définition.

Et vous, vous pensez quoi du bicamérisme?

En l'état actuel de notre système politique, il est d'une importance capitale. Nous avons (au moins) un gros problème dans notre culture politique qui tient dans le fait que sur le papier “le gouvernement est responsable devant le parlement” alors qu'en pratique le gouvernement (dans la présidence actuelle comme les précédentes) a beaucoup de pouvoir sur sa majorité et attend d'avoir à sa disposition un tas de députés godillots votant le doigt sur la couture les textes qu'il leur propose. Lorsque 5 députés de la majorité veulent discuter les propositions du gouvernement on en fait une presque affaire d'État, on les appelle les frondeurs, et ils sont mis au pilori avec l'assistance bienveillante de tous nos organes de presse, qui ont tous repris en chœur l'expression “les frondeurs” sans rappeler une fois, qu'au fond, c'est le travail du parlement de critiquer le travail du gouvernement! En l'état il n'y a pratiquement plus de débat démocratique à l'assemblée nationale. Pour plusieurs raisons, les sénateurs sont largement plus indépendants (électoralement parlant) du gouvernement que les députés, et finalement, c'est aujourd'hui eux qui exercent le plus ouvertement le débat et la critique avec le gouvernement.

Sinon dans l'absolu, c'est à dire en imaginant un instant que la relation assemblée-gouvernement soit saine, le bicamérisme est une bonne chose s'il dilue le pouvoir sans en rendre l'exercice impossible, et la situation semble en France, au regard de ce critère, assez équilibrée.

(Et oui, ça coûte cher, mais en plus de fumer des cigares toute la journée ou de faire travailler femme en enfants comme collaborateurs ou de pointer au parlement européen avec la carte de leur collègue, il y a aussi des élus – soyons optimistes, disons que c'est même le plus grand nombre d'entre eux – qui font un vrai travail, étudient les problèmes de société, économiques, politiques, diplomatiques, et font des jolis rapports qui alimentent le débat.)

PS: Même si je suis bien content que cette réforme de la constitution termine aux oubliettes, ça ne va pas faire joli-joli dans le bilan politique de Hollande: quelle camouflet (ou quelle loose, si vous préférez).

le mec qui vient te mettre le nez dans ton caca, c'est ton ami. Tes ennemis, ils la ferment et t'observent merder, et les pires, mais vraiment evil punaise, viennent te dire que c'est super ce que tu fais, continue, pour avoir le plaisir de te voir tomber d'encore plus haut.

C'est tellement vrai que je le cite et le plussoie!

Est-ce qu'il peut exister tout de même des instances ?
Ça correspond à une classe dont tous les constructeurs seraient privés. Mais tu peux tout de même avoir du contenu.

Lorsqu'un type n'a pas de définition on est en pratique face à l'un des deux cas suivants:

• le cas des types abstrait de donnée: il existe une définition du type mais elle est cachée, on ne peut pas créer de valeurs du type à partir d'une valeur “immédiate” ou explicite, mais on peut créer des valeurs en utilisant les fonctions de l'API. Cela correspond, il me semble, à une classe C++ dont le constructeur synthétique (celui fourni par le compilateur) serait privé mais dont des fonctions membre statiques permettent autorisent la création de valeurs.

• le cas des types fantômes: il n'existe nulle-part de définition du type, dans ce cas il est absolument impossible de créer des valeurs!

Ou un bon marabout.

Celui-là me semble tout indiqué: http://www.megabambou.com/galerie/1471

Attention aux excès de poudre verte!

(Il y peut-être encore une solution possible avec les gadt pour émuler les types classes d'haskell mais cela dépasse mon niveau de compétence là…)

En fait il suffit d'attendre bien sagement la sortie de OCaml 4.04 – ou bien utiliser la branche expérimentale du compilateur. Voir à ce sujet la dépêche sur 4.0.3 (encore dans les tuyaux).

Je ne vois pas bien la différence entre un type fantôme et un type (mais te fatigue pas je pense qu'il faudrait que je manipule tout ça pour commencer à comprendre ^_).

En réalité il y a un type fantôme avec lequel tu es déjà familier, c'est le void en C. On ne peut pas créer de valeurs de de type void par contre on peut créer des types dérivés, comme pointer to void – que je n'écris pas avec une petit étoile à cause du markdown.

Un type fantôme est juste un type qui est déclaré mais pas défini, comme dans

type my_first_fantom_type

On ne peut pas créer de valeurs de type my_first_fantom_type par contre on peut s'en servir pour paramétrer d'autres types. L'équivalent en C++ serait d'utiliser des templates et leurs spécialisation. J'essaie de traduire mon example OCaml en déclarations C++, mais mon C++ n'est plus tout frais:

struct validation_pending {};
struct validation_done {};

template<struct T>
struct password {
  typedef string type;
};

password<validation_pending>::type
password_input();

password<validation_done>::type
password_validate(const password<validation_pending>::type&);

void
password_store(const password<validation_done>::type&);

Le paramètre de template, qui correspond au paramètre de type dans le cas de OCaml, sert uniquement à “documenter” l'API aux yeux du compilateur – mais je ne connais malheureusement aucune astuce en C++ pour rendre les types password<validation_pending>::type
et password<validation_done>::type incompatibles entre eux, donc la correspondance est imparfaite.

C'est la différence entre

LIGNES=$(cat file)
printf '%s' "${LIGNES}" | wc - c

et

wc -c < file

(Si je peux me permettre.)

Une solution simple consiste à partager le répertoire également avec une machine C qui reste allumée entre temps, pour recevoir ce qui doit être synchronisé avant l'extinction de A, puis pour le propager jusqu'à B. Si vous avez des Pi qui traînent…

Ce qui revient au final à adopter une architecture centralisée!

Hum… Il me semble que c'est équivalent au Option/Optional que l'on trouve un peu partout.

Oui exactement, la monade ajoute des traitements et des opérateurs pour travailler facilement avec.

Je suis loin de comprendre, mais c'est une représentation de l'état courant en suivant tout le chemin de la donnée ça me semble un peu violent.

Voici un petit exemple en OCaml

type validation_pending
type validation_done
type 'a password = string

val password_input : unit -> validation_pending password
(** Lit un mot de passe sur stdin. *)

val password_validate : 'a password -> validation_done password
(** Valide un mot de passe. Lève l'exception [Failure] si le mot de passe est rejeté. *)

val password_store : validation_done password -> unit
(** Sauvegarde le (hash du) mot de passe. *)

Avec cette API, le mot de passe est une simple chaîne de caractères mais les types fantômes (qui n'ont pas de définition) validation_pending et validation_done permettent à la fonction password_validate de marquer sa sortie et à la fonction password_store de n'accepter que les valeurs passées par l'étape de validation.

C'est différent d'un bit d'attribut car le type est un attribut du programme connu du compilateur, qui garantit que si un programme compile, alors la fonction password_store ne peut être appelée que sur un valeur de sortie de password_validate.

Ça me semble représenter au mieux ce que je pense. En quoi est-ce que c'est un type abstrait ?

Le type password est un type abstrait si on ne montre pas la définition du type password dans l'API. Cela permet de garantir que seules les fonctions de l'API permettent de manipuler la valeur. Ainsi, on peut s'assurer que le programme ne va jamais afficher de password en n'offrant aucune fonction qui permet de transformer le password en string ou un autre type affichable.

Comme je ne le pratique pas (encore) c'est balbutiant, mais pouvoir à minima faire des alias de types et éviter les casts entre le type racine et l'alias.

Avec cette approche, il y a deux candidats “naturels” dans le monde fonctionnel. Le premier est l'utilisation de monades pour représenter le mot de passe validé, un peu comme si en JavaScript la fonction de validation retournait une valeur de la forme: {result:"MY-PASSWORD"} ou bien {error:"MESSAGE"}. Avec OCaml, j'utiliserais par exemple la monade Maybe. Le second candidat est l'utilisation de types fantômes, auxquels on peut penser comme à une annotation pour le compilateur qui permet d'exposer certains attributs ou se souvenir des traitements subis par une valeur.

Dans le cas particulier des mots de passe, je préférerais utiliser un type abstrait de donnée, qui permet de limiter les traitements sur les mots de passe, interdisant par exemple à ceux-ci d'être imprimés dans la sortie du programme (pas de conversion en type string) et sont effacés de la mémoire aussitôt que possible.

C'est amusant, j'ai écrit sur le même sujet en présentant Lemonade Sqlite. Bien-sûr l'angle est différent puisque je me concentre sur la présentation de Lemonade Sqlite, mais ce paragraphe devrait te plaire:

Almost every programmer has already seen the equation popularised by Niklas Wirth, but is has an aspect whose subtlety that is less well-known: the frontier between data structures and algorithms is very fluid, when it comes to decide how should the different aspects of our program be represented.

Soit en français

Presque tout programmeur a déjà vu l'équation popularisée par Niklas Wirth mais elle a un aspect dont la subtilité est moins bien connue: la frontière entre les structures de données et les algorithmes est très fluide lorsqu'il s'agit de décider comment représenter les divers aspects de nos programmes.

J'ai demandé sur Programmers SE si NIklas Wirth voulait lui-même transmettre cette idée dans son livre (KEJNÉPALU™), il semblerait que ce soit le cas.

Félicitations! Beaucoup de succès avec ton nouveau système et à bientôt! :)

Je ne sais pas vous, mais j'ai l'impression de revivre le même scénario qu'il y a 20 ans.

Le contexte est sensiblement différent. Il y a 20 ans l'introduction de Java et de ses applets avait quelque chose de révolutionnaire, dans le sens où il s'agissait d'une innovation technologique qui précédait un besoin. Si l'on considère le destin particulier de Java on peut douter qu'il ait réellement rencontré le succès escompté sur le web mais en réalité ce sont les idées qu'il a introduites qui dominent: aujourd'hui presque tout utilisateur de du web télécharge des programmes complexes qu'il exécute dans son navigateur. Aujourd'hui le développement de Webassembly apparaît plus comme une évolution naturelle de la technologie existante que comme un réchauffé du scenario d'il y a 20 ans:

• Les machines JavaScript sont largement optimisées.
• Les travaux de compilation et d'optimisation de bytecode intermédiaire sont très à la mode et font de grands progrès (citons par exemple LLVM et flambda pour OCaml).
• De plus en plus de langages peuvent être compilés en JavaScript (citons encore OCaml, ou certains dialectes de JavaScript qui sont transpilés ), de sorte que remplacer JavaScript par un langage de plus bas niveau répond ici aussi à une forme de besoin.

Frimeur. :)

Il faut utiliser printf au lieu de echo -e – tu cherches à te faire du mal! :)

C'est pourtant évident: JavaScript est une technologie maudite par des années d'utilisation par des web-developpers pour faire du front-end et qui n'a rien à faire dans l'horizon d'un sysadmin digne de ce nom, tandis que Perl, c'est le bien, la lumière, et la vraie philosophie Unix. Une bonne vieille querelle de clocher, en somme. – Je sais que tout le monde sait, mais le titre du fil est “trollons” ;)

Non ce n'est pas peine perdue, à ma connaissance Debian package de tas d'applications capables d'utiliser les dépendances des mêmes dépôts ? Cette mode de vouloir outrepasser les versions de la distribution et avoir du frais est à mon sens récente et est arrivée avec node.

C'est parceque tu vois ça avec tes yeux d'utilisateur de Debian, mais regardons le problème du point de vue du programmeur JavaScript. Ce programmeur fait partie d'une communauté qui se retrouve autour d'un langage mais travaille dans un environnement hétérogène. Ainsi les développeurs JavaScript utilisant des dépendances externes se retrouvent confrontés aux problèmes où le binding qu'ils écrivent ne marchent pas sous la distribution bla bla Linux parceque la zlib y est en version 2.0 tandis que sur leur système glop glop Linux elle est en version 2.0.1 – et que des différences subtiles créent des problèmes difficile à reproduire. L'introduction d'un système de packages ad-hoc permet donc à cette communauté de se réunir autour d'un éco-système relativement homogène, et d'introduire une abstraction pour traiter les cas particuliers liés aux différents systèmes.

Cette stratégie répond donc à un problème bien concret qu'elle résout – non sans amener son propre lot de problèmes, mais apparemment il n'y a aucune solution qui permet de gagner sur toute la ligne, on est donc amené à faire des compromis en fonction de ses priorités.

Je ne le soulève pas parce que le raisonnement présenté n'était basé que sur la rentabilité de l'opération.

Pour certaines personnes, le fait d'éviter de produire des déchets a de la valeur, une valeur qui est justement mise en évidence dans dans les décisions prises dans ce genre d'achats.

Sur le point particulier du raisonnement écologique, il faut faire hyper-attention, parce que les coûs écologiques cachés peuvent être très grands et très complexes.

C'est vrai et de plus c'est un sujet surlequel il est incroyablement difficile de se renseigner! Par exemple avec l'apparition des magasins “sans emballage” où l'on amène ses contenants pour acheter des pâtes ou ce genre de denrées, ce serait chouette d'avoir des données qui disent “ben oui c'est mieux d'acheter des pâtes sans emballage que des dans une boîte en carton, même s'il faut rouler 20 minutes de plus pour aller au magasin” (ou le contraire, le cas échéant).

Bref, les gens ne sont pas (tous) des cons. Je sais bien que c'est toujours glorifiant de penser "mieux" que les autres, mais dans cet exemple précis, il ne me semble absolument pas évident qu'il vaille mieux acheter un appareil deux fois plus cher si on pense qu'il durera deux fois plus longtemps.

Un point que tu ne soulève pas, c'est qu'acheter deux machines au lieu d'une, cela fait une machine qui va au rebut.

Sans faire de pub, une machine robuste et réparable (et pas qu'un peut) ça existe : Miele.

Sans faire de pub, c'est la vérité.

Pour expérimenter avec Linux je ne peux que te conseiller d'utiliser VirtualBox. Le logiciel VirtualBox est un logiciel libre qui te permet de simuler un PC, et donc d'installer Linux dans un environnement virtuel. Cette procédure est très simple et idéale pour se familiariser avec Linux. La solution d'une installation sur une partition dédiée est beaucoup plus technique – mais pas réellement difficile.

Il n'est pas difficile de trouver des procédures d'installation pas à pas, par exemple: http://www.brianlinkletter.com/installing-debian-linux-in-a-virtualbox-virtual-machine/

Voici une petite marche à suivre pour découvrir Linux:

• installe Linux dans une machine virtuelle, par exemple en suivant la procédure pas à pas ci-dessu
• prend contact avec un groupe d'utilisateurs de Linux de ta région, ce qui te permettra de pouvoir échanger avec des gens qui pourront t'apporter l'assistance ou les conseils dont tu as besoin.
• si tes impressions sont concluantes tu pourras faire le choix d'installer Linux “pour de vrai“ sur ta machine, ici aussi l'aide d'utilisateurs plus expérimentés te sera précieuse!

Je ne connais pas de projet qui soit à plus de 80% de couverture, mais ça n'empêche pas que s'empêcher de tester son code ne me semble pas du tout être une bonne idée.

Là où un peu de pédagogie est nécessaire est certainement qu'il faut bien expliquer qu'une partie de test et de mise au point est inévitable. Ceci étant quel statut donner à ce travail? Faut-il se contenter des résultats immédiats (ça marche, on livre) et oublier le reste du travail fait ou bien faut-il le sauvegarder, l'incarner, dans des artefacts sous contrôle de version, des tests automatiques? En plus des bénéfices que tu soulignes qui se révèlent payants sur le long terme, souligner que c'est un travail qui va de toute façon être fait et que la vraie question est s'il faut l'organiser pour l'automatiser ou juste l'oublier est un argument qui “touche” parfois.

Et toi tu as fait quoi pendant ce temps ?

Je moulais sur LinuxFR pardi!