raum_schiff a écrit 165 commentaires

On a vraiment besoin de la 5G ?

Effectivement le "parsage" de P5 -> P6 n'aurait eut aucun intérêt.

Même perl 5.10 va avoir du mal a interpréter du code utilisant les fonctionnalités réçentes.

Ces fonctionnalités sont contingentées, P5 reste P5; du 5.10 en core ne pourra pas interpréter (par ex)

use feature bitwise;

En revanche, le "use feature" est ici très utile pour isoler du code obsolète ou upgrader ce même code de façon progressive (les "feature guards" pouvant être scopées dans un bloc { … }

Toucher au CORE est une autre chose, je suis d'accord qu'une version majeure casse des choses, mais jusqu'à quel point ?

Vu le nombre gragantuesque de modules du CPAN, la ré-écriture des modules et de leur dépendances même en passant par inline-perl5 (qui encapsule le code dans un objet) aurai été cyclopéenne (et invoqué Cthulhu ?).

Je ne sais pas si un outil de conversion de code a été envisagé, mais même si cela avait été possible, la communauté l'aurait-elle accepté ?

Quand on voit la levée de boucliers sur P7 et ses changements mineurs, la réponse est (IMHO) non.
D'où le "fork" (terme a prendre ici avec des pincettes) de Raku.

Homère d'alors :

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

C'est vrai, ça a très mal vieilli …

Coucou,

Si Raku n'a pas "pris" en temps que "nouvelle" version de Perl c'est à cause (IMHO) de l'éloignement progressif de la syntaxe des deux langages qui a amené à l'éloignement des communautés.

Bouger un monolithe comme Perl qui mise sur la stabilité et la rétrocompatibilité vers des nouveaux paradigmes (Typage progressif des variables, Modèle objet intégral, Refonte des regex, Parser modifiable, etc ..) n'allait pas être une mince affaire. Rien que pour implémenter toutes les RFC de Raku avec une équipe réduite, cela pris plus de 10 ans (Un petit retour sur les RFC est dispo ici); si une fois effectif Raku a tendu la main à la communauté Perl, l'accueil a été plus que froid.

Cela peut se comprendre, si Raku est capable d'interpréter du Perl, l'inverse tient de de l'impossible. Un convertisseur 5 vers 6 aurait pu se faire, mais aurait demandé de très grands efforts des deux côtés. Vu que le torchon brulait déjà au sein d'une communauté qui au fur et à mesure des années est devenue de plus en plus conservatrice (le temps des mongeurs bienveillants envers les nouveaux est depuis longtemps passé, mais il reste heureusement beaucoup de types sympas), le cas était plié d'avance.

Si Raku ne prend pas en temps que langage propre, seul le temps le dira. L'objectif d'une version majeure de Perl n'étant plus d'actualité, il en va autant de l'efficacité rapide à des fins commerciales qui a poussé Perl dans les années 90/2000. Reste donc le "fun" ou la volonté d'enrichir le langage pour lui même, un langage qui a beaucoup à offrir.

Je pense quoiqu'il en soit que la mise en place prochaine d'un conseil décisionnaire apportera du grain à moudre quand à l'avenir de Raku.

Ponceto n'infère rien, c'est un témoignage à prendre comme tel.

Si tu ne t'y retrouve pas, c'est que cela ne correspond pas à ton expérience.

Sa "déduction" est assez optimiste et finit par des remerciements.

Je n'ai pas tout lu, mais je vais m'arrêter là dessus.

Oui, Hélas !

Je suis d'accord que donner un cadre historique à ces évolutions est pertinent.

Quant au côté inéluctable de la chose (même si il est plus présent dans les domaines complexes comme l'informatique), qui tend à faire une analogie avec la théorie Darwinienne de l'évolution je pense que c'est forcer un peu le trait ("Espèce menacée d'extinction").

Et c'est là que le filage de la métaphore Jurasic-Park s'arrête.

Contrairement à l'évolution des organismes, l'environnement qui conditionne la "survie" d'une technique est modifiable par ceux qui l'utilisent.
(Eg : Les trilobites ne pouvaient rien faire pour contrer les conditions de l'extinction du Permien)

C'est donc une question de choix d'environnement, et celui des "grandes corpos" comme tu les cite est effectivement toxique dans ce cas.

Le changement de nom de P6 vers Raku semble autant voulu des deux côtés (pour des raisons différentes) afin d'éviter l’explosion en vol.

La situation initiale était très toxique pour la communauté et la majorité des bonnes volontés de rapprochement des deux langages est venue des devs de Raku : Avec des portages ad-hoc de modules de Perl5 par Elizabeth Mattijsen et le module Inline::Perl5 (a noter qu’il y a aussi Inline::Python, mais c’est une autre histoire …).

Le retour de la Perl Fondation a été inexistant même si elle a financé et continue de le faire les travaux d’optimisation de la VM de Raku; la communauté quant à elle s’est montrée inintéressée voire hostile dans sa majorité.

Le changement de nom, IMHO à fait du bien aux deux parties, laissant certes Raku dans une position de faiblesse au niveau de ses ressources et de sa visibilité, mais a libéré des énergies qui auraient été gâchées par des querelles de chapelles. En optant pour un nouveau nom, Raku est sortit par la grande porte au niveau moral en laissant plus d’écho aux voix du changement dans la communauté Perl (Curtis Poe, Sawyer, et même Damian Conway).

Si le passage à P7 paraît mineur (il l’est, je ne le nie pas), il ouvre le chemin vers des modifications plus profondes ; modifications que j’espère, mais si le camp des conservateurs l’emporte (Sawyer même si il semble jouer sur du velours, mise gros sur ce coup là) et cela ne résulte que d’un coup d’épée dans l’eau, seule la communauté de Perl aura à s’en mordre les doigts et Camelia (ça aurait pu être un nom sympa, soupirs …) n’aura pas à en souffrir.

Pour en revenir à Raku, je pense aussi que c’est un excellent langage, compréhensible autant que compréhensif pour l’utilisateur qui offre la possibilité de produire du code clair (voir même naïf) pour des situations simples, et permet la complexification sans charge cognitive trop lourde.

Note : si Larry semble maintenant plus s'intéresser à ces petits enfants, c’est tout à son honneur.
Il a toujours insisté sur le côté humain du dev dans ses conférences, son attitude est donc linguistiquement autant pertinente que performative.

IMHO : Avoir utilisé le principe "feature guard" pour faire évoluer le langage tout en conservant une rétro-compatibilité ne pouvait pas durer éternellement.

Ce principe appelait d’emblée à une mise à jour de Perl, car la rendait possible techniquement.

Il ne manquait plus que la volonté "politique" (merci sawyerX) de faire le premier pas.

Bien sûr, le plus dur dans cette migration sera le CPAN (dont l’automatisation a été proposée ici).
Mais les mainteneurs de modules étant responsables de leur code, c’est bien à eux de déterminer ou non la migration à terme de leur modules dans la branche 7 : si en plus, l’équipe du core de Perl leur propose les outils nécessaires pour le faire, les dents vont moins grincer.

Pour tout le code ≤ 5.8 sans flag strict et warnings qui tourne déjà sur des distrib pas upgradées depuis 10 ans il finira peu à peu dans des containers ou sera remplacé.

A bien y réfléchir, la fenêtre de temps d’environ 9 mois entre le renommage de Perl6 en Raku a libéré les esprits, pour le mieux.

Tous mes vœux de réussite aux prochaines versions de Perl (et Raku évidemment) !

Pour de l'aide sur P6 => Raku :

• A approfondir, voir liens proposés
• Pour historique, oui c'est vieux !

Sinon Elizabeth Mattijsen et Jonathan Worthington se feront un plaisir de répondre aux questions posées sur Raku.

Sawyer X fera de même en temps que Pumpking de P5.

Vidéo explicative pour les curieux, et les autres …

• Pourquoi 7 en numéro de version
• La compatibilité future 5/7
• etc.

https://www.youtube.com/watch?v=6wPMh-3qYJM&feature=youtu.be&t=2973

Perl 7 is going to be Perl 5.32, with saner, more modern defaults.

Citation : https://leanpub.com/preparing_for_perl7

La prochaine marche "pourrait" être une révision de l'OO : https://github.com/Ovid/Cor/wiki

à voir …

La réponse se trouve peut-être par ici (pour Debian) : https://unix.stackexchange.com/questions/332909/update-upgrade-debian-and-skip-any-interactions

La distrib va installer les paquets avec une config par défaut et/ou vide/minimale.

Par contre ton script devra lui même éditer les fichiers de config avec les valeurs voulues suivant le prompt que tu donneras à l'utilisateur.

Merci !

Je vais m'auto-citer depuis ce post :

l'exemple donné ne l'était qu'à son propre titre, dans le contexte des regex

Donc cet exemple n'était pas "utile", mais démonstratif dans son concept.

Pour parser des trucs plus complexes, si tu aimes yacc et/ou des grammaires BNF (avec des jolis pipes), libre à toi. Chacun utilise les outils qu'il veut même quand (note le point d'interrogation) on est con … non ?

C'est étrange qu'on parle de regex, alors qu'une bonne compréhension du Français devrais suffire, mais bon les posts à la tl;dr avec réaction épidermique ça fatigue à la longue.

Certes, dans le cas d'une date seule, il est plus facile d'utiliser les types natifs d'un langage et de les comparer avec la validité d'une entrée.

> my $कामसूत्र = Date.new('0100-02-29');
Day out of range. Is: 29, should be in 1..28

Intéressant de savoir que l'année 100 a été bissextile, et qu'elle correspond à l'année de compilation des textes du कामसूत्र en Inde ….

Mais, pour mémoire, le sujet initial était sur les regex et l'exemple donné ne l'était qu'à son propre titre, dans le contexte des regex où la logique vient après le match.

Le but d'une regex est de valider des formats d'entrés typographique, la logique vient après.

Vu que comme le dit 'OP, "ça va bien cinq minutes" (et que midi approche) :

• On peut aussi ajouter du code dans la regex
• Ou faire un post-traitement sur l'ast résultant de la la grammaire

Juste à titre d'exemple :

grammar rdate {
    rule  TOP        { 
        <year> <separator> <month> <separator> <day>
        { self.check(self.year,self.month,self.day,self.separator) }
    }
    token separator           { '/' || '.' || '-' }
    token year                { '-'? <[0..9]> ** 4 }
    token month               { '0'<[0..9]> || '1'<[0..2]> }
    token day                 { '0'<[0..9]> || <[1..2]><[0..9]> || '3'<[0..1]> }
    method check($y,$m,$d,$s) {
        # Code de vérification ici
    }
}

class rdate-actions {
    # Code post-traitement ici.
}

La doc pour bien commencer est ici

Bon app'

Non … c'est une typo, j'aurais dû faire partir la deuxième range de 0

:-)

Merci pour la correction.

Une bonne cheat sheet pour pcre.

Merci pour le lien !

Mais ces temps-ci j'écris ce genre de choses (https://ihateregex.io/expr/date) comme ça :

grammar rdate {
    rule  TOP        { 
        <year> <separator>  <month> <separator> <day>
    }
    token separator  { '/' || '.' || '-' }
    token year       { <[0..9]> ** 4 }
    token month      { '0'<[0..9]> || '1'<[1..2]> }
    token day        { '0'<[0..9]> || <[1..2]><[0..9]> || '3'<[0..1]> }
}

Mais c'est une autre histoire, et je ------->[]

On réinvente la roue, car celle-ci semble mal tourner.

L'aspect descriptif de l'économie posé par Adam Smith se traduit, IMHO, par une mauvaise interprétation performative de celle-ci par les acteurs majeurs de la pensée économique actuelle, qui l'on adopté comme invariant.

"The Theory of Moral Sentiments" et "Nature and Causes of the Wealth of Nations" sont des ouvrages qui se veulent scientifiques à une époque où la séparation entre philosophie et sciences était à peine en train de se construire. Or si on parle de "Morale" et de "Richesse" on se doute de tout l'aspect performatif et politique que cela peut induire.

Sauf qu'on peut légitimement penser que l'application de la loi la concernant à l'époque était une violation manifeste de l'État de droit américain et du concept des Droits de l'Homme.

Du fait de la constitution américaine basée sur le système des Check and Balances, le moyen le plus rapide pour contraindre l'état d'Alabama à changer sa loi était de violer cette loi, donc de rentrer dans l'illégalité.

La loi n'a rien avoir avec la démocratie et l'humanisme, elle est le reflet d'un type de gouvernance.

Or, il n'y a rien de naturel ou d'évident à penser que ses revendications propres sont supérieures à celle des autres. Et donc à même de justifier une violation de la loi pour ça.

"naturel" encore de l'essentialisation.
Si la loi était naturelle, toute pensée hors de la loi serait hors nature.

Il faut aussi respecter l'État de droit et la démocratie dans la procédure. Faire des actions sans bases légales ne vont pas dans ce sens. Sinon cela revient à penser que ses revendications sont d'un intérêt supérieur à celui des autres ce qui n'est pas une pensée humaniste.

Attention à ne pas essentialiser le propos …

Ce qui peu mener à penser que Rosa Parks n'a pas eu de pensée humaniste.

La première phrase de la citation se suffit à elle même, la deuxième si je puis, dire est de "trop", car très orientée politiquement.

A en juger par les réactions de certains usagers de la plateforme dans l'article de mediapart:

Dans le numérique, un blocage est plus efficace qu'une grève.

A méditer.