Pegjs: Adicionar suporte para analisadores incrementais

Estou assumindo que você deseja suporte para análise de um índice diferente de 0, sim?

Não, na verdade, apenas suporte para modificar o local que é relatado no objeto location().

O analisador que estou escrevendo analisa um pedaço de dados de cada vez (ou seja, fluxos de nó) e analisa o máximo que pode.

assim dado o seguinte documento

<raiz>
<filho> texto</filho>
</root>

e suponha que ele vem em dois pedaços

1:
<raiz>
<criança> te

2:
xt</filho>
</root>

durante a primeira análise, ele analisaria

<raiz>
e
<criança>
e jogaria fora "te"

mas na próxima análise ele analisaria
"texto"
</criança>
</root>

Durante a segunda análise, quero que reflita a localização no documento original e não o pedaço que foi apresentado.

Desculpe, apenas tentando entender o que você quer aqui 😄

Basicamente, você deseja que os dados de localização reflitam o que é passado por meio das opções, em vez do índice inicial usado pelas funções do analisador interno? Isso não retornaria dados de localização incorretos para o que foi analisado na primeira análise (ou seja, "te" de "texto")?

Desde a análise de blocos de dados de cada vez, não seria mais ideal retornar apenas o intervalo:

function range() {

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

}

O analisador nunca tem acesso a todo o documento de uma vez, apenas um pedaço de cada vez, já que não tem acesso a todo o documento, a função location() como está não fornece informações muito relevantes.

no exemplo anterior, o primeiro pedaço teria as informações de localização corretas, o segundo pedaço estaria muito incorreto. a string "te" seria anexada ao segundo pedaço e seria reconhecida como a string completa "texto". Sem alterações na função de localização, o início da string "texto" seria reconhecido como deslocamento 0, linha 1, coluna 1, em vez dos valores corretos de deslocamento 13, linha 2, coluna 8

Isso também seria útil se você quisesse apenas analisar parte de um documento.

no exemplo anterior, o primeiro pedaço teria as informações de localização corretas, o segundo pedaço estaria muito incorreto. a string "te" seria anexada ao segundo pedaço e seria reconhecida como a string completa "texto". Sem alterações na função de localização, o início da string "texto" seria reconhecido como deslocamento 0, linha 1, coluna 1, em vez dos valores corretos de deslocamento 13, linha 2, coluna 8

Como eu perguntei acima, basicamente você quer que os dados de localização reflitam o que é passado através das opções, em vez do índice inicial usado pelas funções do analisador interno, que, como você mostrou acima, pode ser alcançado substituindo _peg$posDetailsCache_ e _peg$computeLocation_.

Atualmente, os analisadores gerados pelo PEG.js não mantêm seu estado entre diferentes sessões de análise, portanto, não há como fazer o que você deseja automaticamente, portanto, substituir manualmente _peg$posDetailsCache_ e _peg$computeLocation_ é a única maneira.

Isso também seria útil se você quisesse apenas analisar parte de um documento.

Este pode ser um problema diferente dependendo da entrada de origem fornecida ao analisador gerado:

1) Se estiver usando fluxos, o método atual que você está empregando é o melhor
2) Se estiver analisando um documento inteiro, definir manualmente os valores para _peg$savedPos_ e _peg$currPos_ pode resolver o problema, mas para ser honesto, nunca tentei isso, embora esteja ponderando se deve implementar isso como um recurso ou não .

Decidi implementar isso antes da v1, mas precisarei pensar em uma direção concreta a seguir com base na solicitação do OP e no meu post acima.

Isso basicamente não é possível. Infelizmente, o mantenedor atual está pesquisando promessas impossíveis em vez de consertar coisas fáceis que os usuários realmente precisam.

A maneira como um analisador packrat funciona é o equivalente de análise de A* - ele armazena em cache suas tentativas de correspondência antigas. A razão pela qual ele é capaz de corresponder tão liberalmente é que ele tem todas as hastes de encaminhamento, que antes do armazenamento em cache pareciam irreais no desempenho. É também por isso que é tão rápido.

O problema é que, para fazer a análise incremental, você precisaria de uma cópia do cache antigo, que normalmente é de milhares a centenas de milhares de vezes o tamanho do documento, ou manter a parte avançada do documento antigo e basta reanalisar.

Este problema deve ser encerrado, pois não é possível. Não é assim que os packrats funcionam. (Além disso, eles são rápidos o suficiente para que eu não consiga pensar em uma razão pela qual isso seria necessário ou desejável. Normalmente, posso analisar documentos de ~ 10 meg em um único quadro de tela.)

Provavelmente é mais rápido reanalisar do zero do que carregar as hastes antigas do disco

Basta rastrear sua localização na primeira análise e procurar novamente na segunda, com um XPath exclusivo. XML não tem exclusão. É garantido que a posição de stream em que você estava ainda está lá.

Existe algo chamado parser incremental packrat, e existem implementações de javascript disponíveis abertamente pelo pessoal da Ohm

Mas se você chegar ao âmago da questão e olhar, você perceberá que eles estão tão relacionados quanto um hashmap e um vetor (porque um é um array esparso e o outro é um array denso, e as únicas coisas que eles realmente compartilham são palavras no título)

Este problema deve ser encerrado, pois não é possível.

Acho que não. Sim, existem gramáticas para as quais a análise incremental não dará nada, mas também existem aquelas para as quais isso pode ser feito. O problema é dividir essas classes e reportá-las na fase de compilação para não gerar código que não funcione

Você conhece este software melhor do que eu, e posso estar errado, e se você tem certeza eu vou calar a boca, mas

Você realmente acredita que peg.js pode ser praticamente feito para fazer isso sem uma revisão séria?

Tipo, a abordagem das pessoas ohm requer um tipo de memorização preguiçosa que não está em peg até onde eu sei, e eu não vejo como colocar isso (talvez eu estou perdendo o barco; isso acontece às vezes)

Você realmente acredita que o peg.js pode ser feito praticamente para fazer isso sem uma revisão séria?

Eu tive algumas idéias no passado, mas como o projeto está morto nunca as implementei... É apenas um desafio, mas neste momento eu não preciso dessa funcionalidade, mas para fazer algo que ninguém precisa - chato

Este projeto não está morto. Tem 200.000 downloads por semana.

Ele só precisa de um mantenedor que se importe. Eu adoraria ressuscitar isso e começar a corrigir os problemas. Vou apenas passar pelo log de trabalho existente, escolher a cereja, adicionar testes e liberar.

Estou corrigindo minhas gramáticas de peg com scripts bash.

Não há razão para este projeto morrer. É o melhor analisador JS que existe.

Compreendo. Talvez a melhor opção para fazer um garfo e desenvolvê-lo de acordo com suas necessidades

Fiz isso há três anos.

Não, não vou bifurcar uma biblioteca para tirá-la de seus mantenedores atuais e trazê-la de volta à vida. Não é isso que os garfos são, ou como eles funcionam.

Meu objetivo explícito é remover a equipe que passou três anos fazendo 0.11.0 e depois jogou fora e disse "vamos escrever uma nova biblioteca do zero, e você não pode contribuir ou ver a nova , e este agora é meu projeto de hobby pessoal."

Pelo que entendi, esse time é ryuu.

Esta é uma biblioteca extremamente importante que é muito usada por muitos pacotes em todo o sistema. É hora de alguém trazê-lo de volta a um estado saudável.

Bifurcá-lo não atingirá esse objetivo.

Meu objetivo é bifurcar 0.10.0 e começar a portar 0.11.0 se fundir em 0.12.0 , mas aumentando os testes à medida que progrido e, na verdade, liberando a biblioteca

Há seis questões diferentes neste repositório que dizem "Desisti do peg porque ele não é lançado há anos" ou "porque não foi lançado desde que David saiu".

Ninguém se importa com o meu garfo. Se eu o bifurcasse, nada seria salvo.

Vou salvar a coisa real agora, se David me deixar.

Lamento que você queira que eu deixe a coisa real morrer, mas não estou disposto a fazer isso. Eu também não sei por que você iria querer isso. Seus PRs estão morrendo com 0.11.0 . Eu os manteria.

De qualquer forma, eu não estava pedindo conselhos. Eu já disse a David o que eu quero, e eu ainda quero, mesmo que você queira que eu puxe um Ryuu, e comece de novo em um repositório diferente que ninguém possa ver ou com o qual ninguém se importará, e continuar deixando os usuários presos.

Meu objetivo não é me salvar. Meu objetivo é salvar a biblioteca.

É hora de os desenvolvedores atuais deixarem alguém com experiência em biblioteca entrar e criar um processo de desenvolvimento e lançamento saudável e salvar a biblioteca.

Sua opinião sobre o meu desejo está anotada.

Eu ainda quero que David me deixe desfazer os três anos de danos que foram feitos desde que ele partiu, por um grupo que aceitou a responsabilidade da manutenção, mas nunca o fez.

O mantenedor atual literalmente nunca manteve a biblioteca uma única vez , e todas as promessas que ele fez a David em 2017 para adquirir esse repositório são falhas.

Era hora de deixar ir em 2018

Quero que David me deixe consertar isso. Peg é o melhor analisador ao redor

Seus próprios desenvolvedores ( você ) estão dizendo "eu desisti deste projeto, está morto"

Por que você também quer que eu não o salve e trabalhe em meu próprio fork privado, quando todos os desenvolvedores desistiram do projeto como um projeto morto, está além de mim

Lamento que você tenha desistido de peg.js

Eu não tenho.

Eu os manteria.

Acabei de deixá-los no meu garfo. Eles não morreram completamente, você ainda pode ressuscitá-los. Só não estou interessado em fazer isso.

Ninguém se importa com o meu garfo. Se eu o bifurcasse, nada seria salvo.

Eu tenho adaptado a implementação de intervalos por 5 anos a todas as mudanças nos requisitos de formatação, adicionei 3 novos recursos durante a evolução do PR inicial (delimitadores, limites variáveis, limites de função), mas isso nem foi visto por ninguém na comunidade. Isso sugere que não há realmente nenhuma comunidade. Na verdade, lá fora na minha cara foi dito que eu não sou uma comunidade e minha opinião não importa, embora não houvesse outras.

Então eu acho que "a comunidade" vai custar bastante sem o seu sacrifício :(

Meu objetivo não é me salvar. Meu objetivo é salvar a biblioteca.

Apenas garfo, IMHO. Triste mas verdadeiro. Talvez um exemplo de io.js ensine algo.

trabalhar no meu próprio fork privado

Por que privado? Faça um fork público, faça coisas boas e a comunidade (se existir) o encontrará

Por que privado? Faça um fork público

Estou aqui para salvar a biblioteca, não para criar uma nova.

Por favor, pare de me pedir isso agora. Tenho sido claro que a resposta é não.

.

Há 5 anos que me adapto à implementação de gamas

Eu sei. Se eu for mantenedor, os intervalos usarão seu código em 2020.

Esses problemas vêm da falta de um mantenedor. Bifurcar não vai corrigi-los; vai torná-los piores.

.

Isso sugere que não há realmente nenhuma comunidade.

Costumava haver. Pode haver novamente.

Comecei a arquivar as multas há menos de 24 horas e já conversei com nove pessoas.

Deixe de ser fatalista. Isso é facilmente corrigível. Tudo o que precisa acontecer é que as chaves precisam ser colocadas nas mãos de um mantenedor experiente que tenha foco em lançamentos.

.

Então eu acho que "a comunidade" vai custar bastante sem o seu sacrifício :(

Eu não estou fazendo um sacrifício aqui.

.

era tão nem visto por ninguém na comunidade

Vi isso pela primeira vez ontem à noite, quando comecei a ler o rastreador de problemas. (Vou ler tudo, aberto e fechado.)

Eu também vi o número 209.

Sou solidário com ambas as posições aqui.

Por um lado, esse é um recurso que realmente deveria entrar, que muitas pessoas desejam, que outras bibliotecas suportam e que as ferramentas subjacentes estão prontas para suportar.

Por outro lado, a conversa não estava realmente terminada.

Se eu pudesse ser mantenedor, aqui está o que eu faria:

1. Eu faria um novo ticket e marcaria todos que eu achava que estavam envolvidos no passado. Eu também pediria a eles que marcassem qualquer pessoa que soubessem que eu perdi.
2. Eu diria "ei, podemos conversar sobre isso e tomar uma decisão? Geralmente gosto do código do Mingun e quero descobrir se podemos mesclá-lo ou modificá-lo ligeiramente para torná-lo mesclável".
3. Se a discussão não fosse breve e sucinta, digamos três ou quatro dias, eu diria "ok, esta biblioteca está tentando direcionar para um novo progresso, então eu gostaria de definir um cronômetro de uma semana a partir de hoje" e re- marque todo mundo
4. Eu também teria padrões bastante altos para testes
5. Então, no vernáculo, é hora de fundir. Este é um bom recurso e, com mais testes, também é uma boa implementação.
   
   
   
   1. Eu gostaria que a comunidade pudesse discutir quais personagens são melhores para o sigilo, mas cinco anos é um absurdo, e é hora de puxar o gatilho
   
   

.

Meu gol

NA MINHA HUMILDE OPINIÃO.

Oi, você empurrou essa opinião quatro vezes agora, e eu disse não todas as vezes.

Pare de me dizer sua opinião sobre meu objetivo. Meu objetivo não está mudando.

.

Por que privado?

Porque eu fiz isso três anos atrás, quando esta ainda era uma biblioteca saudável, e as mudanças que eu estava fazendo eram coisas que @dmajda tinha dito não.

Então pensei em corrigi-lo localmente e, quando a comunidade corrigi-lo corretamente, eu converteria minha gramática.

Três anos depois, os desenvolvedores desistiram deste projeto como morto, mas também estão se esforçando ao máximo para que eu não conserte isso, mesmo depois de eu ter dito claramente para eles pararem, o que é desconcertante e inapropriado .

Se você fizer mais comentários sobre minha necessidade de fazer um fork, simplesmente deixarei de responder. Não tenho interesse em sua esperança de manter peg.js morto.

A resposta é um duro não. Se você quiser peg 0.10.0 , fixe seu pacote. peg 0.12.0 precisa acontecer, e eu realmente não entendo ou me importo por que você quer atrapalhar isso.

Tudo o que você fundiu em 0.11.0 está perdido agora. Ryuu disse que tudo está sendo jogado fora. Se você acha que está mantendo seu trabalho mesclado, entenda que minha manutenção fará isso, e Ryuu declarou explicitamente que está começando do zero a partir de uma base de código personalizada.

Ryuu também iniciou três outros compiladores PEG desde que assumiu a manutenção

Esta biblioteca só morreu porque

1. O novo mantenedor não irá manter, e
2. Os novos desenvolvedores não estão com raiva

Oi, eu sou um dos desenvolvedores antigos e estou com raiva

Se você não estiver disposto a ajudar a salvar esta biblioteca, pelo menos pare de me dizer para não .

Esta biblioteca precisa ser mantida. É uma peça crítica de infraestrutura. Um garfo não é manutenção. Um garfo não resolve nenhum dos problemas.

.

Talvez um exemplo de io.js ensine algo.

io.js falhou, apesar do buy-in do criador do idioma original e de todos os seus cinco maiores contribuidores, e quando eles o descartaram, a única razão pela qual eles fingiram que não foi uma perda total foi poder recontratar duas dessas cinco pessoas

Sim, io.js me ensina alguma coisa. Ou seja, "forks não funcionam e os problemas de ninguém foram corrigidos até que o nó fosse atualizado posteriormente".

Não estou tentando dissuadi-lo. Se você fizer isso, ficarei feliz e poderei até completar alguns dos meus experimentos e trazê-los para o estado mesclável. Apenas olhando no passado, de alguma forma eu não posso acreditar.

A criticidade é fortemente exagerada. Se fosse como você diz, alguém já teria feito um fork e desenvolvido. Ou esta biblioteca desenvolvida em vez de congelada em desenvolvimento por 5 anos.

Se você fizer isso, ficarei feliz e poderei até completar alguns dos meus experimentos e trazê-los para o estado mesclável.

Isso seria fantástico. Muitos de seus PRs parecem realmente poderosos para mim e, com alguns testes adicionais, parece-me que eles devem ser mesclados

.

A criticidade é fortemente exagerada. Se fosse como você diz, alguém já teria feito um fork e desenvolvido.

O mantenedor atual sozinho fez três ou quatro forks distintos (pegx, epeg, meg; sem dúvida pegjs-dev, já que ele fez isso sozinho antes de ser um mantenedor), bem como um fork openpeg. Neste ponto, eu argumentaria que 0.11.0 também é um fork, já que ele declarou que nunca está sendo mesclado.

Nas minhas últimas 48 horas, falei com cerca de dez pessoas aqui. Metade deles tem garfos.

polkovnikov-ph tem um meta-peg inteiro que coloca pinos em outros pinos.

Eu mesmo tenho dois garfos, um que não aparece na lista de garfos - o contrário que mantenho há anos, e o novo que fiz outro dia, antes de saber que 0.11.0 estava morto, em o esforço para implementar correções para densificação #638, módulos es6 #627 e módulos typescript #597 .

Dois dos meus amigos que, até onde eu sei, nunca estiveram neste rastreador de problemas têm bifurcações

O fato de as pessoas continuarem trabalhando em 0.11.0 por três anos, apesar de ninguém lançar, me diz tudo o que preciso saber sobre o quão crítico isso é.

.

Ou esta biblioteca desenvolvida em vez de congelada em desenvolvimento por 5 anos.

Esta biblioteca foi de fato desenvolvida ativamente até maio de 2017, quando ocorreu a mudança de mantenedor.

Esse dia foi o dia em que a biblioteca congelou.

É por isso que acredito que uma nova mudança de mantenedor pode descongelá-lo.

Esta é a imagem mais relevante.

Esta biblioteca foi de fato desenvolvida ativamente até maio de 2017

Eu diria que até então havia embaralhamento de código, mas nenhum novo recurso implementado. Talvez alguns bugs corrigidos, e isso, eles tiveram que ser combatidos. O desenvolvimento real congelou muito mais cedo do que @dmajda saiu

Sabe o que eu vejo lá?

Vejo uma biblioteca que está sem manutenção há três anos e ainda tem seis bifurcações ativas nos últimos dois meses.

Enfim, olhe, pinte a linha onde quiser na areia. Talvez haja um lugar melhor para desenhá-lo; Eu não fui em uma escavação arqueológica.

A questão é que ainda é uma linha na areia. Vamos usar os pés para foder a areia agora.

0.12.0 é totalmente possível se conseguirmos que as pessoas digam "ei, vamos deixar acontecer."

Este é o melhor analisador que existe depois de meia década de inatividade.

Você percebe como seria ótimo se se tornasse um projeto acessível de código aberto?

Vamos fazer um 0.12.0 limpo e então começar a escolher os pedaços de 0.11.0 que são confiáveis. Depois disso, podemos limpar e começar a consertar o restante.

Muitos destes são super difíceis, com certeza

Mas muitos deles não são. Recebo suporte ao módulo ES6 de um script bash de uma linha. Isso é bobo e facilmente corrigido

O movimento para frente não precisa ser perfeito; só tem que ser não trivial

Ajude-me a colocar David a bordo? Por favor

Tipo sério.

Imagine o que aconteceria se 0.12.0 saísse, e além de consertar o README e alguma outra merda trivial, fosse apenas 0.10.0 .

E então, e se na próxima semana, o suporte ao módulo es for lançado

E se na semana seguinte, a página da web tiver uma grande atualização

E se, na semana seguinte, lançássemos suporte simples a texto datilografado

Essas são todas as coisas que eu já fiz. Esses são todos como trabalhos de duas horas. Essa é uma cadência relaxada e fácil

Mas é tão diferente do que os usuários estão acostumados que deixaria claro que algo mudou

Estou bastante confiante de que esta biblioteca tem a comunidade de usuários e a base de defeitos para obter lançamentos submensais significativos, e estou bastante confiante de que poderia fazer isso acontecer

Eu também tenho meu próprio fork, um único arquivo, implementação de dependência zero com base no artigo acadêmico original. Eu originalmente tentei usar a base de código 0.10.0, mas mesmo isso estava muito inchado para o meu gosto.

Minha sensação é que qualquer um para quem isso é de missão crítica já se bifurcou porque lidar com o drama de "código aberto" é mais desgastante do que passar alguns fins de semana aprendendo e implementando uma solução para suas necessidades específicas. Sério, o artigo é de fácil leitura e em menos de 100 horas eu consegui um analisador 4x mais rápido e 100x menor.

Há sempre a troca fundamental entre querer usar uma solução existente e ter uma combinação perfeita para o seu próprio problema. As comunidades de analisadores estão em um vale difícil, onde uma vez que alguém aprendeu o suficiente para usar uma ferramenta de análise de forma eficaz, é apenas uma pequena quantidade de trabalho adicional para escrever seu próprio analisador inteiro.

O maior custo de oportunidade do código aberto é espiritual.

Namastê :pray:

PS Não me entenda mal, estou gostando muito desses tópicos, é um ótimo entretenimento! Só não espero muito valor produtivo das comunidades GH ou JS nos dias de hoje.

É um ponto de vista compreensível.

Dado o status atual das coisas, espero conseguir que as pessoas digam "bem, deixe uma tentativa acontecer e vamos ver"

@StoneCypher Eu gosto da sua energia que você parece querer colocar nesta lib e eu concordo com suas ideias gerais (e eu já teria depois da primeira vez que você as escreveu - não precisa dizer a mesma coisa cinco vezes :grin :) . Também não gosto muito de garfo, mas isso significa que dependemos exatamente de uma pessoa - futagoza. E se ele não responder? Então estamos presos, nada podemos fazer sobre isso. dmajda já disse que não tem mais direitos, então também não pode fazer nada.

Aqui está a coisa com a qual eu não concordo: "em um repositório diferente que ninguém pode ver ou nunca vai se importar" porque isso tem uma solução simples: abra um novo problema em letras maiúsculas dizendo algo como "PROJETO MORTO - CONTINUA AQUI" e, em seguida, escreva todas as informações necessárias lá. Eu seria a primeira pessoa a mudar meu projeto, e tenho certeza que muitos outros o fariam. E esse não seria o primeiro projeto que isso aconteceria, já acompanhei alguns outros projetos nesse caminho. Não é nada demais, basta trocar. Como usuário, eu realmente não me importo de onde recebo meu código, desde que seja um lugar com o qual as pessoas se importem.

Então eu daria ao @futagoza mais algumas semanas para ver se ele responde e qual é a opinião dele. Se não houver sinal de vida e nenhuma resposta, vá em frente e recrie este projeto corretamente.

Na verdade, acabei de ver que @michel-kraemer também é membro do pegjs, então talvez haja ainda mais esperança :grinning:

@michael-brade - Garfos não funcionam. Vou ser bem direto: não quero que você me diga para fazer algo diferente de novo

Já existem quatro forks tentando salvar este repositório. Você não sabe o que são. Você não está procurando por eles ao dizer "conserte assim".

Não importa. Um garfo não vai consertar nada. Os consumidores downstream existentes não recebem correções de bugs em uma bifurcação. PRs são perdidos em uma bifurcação. Os problemas são perdidos em uma bifurcação.

A resposta é um duro não.

@futagoza deve parar de bloquear o peg imediatamente.

Esta biblioteca não vai morrer porque alguém prometeu ser um mantenedor, recusou-se a mantê-la e decidiu mantê-la para si.

Moralmente, o @futagoza não tem o direito de prometer ser um mantenedor e depois destruir a biblioteca.

Já existem quatro forks tentando salvar este repositório .

Como você sabe que eles são? Você tem algum link? O único tipo de fork ativo que vejo é meisl/pegjs, nenhum dos outros está ativo. E mesmo o fork meisl não parece ser uma tentativa de salvar este repositório.

Você não está procurando por eles ao dizer "conserte assim".

Talvez você não tenha lido minha sugestão: se esses forks pretendiam salvar este repositório, eles fizeram isso errado porque não criaram um problema óbvio dizendo à comunidade para onde ir. Concordo com tudo o que você diz até que este marcador seja criado. Então as regras mudam.

@futagoza deve parar de bloquear o peg imediatamente.

Direito. E como você pretende impor isso?

Como você sabe que eles são?

Porque eu fui à procura de correções de bugs, anos atrás.

.

Você tem algum link?

sim. No entanto, se os garfos funcionassem, eu não teria que dá-los; você os teria também. Esta é a minha explicação de por que eu não vou considerar um fork, ou entreter mais tempo perdido mollycoddling o mantenedor falso

.

se esses forks pretendiam salvar esse repositório, eles fizeram isso errado porque não criaram um problema óbvio dizendo à comunidade para onde ir.

Na verdade, eles fizeram. Foi deletado.

Em certo sentido, você está certo: eles fizeram errado, criando uma bifurcação.

A maioria das pessoas obtém bibliotecas de npm , onde essa biblioteca nem sequer tem um readme. Eles nunca vão ver o problema.

Estou sendo radicalmente claro quando digo "não quero ter mais discussões sobre forks".

Outras tentativas de discutir isso serão ignoradas.

.

Concordo com tudo o que você diz até que este marcador seja criado.

Já foi, várias vezes.

se esses forks pretendiam salvar esse repositório, eles fizeram isso errado porque não criaram um problema óbvio dizendo à comunidade para onde ir.

Na verdade, eles fizeram. Foi deletado.

Ok, não tenho como verificar isso. Mas supondo que você esteja certo, deve ser óbvio para você que a pessoa que excluiu esse problema não tem intenção de desistir do poder sobre esse repositório. Nessas circunstâncias, como você acha que pode mudar qualquer coisa sem um garfo?

Tudo o que posso dizer é que te desejo sorte. E isso eu seguirei onde quer que o desenvolvimento ativo ocorra.

como é que você acha que pode mudar qualquer coisa sem um garfo?

Porque eventualmente o futagoza voltará e ele terá que tomar essa decisão novamente.

Esses foram em 2018. É 2020. Ele iniciou pelo menos quatro analisadores PEG totalmente distintos desde então, um em uma linguagem base diferente, bem como duas linguagens de programação.

Naquela época, ele não tinha jogado fora três anos de trabalho como não confiáveis. Agora ele tem.

Naquela época, ele tinha apenas seis meses. Isso ainda é uma linha do tempo "bem, me dê uma chance", mal. Agora são três anos.

Naquela época, ele ainda podia dizer que estava comprometido com isso e que esse era seu foco.

As coisas mudaram.