Lizzie Crowdagger a écrit 218 commentaires

  • # Les texts blocks

    Posté par  (site Web personnel) . En réponse au journal Java perdra une partie de sa verbosité à la fin de l’hiver. Évalué à 4. Dernière modification le 26/11/19 à 20:28.

    Et vous dans la liste des nouveautés, qu’est-ce qui vous fait envie

    Bon en vrai j'utilise pas spécialement Java mais je dirais les "text blocks", comme le reste c'est pas une killer feature qu'on a jamais vue ailleurs mais c'est le genre de trucs qui rend vraiment moins pénible de manipuler du texte et qui mérite à mon avis d'être mentionné.

  • [^] # Re: Bordel ?

    Posté par  (site Web personnel) . En réponse au journal Ça sent pas bon chez Intel ?. Évalué à 3.

    Pour spectre, sur nos machines perso, la plus grosse attaque possible serait du code JavaScript qui va lire la mémoire du navigateur web (et donc des infos sur les autres sites).

    À noter qu'il y a eu une nouvelle version de Firefox sortie aujourd'hui pour limiter le risque : https://www.mozilla.org/en-US/firefox/57.0.4/releasenotes/

  • [^] # Re: Je déteste CL

    Posté par  (site Web personnel) . En réponse au journal C'est décidé, j'apprends Common Lisp!. Évalué à 5.

    Niveau Scheme, il y a Racket, où il me semble qu'il y a quand même pas mal de choses de disponibles.

    Perso, je m'étais pas mal intéressée à Clojure, mais autant l'intégration à la JVM peut être un avantage pour utiliser plein de bibliothèques Java sans (trop) se prendre la tête, autant ça limite aussi si tu préférerais plutôt proposer un « vrai binaire » (notamment, je sais pas si ça a a évolué dernièrement, mais les temps de lancement étaient assez rédhibitoires à mon goût pour un programme en ligne de commande qui est censé s'exécuter plus ou moins instantanément).

  • [^] # Re: Script sieve

    Posté par  (site Web personnel) . En réponse au journal Chiffrement, chiche ?. Évalué à 6.

    Du coup si un écrivain envoie un manuscrit à un éditeur, ce dernier obtient les droits sur le manuscrit, sans avoir à signer de contrat ? Je dubite.

  • [^] # Re: ...

    Posté par  (site Web personnel) . En réponse à la dépêche C++17, Genèse d’une version mineure. Évalué à 10.

    Pourtant si tu fais du C++ t'as bien le temps de poster un commentaire à chaque fois que tu recompiles

    ---> []

  • [^] # Re: Donc pour résumer…

    Posté par  (site Web personnel) . En réponse à la dépêche C++17, Genèse d’une version mineure. Évalué à 5.

    Par contre Swift me paraît quand même assez limité actuellement si tu veux du multiplateforme (ou simplement que ça tourne sur ta plateforme). Je trouve le langage intéressant, mais j'avais essayé vite fait de le choper à l'époque de l'annonce de la libération de la version 2.0, sauf que y'a juste des binaires pour Ubuntu (qui marchaient pas sous ma debian, j'avais testé quand même). Je précise que j'avais pas testé plus que ça, et je sais que j'aurais moyen d'installer Swift pour jouer avec. Par contre avec Rust, Go, et je parle même pas de C++, je sais que si je publie un projet je peux dire "allez choper le compilater ici (ou utilisez la version de votre distrib) et installez mon projet". Avec Swift actuellement c'est pas le cas, et j'ai pas l'impression qu'Apple soit très motivé pour en faire une plateforme intéressante ailleurs que sur leur environnement.

  • [^] # Re: Pourquoi pas ? Parce queeeeeee !

    Posté par  (site Web personnel) . En réponse à la dépêche Swift sous GNU/Linux - Introduction. Évalué à 1.

    Cela dit la plupart des langages, à ma connaissance, ne disposent pas d'une bibliothèque GUI qui leur est propre. À partir du moment où on peut appeler du code C sans trop de difficulté, ça paraît envisageable d'avoir des bindings pour, par exemple, Gtk+ (Qt vu que c'est du C++ c'est déjà une autre paire de manches). La question après c'est de savoir s'il y aura suffisamment d'utilisateurs/développeurs sous systèmes libres pour qu'il soit possible de trouver facilement des bindings pour la bibliothèque que tu veux utiliser.

  • [^] # Re: Go

    Posté par  (site Web personnel) . En réponse au journal Et si JavaScript allait droit dans le mur ?. Évalué à 3.

    Certes, mais ce que je voulais dire c'est surtout que je ne vois pas en quoi le fait de ne pas avoir (ou montrer) d'opinion serait la démonstration de plus de capacité à choisir le bon outil : tu peux aussi avoir tendance à utiliser tout le temps la même chose simplement parce que c'est la seule que tu connais, ou parce que t'en as plus l'habitude, etc.

  • [^] # Re: Go

    Posté par  (site Web personnel) . En réponse au journal Et si JavaScript allait droit dans le mur ?. Évalué à 6.

    (Hors sujet)

    Du coup ça me fait penser à une question piège d'entretiens d'embauche :

    Quel est votre design pattern préféré ?
    Ce à quoi il faudrait répondre « aucun, ça dépend du besoin ».

    J'ai déjà vu aussi appliqué aux langages de programmation, et j'ai jamais compris la logique d'opposer « avoir un préféré » et « adapter au besoin ». Je veux dire, si je je préfère faire à manger que faire la vaisselle c'est pas pour autant que si je sors de table je vais me préparer un deuxième repas plutôt que de laver mon assiette :P

  • [^] # Re: Go

    Posté par  (site Web personnel) . En réponse au journal Et si JavaScript allait droit dans le mur ?. Évalué à 3.

    «Je cherche à montrer que beaucoup de gens disent du mal des framework principalement parce qu'ils ne les maîtrisent et préfèrent affirmer que le framework est mauvais plutôt d'expliquer qu'ils n'ont pas envie de prendre le temps d'apprendre, comprendre, puis maîtriser le dit framework.»

    Cela dit ça me parait pas en soi une mauvaise raison. Personnellement, je sais que ça me fatigue que beaucoup d'exemples de code que je peux trouver quand je cherche de la doc sur javascript dépendent de gros frameworks parce qu'effectivement en général les fois où je fais du javascript c'est pour une fonction de 10 lignes, ça arrive assez peu souvent pour que je doive googler le mot-clé pour déclarer une fonction et j'ai pas spécialement envie d'apprendre un framework alors que j'ai juste besoin d'une fonction qui prend une valeur en entrée et renvoie une valeur en sortie, point. J'irais pas dire que ces frameworks sont mauvais pour autant, mais par contre le fait de tomber avant tout sur des exemples dépendant de frameworks quand tu cherches à faire un truc basique qui n'en a pas besoin ça peut être rebutant (surtout quand t'as l'impression qu'il te faudrait déjà investir un temps considérable uniquement pour choisir quel framework utiliser).

  • [^] # Re: Remarque à la c...

    Posté par  (site Web personnel) . En réponse à la dépêche Servo fin 2015 : où en est-on ?. Évalué à 1.

    Et puis deux processeurs qui fonctionneraient à 50% au lieu d'un à 100%, a priori c'est dans le cas où y'a pas de gain de vitesse final. Le but si tu veux accélérer le rendu ce serait plutôt que les deux processeurs fonctionnent à 100% pendant deux fois moins longtemps.

  • [^] # Re: À suivre?

    Posté par  (site Web personnel) . En réponse au journal C++ Core Guidelines. Évalué à 1.

    Je parlais de GSL, et de ce que présente Herb Sutter dans sa conf https://www.youtube.com/watch?v=hEx5DNLWGgA où il y a quand même des trucs un peu spécifiques (comme les annotations sur les lifetimes) et des trucs qui m'ont l'air « un peu pareil mais pas avec le même nom ».

    Après j'avoue que je m'y connais pas des masses en C++ récent, mais j'ai l'impression que ça risque de « fractionner » un peu le langage entre différentes écoles sur la façon moderne d'écrire du C++.

  • [^] # Re: À suivre?

    Posté par  (site Web personnel) . En réponse au journal C++ Core Guidelines. Évalué à 1.

    Ah je croyais qu'il y avait d'un côté la bibliothèque que tu peux utiliser pour ton code et de l'autre un outil d'analyse (qui utilise cette bibliothèque pour te prévenir que ce que tu fais est peut-être une erreur).

  • # À suivre?

    Posté par  (site Web personnel) . En réponse au journal C++ Core Guidelines. Évalué à 3.

    La chaine avec les vidéos des conférences sur Youtube : https://www.youtube.com/user/CppCon

    Je trouve intéressant l'outil dont Herb Sutter faisait la démonstration dans sa conférence "Writing good C++14… by default" (mais qui, il me semble, n'est pas encore disponible), et qui permet visiblement de s'assurer qu'il n'y a pas de soucis de dangling pointers. Ce qui est assez rigolo c'est que ça se rapproche assez de ce que Rust peut faire (avec des différences évidemment, et pas tout à fait les mêmes objectifs non plus je crois).

    Par contre je me demande ce que ça va vraiment donner en pratique : certes (par rapport à Rust notamment) il y a l'avantage que ça reste du C++, que tu peux continuer à utiliser le code existant ; d'un autre côté est-ce qu'il est vraiment possible de profiter des garanties de sécurité dans ce cas là ? Et la question bonus : est-ce que ça va vraiment être utilisé en pratique, ou est-ce que ça revient pas au final à créer un "dialecte" de C++ qui aura autant de mal à s'imposer qu'un nouveau langage ?

  • [^] # Re: Remarque à la c...

    Posté par  (site Web personnel) . En réponse à la dépêche Servo fin 2015 : où en est-on ?. Évalué à 5.

    D’après ce que j’avais compris le JavaScript tourne en parallèle également.

    Ben que ce soit en parallèle du reste du navigateur, oui sans doute, mais vu que c'est la reprise de SpiderMonkey, l'interprétation en elle-même du javascript doit être à peu près similaire à Firefox, je suppose…

    Pour compléter le commentaire au-dessus, je dirais qu’être plus rapide et consommer moins d’énergie même sur PC c’est quand même plutôt appréciable. :)

    En soit oui, c'est toujours appréciable (et plus sûr aussi, ce qui je pense peut pour le coup être un net avantage de Rust par rapport au C++), mais disons que je m'attends pas non plus à ce que ça change radicalement mon expérience, quoi.

    (Pour ce qui est de consommer moins d'énergie j'ai un doute quand même, mais peut-être que c'est une question bête : est-ce que ça consomme vraiment moins d'énergie d'avoir deux procs qui tournent moins longtemps, qu'un proc qui tourne deux (probablement un peu moins en pratique) fois plus longtemps ?)

  • [^] # Re: Remarque à la c...

    Posté par  (site Web personnel) . En réponse à la dépêche Servo fin 2015 : où en est-on ?. Évalué à 6.

    Je pense pas qu'après c'est pas tant une question de langage que d'algorithmes ? Rust fournit des mécanismes pour garantir une relative sécurité quand tu fais de la concurrence, mais après il en reste pas moins que c'est compliqué de considérer tous les éléments d'une page comme des éléments parfaitement indépendants (typiquement la taille d'un élément risque de dépendre de celle des autres éléments, donc il faut faire plusieurs «passes» si j'ai bien compris la présentation que j'avais vue).

    Après j'avoue que je suis un peu sceptique sur l'intérêt de l'optimisation du rendu des pages webs, au moins sur PC. Personellement quand Firefox galère, j'ai l'impression que 90% du temps ça vient du Javascript, ce qui sort du coup du cadre de Servo.

  • [^] # Re: code server ?

    Posté par  (site Web personnel) . En réponse à la dépêche Servo fin 2015 : où en est-on ?. Évalué à 4.

    Iron, peut-être ? https://github.com/iron/iron

  • [^] # Re: Ce qui m’a fait tiquer…

    Posté par  (site Web personnel) . En réponse à la dépêche Rust versions 1.1, 1.2 et 1.3. Évalué à 4.

    «Une question pour ceux qui suivent ce langage de près, le langage est-il stable grammaticalement ?»

    Au niveau de la syntaxe c'est à peu près stable : du code écrit en version 1.0 devrait fonctionner pour toute 1.x, par contre ça ne veut pas dire qu'il ne peut pas y avoir de nouvelle fonctionnalité ajoutée au langage lui-même.

    Pour ce qui est de la bibliothéque standard c'est un peu différent : il y encore des fonctionnalités qui sont "unstable" (qu'on peut utiliser uniquement avec la version nightly) et qui, comme leur nom l'indique, peuvent changer ou disparaître dans les futures versions. Pour le reste normalement c'est aussi rétrocompatible pour 1.X.

    «Reste-il beaucoup de fonction à ajouter ?»

    Je pense que ça dépend ce dont t'as besoin ^ Perso je trouve que c'est en général utilisable, mais a) y'a des trucs qui peuvent/vont être améliorés b) il y a pas mal de bibliothèques tiers-partie qui sont assez jeunes (voire manquantes), ce qui est assez inévitable pour un langage récent.

  • [^] # Re: Maven

    Posté par  (site Web personnel) . En réponse au journal biicode, c'est fini. Évalué à 3.

    Dans l'absolu je suis plutôt d'accord avec ce que tu dis (pour écrire un tel outil ciblé pour un langage spécifique, ça me paraît effectivement avoir plus de chances de drainer un minimum de contributeurs si c'est écrit dans le langage en question), seulement il me semble que le commentaire de base ne disait pas « il faudrait écrire un tel outil pour le C++ en Java » mais simplement « moi j'ai réussi à me démerder en utilisant Maven », ce qui est quand même assez différent.

  • [^] # Re: Premières impressions

    Posté par  (site Web personnel) . En réponse à la dépêche Rust 1.0, entrée dans la période stable. Évalué à 2.

    En fait je crois que ce que j'avais pas très bien compris (j'espère que là je dis pas des conneries :) ) c'est qu'au départ je pensais que si le terme implémentait le trait Copy ça appelait la méthode "copy" correspondante. Sauf qu'en fait le trait Copy ne contient aucune méthode, il s'agit juste d'un marqueur pour dire que le compilateur peut copier la mémoire (avec un memcpy quoi en gros), il n'est pas possible de redéfinir une implémentation. Ça c'est possible de le faire avec le trait Clone, mais dans ce cas il faut appeler la méthode x.clone () explicitement.

  • [^] # Re: Premières impressions

    Posté par  (site Web personnel) . En réponse à la dépêche Rust 1.0, entrée dans la période stable. Évalué à 4.

    C'est effectivement pas possible, si on essaie par exemple le code suivant (pour étendre le trait Iterator au type u32) :

    impl Iterator for u32 {
        type Item = u32;
        fn next (&mut self) -> Option<u32> {
            *self = *self + 1;
    
            Some(*self)
        }
    }

    le compilateur renvoie le message d'erreur suivant :
    test.rs:1:1: 8:2 error: the impl does not reference any types defined in this crate; only traits defined in the current crate can be implemented for arbitrary types [E0117]

  • [^] # Re: Premières impressions

    Posté par  (site Web personnel) . En réponse à la dépêche Rust 1.0, entrée dans la période stable. Évalué à 2.

    Oui, en fait ce que je trouvais "bizarre" c'est que décider si c'est une copie ou un move soit «implicite» (en fonction de si le type implémente copy ou pas) alors que le reste (dire que c'est une référence, dire que c'est muable) est explicite.

  • [^] # Re: Les traits

    Posté par  (site Web personnel) . En réponse à la dépêche Rust 1.0, entrée dans la période stable. Évalué à 5.

    "Est-ce possible en rust ?"

    Oui tu peux avoir la même chose avec l'implémentation par défaut de traits.

    trait Plop {
        fn even (&self) -> bool {!self.odd ()}
        fn odd (&self) -> bool {!self.even ()}
    }
  • # Premières impressions

    Posté par  (site Web personnel) . En réponse à la dépêche Rust 1.0, entrée dans la période stable. Évalué à 7.

    L'annonce de la sortie imminente de la version 1.0 de ce langage m'avait motivée à m'y pencher un peu plus (j'avais regardé un peu suite aux différentes dépêches, mais vu les évolutions d'une version à l'autre j'avais préféré attendre que ça se stabilise).

    Bilan : je trouve les fonctionnalités un peu "annexes" (le pattern matching, l'inférence de type) plutôt sympathiques, certes c'est pas "nouveau" mais quand même plutôt bien foutu.

    Par contre la façon de gérer la mémoire… ouah, c'est quand même vraiment particulier, et autant le reste j'ai l'impression d'avoir déjà vu des éléments dans un langage ou un autre, autant là, il y a un coup de main à prendre. Je pense notamment à la notion de "lifetime", qu'il faut parfois déclarer en plus du type des variables pour indiquer que la référence que renvoie une fonction ne sera plus valable une fois que tel argument sera détruit. Une fois le truc un peu compris, ça paraît une bonne idée, mais ça m'a demandé de réfléchir un peu plus que la plupart des autres langages à la syntaxe "à la C". (Ce qui me rend dubitative sur l'attrait de Rust pour les fans de langages dynamiques : pour le coup le on a un compilateur que je trouve quand même fort psychorigide, ce qui est une qualité dans une logique de sécurité du code mais me paraît demander quand même une autre approche qu'un langage dynamique.)

    Globalement je trouve l'approche du langage intéressante, même s'il y a des choses qui me convainquent moyennement pour l'instant (notamment le fait que quand tu fais un appel à ma_fonction (x) ça peut être soit une copie, soit un move qui va transférer la «propriété» de la variable x à la fonction ma_fonction, ce qui empêche d'utiliser à nouveau la variable par la suite dans la fonction appelante). Peut-être que c'est une question d'habitude à l'usage, cela dit.

  • [^] # Re: .

    Posté par  (site Web personnel) . En réponse au journal systemd: je me lance. Évalué à 10.

    Ben d'après le journal ce qui se passe c'est que :

    Effectivement, au boot, j'ai un timeout puis le choix de retenter ou d'entrer dans un shell de secours.

    Je trouve que ça mangerait pas de pain de proposer une option supplémentaire pour continuer le démarrage en ne montant pas cette partition ce coup-ci.