Pegjs: Como definir uma regra para corresponder a um padrão várias vezes no PEG.js?

Por favor, leia as gramáticas de exemplo de peg. Não há bug aqui. Os rastreadores de problemas não se destinam a solicitações de ajuda. Uma das gramáticas de exemplo é exatamente o que você está pedindo.

O local apropriado para solicitações de ajuda é o StackOverflow. Os rastreadores de problemas são o que os desenvolvedores usam para acompanhar o que está quebrado e quais repositórios de pacotes usam para medir a qualidade do projeto.

Document
  = ClassRow+

ClassID
  = "G04"

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

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

Depois de ver isso, feche este problema. Obrigado.

A chave é aprender a ler gramáticas PEG. Isso diz:

1. "Um Document é um ou mais ClassRow s."
2. "A ClassID é a string fixa "G04" ."
3. "Um ClassTitle é qualquer texto até, mas não incluindo, a próxima nova linha. Você chamará isso de "título". Retorna título como uma string, não como uma matriz de caracteres."
4. "Um ClassRow é um ClassID seguido por um ClassRow .

Como ClassRow termina em uma nova linha, uma nova linha efetivamente inicia a nova linha.

Usarei o StackOverflow para minhas outras perguntas, obrigado pela resposta e pelas explicações.

No entanto, há algumas coisas que quero expressar:

1. A parte "Tipo de problema: Pergunta: [sim/não]" é um pouco enganosa em relação à diretiva que você mencionou. Interpretei essa seção como "O rastreador de problemas é o lugar certo para fazer perguntas"
2. "exemplos": vejo 4 exemplos de gramática na pasta examples/ . No entanto, IMHO, nenhum deles é adequado (simples o suficiente) para iniciantes (como eu ou para mim), exceto o "arithmetics.pegjs". Eu entendo que o PEG.js está em (pesado?) desenvolvimento, então é bastante compreensível que você possa estar mais focado em problemas/cenários complexos do mundo real. Eu só esperava exemplos passo a passo de gramáticas simples a complexas.

Por favor, considere isso como um feedback de recém-chegado.

A parte "Tipo de problema: Pergunta: [sim/não]" é um pouco enganosa em relação à diretiva que você mencionou. Interpretei essa seção como "O rastreador de problemas é o lugar certo para fazer perguntas"

Eu concordo. Quero remover esse texto e solicitado em 2017.

A razão pela qual o texto está lá é porque David, que não administra mais esta biblioteca, estava cansado de pessoas dizendo "isso é um bug" sem olhar para os problemas e encontrar a outra pessoa que achava que havia um bug, e não havia

Esta edição, por exemplo, tem meia dúzia de clones

.

"Exemplos": posso ver 4 exemplos de gramática na pasta exemplos/. No entanto, IMHO, nenhum deles é adequado (simples o suficiente) para iniciantes (como eu ou para mim), exceto o "arithmetics.pegjs".

Eu concordo. Eu gostaria de escrever muitos deles.

.

Entendo que o PEG.js está em desenvolvimento (pesado?)

Certamente não é.

O autor original o deixou inativo por um ano, então ele pediu novos mantenedores.

O novo mantenedor que assumiu em maio de 2017 não liberou um único byte de código para o branch master.

Comecei o processo de agitação para uma aquisição, porque o uso da biblioteca está caindo, a biblioteca não suporta javascript a partir de 2014, não há readme no NPM há quase três anos, correções de AST de caractere único são sem resposta por um ano em questões, e o novo mantenedor decidiu jogar fora 2,5 anos de uma ramificação de recursos que ele marcou como encerrando uma tonelada de questões e substituir toda a biblioteca por algo novo que ele mesmo escreveu em um idioma diferente

.

é bastante compreensível que você possa estar mais focado em problemas/cenários complexos do mundo real. Eu só esperava exemplos passo a passo de gramáticas simples a complexas.

Acredito que a integração do usuário é provavelmente o problema mais importante do mundo real agora, após a recuperação dessa biblioteca

Para maior clareza, não sou o autor original. @dmajda é.

Para maior clareza, não sou o mantenedor. Não há mantenedor.

A parte "Tipo de problema: Pergunta: [sim/não]" é um pouco enganosa em relação à diretiva que você mencionou. Interpretei essa seção como "O rastreador de problemas é o lugar certo para fazer perguntas"

@ceremcem , você fez tudo certo (além do que você não olhou para a descrição do PEG na wikipedia e não para tentar analisar sua gramática manualmente, após o que sua pergunta, IMHO, seria resolvida). Você não pode saber que sua pergunta é simplesmente uma pergunta ou uma descrição de um bug na biblioteca. Isso só pode ser decidido pelo desenvolvedor. Portanto, não existe uma regra GitHub apenas para bugs . Problema é problema mesmo na África

em geral, um rastreador de problemas é destinado a problemas, não a perguntas

O ceremcem teria obtido uma resposta em horas no stackoverflow. aqui, ele esperou nove dias, e se eu não tivesse falado, acho que ele não teria recebido uma resposta.

muitas perguntas semelhantes como essas ficam sem resposta aqui depois de um ano ou mais. há meia dúzia de oito anos.

.

Você não pode saber que sua pergunta é simplesmente uma pergunta ou uma descrição de um bug na biblioteca.

Sim ele pode. Ele estava perguntando "como eu faço isso?"

A menos que ele acredite que o analisador não pode fazer isso, isso nunca é um bug.

É basicamente a coisa mais simples possível em um analisador, e acredito que peg ainda é o analisador javascript mais usado, embora isso esteja rapidamente deixando de ser verdade e ele pareça ser inteligente, então não acho ele acreditava que um gerador de analisador não era capaz de usar uma regra mais de uma vez

No melhor interesse dele, é ideal encaminhá-lo para um recurso projetado para perguntas, em vez de reparo de biblioteca, especialmente se o recurso de pergunta for altamente ativo e o recurso de reparo de biblioteca acaba de anunciar que está desperdiçando três anos de trabalho e geralmente ignora perguntas como essas

Não é coincidência que isso não tenha sido respondido até eu começar a marcar pessoas, assim como meia dúzia de outras questões até agora

Nenhuma decisão está sendo tomada. Eu estava lhe dando conselhos.

Além disso, eu respondi sua pergunta .

Geralmente recebo uma resposta em poucas horas no StackOverflow, então sou um usuário regular dele. No entanto, não havia atividades na minha pergunta SO , então vim e perguntei aqui. Basicamente, os tempos de resposta são quase idênticos.

Eu vi todas as combinações de uso do rastreador de problemas:

• Apenas para relatórios de bugs, se for fornecido um fórum ou grupo de e-mail separado (PaperJS, por exemplo),
• Para perguntas e relatórios de bugs (RactiveJS <3, FreeCAD_Assembly3 <3)
• Para algo que eu realmente não entendo, junto com um fórum separado, onde os suspeitos do costume assumiram e estão falando em nome dos proprietários do projeto, o que causa mais frustração do que qualquer outra coisa (como KiCAD (grrr))
• Por nada (Espruino, AFAIR). Cada problema é imediatamente encerrado e você é forçado a abrir um tópico apropriado em seu fórum.

Não há uma única escolha melhor para isso (ninguém se encaixa em todos os casos), mas eu gosto de usar o rastreador de problemas para tudo.

Você não pode saber que sua pergunta é simplesmente uma pergunta ou uma descrição de um bug na biblioteca.

Já vimos isso muitas vezes na biblioteca FreeCAD_Assembly3. Muitas das minhas perguntas simples e idiotas revelaram um ou mais bugs. Isso acontece, eu vi.

Eu concordo. Eu gostaria de escrever muitos deles.

Eu gosto de sua abordagem para esta biblioteca. Você parece se importar muito.

então eu não acho que ele acreditava que um gerador de analisador não era capaz de usar uma regra mais de uma vez

Correto. Minha intenção não era um relatório de bug. Só não encontrei a saída para reutilizar a mesma regra para várias linhas.

No entanto, não havia atividades na minha pergunta SO, então vim e perguntei aqui.

Oh cara, a comunidade peg lá também morreu?

Que triste ☹️

Ok, se você já fez um post SO, então nesse ponto você está 100% correto em vir aqui

.

Eu vi todas as combinações de uso do rastreador de problemas:

Sim, as pessoas violam as normas da comunidade o tempo todo

.

Eu concordo. Eu gostaria de escrever muitos deles.

Eu gosto de sua abordagem para esta biblioteca. Você parece se importar muito.

Muito. Eu queria estar envolvido na transição de propriedade de 2017, mas alguém deu um plano com 17 grandes lançamentos, e o antigo proprietário acreditou neles

Essa pessoa desistiu de seu primeiro lançamento menor três anos depois.

A verdade é que software público é muito difícil de escrever. Quase todo mundo que conheço, inclusive eu, tem a tendência de dizer "este lançamento não está pronto até que X, Y e Z estejam prontos".

E então, quando Y termina, você percebe que também precisa de V e W.

E então, quando Z termina, você percebe que também precisa de S, T e U.

E então quando V termina...

Foi assim que 0.11.0 começou com meia dúzia de recursos em 2017 e morreu com cem mesclagens marcadas incorretamente como fechadas no rastreador em 2020

Parte da disciplina de software público são lançamentos frequentes e pequenos. Isso sempre foi um problema com o peg, mas a qualidade do software era tão alta que agüentávamos mesmo assim.

Então dmajda saiu, e tudo parou.

E esperamos, pacientemente, por muito tempo.

Mas o novo cara agora chama isso de seu projeto de hobby e diz que descartou a coisa toda em favor de algo novo e incompatível que ele escreveu. E mesmo que tivesse o mesmo AST e o mesmo conjunto de recursos e mais, não teria dez anos de depuração da comunidade por trás dele, e eu não seria capaz de mudar

E você sabe, se ele quiser escrever um analisador PEG novo e mais poderoso, tudo bem, ótimo, vá em frente.

Mas ele não consegue matar este fingindo ser um mantenedor e nunca mantendo, depois assumindo a comunidade e a posição da biblioteca deste, e colocando seu próprio software que nunca será lançado em seu lugar

É hora de um processo saudável retomar. O novo mantenedor construiu uma microcomunidade de desenvolvedores juniores, e eles estão defendendo manter a biblioteca morta em vez de salvá-la

É claro que a mudança é extremamente necessária

.

Só não encontrei a saída para reutilizar a mesma regra para várias linhas.

Se você tiver problemas para encontrar respostas novamente, sinta-se à vontade para me marcar pessoalmente

Dito isso, geralmente eu procuro exemplos no Google, e porque essa biblioteca já foi tão popular e muito usada (e pode ser novamente se os assassinos de bibliotecas atuais apenas abrirem espaço no banco para outra pessoa ajudar), existem exemplos mais do que suficientes lá fora para cobrir as coisas que você precisa encontrar

Geralmente, porém, o que eu gostaria que alguém tivesse me dito quando eu era novo é o que eu disse sob o comentário começando "A chave é aprender a ler gramáticas PEG"

Uma vez que você aprende a ler gramáticas PEG nesse formulário de discussão, também se torna muito fácil pensar sobre elas e, nesse ponto, elas são de repente trivialmente fáceis de escrever.

É como um interruptor de luz. Sem rampa. Direto do impossível ao fácil

É como um interruptor de luz. Sem rampa. Direto do impossível ao fácil

Você me incentivou! :) Então eu não deveria me sentir tão estúpido quando eu só podia ver alguns conjuntos de regras "sem sentido" :)

Se você tiver problemas para encontrar respostas novamente, sinta-se à vontade para me marcar pessoalmente

Eu não quero abusar disso, então será difícil ligar toda vez se vale a pena perguntar ou devo pesquisar um pouco mais na net. Esta foi uma oferta generosa, obrigado.

É claro que a mudança é extremamente necessária

Vejo que você ativou a seção "problemas" em sua bifurcação. Isso é sempre um bom sinal de tentar pilotar um avião entrando correndo na cabine enquanto você era apenas um passageiro. Isso é uma coisa boa.

Se houver uma fonte de água viva, ela sempre encontrará seu caminho para fluir, não importa o que você coloque em seu caminho. Se não houver fluxo porque a fonte está drenada, não há nada a fazer. A fonte é a demanda. Sua atitude indica que a fonte da água está muito viva.

Então, estou curioso, por que você simplesmente não assume? Isso é o que eu fiz para carregar a biblioteca da barra . Percebi que o desenvolvimento está parado, então assumi o controle dos problemas começando pelos meus e criando pull requests para cada branch. Algum tempo depois, o autor original decidiu continuar seu trabalho, e estávamos prontos para ir. Você acha que essa é uma solução viável?

Você me incentivou! :)

Estou feliz.

.

É como um interruptor de luz. Sem rampa. Direto do impossível ao fácil

Então eu não deveria me sentir tão estúpido quando eu só podia ver alguns conjuntos de regras "sem sentido" :)

Não. Os analisadores são um caso extremo da coisa "é ridículo e, de repente, é fácil".

Aqui está o kicker - comparativamente falando, peg é bem fácil. Os outros são muitas vezes apenas brutais.

Existem, na minha opinião, quatro grandes problemas no aprendizado do peg.

1. Não há nenhum material introdutório muito bem estruturado
2. Existem muitos exemplos de nível médio por aí, mas você precisa ser bom no google para encontrá-los
3. Também há maus exemplos e é preciso experiência para identificá-los
4. Você tem que ser capaz de "pensar assim" e isso não acontece imediatamente

Estou pensando em fazer alguns tutoriais em vídeo. Eles tornariam isso _muito_ mais fácil de entender, eu acredito.

.

Eu não quero abusar disso, então será difícil ligar toda vez se valer a pena perguntar

Uma vez por semana está bom. Entenda que às vezes sou lento para responder

.

Vejo que você ativou a seção "problemas" em sua bifurcação. Isso é sempre um bom sinal de tentar pilotar um avião entrando correndo na cabine enquanto você era apenas um passageiro. Isso é uma coisa boa.

Eu mal comecei. Primeiro eu quero ver se o repositório real pode ser resgatado

Fazer isso de um garfo seria obscenamente mais difícil. Eu perderia todos os PRs e todas as referências cruzadas, e todo o material fechado não mesclado ou fechado deletado, alguns dos quais são muito valiosos

.

Então, estou curioso, por que você simplesmente não assume?

Eu gostaria de.

Neste momento, as senhas e autenticação relevantes estão nas mãos de uma pessoa, e ela ainda não respondeu.

Veremos.

.

Percebi que o desenvolvimento está parado, então assumi o controle abordando os problemas começando pelos meus e criando pull requests para cada branch

Este é um caso especial

O que está publicado é 0.10.0

O novo mantenedor permitiu que o ramo 0.11.0 crescesse sem limites por três anos, então decidiu que foi cancelado, em favor de um 0.12.0 que ele está escrevendo do zero isoladamente

Não há nada para colocar PRs. O que está em npm é de 2017, e o que está em github sob o novo mantenedor é cancelado após três anos sem nunca ter publicado

.

Algum tempo depois, o autor original decidiu continuar seu trabalho, e estávamos prontos para ir. Você acha que essa é uma solução viável?

Se o mantenedor substituto estiver disposto a permitir, isso é exatamente o que eu quero.

Duvido que David volte, mas se voltar, seria fantástico

Como tal, quero transformar isso em um projeto de código aberto padrão novamente

Quais são as 3 questões mais importantes aqui, de acordo com você?

Acho que dizer quais são as questões mais importantes para mim é um pouco perigoso, porque tem um número razoável de pessoas aqui com mais experiência do que eu em peg , e se eles dizem "na verdade é essa outra coisa, "É provável que eu escute.

Para esse fim, quero alertar que, embora esteja feliz em desenvolver aqui, meu interesse aqui é como mantenedor .

Isso é, eu acho, algo que muitas pessoas não entendem: codificação de desenvolvimento e manutenção são muito, muito diferentes.

• Development coding quer grandes ideias novas, novos recursos, novas ideias chamativas.
• Maintenance coding quer resolver pequenos problemas antes que eles se agreguem e tornem algo bom inutilizável.

Estou feliz em fazer alguma codificação de desenvolvimento - talvez até ansioso para alguns - mas há outras pessoas aqui que são mais adequadas para isso. E, por isso, quero deixar claro: meu objetivo real é fazer isso para que eles possam contribuir com PRs novamente, como costumavam fazer.

Dito isto, para mostrar qual é o meu ponto de vista pessoal:

1. Recuperando uma cadência de lançamento regular

peg.js nunca deve ter um ramo mágico novamente. É como a porra do Um Anel. Parece ótimo e poderoso, mas não funciona, e no final, você é Gollum. Isso não é svn . Na voz de Steve Ballmer, feature branches , feature branches , feature branches , feature branches .

Uma versão deve ser o resultado de um recurso, não um ponto de coleta para um plano de recursos. Não somos uma empresa dos anos 1980 e não deveríamos estar planejando como uma.

A única vez que mais de um recurso deve entrar ao mesmo tempo é quando é inevitável, como o resultado de recursos de patch para lidar com uma atualização externa ou coisas que genuinamente não podem ser feitas separadamente. Ah, você acha que isso está relacionado a outro recurso? Ótimo, coloque 2.31.0 , precisamos tirar 2.29.0 e essa outra coisa ali provavelmente será 30 .

As pessoas têm tratado os menores como se fossem maiores. É por isso que o menor nunca saiu: foi pendurado na mesma armadilha comportamental que trava os maiores. Apenas não faça isso, porra, ™.

Para ser específico,

• As pessoas, acredito, perderam em grande parte a fé de que essa biblioteca ainda existe.
• Três meses de lançamentos semanais levariam as pessoas a dar outra chance.
  
  
  
  • Três meses de lançamentos semanais seriam realmente super fáceis de alcançar
  
  
• Se não tivéssemos apenas 0.12.0 , mas também 0.13.0 - e observe que não estou dizendo o que há neles, e acho que não importa - então teríamos ter uma chance real de 1.0.0
• Apenas passando pelos PRs abertos e fechados não mesclados aqui, há uma enorme quantidade de poder e beleza, com um comentário de 2015 mais ou menos como "Vou analisar isso mais tarde". Ser uma pessoa generosa e encontrar espaço para compartilhar autoridade ajudaria peg não apenas a ganhar vida, mas a florescer
• Para esse fim, eu não quero ser o artista. Eu quero ser o curador.

2. Colocar a documentação e os testes em um local aceitável

Todo mundo fala sobre isso, mas meu hobby máquina de estado finito atualmente tem 3500 testes de unidade e 100% de cobertura de documentação, então, me leve mais a sério.

Eu realmente acredito profundamente em testes.

Há outra biblioteca que escrevi que tem metade do tamanho e complexidade significativamente menor do que a máquina de estado. É muito mais fácil fazer alterações de linguagem abrangentes na máquina de estado do que pequenas alterações no manipulador de rede, porque o manipulador de rede é mal testado e você precisa fazer um esforço real para garantir que algo esteja certo.

O FSM? Não, os testes são ótimos, eles vão te pegar

Esse contraste específico me lembra com uma clareza brutal toda vez que toco em qualquer um deles o quão importante é o teste para que algo seja, pelo menos para mim, confiável.

Eu acho que uma grande parte do problema de trabalhar em peg.js é que os testes e a documentação estão em frangalhos. Acho que está na hora de isso mudar.

3. Removendo o absurdo hipster.

• Eu não sou uma pessoa de Ruby, mas o pessoal de Ruby tem um ponto real sobre configuração por convenção. Eu não entendo nada de Ruby, mas ainda posso sentar e saber como um projeto funciona, porque é assim que todos funcionam, e se eu não conseguir algo posso perguntar a alguém, e eles não precisam de acesso, porque é assim que todos eles funcionam
• peg enfrenta quatro problemas nesse sentido
  
  
  
  1. peg é uma biblioteca javascript extremamente antiga, e fez um monte de escolhas fundamentais antes que as normas da comunidade existissem. na verdade, várias normas da comunidade são por causa de david; antes da fixação, muitas pessoas pensavam que multipackaging era difícil, então agora que um dos pioneiros a esse respeito está problematicamente atrasado no mesmo sentido, é meio de partir o coração. Dito isto, além das coisas brilhantes que David acertou antes do tempo, algumas coisas que ele errou, e algumas coisas que estavam certas naquela época não são mais. Muitas pequenas mudanças resultariam em uma mudança radical na experiência do desenvolvedor.
  
  
  2. As normas comunitárias devem ser restabelecidas.
     
     
     
     
     
     1. Há apenas certas maneiras de um projeto node funcionar. Isso inclui a produção de saída direcionada ao navegador e, portanto, um projeto de nó é claramente a maneira moderna certa de trabalhar
     
     
     
     2. Este ainda é um projeto de navegador com automação feita à mão. Isso deve mudar
     
     
     
     3. É um desafio de aprendizado significativo chegar à posição de editar corretamente o README . Depois de três anos, o mantenedor atual ainda não conseguiu (!), e nem o desenvolvedor original nas duas últimas versões
        
        
        
        
        
        
        
        • Isso é asinino. Partes do projeto que deveriam ser triviais estão quebrando porque não são feitas da maneira simples e normal. Eles devem ser feitos da maneira simples e normal, mas isso requer alguém que conheça o nó e esteja pronto para fazer um trabalho chato.
        
        
        
        
     
     
     
  
  
  3. peg é tanto o beneficiário quanto a vítima da automação extrema.
     
     
     
     
     
     • É provável que dmajda não pudesse ter chegado tão longe sem ele. Eu certamente não posso em minhas coisas.
     
     
     
     • No entanto, esta é a automação de 2011, não a automação de 2020
     
     
     
     • Também é a automação de 2013, 2014, 2016 e 2018. Essas coisas estão espalhadas pelo zeit, agora, páginas do github, uma conta pessoal do yahoo, gitlab, vários serviços estranhos de rastreamento e implantação automática e provavelmente um monte de coisas que ainda não encontrei
     
     
     
     • É apenas uma surra de ferramentas para sobreviver a um colapso ou brincar com a novidade quente. A seleção cuidadosa da ferramenta leva à permanência por design. O real repl é quase dez anos durável agora. Todo o resto também pode ser, se "ooh shiny" for tratado como uma bandeira vermelha.
     
     
     
     • Isso deve ser movido para gh pages e gh actions , que todos entendem, e deixado em paz para sempre
     
     
     
  
  
  4. O novo mantenedor optou por mergulhar fundo em ferramentas incomuns e estratégias marginalizadas. Como resultado, você precisa instalar um novo gerenciador de pacotes para contribuir com correções de bugs e aprender um layout de fonte incomum que coexiste, de maneira confusa, com um conjunto de fontes não relacionado que parece ser o produto real, no layout de fonte regular.
     
     
     
     
     
     • Quando um terceiro contribuiu com uma correção permitindo que o gerenciador de pacotes de idioma padrão também funcionasse, ele a rejeitou.
     
     
     
     • Esse tipo de comportamento é, francamente, inaceitável em um projeto comunitário. Isso torna a biblioteca muito mais difícil de contribuir.
     
     
     
     • Várias dessas ferramentas extremistas foram substituídas por outras ferramentas extremistas, então ele não vai atrás de coisas que conhece; ele está experimentando coisas. Enquanto isso, esperamos pelo básico, como erros de ortografia no AST, como corrigir readme em npm ou mesclar es6 modules , por três anos de cada vez.
     
     
     
     • Francamente, em um rebake 0.12.0 , coisas como o módulo em material de fio de módulo simplesmente sairiam. O material de construção de David funciona desde 2011. O novo material de 2018 já está quebrado em 2020. Não há mais tecnologia diletante.
     
     
     
  
  
• E POSSO OBTER UMA EXPORTAÇÃO ES6

mas você notará que nenhum deles é realmente sobre o software em si

eu não acho que o software aqui é o problema

eu acho que o processo é, e em menor grau, o projeto

é isso que eu vou consertar, se o @futagoza permitir

esta biblioteca pode voltar à vida em 30 dias se engolirmos nosso orgulho e escolhermos as necessidades da grande comunidade da biblioteca em vez de nossos interesses de projeto de hobby

deixe o hobby reescrever ser o garfo

deixe um mantenedor começar a manter

@StoneCypher Eu gosto de sua energia :-) Eu costumava usar pegjs no passado (nos tempos de dmajda) e gostei muito.

Basta bifurcá-lo e não lutar. As coisas podem e vão se acalmar mais tarde. Se a comunidade o seguir, você não precisa se preocupar com o "portador de chave" existente ou algo assim. Construir reputação leva tempo, mas é necessário. Não perca mais tempo discutindo.

Oito seu garfo vai "voltar para a origem" em algum momento no futuro ou terá vida própria. Ambas as opções são válidas e bem IMO.

Por favor, pare com a besteira de "fazer um garfo". Há quatro deles e você não sabe o que são. Um fork não salvará nenhum dos consumidores downstream existentes, não salvará os PRs, não salvará os problemas, não levará a comunidade e não será visível.

As pessoas vêm tentando isso há três anos. NÃO FUNCIONA.

Não continue a oferecer este conselho.

@futagoza - todo mundo desistiu de você fazer a coisa certa. Cinco pessoas me disseram para bifurcar a biblioteca, porque esperam que você se recuse a permitir o reparo e mantenha o controle da biblioteca que está matando.

Eu acredito que a razão pela qual eles esperam isso é que eu encontrei mais de uma dúzia de pessoas oferecendo ajuda para você fazer o que você prometeu fazer e nunca fez, e toda vez que você diz "não, eu vou fazer isso em breve. "

Faça o que você deveria ter feito em 2018, e dê manutenção para alguém que realmente vai manter o projeto. Pare de matar essa biblioteca, pare de matar essa comunidade e saia do caminho.

@StoneCypher John, quando sugeri criar um fork, eu realmente quis dizer isso. Bifurcar um projeto é uma ótima opção que o código aberto oferece, especialmente se você sentir que precisa de mudanças ou está morrendo. E não, eu não tenho nenhum problema, você não precisa me escrever DM só para me fazer essa pergunta.

Quando eu disse "não dê este conselho novamente", eu também quis dizer isso.

Eu amo essa conversa.

@StoneCypher Eu tenho que discordar de você aqui, porque vi exatamente o oposto:

1. Decidi começar a aprender FreeCAD. No entanto, havia um problema: seu "módulo de montagem" não estava completo, então quase não conseguimos criar montagens complexas, o que o torna inútil para o trabalho profissional.
2. Um cara, realthunder resolveu resolver esse problema. Ele precisava alterar algumas propriedades principais para atingir o objetivo, o que, por sua vez, tornou seu fork incompatível com o ramo principal. Ele perdeu todos os usuários, quase toda a comunidade. Exceto por algumas pessoas, ele não tinha apoiadores (é o que eu vejo). Ele também não tinha usuários ativos, até onde eu entendi.
3. Examinei a documentação dele ¹ e apesar do ano de paralisação no desenvolvimento (foi o que vi na época) fiz as contas (uma matemática interessante) e resolvi tentar.
4. Fiz muitas perguntas ¹ e ele as respondeu pacientemente. Enquanto isso, tomei notas sobre o que aprendi , portanto, fiz um bom material de introdução.
5. As pessoas desencorajavam ¹ a usar seu ramo alegando que ele era o autor e mantenedor solitário e que seu trabalho não deveria ser confiável em termos de sustentabilidade. Eu apenas os ignorei.
6. Sua solicitação de pull não foi mesclada por um longo tempo (cerca de um ano ou mais).

Ultimamente, seu PR começou a ser revisto. Uma grande quantidade de trabalho foi feita e, finalmente, seu ramo e o mainstream se tornaram compatíveis. Na próxima versão, acredito que seu ramo será incorporado ao mainstream.

Enquanto isso, havia um sério problema financeiro. Ele era o único mantenedor e a doação de alguns usuários não poderia fazê-lo sobreviver. Decidi ensinar o FreeCAD/Assembly3 aqui, na Turquia, e vender o suporte para sustentar as finanças. Eu o propus e isso é aceito. Fiz todas as inscrições necessárias para me tornar treinador em uma fundação de grande reputação, que foi aceita recentemente.

Às vezes, 1 pessoa é suficiente para iniciar um incêndio.

e saia do caminho

Discordo. Deixe-os ficar no caminho. Uma boa motivação sempre encontrará uma saída. Se não pode, é porque não foi tão bom.

Eu estou explicitamente e claramente não coletando conselhos sobre este tópico.

Esta biblioteca precisa ser ressuscitada. Desculpe se não estou explicando suficientemente, mas as respostas que estou recebendo não abordam nenhuma das preocupações práticas levantadas.

A vida e os empregos das pessoas dependem disso.