Pegjs: Comment définir une règle pour correspondre plusieurs fois à un modèle dans PEG.js ?

Veuillez lire les exemples de grammaires peg. Il n'y a pas de bogue ici. Les outils de suivi des problèmes ne sont pas destinés aux demandes d'aide. L'un des exemples de grammaires correspond exactement à ce que vous demandez.

L'endroit approprié pour les demandes d'aide est StackOverflow. Les trackers de problèmes sont ce que les développeurs utilisent pour garder une trace de ce qui est cassé et quels référentiels de packages utilisent pour mesurer la qualité du projet.

Document
  = ClassRow+

ClassID
  = "G04"

ClassTitle
  = title:[^\n]+ { return title.join(''); }

ClassRow = 
  id:ClassID title:ClassTitle '\n'? { return { id, title }; }

Une fois que vous avez vu cela, veuillez fermer ce problème. Merci.

La clé est d'apprendre à lire les grammaires PEG. Ça dit:

1. "Un Document est un ou plusieurs ClassRow s."
2. "A ClassID est la chaîne fixe "G04" ."
3. "Un ClassTitle est n'importe quel texte jusqu'à la prochaine nouvelle ligne, mais sans l'inclure. Vous appellerez cela "titre". Renvoyez le titre sous forme de chaîne, pas un tableau de caractères."
4. "Un ClassRow est un ClassID suivi d'un ClassRow .

Étant donné que ClassRow se termine par un retour à la ligne, un retour à la ligne commence effectivement la nouvelle ligne.

Je vais utiliser StackOverflow pour mes autres questions, merci pour la réponse et les explications.

Cependant, il y a certaines choses que je veux exprimer :

1. La partie "Type de problème : Question : [oui/non]" est un peu trompeuse par rapport à la directive que vous avez mentionnée. J'ai interprété cette section comme "Le suivi des problèmes est le bon endroit pour poser des questions"
2. "examples": Je peux voir 4 exemples de grammaires dans le dossier examples/ . Cependant, à mon humble avis, aucun d'entre eux ne convient (assez simple) aux débutants (comme moi, ou pour moi) à l'exception du "arithmetics.pegjs". Je comprends que PEG.js est en cours de développement (lourd ?), Il est donc tout à fait compréhensible que vous soyez plus concentré sur des problèmes/scénarios complexes du monde réel. Je m'attendais juste à des exemples étape par étape de grammaires simples à complexes.

Veuillez considérer cela comme un commentaire de nouveau venu.

La partie "Type de problème : Question : [oui/non]" est un peu trompeuse par rapport à la directive que vous avez mentionnée. J'ai interprété cette section comme "Le suivi des problèmes est le bon endroit pour poser des questions"

Je suis d'accord. Je veux supprimer ce texte et j'ai demandé à le faire en 2017.

La raison pour laquelle le texte est là est que David, qui ne dirige plus cette bibliothèque, en avait assez que les gens disent "c'est un bogue" sans examiner les problèmes et trouver l'autre personne qui pensait qu'il y avait un bogue, et il n'y en avait pas

Ce problème, par exemple, a une demi-douzaine de clones

.

"Examples": Je peux voir 4 exemples de grammaires dans le dossier examples/. Cependant, à mon humble avis, aucun d'entre eux ne convient (assez simple) aux débutants (comme moi, ou pour moi) à l'exception du "arithmetics.pegjs".

Je suis d'accord. J'aimerais en écrire beaucoup.

.

Je comprends que PEG.js est en cours de développement (lourd ?)

Ce n'est certainement pas le cas.

L'auteur original l'avait laissé inactif pendant un an, il a donc demandé de nouveaux responsables.

Le nouveau mainteneur qui a pris la relève en mai 2017 n'a pas publié un seul octet de code pour la branche master.

J'ai commencé le processus d'agitation pour une prise de contrôle, car l'utilisation de la bibliothèque diminue, la bibliothèque ne prend pas en charge le javascript à partir de 2014, il n'y a pas eu de readme sur NPM depuis près de trois ans, les correctifs AST à un seul caractère sont sans réponse depuis un an dans les problèmes, et le nouveau responsable a décidé de jeter 2,5 ans d'une branche de fonctionnalités qu'il a marquée comme fermant une tonne de problèmes, et de remplacer toute la bibliothèque par quelque chose de nouveau qu'il a écrit lui-même dans une autre langue

.

il est tout à fait compréhensible que vous soyez plus concentré sur des problèmes/scénarios complexes du monde réel. Je m'attendais juste à des exemples étape par étape de grammaires simples à complexes.

Je crois que l'intégration des utilisateurs est probablement le problème le plus important dans le monde réel en ce moment après avoir rétabli la santé de cette bibliothèque

Pour plus de clarté, je ne suis pas l'auteur original. @dmajda est.

Pour plus de clarté, je ne suis pas le mainteneur. Il n'y a pas de mainteneur.

La partie "Type de problème : Question : [oui/non]" est un peu trompeuse par rapport à la directive que vous avez mentionnée. J'ai interprété cette section comme "Le suivi des problèmes est le bon endroit pour poser des questions"

@ceremcem , vous avez tout fait correctement (à part ce que vous n'avez pas regardé la description de PEG sur wikipedia et de ne pas essayer d'analyser votre grammaire manuellement, après quoi votre question, à mon humble avis, serait résolue). Vous ne pouvez pas savoir que votre question est simplement une question ou une description d'un bogue dans la bibliothèque. Cela ne peut être décidé que par le développeur. Par conséquent, il n'y a pas de règle GitHub uniquement pour les bogues . Le problème est le problème même en Afrique

en général , un outil de suivi des problèmes est destiné aux problèmes, pas aux questions

ceremcem aurait obtenu une réponse en quelques heures sur stackoverflow. ici, il a attendu neuf jours, et si je n'avais pas parlé, je pense qu'il n'aurait pas eu de réponse.

de nombreuses questions similaires comme celles-ci sont sans réponse ici après un an ou plus. il y en a une demi-douzaine qui ont huit ans.

.

Vous ne pouvez pas savoir que votre question est simplement une question ou une description d'un bogue dans la bibliothèque.

Oui il peut. Il demandait "comment puis-je faire cela?"

À moins qu'il ne pense que l'analyseur ne peut pas faire cela, ce n'est jamais un bogue.

C'est fondamentalement la chose la plus simple possible dans un analyseur, et je crois que peg est toujours l'analyseur javascript le plus utilisé, bien que cela cesse rapidement d'être vrai, et il semble être intelligent, donc je ne pense pas il croyait qu'un générateur d'analyseur ne pouvait pas utiliser une règle plus d'une fois

Dans son meilleur intérêt, il est idéal de le diriger vers une ressource conçue pour les questions, plutôt que pour la réparation de la bibliothèque, surtout si la ressource de question est très active et que la ressource de réparation de la bibliothèque vient d'annoncer qu'elle saborde trois ans de travail et ignore généralement des questions comme celles-ci

Ce n'est pas une coïncidence si cela est resté sans réponse jusqu'à ce que je commence à taguer les gens, comme l'ont fait une demi-douzaine d'autres problèmes jusqu'à présent

Aucune décision n'est prise. Je lui donnais des conseils.

Aussi, j'ai répondu à sa question .

J'obtiens généralement une réponse en quelques heures dans StackOverflow, donc j'en suis un utilisateur régulier. Cependant, il n'y avait aucune activité sur ma question SO , alors je suis venu et j'ai demandé ici. Fondamentalement, les temps de réponse sont presque identiques.

J'ai vu toutes les combinaisons d'utilisation du suivi des problèmes :

• Pour les rapports de bogues uniquement, si un forum ou un groupe de messagerie distinct est fourni (PaperJS, par exemple),
• Pour les questions et les rapports de bogues (RactiveJS <3, FreeCAD_Assembly3 <3)
• Pour quelque chose que je ne comprends pas vraiment, avec un forum séparé, où les suspects habituels ont pris le relais et parlent au nom des propriétaires de projets, ce qui cause plus de frustration qu'autre chose (comme KiCAD (grrr))
• Pour rien (Espruino, AFAIR). Chaque problème est immédiatement fermé et vous êtes obligé d'ouvrir un fil de discussion approprié dans leur forum.

Il n'y a pas de meilleur choix pour cela (personne ne convient à tous les cas), mais j'aime utiliser le suivi des problèmes pour tout.

Vous ne pouvez pas savoir que votre question est simplement une question ou une description d'un bogue dans la bibliothèque.

Nous avons vu cela plusieurs fois sur la bibliothèque FreeCAD_Assembly3. Beaucoup de mes questions simples et stupides ont révélé un ou plusieurs bogues. Cela arrive, j'ai vu.

Je suis d'accord. J'aimerais en écrire beaucoup.

J'aime votre approche de cette bibliothèque. Tu sembles beaucoup t'en soucier.

donc je ne pense pas qu'il croyait qu'un générateur d'analyseur ne pouvait pas utiliser une règle plus d'une fois

Correct. Mon intention n'était pas un rapport de bogue. Je n'ai tout simplement pas trouvé le moyen de réutiliser la même règle pour plusieurs lignes.

Cependant, il n'y avait aucune activité sur ma question SO, alors je suis venu et j'ai demandé ici.

Oh mec, la communauté peg est-elle morte aussi?

C'est tellement triste ☹️

D'accord, si vous avez déjà publié un message SO, alors à ce stade, vous avez raison à 100 % de venir ici

.

J'ai vu toutes les combinaisons d'utilisation du suivi des problèmes :

Oui, les gens violent tout le temps les normes communautaires

.

Je suis d'accord. J'aimerais en écrire beaucoup.

J'aime votre approche de cette bibliothèque. Tu sembles beaucoup t'en soucier.

Beaucoup. Je voulais être impliqué dans la transition de propriété de 2017, mais quelqu'un a donné un plan avec 17 versions majeures, et l'ancien propriétaire les a crus

Cette personne a renoncé à sa première version mineure trois ans plus tard.

La vérité est que les logiciels publics sont vraiment difficiles à écrire. Presque tout le monde que je connais, y compris moi-même, a tendance à dire "cette version n'est pas prête tant que X, Y et Z ne sont pas terminés".

Et puis lorsque Y se termine, vous réalisez que vous avez également besoin de V et W.

Et puis lorsque Z se termine, vous réalisez que vous avez également besoin de S, T et U.

Et puis quand V se termine...

C'est ainsi que 0.11.0 a commencé avec une demi-douzaine de fonctionnalités en 2017, et est mort avec une centaine de fusions incorrectement marquées fermées dans le tracker en 2020

Une partie de la discipline des logiciels publics consiste en de petites versions fréquentes. Cela a toujours été un problème avec peg, mais la qualité du logiciel était si élevée que nous l'avons quand même supporté.

Puis dmajda est parti, et tout s'est arrêté.

Et nous avons attendu, patiemment, longtemps.

Mais le nouveau gars appelle maintenant cela son projet de passe-temps et dit qu'il a tout abandonné au profit de quelque chose de nouveau et d'incompatible qu'il a écrit. Et même s'il avait le même AST et le même ensemble de fonctionnalités et plus, il n'aurait pas dix ans de débogage communautaire derrière lui, et je ne pourrais pas changer

Et vous savez, s'il veut écrire un nouvel analyseur PEG plus puissant, très bien, allez-y.

Mais il ne peut pas tuer celui-ci en faisant semblant d'être un mainteneur puis en ne maintenant jamais, puis en prenant le contrôle de la communauté et de la position de celui-ci, et en mettant son propre logiciel qui ne sera jamais publié à sa place

Il est temps qu'un processus sain reprenne le dessus. Le nouveau mainteneur a construit une micro-communauté de développeurs juniors, et ils préconisent en fait de garder la bibliothèque morte plutôt que de la sauver

Il est clair que le changement est absolument nécessaire

.

Je n'ai tout simplement pas trouvé le moyen de réutiliser la même règle pour plusieurs lignes.

Si vous avez encore du mal à trouver des réponses, n'hésitez pas à me taguer personnellement

Cela dit, je cherche généralement des exemples sur Google, et parce que cette bibliothèque était autrefois si populaire et très utilisée (et peut l'être à nouveau si les meurtriers actuels de la bibliothèque font juste de la place sur le banc pour qu'une autre personne puisse aider), il y a plus qu'assez d'exemples là-bas pour couvrir les choses que vous aurez besoin de trouver

En général, cependant, ce que j'aurais aimé que quelqu'un me dise quand j'étais nouveau, c'est ce que j'ai dit sous le commentaire commençant par "La clé est d'apprendre à lire les grammaires PEG"

Une fois que vous apprenez à lire les grammaires PEG sous cette forme de discussion, il devient également très facile d'y penser, et à ce stade, elles sont soudainement trivialement faciles à écrire.

C'est comme un interrupteur. Pas de rampe. De l'impossible au facile

C'est comme un interrupteur. Pas de rampe. De l'impossible au facile

Vous m'avez encouragé ! :) Donc je ne devrais pas me sentir si stupide quand je ne pouvais voir que des ensembles de règles "charabia" :)

Si vous avez encore du mal à trouver des réponses, n'hésitez pas à me taguer personnellement

Je ne veux pas abuser de cela, donc ce sera difficile d'appeler à chaque fois si cela vaut la peine de demander ou si je dois chercher un peu plus sur le net. C'était une offre généreuse, merci.

Il est clair que le changement est absolument nécessaire

Je vois que vous avez activé la section "problèmes" dans votre fork. C'est toujours un bon signe de tenter de piloter un avion de ligne en se précipitant dans le cockpit alors que vous n'étiez qu'un passager. C'est une bonne chose.

S'il y a une source d'eau vive, elle trouvera toujours son chemin, peu importe ce que vous mettez sur son chemin. S'il n'y a pas de débit parce que sa source est drainée, il n'y a rien à faire. La source est la demande. Votre attitude indique que la source de l'eau est très vivante.

Alors je suis curieux, pourquoi ne prends-tu pas le relais ? C'est ce que j'ai fait pour la bibliothèque de barres de chargement . J'ai réalisé que le développement était au point mort, j'ai donc pris le relais en abordant les problèmes en partant des miens et en créant des pull requests pour chaque branche. Quelque temps plus tard, l'auteur original a décidé de continuer son travail, et nous étions prêts à partir. Pensez-vous que c'est une solution réalisable?

Vous m'avez encouragé ! :)

Je suis contente.

.

C'est comme un interrupteur. Pas de rampe. De l'impossible au facile

Donc je ne devrais pas me sentir si stupide quand je ne pouvais voir que des ensembles de règles "charabia" :)

Non. Les analyseurs sont un cas extrême de la chose "c'est juste ridicule et puis tout d'un coup c'est facile".

Voici le kicker - comparativement parlant, la cheville est assez facile. Les autres sont souvent simplement brutaux.

Il y a à mon avis quatre gros problèmes dans l'apprentissage du peg.

1. Il n'y a pas de matériel d'introduction vraiment bien structuré
2. Il existe de nombreux exemples de niveau intermédiaire, mais vous devez être bon sur Google pour les trouver.
3. Il y a aussi de mauvais exemples là-bas et il faut de l'expérience pour pouvoir les identifier
4. Vous devez être capable de "penser de cette façon", et cela ne se produit pas immédiatement

J'ai envisagé de faire des tutoriels vidéo. Ils rendraient cela _loin_ plus facile à comprendre, je crois.

.

Je ne veux pas abuser de ça, donc ça va être dur d'appeler à chaque fois si ça vaut la peine de demander

Une fois par semaine c'est bien. Comprenez que je suis parfois lent à répondre

.

Je vois que vous avez activé la section "problèmes" dans votre fork. C'est toujours un bon signe de tenter de piloter un avion de ligne en se précipitant dans le cockpit alors que vous n'étiez qu'un passager. C'est une bonne chose.

J'ai à peine commencé. D'abord, je veux voir si le vrai repo peut simplement être sauvé

Faire cela à partir d'une fourchette serait obscènement plus difficile. Je perdrais tous les PR et toutes les références croisées, et tout le matériel fermé non fusionné ou fermé supprimé, dont certains sont très précieux

.

Alors je suis curieux, pourquoi ne prends-tu pas le relais ?

J'aimerais.

À l'heure actuelle, les mots de passe et l'authentification pertinents sont entre les mains d'une seule personne, et elle n'a pas encore répondu.

Nous verrons.

.

J'ai réalisé que le développement était au point mort, j'ai donc pris le relais en abordant les problèmes en commençant par les miens et en créant des pull requests pour chaque branche

C'est un cas particulier

Ce qui est publié est 0.10.0

Le nouveau mainteneur a permis à la branche 0.11.0 de se développer sans limite pendant trois ans, puis a décidé qu'elle était annulée, en faveur d'un 0.12.0 qu'il écrit à partir de zéro de manière isolée

Il n'y a rien à quoi mettre des PR. Ce qu'il y a dans npm date de 2017, et ce qu'il y a dans github sous le nouveau mainteneur est annulé après trois ans sans jamais avoir été publié

.

Quelque temps plus tard, l'auteur original a décidé de continuer son travail, et nous étions prêts à partir. Pensez-vous que c'est une solution réalisable?

Si le mainteneur de remplacement est prêt à le permettre, c'est à peu près exactement ce que je veux.

Je doute un peu que David revienne, mais s'il le fait, ce serait fantastique

En tant que tel, je veux transformer cela en un projet open source standard à nouveau

Quels sont les 3 problèmes les plus importants ici, selon vous ?

Je pense que dire quels sont les problèmes les plus importants pour moi est un peu dangereux, car il y a un bon nombre de personnes ici avec plus d'expérience que moi dans peg , et s'ils disent "en fait, c'est autre chose, " Je suis susceptible d'écouter.

À cette fin, je tiens à avertir que même si je suis heureux de développer ici, mon intérêt ici est en tant que mainteneur .

C'est, je pense, quelque chose que beaucoup de gens ne comprennent pas : le codage de développement et de maintenance est vraiment, vraiment différent.

• Development coding veut de grandes nouvelles idées, de nouvelles fonctionnalités, de nouvelles idées flashy.
• Maintenance coding veut résoudre de petits problèmes avant qu'ils ne s'aggravent et ne rendent quelque chose de bon inutilisable.

Je suis heureux de faire du codage de développement - peut-être même que j'en ai hâte - mais il y a d'autres personnes ici qui sont mieux adaptées à cela. Et donc, je veux être clair : mon objectif réel est de faire en sorte qu'ils puissent à nouveau contribuer aux relations publiques, comme ils le faisaient auparavant.

Cela dit, pour montrer quel est mon point de vue personnel :

1. Retrouver une cadence de publication régulière

peg.js ne doit plus jamais avoir de branche magique. C'est comme le putain d'anneau unique. Ça sonne bien et puissant, mais ça ne marche pas, et à la fin, tu es Gollum. Ce n'est pas svn . Dans la voix de Steve Ballmer, feature branches , feature branches , feature branches , feature branches .

Une version doit être le résultat d'une fonctionnalité, et non un point de collecte pour un plan de fonctionnalités. Nous ne sommes pas une entreprise des années 1980 et nous ne devrions pas planifier comme telle.

La seule fois où plus d'une fonctionnalité devrait être intégrée en même temps, c'est quand c'est inévitable, comme à la suite de correctifs de fonctionnalités pour faire face à une mise à niveau externe, ou des choses qui ne peuvent vraiment pas être faites séparément. Oh, vous pensez que c'est lié à une autre fonctionnalité ? Super, mettez-le dans 2.31.0 , nous devons sortir 2.29.0 et cette autre chose là-bas est susceptible d'être 30 .

Les gens traitent les mineurs comme s'ils étaient majeurs. C'est pourquoi le mineur n'est jamais sorti : il a été accroché au même piège comportemental qui accroche les majeurs. Ne fais pas ça putain de ™.

Pour être précis,

• Les gens ont, je crois, en grande partie perdu la foi que cette bibliothèque existe plus.
• Trois mois de sorties hebdomadaires inciteraient les gens à lui donner une autre chance.
  
  
  
  • Trois mois de sorties hebdomadaires seraient en fait super faciles à réaliser
  
  
• Si nous ne sortions pas seulement 0.12.0 , mais aussi 0.13.0 - et remarquez que je ne dis pas ce qu'ils contiennent, et je pense que cela n'a pas d'importance - alors nous serions avoir un vrai coup à 1.0.0
• En parcourant les relations publiques ouvertes et fermées non fusionnées ici, il y a une énorme quantité de puissance et de beauté, avec un commentaire de 2015 ou plus comme "J'y reviendrai plus tard". Être une personne généreuse et trouver de la place pour partager l'autorité aiderait peg non seulement à prendre vie, mais à s'épanouir
• À cette fin, je ne veux pas être l'artiste. Je veux être le conservateur.

2. Obtenir la documentation et les tests dans un endroit acceptable

Tout le monde en parle, mais ma machine à états finis passe-temps a actuellement 3500 tests unitaires et une couverture de documentation à 100%, alors, prenez-moi plus au sérieux.

Je crois profondément aux tests.

Il y a une autre bibliothèque que j'ai écrite qui est deux fois plus petite et beaucoup moins complexe que la machine d'état. Il est beaucoup plus facile d'apporter des changements de langage radicaux à la machine d'état que de petits changements au gestionnaire de réseau, car le gestionnaire de réseau est mal testé et vous devez faire de réels efforts pour vous assurer que quelque chose est correct.

Le FSM ? Non, les tests sont super, ils t'attraperont

Ce contraste spécifique me rappelle avec une clarté brutale chaque fois que je touche l'un d'eux à quel point les tests sont réellement importants pour que quelque chose soit, pour moi du moins, digne de confiance.

Je pense qu'une très grande partie du problème avec le travail sur peg.js est que les tests et la documentation sont en pagaille. Je pense qu'il est temps que cela change.

3. Supprimer les bêtises hipster.

• Je ne suis pas une personne Ruby, mais les gens de Ruby ont un vrai point de vue sur la configuration par convention. Je ne connais pas Ruby du tout, mais je peux toujours m'asseoir et savoir comment un projet fonctionne, parce que c'est comme ça qu'ils fonctionnent tous, et si je n'obtiens pas quelque chose, je peux demander à quelqu'un, et ils n'ont pas besoin d'y accéder, parce que c'est comme ça qu'ils fonctionnent tous
• peg fait face à quatre problèmes à cet égard
  
  
  
  1. peg est une bibliothèque javascript extrêmement ancienne, et elle a fait tout un tas de choix fondamentaux avant que les normes communautaires n'existent. en fait, plusieurs normes communautaires sont dues à david; avant le peg, beaucoup de gens pensaient que le multipackaging était difficile, alors maintenant que l'un des pionniers à cet égard est problématiquement en retard dans le même domaine, c'est un peu déchirant. Cela dit, en plus des choses brillantes que David a faites à l'avance, certaines choses qu'il s'est trompées et certaines choses qui étaient bonnes à l'époque ne le sont plus. De nombreux petits changements entraîneraient un changement radical dans l'expérience des développeurs.
  
  
  2. Les normes communautaires doivent être rétablies.
     
     
     
     
     
     1. Un node est censé fonctionner de certaines façons. Cela inclut la production d'une sortie ciblée sur le navigateur, et donc, un projet de nœud est clairement la bonne façon moderne de travailler
     
     
     
     2. Il s'agit toujours d'un projet de navigateur avec une automatisation faite à la main. Cela devrait changer
     
     
     
     3. C'est un défi d'apprentissage important de se mettre en position de modifier correctement le README . Après trois ans, le mainteneur actuel n'a toujours pas réussi (!), et le développeur d'origine non plus dans les deux dernières versions
        
        
        
        
        
        
        
        • C'est idiot. Des parties du projet qui devraient être triviales se cassent parce qu'elles ne sont pas réalisées de la manière la plus simple et la plus normale. Ils doivent être effectués de manière simple et normale, mais cela nécessite quelqu'un qui connaît le nœud et qui est prêt à faire un travail ennuyeux.
        
        
        
        
     
     
     
  
  
  3. peg est à la fois le bénéficiaire et la victime d'une automatisation extrême.
     
     
     
     
     
     • Il est probable que dmajda n'aurait pas pu aller aussi loin sans lui. Je ne peux certainement pas sur mes affaires.
     
     
     
     • Cependant, il s'agit de l'automatisation de 2011, pas de l'automatisation de 2020
     
     
     
     • C'est aussi l'automatisation de 2013, 2014, 2016 et 2018. Ce truc est réparti sur zeit, maintenant, les pages github, un compte personnel yahoo, gitlab, plusieurs services de suivi et de déploiement automatique étranges, et probablement un tas de choses que je n'ai pas encore trouvées
     
     
     
     • C'est juste un outil pour survivre à un effondrement ou jouer avec la nouvelle chose. Une sélection minutieuse des outils conduit à la permanence par conception. Le repl réel dure presque dix ans maintenant. Tout le reste peut l'être aussi, si "ooh brillant" est traité comme un drapeau rouge.
     
     
     
     • Cela devrait être déplacé vers gh pages et gh actions , ce que tout le monde comprend, et laissé seul pour toujours
     
     
     
  
  
  4. Le nouveau mainteneur a choisi de plonger profondément dans des outils peu communs et des stratégies marginalisées. En conséquence, vous devez installer un nouveau gestionnaire de packages pour apporter des corrections de bogues et apprendre une mise en page source peu commune qui coexiste, de manière déroutante, avec un ensemble de sources sans rapport qui semble être le produit réel, dans la mise en page source normale.
     
     
     
     
     
     • Lorsqu'un tiers a proposé un correctif permettant au gestionnaire de packages de langage standard de fonctionner également, il l'a rejeté.
     
     
     
     • Ce genre de comportement est franchement inacceptable dans un projet communautaire. Cela rend la bibliothèque beaucoup plus difficile à contribuer.
     
     
     
     • Plusieurs de ces outils extrémistes ont été remplacés par d'autres outils extrémistes, donc il ne va pas pour des choses qu'il connaît ; il essaie des choses. En attendant, nous attendons les bases, comme les fautes d'orthographe dans l'AST, comme la correction du readme sur npm , ou la fusion es6 modules , pendant trois ans à la fois.
     
     
     
     • Franchement, dans un rebake 0.12.0 , des choses comme le module dans le truc du fil de module sortiraient tout simplement. Les trucs de construction de David fonctionnent depuis 2011. Les nouveaux trucs de 2018 sont déjà cassés en 2020. Plus de technologie dilettante.
     
     
     
  
  
• ET PUIS-JE S'IL VOUS PLAÎT OBTENIR UNE EXPORTATION ES6

mais vous remarquerez qu'aucun de ceux-ci ne concerne réellement le logiciel en soi

je ne pense pas que le logiciel soit le problème

je pense que le processus est, et dans une moindre mesure, le projet

c'est ce que je vais corriger, si @futagoza le permet

cette bibliothèque peut reprendre vie dans 30 jours si nous ravalons notre fierté et choisissons les besoins de la grande communauté de la bibliothèque plutôt que nos intérêts de projet de passe-temps

laissez le passe-temps réécrire être la fourchette

laisser un mainteneur commencer à maintenir

@StoneCypher J'aime ton énergie :-) J'utilisais pegjs dans le passé (à l'époque de dmajda) et j'aimais beaucoup ça.

Il suffit de le bifurquer et de ne pas se battre. Les choses peuvent et vont s'arranger plus tard. Si la communauté vous suit, vous n'avez pas besoin de vous soucier du "détenteur de clé" existant ou de quelque chose comme ça. Construire une réputation prend du temps mais est nécessaire. Ne perdez plus de temps à vous disputer.

Huit votre fourchette la fera "retourner à l'origine" à un moment donné dans le futur ou elle aura sa propre vie. Les deux options sont valides et fines IMO.

S'il vous plait, arrêtez avec les conneries "faire une fourchette". Il y en a quatre et vous ne savez pas ce qu'ils sont. Un fork ne sauvera aucun des consommateurs en aval existants, ne sauvera pas les PR, ne sauvera pas les problèmes, ne portera pas la communauté et ne sera pas visible.

Les gens essaient cela depuis trois ans. ÇA NE MARCHE PAS.

Ne continuez pas à offrir ce conseil.

@futagoza - tout le monde a renoncé à ce que tu fasses la bonne chose. Cinq personnes m'ont dit de bifurquer la bibliothèque, car ils s'attendent à ce que vous refusiez d'autoriser la réparation et que vous gardiez le contrôle de la bibliothèque que vous tuez.

Je crois que la raison pour laquelle ils s'attendent à cela est que j'ai trouvé plus d'une douzaine de personnes qui vous proposent de l'aide pour faire ce que vous avez promis de faire et que vous n'avez jamais fait, et chaque fois que vous dites "non, je vais le faire bientôt". "

Faites ce que vous auriez dû faire en 2018 et confiez la maintenance à quelqu'un qui s'occupera réellement de la maintenance du projet. Arrêtez de tuer cette bibliothèque, arrêtez de tuer cette communauté et écartez-vous.

@StoneCypher John, quand j'ai suggéré de créer un fork, je le pensais vraiment. Forker un projet est une excellente option que l'open source vous offre, surtout si vous pensez qu'il a besoin de changements ou qu'il est en train de mourir. Et non, je n'ai aucun problème, vous n'avez pas besoin de m'écrire en DM juste pour me poser cette question.

Quand j'ai dit "ne donnez plus ce conseil", je le pensais aussi vraiment.

J'adore cette conversation.

@StoneCypher Je dois être en désaccord avec vous ici, car j'ai vu exactement le contraire :

1. J'ai décidé de commencer à apprendre FreeCAD. Cependant, il y avait un problème : son "Module d'assemblage" n'était pas complet, nous étions donc quasiment incapables de créer des assemblages complexes ce qui le rend inutile pour un travail professionnel.
2. Un gars, realthunder a décidé de résoudre ce problème. Il avait besoin de changer certaines propriétés de base pour atteindre l'objectif, ce qui rendait son fork incompatible avec la branche principale. Il a perdu tous les utilisateurs, presque toute la communauté. À part quelques personnes, il n'avait pas de partisans (c'est ce que je vois). Il n'avait pas non plus d'utilisateurs actifs, d'après ce que j'ai compris.
3. J'ai examiné sa documentation ¹ et malgré l'année de décrochage dans le développement (c'est ce que j'ai vu à ce moment-là), j'ai fait le calcul (un calcul intéressant) et j'ai décidé de tenter le coup.
4. J'ai posé beaucoup de questions ¹ et il y a répondu patiemment. Entre-temps, j'ai pris des notes sur ce que j'apprends , donc fait un bon matériel d'introduction.
5. Les gens ont découragé ¹ d'utiliser sa branche en affirmant qu'il était l'auteur et le mainteneur solitaire et que son travail ne devrait pas faire confiance en termes de durabilité. Je les ai simplement ignorés.
6. Sa demande d'extraction n'a pas été fusionnée depuis longtemps (environ un an environ).

Dernièrement, son PR avait commencé à être revu. Une grande quantité de travail avait été faite et finalement sa branche et le courant dominant sont devenus compatibles. Dans la prochaine version, je pense que sa branche sera fusionnée avec le courant dominant.

Pendant ce temps, il y avait un sérieux problème financier. Il était le seul mainteneur et les dons de quelques utilisateurs ne pouvaient pas le faire survivre. J'ai décidé d'enseigner FreeCAD/Assembly3 ici, en Turquie, et de vendre le support afin de soutenir les finances. Je l'ai proposé et c'est accepté. J'ai fait toutes les candidatures nécessaires pour devenir formatrice dans une fondation très réputée, qui est acceptée depuis peu.

Parfois, 1 personne suffit pour allumer un feu.

et sors du chemin

Être en désaccord. Qu'ils restent en chemin. Une bonne motivation trouvera toujours son chemin. Si ce n'est pas possible, c'est parce que ce n'était pas très bon.

Je ne suis explicitement et clairement pas en train de recueillir des conseils sur ce sujet.

Cette bibliothèque doit être ressuscitée. Je suis désolé si je ne l'explique pas suffisamment, mais les réponses que je reçois ne répondent à aucune des préoccupations pratiques soulevées.

La vie et les emplois des gens en dépendent.