Pegjs: Ajout de la prise en charge des analyseurs incrémentiels

Je suppose que vous voulez un support pour l'analyse à partir d'un index autre que 0, oui ?

Non, en fait, juste la prise en charge de la modification de l'emplacement indiqué dans l'objet location() .

L'analyseur que j'écris analyse un bloc de données à la fois (c'est-à-dire des flux de nœuds) et analyse autant qu'il le peut.

donc étant donné le document suivant

<racine>
<enfant> texte</enfant>
</racine>

et supposons qu'il arrive en deux morceaux

1:
<racine>
<enfant> te

2 :
xt</enfant>
</racine>

lors de la première analyse, il analyserait

<racine>
et
<enfant>
et ça jetterait "te"

mais la prochaine analyse, il analyserait
"texte"
</enfant>
</racine>

Au cours de la deuxième analyse, je veux qu'il reflète l'emplacement dans le document d'origine et non le morceau qui a été présenté.

Désolé, j'essaie juste de comprendre ce que vous voulez ici 😄

Fondamentalement, vous voulez que les données de localisation reflètent ce qui est passé via les options plutôt qu'à partir de l'index de départ utilisé par les fonctions d'analyseur interne ? Cela ne renverrait-il pas des données de localisation incorrectes pour ce qui a été analysé dans la première analyse (c'est-à-dire "te" de "texte") ?

Étant donné que vous analysez des blocs de données à la fois, ne serait-il pas plus optimal de simplement renvoyer la plage :

function range() {

    return [ peg$savedPos, peg$currPos ];
    /* or */
    //return { start: peg$savedPos, end: peg$currPos };

}

L'analyseur n'a jamais accès à l'ensemble du document à la fois, un seul morceau à la fois, puisqu'il n'a pas accès à l'ensemble du document, la fonction location() telle qu'elle est ne donne pas d'informations très pertinentes.

dans l'exemple précédent, le premier morceau aurait les informations de localisation correctes, le deuxième morceau serait très incorrect. la chaîne "te" serait ajoutée au deuxième morceau et serait reconnue comme la chaîne complète "text". Sans modification de la fonction de localisation, le début de la chaîne "texte" serait reconnu comme décalage 0, ligne 1, colonne 1, au lieu des valeurs correctes de décalage 13, ligne 2 colonne 8

Cela serait également utile si, par exemple, vous ne vouliez analyser qu'une partie d'un document.

dans l'exemple précédent, le premier morceau aurait les informations de localisation correctes, le deuxième morceau serait très incorrect. la chaîne "te" serait ajoutée au deuxième morceau et serait reconnue comme la chaîne complète "text". Sans modification de la fonction de localisation, le début de la chaîne "texte" serait reconnu comme décalage 0, ligne 1, colonne 1, au lieu des valeurs correctes de décalage 13, ligne 2 colonne 8

Comme je l'ai demandé ci-dessus, vous voulez essentiellement que les données de localisation reflètent ce qui est passé via les options plutôt qu'à partir de l'index de départ utilisé par les fonctions d'analyseur internes, ce qui, comme vous l'avez montré ci-dessus, peut être obtenu en écrasant _peg$posDetailsCache_ et _peg$computeLocation_.

Actuellement, les analyseurs générés par PEG.js ne conservent pas leur état entre différentes sessions d'analyse, il n'y a donc aucun moyen de faire ce que vous voulez automatiquement, donc écraser manuellement _peg$posDetailsCache_ et _peg$computeLocation_ est le seul moyen.

Cela serait également utile si, par exemple, vous ne vouliez analyser qu'une partie d'un document.

Cela peut être un problème différent selon l'entrée source donnée à l'analyseur généré :

1) Si vous utilisez des flux, la méthode actuelle que vous utilisez est la meilleure
2) Si vous analysez un document entier, la définition manuelle des valeurs pour _peg$savedPos_ et _peg$currPos_ peut faire l'affaire, mais pour être honnête, je n'ai jamais essayé cela, bien que je me sois demandé s'il fallait l'implémenter en tant que fonctionnalité ou non .

J'ai décidé de l'implémenter avant la v1, mais je devrai réfléchir à une direction concrète à prendre en fonction de la demande de l'OP et de mon message ci-dessus.

Ce n'est fondamentalement pas possible. Malheureusement, le mainteneur actuel recherche des promesses impossibles au lieu de réparer les choses simples dont les utilisateurs ont réellement besoin.

Le fonctionnement d'un analyseur packrat est l'équivalent d'analyse de A* - il met en cache ses anciennes tentatives de correspondance. La raison pour laquelle il est capable de correspondre si généreusement est qu'il a toutes les tiges avant, ce qui, avant la mise en cache, semblait irréaliste. C'est aussi pour ça que c'est si rapide.

Le problème est que, pour effectuer une analyse incrémentielle, vous auriez besoin soit d'une copie de l'ancien cache, qui est généralement des milliers à des centaines de milliers de fois la taille du document, soit de conserver la partie avant de l'ancien document et il suffit de le réanalyser.

Ce problème doit être fermé car impossible. Ce n'est pas comme ça que les packrats fonctionnent. (De plus, ils sont assez rapides pour que je ne puisse pas penser à une raison pour laquelle cela serait nécessaire ou souhaitable. Je peux généralement analyser des documents d'environ 10 Mo sous un seul cadre d'écran.)

Il est très probablement plus rapide de réanalyser à partir de zéro que de charger les anciennes tiges à partir du disque

Il vous suffit de suivre votre position dans la première analyse et de la rechercher à nouveau dans la seconde, avec un XPath unique. XML n'a pas de suppression. Il est garanti que la position de flux à laquelle vous étiez est toujours là.

Il y a quelque chose qui s'appelle un analyseur packrat incrémental, et il y a même des implémentations javascript librement disponibles par les gens d'Ohm

Mais si vous allez au fond des choses et regardez, vous vous rendrez compte qu'ils sont à peu près aussi liés qu'un hashmap et un vecteur (parce que l'un est un tableau clairsemé et l'autre est un tableau dense, et les seules choses qu'ils partagent vraiment sont des mots dans le titre)

Ce problème doit être fermé car impossible.

Je ne pense pas. Oui, il y a des grammaires pour lesquelles l'analyse incrémentale ne donnera rien, mais il y a aussi celles pour lesquelles on peut le faire. Le problème est de diviser ces classes et de le signaler à l'étape de la compilation afin de ne pas générer de code qui ne fonctionne pas

Vous connaissez ce logiciel mieux que moi, et je peux me tromper, et si vous êtes certain, je vais me taire, mais

Croyez-vous vraiment que peg.js peut être pratiquement fait pour faire cela sans une refonte sérieuse ?

Par exemple, l'approche des gens ohm nécessite une sorte de mémorisation paresseuse qui n'est pas du tout dans peg pour autant que je sache, et je ne vois pas comment l'insérer (peut-être que je Je rate le coche ; cela arrive parfois)

Croyez-vous vraiment que peg.js peut être pratiquement conçu pour faire cela sans une refonte sérieuse ?

J'ai eu quelques idées dans le passé, mais comme le projet est mort, je ne les ai jamais mises en œuvre... C'est juste un défi, mais à ce stade, je n'ai pas besoin de cette fonctionnalité, mais pour faire quelque chose dont personne n'a besoin -- ennuyeux

Ce projet n'est pas mort. Il compte 200 000 téléchargements par semaine.

Il a juste besoin d'un mainteneur qui s'en soucie. J'adorerais ressusciter cela et commencer à résoudre les problèmes. Je vais simplement passer en revue le journal de travail existant, sélectionner les cerises, ajouter des tests et publier.

Je corrige mes grammaires peg avec des scripts bash.

Il n'y a aucune raison pour que ce projet meure. C'est le meilleur analyseur JS qui soit.

Je comprend. Peut-être la meilleure option pour fabriquer un fork et le développer selon vos besoins

Je l'ai fait il y a trois ans.

Non, je ne vais pas bifurquer une bibliothèque pour la retirer de ses mainteneurs actuels et la ramener à la vie. Ce n'est pas ce que sont les fourches, ni comment elles fonctionnent.

Mon objectif explicite est de retirer l'équipe qui a passé trois ans à faire 0.11.0 puis l'a jeté et a dit "nous allons écrire une nouvelle bibliothèque à partir de zéro, et vous ne pouvez pas contribuer ou voir la nouvelle , et c'est maintenant mon projet de passe-temps personnel."

Si je comprends bien, cette équipe est ryuu.

Il s'agit d'une bibliothèque extrêmement importante qui est largement utilisée par de nombreux packages à l'échelle du système. Il est temps pour quelqu'un de le ramener à un état sain.

Le bifurquer n'atteindra pas cet objectif.

Mon objectif est de bifurquer 0.10.0 et de commencer à rétroporter les fusions 0.11.0 dans 0.12.0 , mais en augmentant les tests au fur et à mesure et en libérant la bibliothèque

Il y a six problèmes différents dans ce repo qui disent "J'ai abandonné le peg parce qu'il n'est pas sorti depuis des années" ou "parce qu'il n'est pas sorti depuis le départ de David".

Personne ne se soucie de ma fourchette. Si je le bifurquais, rien ne serait sauvé.

Je vais sauver la vraie chose maintenant, si David me le permet.

Je suis désolé que tu veuilles que je laisse la vraie chose mourir, mais je ne veux pas faire ça. Je ne sais pas non plus pourquoi tu voudrais ça. Vos relations publiques meurent avec 0.11.0 . je les retiendrais.

En tout cas, je ne demandais pas conseil. J'ai déjà dit à David ce que je veux, et je le veux toujours même si vous voulez que je tire un Ryuu, et que je recommence dans un référentiel différent que personne ne peut voir ou dont personne ne se souciera jamais, et continuer à laisser les utilisateurs bloqués.

Mon but n'est pas de me sauver. Mon but est de sauver la bibliothèque.

Il est temps pour les développeurs actuels de laisser quelqu'un avec une expérience en bibliothèque intervenir et de créer un processus de développement et de publication sain, et de sauvegarder la bibliothèque.

Votre avis sur mon désir est noté.

Je veux toujours que David me laisse réparer les trois années de dégâts qui ont été causés depuis son départ, par un groupe qui a accepté la responsabilité de l'entretien, puis ne l'a jamais fait.

Le mainteneur actuel n'a littéralement jamais entretenu la bibliothèque une seule fois , et chaque promesse qu'il a faite à David en 2017 d'acquérir ce référentiel est erronée.

Il était temps de lâcher prise en 2018

Je veux que David me laisse réparer ça. Peg est le meilleur parseur du moment

Ses propres développeurs ( vous ) disent "J'ai abandonné ce projet, il est mort"

Pourquoi vous voulez aussi que je ne le sauvegarde pas et que je travaille sur mon propre fork privé, alors que tous les développeurs ont abandonné le projet comme un projet mort, cela me dépasse

Je suis désolé que vous ayez abandonné peg.js

Je n'ai pas.

je les retiendrais.

Je les ai juste laissés dans ma fourchette. Ils ne sont pas complètement morts, vous pouvez toujours les ressusciter. Je ne suis pas intéressé à faire ça.

Personne ne se soucie de ma fourchette. Si je le bifurquais, rien ne serait sauvé.

J'ai adapté la mise en œuvre des gammes pendant 5 ans à toutes les exigences de formatage changeantes, j'ai ajouté 3 nouvelles fonctionnalités lors de l'évolution du PR initial (délimiteurs, limites variables, limites de fonction), mais cela n'a même pas été vu par personne dans la communauté. Cela suggère qu'il n'y a en réalité aucune communauté. En fait, à l'extérieur, on m'a dit en face que je n'étais pas une communauté et que mon opinion n'avait pas d'importance, même s'il n'y en avait pas d'autres.

Je pense donc que "la communauté" coûtera assez cher sans votre sacrifice :(

Mon but n'est pas de me sauver. Mon but est de sauver la bibliothèque.

Seule fourche, à mon humble avis. Triste mais vrai. Peut-être qu'un exemple de io.js enseignera quelque chose.

travailler sur mon propre fork privé

Pourquoi privé ? Faites un fork public, faites de bonnes choses et la communauté (si elle existe) vous trouvera

Pourquoi privé ? Faire un fork public

Je suis ici pour sauver la bibliothèque, pas pour en créer une nouvelle.

S'il te plaît, arrête de me demander ça maintenant. J'ai été clair que la réponse est non.

.

Je monte la mise en place des gammes depuis 5 ans

Je sais. Si je suis nommé mainteneur, les gammes seront intégrées à l'aide de votre code en 2020.

Ces problèmes viennent du manque de mainteneur. Forking ne les résoudra pas; ça va les aggraver.

.

Cela suggère qu'il n'y a en réalité aucune communauté.

Il y avait. Il peut y avoir encore.

J'ai commencé à déposer des contraventions il y a moins de 24 heures et j'ai déjà eu des conversations avec neuf personnes.

Arrêtez d'être fataliste. Ceci est facilement réparable. Tout ce qu'il faut, c'est que les clés soient entre les mains d'un mainteneur expérimenté qui se concentre sur les versions.

.

Je pense donc que "la communauté" coûtera assez cher sans votre sacrifice :(

Je ne fais pas de sacrifice ici.

.

il n'a même pas été vu par quiconque dans la communauté

J'ai vu cela pour la première fois hier soir, lorsque j'ai commencé à lire le suivi des problèmes. (Je vais tout lire, ouvert et fermé.)

J'ai aussi vu #209.

Je suis sympathique aux deux positions ici.

D'une part, c'est une fonctionnalité qui devrait vraiment être intégrée, que beaucoup de gens veulent, que d'autres bibliothèques supportent et que les outils sous-jacents sont prêts à supporter.

D'un autre côté, la conversation n'était pas réellement terminée.

Si j'étais autorisé à être mainteneur, voici ce que je ferais :

1. Je créerais un nouveau ticket et étiquetterais tous ceux que je pensais avoir été impliqués dans le passé. Je leur demanderais également de taguer tous ceux qu'ils savaient que j'avais manqués.
2. Je dirais "hé, pouvons-nous en parler et prendre une décision? J'aime généralement le code de Mingun, et je veux savoir si nous pouvons soit le fusionner, soit le modifier légèrement pour le rendre fusionnable."
3. Si la discussion n'était pas brève et succincte, disons trois ou quatre jours, je dirais "d'accord, cette bibliothèque essaie de s'orienter vers de nouveaux progrès, donc j'aimerais régler une minuterie d'une semaine à partir d'aujourd'hui", et re- marquer tout le monde
4. J'aurais aussi des normes assez élevées pour les tests
5. Ensuite, dans le vernaculaire, il est temps de fusionner. C'est une bonne fonctionnalité et, avec plus de tests, c'est aussi une bonne implémentation.
   
   
   
   1. Je voudrais que la communauté puisse discuter des personnages qui conviennent le mieux au sceau, mais cinq ans, c'est un non-sens, et il est temps d'appuyer sur la gâchette
   
   

.

Mon but

A MON HUMBLE AVIS.

Salut, vous avez poussé cette opinion quatre fois maintenant, et j'ai dit non à chaque fois.

Arrêtez de me dire votre opinion sur mon objectif. Mon objectif ne change pas.

.

Pourquoi privé ?

Parce que je l'ai fait il y a trois ans, quand c'était encore une bibliothèque saine, et les changements que j'apportais étaient des choses auxquelles @dmajda avait dit non.

Alors j'ai pensé que je le corrigerais localement, et quand la communauté le corrigerait correctement, je convertirais ma grammaire.

Trois ans plus tard, les développeurs ont abandonné ce projet comme mort, mais font également de leur mieux pour que je ne corrige pas cela même après que je leur ai clairement dit d'arrêter, ce qui est déconcertant et inapproprié .

Si vous faites d'autres commentaires sur mon besoin de faire un fork, je cesserai simplement de répondre. Votre espoir de garder peg.js mort ne m'intéresse pas.

La réponse est un non dur. Si vous voulez peg 0.10.0 , épinglez votre colis. peg 0.12.0 doit arriver, et je ne comprends pas vraiment pourquoi vous voulez vous en mêler.

Tout ce que vous avez fusionné en 0.11.0 est perdu en ce moment. Ryuu a dit que tout était jeté. Si vous pensez que vous conservez votre travail fusionné, comprenez que ma maintenance y parviendra, et Ryuu a explicitement déclaré qu'il recommençait à partir d'une base de code personnalisée à partir de zéro.

Ryuu a également démarré trois autres compilateurs PEG depuis qu'il a repris la maintenance

Cette bibliothèque n'est morte que parce que

1. Le nouveau mainteneur ne maintiendra pas, et
2. Les nouveaux développeurs ne sont pas en colère

Salut, je suis l'un des anciens développeurs et je suis en colère

Si vous n'êtes pas prêt à aider à sauver cette bibliothèque, arrêtez au moins de me dire de ne pas le faire .

Cette bibliothèque doit être entretenue. C'est un élément essentiel de l'infrastructure. Une fourche n'est pas un entretien. Une fourchette ne résout aucun des problèmes.

.

Peut-être qu'un exemple de io.js enseignera quelque chose.

io.js a échoué, malgré l'adhésion du créateur de la langue d'origine et de ses cinq plus grands contributeurs, et lorsqu'ils l'ont rejeté, la seule raison pour laquelle ils ont prétendu que ce n'était pas une perte totale était de pouvoir de réembaucher deux de ces cinq personnes

Oui, io.js m'apprend quelque chose. À savoir, "les fourches ne fonctionnent pas et les problèmes de personne n'ont été résolus jusqu'à ce que le nœud soit mis à jour plus tard".

Je n'essaie pas de vous dissuader. Si vous le faites, je ne serai qu'heureux et je pourrai même terminer certaines de mes expériences et les amener à un état fusionnable. Je regarde juste dans le passé, d'une certaine manière, je ne peux pas croire.

La criticité est fortement exagérée. Si c'était comme vous le dites, quelqu'un aurait déjà fait un fork et l'aurait développé. Ou cette bibliothèque développée plutôt que figée en développement pendant 5 ans.

Si vous le faites, je ne serai qu'heureux et je pourrai même terminer certaines de mes expériences et les amener à un état fusionnable.

Ce serait fantastique. Beaucoup de vos relations publiques me semblent vraiment puissantes, et avec quelques tests supplémentaires, il me semble qu'elles devraient être fusionnées

.

La criticité est fortement exagérée. Si c'était comme vous le dites, quelqu'un aurait déjà fait un fork et l'aurait développé.

Le mainteneur actuel à lui seul a créé trois ou quatre forks distincts (pegx, epeg, meg ; sans doute pegjs-dev, puisqu'il l'a fait lui-même avant d'être mainteneur) ainsi qu'un fork openpeg. À ce stade, je dirais que 0.11.0 est également un fork, puisqu'il a déclaré qu'il ne sera jamais fusionné.

Au cours de mes dernières 48 heures, j'ai parlé à une dizaine de personnes ici. La moitié d'entre eux ont des fourches.

polkovnikov-ph a un méta-pilier entier qui met des piquets dans d'autres piquets.

J'ai moi-même deux fourches, une qui n'apparaît pas dans la liste des fourches - celle à contre-courant que j'ai maintenue pendant des années, et la nouvelle que j'ai faite l'autre jour, avant d'apprendre que 0.11.0 était mort, en l'effort d'implémentation des correctifs pour la densification #638, les modules es6 #627 et les modules dactylographiés #597 .

Deux de mes amis qui, pour autant que je sache, n'ont jamais été dans ce traqueur de problème ont des fourches

Le fait que des gens aient continué à travailler sur 0.11.0 pendant trois ans malgré le fait que personne ne publie me dit tout ce que j'ai besoin de savoir sur l'importance de tout cela.

.

Ou cette bibliothèque développée plutôt que figée en développement pendant 5 ans.

Cette bibliothèque a en fait été activement développée jusqu'en mai 2017, lorsque le changement de responsable s'est produit.

Ce jour-là était le jour où la bibliothèque a gelé.

C'est pourquoi je pense qu'un nouveau changement de responsable peut le dégeler.

C'est une image plus pertinente.

Cette bibliothèque a en fait été activement développée jusqu'en mai 2017

Je dirais que jusque-là, il y avait eu du brassage de code, mais aucune nouvelle fonctionnalité n'a été implémentée. Peut-être quelques bugs corrigés, et ça, ils ont dû être combattus. Le développement réel a gelé bien avant que @dmajda ne parte

Vous savez ce que je vois là-bas ?

Je vois une bibliothèque qui n'a pas été entretenue depuis trois ans et qui a encore six fourches actives au cours des deux derniers mois.

Quoi qu'il en soit, regardez, peignez la ligne où vous voulez dans le sable. Peut-être y a-t-il un meilleur endroit pour le dessiner ; Je n'ai pas fait de fouille archéologique.

Le fait est que c'est toujours une ligne dans le sable. Utilisons nos pieds pour foutre le sable maintenant.

0.12.0 est tout à fait possible si nous pouvons amener les gens à dire "hé, laissons faire".

C'est le meilleur analyseur après une demi-décennie d'inactivité.

Réalisez-vous à quel point cela deviendrait s'il devenait un projet accessible en open source ?

Faisons un 0.12.0 propre puis commençons à choisir les morceaux de 0.11.0 qui sont dignes de confiance. Après cela, nous pouvons nettoyer et commencer à réparer le reste.

Beaucoup d'entre eux sont super difficiles, bien sûr

Mais beaucoup d'entre eux ne le sont pas. J'obtiens la prise en charge du module ES6 à partir d'un script bash d'une ligne. C'est idiot et facilement réparable

Le mouvement vers l'avant n'a pas besoin d'être parfait ; ça doit juste être non trivial

M'aider à embarquer David ? S'il te plaît

Comme sérieux.

Imaginez ce qui se passerait si 0.12.0 sortait, et à part réparer le README et quelques autres trucs triviaux, c'était juste 0.10.0 .

Et puis si la semaine prochaine, le support du module es sortait

Et si la semaine suivante, la page Web recevait une mise à jour majeure

Et si la semaine suivante, nous publiions un simple support de dactylographie

Ce sont toutes des choses que j'ai déjà faites. Ce sont tous des emplois de deux heures. C'est une cadence détendue et facile

Mais c'est tellement différent de ce à quoi les utilisateurs sont habitués que cela indiquerait clairement que quelque chose a changé

Je suis tout à fait convaincu que cette bibliothèque dispose de la communauté d'utilisateurs et de la base de défauts pour obtenir des versions sous-mensuelles significatives, et je suis tout à fait convaincu que je pourrais y arriver

J'ai aussi mon propre fork, un fichier unique, une implémentation sans dépendance basée sur l'article académique original. J'avais initialement essayé d'utiliser la base de code 0.10.0, mais même celle-ci était trop gonflée à mon goût.

Mon sentiment est que quiconque pour qui cela est essentiel à la mission a déjà bifurqué parce que traiter avec un drame "open source" est plus épuisant que de passer quelques week-ends à apprendre et à mettre en œuvre une solution à ses besoins spécifiques. Sérieusement, le papier est facile à lire et en moins de 100 heures, j'ai pu obtenir un analyseur 4 fois plus rapide et 100 fois plus petit.

Il y a toujours un compromis fondamental entre vouloir utiliser une solution existante et avoir une solution parfaite pour votre propre problème. Les communautés d'analyseurs sont dans une vallée difficile où une fois que quelqu'un a suffisamment appris pour utiliser efficacement un outil d'analyse, il ne reste qu'une petite quantité de travail supplémentaire pour écrire son propre analyseur.

Le plus grand coût d'opportunité de l'open source est spirituel.

Namasté :prier:

PS Ne vous méprenez pas, j'apprécie vraiment ces discussions, c'est un excellent divertissement ! Je ne m'attends tout simplement pas à beaucoup de valeur productive des communautés GH ou JS ces jours-ci.

C'est un point de vue compréhensible.

Compte tenu de l'état actuel des choses, j'espère pouvoir amener les gens à dire "Eh bien, laissez une tentative se produire et voyons"

@StoneCypher J'aime votre énergie que vous semblez vouloir mettre dans cette lib et je suis d'accord avec vos idées générales (et je l'aurais déjà après la première fois où vous les avez écrites - pas besoin de dire la même chose cinq fois :grin:) . Je n'aime pas non plus beaucoup une fourchette, mais cela signifie que nous dépendons d'exactement une personne - futagoza. Et s'il ne répond pas ? Ensuite, nous sommes coincés, nous ne pouvons rien y faire. dmajda a déjà dit qu'il n'avait plus de droits, donc il ne peut rien faire non plus.

Voici la chose avec laquelle je ne suis pas d'accord : "dans un référentiel différent que personne ne peut voir ou dont personne ne se souciera jamais" car cela a une solution simple : ouvrez un nouveau problème en majuscules en disant quelque chose comme "PROJET MORTE - SUITE ICI" puis écrivez-y toutes les informations nécessaires. Je serais la première personne à basculer mon projet, et je suis sûr que beaucoup d'autres le feraient. Et ce ne serait pas le premier projet auquel cela arriverait, j'ai déjà suivi quelques autres projets dans cette voie. Pas grave, il suffit de changer. En tant qu'utilisateur, peu m'importe d'où je tire mon code tant que c'est un endroit auquel les gens se soucient.

Je donnerais donc à @futagoza quelques semaines de plus pour voir s'il répond et quel est son avis. S'il n'y a aucun signe de vie et aucune réponse, continuez et recréez ce projet correctement.

En fait, je viens de voir que @michel-kraemer est aussi membre de pegjs, alors peut-être qu'il y a encore plus d'espoir :grinning:

@michael-brade - Les fourches ne fonctionnent pas. Je vais être très direct : je ne veux pas que vous me disiez de refaire quelque chose de différent

Il y a déjà quatre forks qui tentent de sauvegarder ce dépôt. Vous ne savez pas ce qu'ils sont. Vous ne les recherchez pas lorsque vous dites "réparez-le de cette façon".

Cela n'a pas d'importance. Une fourchette ne résoudra rien. Les consommateurs en aval existants ne reçoivent pas les corrections de bogues dans un fork. Les PR sont perdus dans une fourchette. Les problèmes sont perdus dans un fork.

La réponse est un non dur.

@futagoza doit arrêter de bloquer la cheville immédiatement.

Cette bibliothèque ne mourra pas parce que quelqu'un a promis d'en être le mainteneur, a refusé de la maintenir et a décidé de la garder pour lui-même.

Moralement, @futagoza n'a pas le droit de promettre d'être mainteneur, puis de détruire la bibliothèque.

Il y a déjà quatre forks qui tentent de sauvegarder ce repo .

Comment savez-vous qu'ils le sont? Avez-vous des liens? Le seul type de fork actif que je vois est meisl/pegjs, aucun des autres n'est actif du tout. Et même le fork meisl ne semble pas être une tentative de sauver ce dépôt.

Vous ne les recherchez pas lorsque vous dites "réparez-le de cette façon".

Peut-être que vous n'avez pas lu ma suggestion : si ces forks avaient l'intention de sauvegarder ce référentiel, ils l'ont mal fait car ils n'ont pas créé de problème évident indiquant à la communauté où aller. Je suis d'accord avec tout ce que vous dites jusqu'à ce que ce marqueur ait été créé. Ensuite, les règles changent.

@futagoza doit arrêter de bloquer la cheville immédiatement.

À droite. Et comment comptez-vous faire respecter cela ?

Comment savez-vous qu'ils le sont?

Parce que je suis allé chercher des corrections de bugs, il y a des années.

.

Avez-vous des liens?

Oui. Cependant, si les fourches fonctionnaient, je n'aurais pas à les donner; vous les auriez aussi. C'est mon explication de la raison pour laquelle je ne considérerai pas une fourchette, ou ne divertirai plus de temps perdu à choyer le faux mainteneur

.

si ces forks avaient l'intention de sauvegarder ce dépôt, alors ils l'ont mal fait car ils n'ont pas créé de problème évident indiquant à la communauté où aller.

En fait, ils l'ont fait. Il a été supprimé.

Dans un sens, vous avez raison : ils ont mal agi, en créant un fork.

La plupart des gens obtiennent des bibliothèques à partir de npm , où cette bibliothèque n'a même pas de fichier readme. Ils ne verront jamais le problème.

Je suis radicalement clair quand je dis "Je ne veux pas avoir d'autres discussions sur les fourches".

D'autres tentatives pour en discuter seront ignorées.

.

Je suis d'accord avec tout ce que vous dites jusqu'à ce que ce marqueur ait été créé.

Il l'a été, plusieurs fois.

si ces forks avaient l'intention de sauvegarder ce dépôt, alors ils l'ont mal fait car ils n'ont pas créé de problème évident indiquant à la communauté où aller.

En fait, ils l'ont fait. Il a été supprimé.

Ok, je n'ai aucun moyen de vérifier cela. Mais en supposant que vous ayez raison, il devrait être évident pour vous que la personne qui a supprimé ce problème n'a pas l'intention de renoncer au pouvoir sur ce dépôt. Dans ces circonstances, comment se fait-il que vous pensiez pouvoir changer quoi que ce soit sans fork ?

Tout ce que je peux dire, c'est que je vous souhaite bonne chance. Et que je suivrai partout où un développement actif aura lieu.

comment se fait-il que tu penses pouvoir changer quoi que ce soit sans fork ?

Parce que finalement futagoza reviendra, et il devra à nouveau prendre cette décision.

C'était en 2018. Nous sommes en 2020. Depuis, il a lancé au moins quatre analyseurs PEG entièrement distincts, un dans un langage de base différent, ainsi que deux langages de programmation.

À l'époque, il n'avait pas rejeté trois années de travail comme s'il n'était pas digne de confiance. Maintenant, il l'a fait.

À l'époque, il n'y était que depuis six mois. C'est toujours une chronologie "bien, donnez-moi une chance", à peine. Maintenant, ça fait trois ans.

À l'époque, il pouvait encore dire qu'il s'y était engagé et que c'était son objectif.

Les choses ont changé.