gasche a écrit 1131 commentaires

  • [^] # Re: Mauvais message

    Posté par . En réponse à la dépêche Les femmes et l’informatique — émission « Libre à vous ! » du 5 novembre 2019. Évalué à -1 (+1/-4).

    Ce que je dis, c'est qu'il y a une inégalité entre les hommes et les femmes sur le temps de travail domestique. Il me semble que c'est exactement ce que dis l'étude.

    Toi tu parles des inégalités au sein d'un couple donné, c'est effectivement différent. Mais tu pourrais estimer le biais dont tu parles; par exemple sur les chomeurs, on a sans doute des statistiques sur le nombre de couples où seulement un des conjoints est au chômage (et son genre), ou alors les deux. Si le déséquilibre de genres dans ce cas est petit, il ne peut pas expliquer une heure de différence de temps de travail domestique.

  • [^] # Re: Mauvais message

    Posté par . En réponse à la dépêche Les femmes et l’informatique — émission « Libre à vous ! » du 5 novembre 2019. Évalué à 1 (+3/-4).

    Note que mon point de vue est que l'enquête que tu as pointé a des failles méthologique, ils ne mettent en avant qu'une corrélation mais pas une causalité et je trouve cela regrettable.

    L'enquête de l'INSEE mesure des choses objectives et quantifiables (même s'il peut toujours y avoir des biais dans la prise de mesure) : combien de temps différentes parties de la population passent à telle ou telle tâche. Évidemment ça ne donne pas de causalité, mais on ne peut pas établir une causalité de façon objective et quantifiable de cette façon. Tu parles de failles méthodologique, mais comment proposerais-tu de corriger cette étude pour savoir pourquoi, globalement, les français-e-s passent tant et tant de temps à faire telle ou telle activité ?

    Pour moi différentes méthodes scientifiques ont des rôles différents. L'INSEE produit des données statistiques brutes, suite à des enquêtes sur une partie représentative de la population, qui montrent l'état de notre société. Ça ne nous permet pas de démontrer la cause de tel ou tel aspect des données mais, quand c'est possible, c'est le rôle d'autres études avec d'autres méthodes, et les rôles sont complémentaires. De manière générale il est souvent impossible de répondre précisément à la question "pourquoi les gens font-ils X ?", et donc il me semble très peu raisonnable de ta part de critiquer toute étude qui n'y répond pas. Cette façon de faire ("je conteste, j'ignore ces résultats car la causation n'est pas démontrée") serait aussi une technique très commode pour des gens souhaitant contester quasiment n'importe quelle vérité qui les dérange dans le monde.

    Je veux dire, cela n'a aucun sens de comparer le temps de ménage d'un employé homme et femme si on compare l'ensemble des hommes et des femmes salariés. Il faut étudier les couples avec un temps de travail équivalent d'une part, et mettre le reste dans une autre catégorie. Car forcément si tu fais une moyenne globale tu n'as pas une vision claire de ce qui se passe.

    Que fais-tu alors des données sur les hommes et les femmes au chômage ? 3h23 de tâches domestiques pour les hommes au chômage (dont 17mn de soins aux enfants), 4h56 de tâches domestiques pour les femmes au chômage (dont 46mn de soins aux enfants). Il me semble que les personnes au chômage ont quand même un "temps de travail" relativement équivalent, et que la moyenne a du sens. Et chez les retraité-e-s ? 3h31 chez les hommes retraités, 4h25 chez les femmes retraitées.

    C'est probablement un mélange de ces éléments (travail, enfants, machisme), mais si par exemple le 3e point est finalement assez marginal, insister dessus pour essayer d'améliorer les choses sera contre productif.

    Il me semble que les personnes qui réclament plus d'égalité hommes-femmes font des efforts sur tous les points que tu indiques et bien d'autre : lutte contre les inégalités professionnelle (et les inégalités de carrières liées à la maternité), réclamation de droits parentaux plus équilibrés, de plus de solutions de garde d'enfants, et aussi campagnes de sensibilisations variées.

  • [^] # Re: Mauvais message

    Posté par . En réponse à la dépêche Les femmes et l’informatique — émission « Libre à vous ! » du 5 novembre 2019. Évalué à 0 (+1/-3). Dernière modification le 16/11/19 à 08:57.

    Je passe outre ta diatribe sur le fait que de discuter d'un lien que tu lances te semble limite insultant car cela t'oblige de travailler pour justifier ta position. C'est pourtant la base d'une discussion saine de ne pas prendre pour argent comptant ce qu'on trouve dans la nature.

    Une discussion saine serait une discussion où le temps de chacun est respecté, et où tout le monde accepte de fournir un effort dans des proportions raisonnablement égales. Sinon on peut étouffer tout point de vue impopulaire en se contentant d'émettre des objections oiseuses en grand nombre. Comme c'est malheureusement trop souvent le cas sur LinuxFR dès qu'un sujet déplaît aux réactionnaires (La place des femmes en informatique ! Scandale, nous sommes attaqués !)—dont je ne considère pas que tu fais partie.

    J'ai cité une étude précise de l'INSEE, avec un lien vers les documents, qui discute du temps de tâche domestique. J'ai précisé qu'il y avait des chiffres sur les salarié-e-s et sur l'ensemble de la population. Pourrais-tu aller voir l'étude pour répondre toi-même à tes objections ?

    • Tu parles d'une différence à l'accès à l'emploi, mais il y a des chiffres clairs sur les différences de temps de travail moyen entre les hommes salariés et les femmes salariées. (D'ailleurs je les ai cités dans mes message précédent.)

    • Tu parles d'une différence dans le temps passé à s'occuper des enfants; c'est une source évidente de disparité homme/femme, mais il y a des chiffres clairs sur cette différence-là, et les autres sortes de tâches domestiques, qui permettent de voir que cette différence-là s'ajoute à d'autres inégalités sur les autres tâches domestiques. (D'ailleurs j'ai cité des chiffres linge-cuisine-courses dans mon message précédent.)

    Pourquoi serait-ce à moi de faire ce travail de clarifier, pour toutes les formes d'explications "ce n'est pas du sexisme, c'est …" qui me seraient proposées ? Tu as autant accès aux documents que moi, si tu veux proposer des facteurs alternatifs, tu pourrais faire l'effort de regarder s'ils sont justifiés par les données que nous avons (collectivement) à disposition. (Réponse : en fait ces explications ne suffisent pas à expliquer les différentes hommes/femmes sur les tâches ménagères, et d'assez loin.)

    Par ailleurs, il me semble que le propos d'ensemble n'est pas de dire que les différences hommes/femmes sur les tâches ménagères étaient "dues aux sexisme" (qui serait un état d'esprit spécifique conduisant les femmes à faire plus de tâches ménagères et les hommes à en faire moins ?), mais que ces différences faisaient parties des inégalités, présentes dans notre société pour un ensemble de raisons sociétales variées (dont, par exemple, un accès différencié au congé parental, qui crée des inégalités), dont le résultat d'ensemble est, entre autre, une charge de travail domestique inégale entre les hommes et les femmes.

    Essayer de comprendre les raisons de ces inégalités est une bonne idée (mais comme tu le dis ce n'est pas facile, un facteur pouvant en cacher un autre), mais par ailleurs la présence de ces inégalités objectives et mesurables a un impact sur notre société, sur les capacités de chacun-e (en moyenne) dans leur rôle professionnel, etc., qui est un facteur créant d'autres inégalités entre hommes et femmes.

  • [^] # Re: Mauvais message

    Posté par . En réponse à la dépêche Les femmes et l’informatique — émission « Libre à vous ! » du 5 novembre 2019. Évalué à 4 (+7/-5).

    Je ne comprends pas ce commentaire. Je répondais à un commentaire prétendant que les différences hommes/femmes de charges domestiques n'existent plus depuis les années 50, en montrant que nous sommes entourés d'études qui montrent le contraire aujourd'hui. C'est facile de voir, en faisant une très rapide recherche, que le commentaire initial de Lutin c'était du n'importe quoi.

    Depuis que j'ai fait ce commentaire évident, on me pose des questions qui me semblent assez secondaires. "Et le temps de bricolage ?" (Il est dans l'étude, il est négligeable.) "Et les couples homosexuels ?" (vu leur nombre plus faible (une recherche rapide suggère moins de 1%), leur poids sur les statistiques d'ensemble est relativement faible).

    En me posant ces questions, on ne fait pas que lever des doutes qui n'ont pas lieu d'être, on me donne aussi du travail, à moi ou à d'autres, pour répondre, alors que ce que je dis est une évidence : tous les chiffres, toutes les études montrent qu'aujourd'hui, en France, les femmes font en moyenne plus de travail domestique que les hommes.

    Je ne dis pas que la question a pour but de mettre en doute ce fait, ou d'étouffer le fait de le dire dans une discussion sans fin. Mais en partie c'est l'effet que cela produit. Je pense qu'il y a des gens qui la pose en étant de mauvaise foi (xev), et des gens qui ne se rendent pas forcément compte (Renault), mais dans tous les cas il me semble que ça nuit à la discussion, plutôt que lui apporter.

    Renault: personne n'a dit que le genre était le seul effet expliquant des différences de temps de travail domestique. Mais c'est un effet mesurable et très important.

  • [^] # Re: Mauvais message

    Posté par . En réponse à la dépêche Les femmes et l’informatique — émission « Libre à vous ! » du 5 novembre 2019. Évalué à 3 (+2/-1).

    L'enquête de l'INSEE (j'ai mis le lien dans mon message) compte aussi le temps de bricolage et de "jardinage, soin des animaux", qui me semble contenir les tâches que tu décris. Ce n'est pas complètement clair pour l'entretien automobile, mais les catégories données ne sont pas très précises.

    Les hommes selon cette enquête en font effectivement plus que les femmes : chez les salariés, 22 minutes par jour en moyenne chez les hommes, contre 5 minutes par jour chez les femmes. La différence reste assez petite par rapport à la différence d'ensemble des temps domestiques (qui inclus ces tâches), chez les salariés à 2h06 pour les hommes et 3h27 pour les femmes.

    (Si on se limite, au sein des tâches domestiques, uniquement à "ménage, cuisine, linge, courses", la différence est encore plus marquée puisqu'on a, chez les salariés, 1h11 chez les hommes et 2h36 chez les femmes. Mais effectivement cette catégorie regroupe les tâches plutôt féminines et exclus des tâches plutôt masculines, donc elle ne donne pas une bonne idée d'ensemble du temps de travail domestique.)

  • [^] # Re: Mauvais message

    Posté par . En réponse à la dépêche Les femmes et l’informatique — émission « Libre à vous ! » du 5 novembre 2019. Évalué à 3 (+3/-2).

    C'est n'importe quoi ce commentaire, une recherche "homme femme temps domestique" suffit pour montrer qu'il est juste faux.

    https://www.inegalites.fr/L-inegale-repartition-des-taches-domestiques-entre-les-femmes-et-les-hommes

    En moyenne, les femmes consacrent 3h26 par jour aux tâches domestiques (ménage, courses, soins aux enfants, etc.) contre 2h pour les hommes, selon l’Insee (données 2010).

  • # Où trouver les sites et les programmes des années passées ?

    Posté par . En réponse à la dépêche Journées du Logiciel Libre de Lyon 2020 : l’appel à participation est ouvert !. Évalué à 4 (+2/-0).

    Où trouver le programme des années passées ? Les communications des années précédentes utilisaient une URL non millésimée, https://jdll.org/programme, qui pointe maintenant vers le programme vide de 2020. J'aimerais consulter le programme de 2019 ou 2018, en particulier les conférences, pour me faire une idée de l'événement.

  • [^] # Re: Petite erreur

    Posté par . En réponse à la dépêche Moi, expert C++, j’abandonne le C++. Évalué à 3.

    Les OS les plus utilisés sont écrits dans des langages non-sûrs (C et C++) et d'ailleurs ils sont bourrés de failles, comme les logiciels qui font l'infrastructure internet. Ça fait des décennies que des centaines voire milliers de gens sont payés pour réagir au quart de tour à la dernière faille de type "buffer overflow" trouvée dans un logiciel critique, tout ça parce que tout ce logiciel est écrit dans un langage où la grande majorité des erreurs de programmation permettent à un attaquant malicieux d'exécuter du code arbitraire. On a collectivement investi des milliers d'années de travail, de l'argent par million, pour gérer les conséquences de ces choix désastreux (même si c'était moins visible à l'époque où ils ont été faits) de construire toute notre infrastructure sur des langages fortement peu sûrs.

    Le langage n'a rien à voir avec la qualité du soft. Une mauvaise architecture, un mauvais développeur donnera du code non secure et buggué quelque soit le langage.

    Buggué, sans doute—même s'il existe des langages qui permettent d'exprimer son besoin plus clairement et donc d'avoir moins de bugs. Mais tous les bugs ne deviennent pas automatiquement des énormes failles de sécurité. Par exemple, si tu as un parseur d'un format binaire quelconque écrit en C, la plupart des erreurs de programmation permettent à un attaquant qui fournit un binaire malicieux d'exécuter du code (d'où l'exemple de prise de contrôle d'une voiture en insérant un CD audio bien choisi; il y a une erreur d'architecture dans le système, mais aussi un langage non-sûr qui permet de l'exploiter très facilement). On n'a pas du tout le même problème si on écrit le même parseur en Java, Ada, OCaml, WebAssembly, ou n'importe quel autre langage qui garantit la sûreté mémoire par défaut.

    C'est une illusion de croire que le dernier langage à la mode protège des failles de sécurité et des bugs.

    Un langage qui garantit que tous les accès à un tableau sont vérifiés pour leur validité protège des failles de sécurité lié à un accès arbitraire en mémoire—si l'implémentation du langage et le matériel dessous sont corrects. Tous les langages à la modes ne donnent pas forcément de bonnes garanties—mais en fait aujourd'hui presque tous les langages donnent de meilleures garanties que C.

    (Certains langages dynamiques introduisent des problèmes de sécurité qui n'existent pas avec C, en permettant à chaque bibliothèque d'aller redéfinir n'importe quel autre symbole visible par l'utilisateur ou presque.)

  • [^] # Re: Petite erreur

    Posté par . En réponse à la dépêche Moi, expert C++, j’abandonne le C++. Évalué à 3.

    Peu de gens comprennent vraiment le modèle mémoire des atomiques de C11 (les concepteurs du standard ont voulu faire plus fin et plus optimisé que celui Java, et donc pendant longtemps on n'a pas su si le modèle était raisonnable/correct), et parmi les gens qui le comprennent vraiment il y en a peu qui écrivent des programmes en C. Du coup pour les programmes multi-threadés, la plupart n'utilise pas les atomiques de C11 (typiquement le noyau Linux qui avait ses propres macros pour insérer des barrières), et la plupart de ceux qui les utilisent sont quand même indéfinis. En tant que simple mortel il faut vraiment être très strict, et ne pas descendre en-desous de release/acquire, pour ne pas se planter.

  • [^] # Re: Petite erreur

    Posté par . En réponse à la dépêche Moi, expert C++, j’abandonne le C++. Évalué à 7.

    C est aussi le langage des "comportements indéfinis", où personne n'est d'accord sur ce que devrait faire un programme et en fait tous les programmes sont faux (n'ont pas de sémantique définie) (en tout cas presque tous, surtout les programmes qui utilisent du multi-threading). Utiliser C pour un nouveau projet aujourd'hui, pour moi c'est irresponsable du point de vue de la correction et de la sécurité.

  • [^] # Re: Composer, pip, npm, gem, go-get et cargo, ces nouveaux SPOF des temps modernes...

    Posté par . En réponse à la dépêche Moi, expert C++, j’abandonne le C++. Évalué à 9. Dernière modification le 08/06/19 à 17:25.

    Sauf que créer un paquet npm (ou pip, gem, etc.) me permet de déployer mon code chez des gens qui utilisent n'importe quelle distribution, pas seulement la mienne. C'est autrement plus facile que d'écrire un paquet pour chaque empaqueteur Linux, OSX et BSD.

    Les gestionnaires de paquets spécifiques à une communauté ont des défauts et aussi des avantages. Pour les gens qui attachent plus d'importance à l'appartenance à cette communauté qu'à leur utilisation d'une distribution spécifique, ils sont clairement avantageux. Pour des gens qui utilisent ces travaux communautaires comme un paquet parmi d'autre au sein d'un système donné, ils sont clairement moins commodes qu'un empaquetage de distribution.
    Je trouve un peu triste qu'on répète ce débat à chaque fois, chaque personne donnant seulement un des points de vue ("développeur Javascript", "admin Debian", etc.), ce qui ne permet pas de comprendre la situation.

    Par ailleurs je remarques que les empaqueteurs des distributions sont très lents à réagir à de nouveaux besoins. Les développeurs sont très clairs sur le fait qu'ils ont besoin de travailler sur plusieurs projets qui vont utiliser chacun une version différente d'un paquet donné. Quels sont les gestionnaires de distributions qui permettent ça facilement ? À ma connaissance il n'y a que Nix et Guix qui font un bon boulot là-dessus, alors que pourtant c'est un besoin qui est apparu il y a des années. C'est bien beau de venir ensuite faire la morale "non mais les gestionnaires paquage-spécifique c'est puéril, il suffit d'utiliser Rpm/Deb/whatever".

  • [^] # Re: Mon avis

    Posté par . En réponse au journal Moi, expert C++, j'abandonne le C++. Évalué à 2.

    C'est peut-être aussi le moment de rappeler qu'il existe des postes où on a de la liberté pour faire son travail dans de bonnes conditions—toutes les entreprises ne se valent pas, on peut avoir plus ou moins de marge de manœuvre, et il y a des besoins d'informaticiens en dehors du secteur privé (personnellement je suis dans le secteur de la recherche publique, qui embauche des chercheurs mais aussi des ingénieurs, et qui a la valeur du travail bien fait). Ça ne veut pas dire abandonner complètement la recherche de l'efficacité au travail, et il y a aussi souvent des inconvénients à accepter en conséquence (plus difficile d'obtenir un poste stable, salaire plus faible).

    Les personnes qui savent programmer ont la chance d'être dans un domaine où la demande en personnel est très forte. Il est possible d'en profiter pour être un peu difficile sur les offres qu'on accepte, et de ne pas se laisser imposer des environnements de travail qui ne nous conviennent pas.

  • [^] # Re: .

    Posté par . En réponse à la dépêche GIMP 2.10.10 : « c’est dur de colorier ! ». Évalué à 4.

    Il existe des postes d'ingénieur de recherche dans la plupart des instituts de recherche publique française, qui cherchent des compétences souvent assez pointues pour contribuer à la recherche scientifique. À chaque fois, il y a des postes en CDD et aussi des postes permanents (moins nombreux, plus difficiles à obtenir). Exemples:

    (attention, certains postes "ingénieurs" sont plus administratifs que R&D, c'est dit clairement dans la description du poste.)

  • [^] # Re: .

    Posté par . En réponse à la dépêche GIMP 2.10.10 : « c’est dur de colorier ! ». Évalué à 10.

    pour une fois je ne saurais critiquer l'utilisation qui est faite de mes impôts.

    En tant que fonctionnaire (qui contribue aussi au logiciel libre) je trouve ça un poil vexant de lire ça. J'espère que cet exemple particulier (et, je suis d'accord, particulièrement sympathique) te fera réfléchir au fait qu'il existe plein de gens qui travaillent, grâce à nos impôts à tous, pour l'intérêt général, au CNRS et ailleurs. C'est un peu dommage ces petites formules qui critiquent tous les services publics, alors que ce sont des milieux très diversifiés qui sont remplis de beaucoup d'êtres humains qui font des choses importantes avec générosité.

  • # system76

    Posté par . En réponse au journal Sélection d'un PC libre. Évalué à 3.

    J'ai décidé que ma prochaine machine serait une system76, et il me semble que c'est un vendeur qui pourrait t'intéresser—je n'ai pas vérifié pour les ports disponibles, mais pour le reste ça fait ce que tu veux : des ordinateurs portables de bonne qualité, y compris des machines puissantes/récentes, et du logiciel libre. Voici par exemple un pointeur veurs leur laptop 13"/14", le Galago à $900.

  • [^] # Re: Vala ?

    Posté par . En réponse à la dépêche Financement participatif pour Akira. Évalué à 3.

    Il y a plein de projets intéressants dans plein de langages différents, et c'est un peu la norme de devoir découvrir un nouveau langage (ou un nouveau mode d'usage d'un langage qu'on a déjà utilisé) quand on veut contribuer à un projet spécifique—ou un nouveau gestionnaire de version, système de build, etc. C'est difficile de créer un projet à partir de rien dans un nouveau langage, mais éditer du code en se guidant avec l'existant est beaucoup plus raisonnable.

  • [^] # Re: Inférence de types

    Posté par . En réponse à la dépêche Sortie de JDK 10. Évalué à 4. Dernière modification le 11/11/18 à 18:38.

    La question que je pose depuis le début […] [c'est] comment tu connais le type de retour de getNextValue() sans aller voir sa déclaration (dans un autre fichier ou des centaines de lignes plus loin) ?

    La réponse:
    - souvent c'est évident selon le contexte (par exemple ce qui se trouve à droite est le constructeur d'une classe)
    - quand ça ne l'est pas, je peux demander à mon éditeur de me donner le type (chez moi c'est C-c C-t, chacun ses goûts)

    Si tu refuses d'avoir des outils pour t'aider dans ta programmation, tu as toujours le loisir de râler sur tes collègues, pendant la relecture de code, quand ils utilisent un auto/var à un endroit où ce n'est pas clair pour toi.

    De plus, je ne suis pas fan du code que tu proposes, tester les limites des types en dynamique alors que le type ne changera pas en runtime tout ca parce que c'est "mieux" d'écrire "auto counter" que "int counter", ca n'a pas de sens (et je ne parle même pas des performances…).

    Je pense qu'aucun test dynamique n'est fait dans le code C++ qu'il montre. Par ailleurs, Java est un langage qui fait un test de typage dynamique à chaque écriture dans un tableau, donc je dirais qu'il faut se détendre un peu.

  • [^] # Re: optimisation et propagation de constante

    Posté par . En réponse à la dépêche OCaml 4.06 et 4.07. Évalué à 4.

    Oleg ne travaille plus là-bas (il est professeur d'université au Japon depuis quelques années) et il me semble qu'il y a beaucoup de groupes de recherche&développement qui travaillent sur des prototypes sans pour autant mettre du code en production dans leur structure mère. Ce que tu dis n'est pas impossible (Oleg a travaillé sur des spécialisations de bibliothèques d'algèbre linéaire et calcul numérique, c'est compatible) mais me semble drôlement spéculatif.

  • [^] # Re: optimisation et propagation de constante

    Posté par . En réponse à la dépêche OCaml 4.06 et 4.07. Évalué à 5.

    Pourquoi crois-tu que je ne connais pas le sujet ?

    J'ai pensé que tu ne connaissais pas le sujet car tu as posé la question comme si tu ne connaissais pas le sujet:

    Je me demandais à quel point la propagation de constante pouvait remplacer les templates, voir même la génération de code. En général, la propagation de constante se limite aux littéraux( 10, 'c'). Pourquoi ne pas aller au delà, et faire de la propagation de constante de conteneur ?

    Imaginez la propagation d'une string qui définit une expression régulière : cela revient à générer le code lié à cette expression.

    On peut imaginer la même chose avec une structure arborescente : un interpréteur d'AST classique devient un générateur de code sur un AST statique.

    Qu'en pensez-vous ?

    J'ai supposé que, si tu savais que c'est un domaine sur lequel des gens ont travaillé, tu l'aurais indiqué en donnant un pointeur vers ces travaux (ou au moins le mot-clé à chercher : évaluation partielle, projection de Futamura, etc.), afin d'aider les gens intéressés à se renseigner plus en profondeur.

    (À relire ton message, tu mentionnes l'idée de spécialiser un interpréteur pour obtenir un compilateur, qui est assez avancée. J'aurais pu me douter que tu avais lu des choses sur le sujet, mais je me suis simplement dit que c'étaient des méditations sous la douche ou équivalent.)

  • [^] # Re: optimisation et propagation de constante

    Posté par . En réponse à la dépêche OCaml 4.06 et 4.07. Évalué à 6.

    Je trouve assez gonflé de critiquer une fonctionnalité d'un langage expérimental parce que tu n'aimes pas la syntaxe. Est-ce vraiment moins lisible que HTML ou Lisp ? Un utilisateur qui a un poil l'habitude sait lire d'abord le code dans les annotations de staging (étagement ?), et voir ensuite la structure des annotations (qui indique la séparation entre le code exécution statiquement et le code produit).

     let rec power n x =
       if n = 0 then 1
       else if n mod 2 = 0 then square (power (n/2) x)
       else x * (power (n-1) x)
    
     let rec spower n x =
       if n = 0 then .<1>.
       else if n mod 2 = 0 then .<square .~(spower (n/2) x)>.
       else .<.~x * .~(spower (n-1) x)>.;;

    Tu ouvres un fil de discussion avec une question un peu naïve qui correspond à un domaine de recherche entier (le mot-clé pour chercher les références est "évaluation partielle", "partial evaluation") qui a commencé dans les années 1970. Les gens ont pas mal réfléchi à ça, poussé l'idées dans des recoins intéressants, et un consensus qui est en train de se former est que pour avoir de la prédictibilité sur les performances obtenues il faut séparer explicitement les parties évaluées statiquement et dynamiquement (et, dans le cas général, à un stage/étage ou un autre).

    Il y a des choses intéressantes qui sont faites dans ce domaine, et je trouve ça un peu triste d'ignorer une idée simplement parce que tu n'aimes pas la syntaxe. Si le sujet t'intéresse, tu devrais peut-être te renseigner sur ce que les gens ont déjà fait dessus.

    Note: MetaOCaml et les templates/constexpr n'ont pas le même but. L'idée de la méta-programmation "staged" (étagée) est de laisser l'utilisateur définir ses propres évaluations partielles, pour les calculs qui comportent un mélange entre une partie déterminée statiquement et une partie déterminée dynamiquement (par exemple: précalcul de flot de contrôle, ou autotuning "statique" du code pour une architecture spécifique). constexpr propose une forme d'évaluation statique fixée par le langage, où tout doit pouvoir être calculé statiquement. C'est facile à utiliser mais l'utilisateur ne peut pas contrôler la méthode de spécialisation. Dans le cadre plus général de la métaprogrammation template, on peut choisir des mélanges entre calcul statique et calcul dynamique, mais les possibilités sont limitées aux formes de spécialisation prévues par le compilateur du langage, plutôt que programmées directement par l'utilisateur.

  • [^] # Re: En cas de doute il faut en parler -- avec la personne concernée

    Posté par . En réponse au journal Forker ou ne pas forker ?. Évalué à 4.

    J'ai déjà travaillé avec des gens frileux, ayant peur de montrer leur travail intermédiaire au monde. Le modèle "je donne des tarballs de mes release mais pas l'accès au dépôt versionné" est malheureusement plus courant qu'on ne pourrait le croire. Parfois les gens ont changé de point de vue à force de discussion et mettent tout en ligne aujourd'hui. Souvent ils sont restés sur leur position. Quand je contribue, j'essaie de m'adapter aux choix et préférences des gens qui ont fait le gros du boulot—tout en étant clair sur le fait que je préfère faire les choses différemment, si on me pose la question. Si on fait comme ça vient, et que des deux côtés les gens ont de bonnes intentions, ça se passe en général bien.

  • [^] # Re: En cas de doute il faut en parler -- avec la personne concernée

    Posté par . En réponse au journal Forker ou ne pas forker ?. Évalué à 10. Dernière modification le 16/09/18 à 12:58.

    On n'est pas là (ni toi) pour construire un modèle mental prédictif d'un individu à partir de sa page web ou pour lui faire une psychanalyse gratuite. Je pense que ce qui marche le mieux c'est d'être gentil avec les gens et de s'attendre au meilleur de leur part. En l'occurrence tu as travaillé sur le code de la personne, le plus naturel est de lui en parler de façon naturelle, et de s'attendre (naturellement) à une réponse, quoi qu'il y ait marqué sur sa page web.

    Que tu ais un retour ou non, en fait dès maintenant, tu peux faire tout ce qui te semble gentil et raisonnable. Par exemple héberger ta branche modifiée quelque part (de préférence un endroit un peu plus visible que Launchpad, par exemple Gitlab), avec une mention claire du fait que c'est une version de travail que tu as envoyée upstream et que tu espères que ça va être intégré à terme.

    Je trouve que tout cela est assez simple et que tu réfléchis un peu trop, à apprendre une page web par cœur et demander des avis sur LinuxFR avant d'envoyer un email. Fais comme ça vient !

  • [^] # Re: En cas de doute il faut en parler -- avec la personne concernée

    Posté par . En réponse au journal Forker ou ne pas forker ?. Évalué à 5.

    Je suis certainement dans le cas où je devrais attendre des mois, car il écrit clairement sur sa page de développement qu'il ne veut pas d'aide au développement.

    Je ne vois pas de raison d'avoir des certitudes, mais si tu penses attendre il vaut mieux écrire le plus tôt possible.

  • # En cas de doute il faut en parler -- avec la personne concernée

    Posté par . En réponse au journal Forker ou ne pas forker ?. Évalué à 6.

    Je n'hésiterais pas dans un cas comme cela à écrire au développeur de HomeBank. Tu fais des plates excuses sur le fait d'avoir commencé à coder avant de lire ses instructions, et que donc tu ne l'as pas contacté auparavant, mais que maintenant tu as un patch et/mais tu es prêt à refaire autre chose différemment s'il a une meilleure approche. Et là tu vois ce qu'il se passe.

  • # Upstream ?

    Posté par . En réponse au journal softs dev en Rust empaqueté pour Ubuntu & cie. Évalué à 3.

    As-tu prévu de pousser pour mettre cela dans les dépôts upstream ? (Y a-t-il moyen de collaborer avec les gens côté Debian ?)