Michaël a écrit 2929 commentaires

"Si je sais combien j'ai sur mon compte bancaire ? Mais c'est une question de pauvre, ça !"

Ça me fait tout autant peur qu'à Louis Cole:

 ♫ I don't want to… check my bank account!
   I'm too scared to… check my bank account!
   Oh, check it! ♩

https://www.youtube.com/watch?v=dAH4zGd_W1s

qu’il serait temps d’essayer de résoudre collectivement plutôt que de s’enfermer dans un individualisme de plus en plus méfiant jusqu’à faire des choix finalement contraires à nos propres intérêts

Tu oublies que travailler dans une association pour faire valoir ses droits est nettement plus fatiguant que rester assis sur son canapé et de résoudre ses problèmes n'importe comment.

En plus la défiance envers le pouvoir donne l'air malin.

Tu peux récupérer les dépendances aux headers via le compilateur, par exemple avec gcc -M et gcc -MM
Cf. https://stackoverflow.com/a/2394651/518853

La meilleure façon de capturer les dépendances – meilleure parcequ'elle est exhaustive et indépendante du compilateur – est de tracer les appels système.

C'est ce que fait le make de NetBSD et de FreeBSD qui est bmake. avec son meta-mode. L'intérêt de cette méthode est qu'elle permet d'avoir les vraies dépendances et donc paralléliser au mieux.

Pour une école qui enseigne l'informatique, ça craint du boudin vu le nombre d'infractions.

C'est peut-être un énorme TP sur le cadre législatif des fichiers informatiques?

Ou au moins être plus confiant qu'avec une ligne de commande venant du même site, administré par les mêmes personnes.

Ce qui augmente la confiance c'est d'avoir un contenu cryptographiquement signé avec un checksum publié séparément.

Rien n'interdit par exemple de faire un serveur qui publie un script différent en fonction des paramètres du client (IP, user agent, plage horaire) ce qui pourrait constituer un vecteur d'attaque.

Avec un paquet hébergé ad-hoc c'est un peu mieux – faire confiance à une clef GPG est plus restrictif que de faire confiance à un serveur web – l'idéal serait d'avoir des sources différentes pour le checksum et pour le paquet.

Le format des paquets n'a aucun lien avec le problème présenté ici.

Le rapport c’est que distribuer son logiciel proprement en créant un dépôt ad-hoc et des packages pour une distribution est déjà chiantissime alors le faire pour toutes les distributions est inimaginable hormis pour les plus gros projets.

Le plus simple moyen de distribution est MacPorts mais la cible est spécifique au possible.

Le vieux combo «configure && make all install» est largement délaissé — pour de bonnes raisons, l’investissement temps-bénéfice pour apprendre les Auto-Tools est assez décourageant, et même si on a tout bien fait, créer son package pour une distribution de premier plan comme Debian ou Ubuntu est absurdement difficile.

Comme n'importe quel langage interprété non ?

Non c'est loin d'être le cas. En Lisp si je définis ma fonction nb-browse-to-url et que je l'appelle depuis nb-open-bookmarks-in-tabs et bien il me suffit d'envoyer la nouvelle définition de nb-browse-to-url à l'interpréteur pour que open-bookmarks-in-tabs utilise la nouvelle version. Dans la plupart des langages interprétés, la fonction nb-open-bookmarks-in-tabs se souviendrait de la vieille définition de nb-browse-to-url jusqu'à ce que nb-open-bookmarks-in-tabs soit elle-même redéfinie.

Ce n'est pas parceque c'est possible que c'est toujours la bonne chose à faire mais en pratique cette possibilité permet de considérablement réduire la durée de la boucle de développement.

À la page 130 on aura vu docker run -t -i et quelques commandes de base.

C'est une prise en main bien tardive… ;)

C'est dans l'avant-dernier chapitre qu'on parlera de persistance de données, de volumes, etc. J'appris des choses, mais vous savez ma frustration de ne pas avoir vu de cas d'usage plus réaliste pour un développeur web.

Mon expérience pour ton cas est qu'il vaut largement mieux “se faire son expérience soi-même” car la plupart des sources que j'ai eues sous les yeux ne sont pas terribles.

Les problèmes récurrents que l'on repère dans les exemples facilement accessibles sont:

• Un mauvais usage du cache. – Cela produit des temps de compilation trop long.

• Un trop grand nombre de layers produits. – Cela ralentit les opérations push, pull et create.

• Une trop grande dépendance à des ressources en lignes. – Chaque source différente augmente le risque qu'on ne puisse déployer à un moment critique à cause d'une ressource indisponible.

Je sentais que je perds trop de temps à re-compiler tout le machin au moindre changement de fichier, je n'ai pas de bonne pratique pour construire une image python&node.js

C'est un problème assez difficile, j'ai à propos d'un autre problème rédigé quelques conseils pour améliorer ses Dockerfiles.

Dans le cas d'une application node.js ces conseils se résument en gros à dire que la fin du Dockerfile doit ressembler à:

ADD src/package.json /opt/my-project/var/src/my-package/package.json
RUN cd /opt/my-project/var/src/my-package\
 && yarn install
ADD src/. /opt/my-project/var/src/my-package/
RUN cd /opt/my-project/var/src/my-package\
 && yarn build

ou un truc du genre qui sépare bien l'installation des dépendances de la préparation du fichier JavaScript final.

Mais ceci dit il n'y a aucune bonne raison pour que l'environnement de développement utilise les mêmes images que l'environnement de test ou de production. C'est parfaitement légitime d'utiliser un environnement spécifiquement destiné au développement qui favorise une boucle de développement rapide quitte à prendre quelques raccourcis.

Un autre point très important est qu'il est absolument nécessaire d'écrire des petits scripts qui implémentent les “verbes” du développement. De bons candidats sont “reconstruire toutes les images” ou bien ”ouvrir un shell root dans un container pour voir ce qui s'y passe” etc.

C'est fou le nombre de livres d'informatique où des pages entières de captures d'écrans sont désormais nécessaire là où quelques caractères suffisaient amplement autrefois.

Dans mon ancienne entreprise mon chef s'éclatait à essayer des logiciels pour représenter “rôles” et ”ownerships” dans l'entreprise… vu qu'on était 25 employés et qu'ils n'ont recruté personne depuis un an et demi, ça aurait été torché en 14 minutes en faisant un dessin à la main.

J’avais netbsd dans un radio-réveil »connecté«.

J'ai toujours eu un faible pour trac, par exemple voilà le formulaire de création de ticket.

Les gros plus de trac sont:

• La simplicité.
• La bonne intégration du système de tickets avec le wiki et les autres ressources du web (voir TracLinks)
• Une procédure de sauvegarde et de restoration intégrée.
• Les rapports de tickets super faciles à utiliser
• Une API facile à utiliser

Le gros moins est pour les utilisateurs non techniques l'utilisation du wiki-formatting à peu près partout, mais on peut aussi partir du principe que ce n'est pas grave si les utilisateurs veulent juste entrer quelques lignes de texte.

J'ai du reste une image docker pour trac dans un projet qui intègre Jenkins, Trac et bientôt d'autres choses. Là je travaille pour qu'on puisse utiliser uniquement ce dont on a besoin (Jenkins sans Trac ou vice-versa).

Je ne l'ai jamais utilisé mais il me semble que RedMine est le seul produit libre qui a un “look & feel” de bonne grosse ”corporate software” si on m'autorise cette flopée d'anglicismes.

Mais si ton datacenter est français mais que les gens qui l'exploitent travaillent pour IBM, Accenture, HP, tes données sont-elles vraiment en sécurité d'un point de vue national?

Si j'ai bien compris le patriot act la réponse est “non mes données dans un datacenter en France géré par une entreprise américaine ne sont pas en sécurité.” Et indépendamment du GRPD/DSGVO, les multinationales qui sollicitent mon entreprise ne veulent pas entendre parler de IAAS américain – parcequ'ils ne veulent aucune donnée sensible affectée par le patriot act.

La solution, ce serait d'avoir un cloud européen de l'administration, mais cela obligerait l'Union européenne à redévelopper tout ce qu'Amazon ou Google ont déjà, tout en étant plus cher et moins performant (car moins de clients) - ce qui peut être acceptable pour le RGDP. Mais "une bonne VM avec un bon ingé" n'est certainement pas une bonne alternative.

Euuuh, alors franchement tout ce qu'Amazon ou Google ont déjà c'est largement plus que ce qui est nécessaire. Et quand on pense à cloud pas cher ce n'est pas forcément Amazon ou Google qui viennent tout de suite en tête.

Des fournisseurs de IAAS il y a en des dizaines en Europe, plus ou moins grands, plus ou moins gros et plus ou moins OpenStack.

qui se règle en bougeant un seul point.

Elle est réglée même sans rien faire, si je m'autorise des jeux de mots moisis.

La limite pointée ne permet pas de faire facilement la différence entre une discontinuité vraiment sale du genre de sin(1/x) en x=0 d'une discontinuité un peu artificielle comme la fonction

La bonne notion à regarder c'est plutôt l'ensemble des valeurs d'adhérence pour la fonction.

Donc bon. L'utilisation de la limite pointée simplifie les trucs très simples,

C'est, plutôt que les “trucs très simples”, les énoncés de topologie générale qui “marchent mieux” avec la limite pointée (sinon on s'emmerde à devoir distinguer le cas “point d'accumulation vs. point isolé”, c'est tarte. Par exemple l'énoncé

Soit une suite réelle à valeurs dans et soit une fonction. Si , si et si alors .

est faux si on a comme notion de limite la limite “épointée” – à la place il faut dire que est continue en .

(essentiellemet équivalents à la limite épointée)

À aucun moment il ne s'agit de dire que la limite épointée ne sert à rien, au contraire c'est aussi une notion fondamentale (cas de N et des suites, limite à l'infini, limite au bord du domaine de définition, dérivées à gauche, à droite, par exemple) et on est bien obligé de manipuler les deux.

Tel qu'écrit dans le Frido, il y a (je crois) une incohérence pour limite et continuité d'une fonction définie sur un singleton ou plus généralement sur un espace contenant un point isolé.

En gros c'est un peu le sujet de la discussion – cf. ma remarque concernant le théorème 1. Et quand on passe l'agreg on n'a pas le droit de se prendre les pieds dans le tapis sur des notions aussi fondamentales que la continuité et les limites.

Dites les gars, si quelqu'un voulait un jour «défendre» la limite épointée en citant autre chose que de sources françaises …

Perso je m'en fiche de la nationalité des mathématiciens en question, ce qui compte est d'avoir un outil efficace. (PS. Du reste l'école mathématique française et particulièrement celle des années 60-70 jouit d'une réputation internationale. PS2 Si le but est de préparer des candidats à l'agreg de maths, c'est quand-même important de considérer le point de vue français sur la question.)

M'est avis qu'il ne faut pas deux définitions de limites, parce que la définition pointée demande quand même de prendre l'intersection entre le voisinage et le domaine de la fonction.

En fait ce qui unifie les définitions, c'est la notion de filtre.

Je crois que le seul cas où les deux définitions ne sont pas complètement interchangeables, c'est quand la fonction existe au point considéré, comme pour

Ou, pour le dire plus correctement, lorsque le point considéré est dans le domaine de la définition.

Notamment, lorsqu'on étudie les fonctions continues et la notion de limite, on montre des théorèmes comme (définition de limite ”avec le point”)

THÉORÈME 1. Une fonction est continue en ssi a une limite en .

THÉORÈME 2. Soit et , si a une limite en et si est continue en alors a une limite en et cette limite est .

et ces théorèmes sont plus pénibles à énoncer ou utiliser avec la définition de limite “sans le point”. (Dans le THÉORÈME 1 il faut ajouter que que est un point d'accumulation du domaine et quand on utilise le THÉORÈME 2 il faut traiter à part les points qui ne sont pas des points d'accumulation.)

Roger Godement, Analyse mathématique, t.1, p. 65 et Gustave Choquet, Cours de topologie, p. 26. Je n'ai pas Bourbaki sous la main, mais d'après le papier de Daniel Perrin suscité, c'est également la définition dite pointée qui est adoptée dans son traité. Je ne pense pas que Daniel Perrin ait inventé cela. Si je comprends bien ton commentaire, tout cela n'est en somme que des « sources secondaires » ?

Ce serait étonnant de voir une forte déviation entre Choquet et Godement d'une part et Bourbaki de l'autre. ;)

La définition “où on enlève le point“ donne des théorèmes plutôt moins jolis (par exemple la caractérisation d'une fonction continue par les limites) mais évite de devoir travailler avec deux définitions de limites (limite en un point du domaine et limite en un point extérieur adhérent au domaine) ce qui est peut-être un avantage “dans les petites classes”.

C'est un petit extrait dans la boucle d'interaction:

(cl-ppcre:parse-string "((?<small>[a-z]*)(?<big>[A-Z]*))")

J'appelle la fonction cl-ppcre:parse-string sur la chaîne de caractères "((?<small>[a-z]*)(?<big>[A-Z]*))"). Son métier est de compiler une expression rationnelle écrite en notation “perl-esque”. Le nom vient de PCRE pour Perl-Compatible Regular Expressions, une bibliothèque qui a été liée ou implémentée dans un bon paquet de langages.

La partie

(:REGISTER
 (:SEQUENCE
  (:NAMED-REGISTER "small"
   (:GREEDY-REPETITION 0 NIL (:CHAR-CLASS (:RANGE #\a #\z))))
  (:NAMED-REGISTER "big"
   (:GREEDY-REPETITION 0 NIL (:CHAR-CLASS (:RANGE #\A #\Z))))))

est la valeur de retour, c'est donc l'arbre syntaxique qui correspond à l'expression rationnelle. La partie (:CHAR-CLASS (:RANGE #\a #\z)) correspond visiblement à [a-z] et l'opérateur étoile est noté (:GREEDY-REPETITION 0 NIL …) et ainsi de suite.

La notation :REGISTER signifie juste un symbole ad-hoc – c'est en gros une chaîne de caractère immutable et c'est à peu près la même idée que les const REGISTER = 'REGISTER' qu'on peut lire en Javascript, mais en moins lourdaud. L'intérêt est que deux occurrences de :REGISTER sont toujours physiquement égales, ce qui permet de comparer rapidement les valeurs de ce type.

Dans le problème qui nous occupe, le module Lisp cl-ppcre permet de “lexer” à l'avance son expression rationnelle comme je viens de le montrer, pour ne plus avoir besoin de le faire à l'exécution.

Si on voulait vraiment compiler l'expression rationnelle à la compilation, on pourrait le faire en utilisant eval-when mais c'est un opérateur d'usage légèrement avancé.

Si je suis bien la conversation il y a une confusion entre deux choses:

• Les fonctions (pour faire simple) d'une bibliothèque qui ne sont jamais citées par une partie du code. Cela se teste en lisant le code.

• Les fonctions d'une bibliothèque qui sont citées mais dont on peut démontrer qu'elles ne seront jamais vraiment appelées pendant l'exécution du programme.

Dans le premier cas c'est un problème relativement facile à résoudre. Dans le second, il y a bien-sûr des heuristiques utiles qui permettent de traiter plein de cas intéressants en pratique, mais c'est impossible à faire “parfaitement” puisque c'est plus difficile que le problème de l'arrêt.

C'est de définir un DSL dont l'écriture d'un simple émulateur permet de le transformer en compilateur.

Un truc comme en Lisp donc:

;; parse tree syntax
* (cl-ppcre:parse-string "((?<small>[a-z]*)(?<big>[A-Z]*))")
(:REGISTER
 (:SEQUENCE
  (:NAMED-REGISTER "small"
   (:GREEDY-REPETITION 0 NIL (:CHAR-CLASS (:RANGE #\a #\z))))
  (:NAMED-REGISTER "big"
   (:GREEDY-REPETITION 0 NIL (:CHAR-CLASS (:RANGE #\A #\Z))))))

Voir http://edicl.github.io/cl-ppcre

La forme “DSL” de l'expression rationnelle peut être utilisée partout à la place d'une regexp “concrète” en syntax Perl.

Comme OCaml a de l'évaluation paresseuse (explicite), la manière idoine d'empêcher le programme de compiler toutes ses rexps à l'initialisation est de compiler la regexp au dernier moment.

C'est faux ?

Il y a une différence entre “objets inutilisés” et ”objets qui ne seront jamais appelés” – le premier énoncé porte sur le code et l'autre sur l'éxécution du programme.

des hommes mâles cis, donc des violeurs par essence.

Du coup il ne peuvent être tenu responsables et on ne peut rien changer? Et il y a des qui se proclament féministes et pensent cela (je suppose?). Lâchez tout!

Pour les naturels, j'ai en fait un doute. Ce qui est faisable sans trop de problèmes est de dire que le vide est un naturel et ensuite de définir…

Ce n'est pas plus facile de partir de l'axiome “il existe un ensemble infini”? Disons autrement dit on a une injection non surjective .

Ensuite on prend qui n'est pas dans l'image de et on dit

On a par exemple et on définit

et ensuite il faut travailler pour montrer que notre a les bonnes propriétés, autrement dit, satisfait les axiomes de Peano mais tous sont tautologiques dans ce modèle.

Par exemple, l'axiome de récurrence: Si contient et est stable par alors et donc on a aussi .

Petite remarque en passant: L'intégrale de Henstock-Kurzweil, qu'on peut voir comme une variation de celle de Riemann, permet de démontrer les théorèmes de convergence dominée et le théorème fondamental du calcul intégral sans faire de théorie de la mesure, ce qui est assez fascinant!

https://www-fourier.ujf-grenoble.fr/~demailly/books.html

Pfff, Bagdad c'est surfait, autant aller à Perl directement, en plus Apach est juste à côté, à un jet de common gateway interface.