Pegjs: ¿Cómo definir una regla para que coincida con un patrón varias veces en PEG.js?

Por favor, lea las gramáticas de ejemplo de peg. No hay ningún error aquí. Los rastreadores de problemas no están destinados a solicitudes de ayuda. Una de las gramáticas de ejemplo es exactamente lo que estás pidiendo.

El lugar adecuado para las solicitudes de ayuda es StackOverflow. Los rastreadores de problemas son lo que usan los desarrolladores para realizar un seguimiento de lo que está roto y qué repositorios de paquetes usan para medir la calidad del proyecto.

Document
  = ClassRow+

ClassID
  = "G04"

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

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

Una vez que haya visto esto, cierre este problema. Gracias.

La clave es aprender a leer gramáticas PEG. Que dice:

1. "Un Document es uno o más ClassRow s".
2. "Un ClassID es la cadena fija "G04" ".
3. "Un ClassTitle es cualquier texto hasta el siguiente salto de línea, pero sin incluirlo. Lo llamarás "título". Devuelve el título como una cadena, no como una matriz de caracteres".
4. "Un ClassRow es un ClassID seguido de un ClassRow .

Debido a que ClassRow termina en una nueva línea, una nueva línea comienza efectivamente la nueva fila.

Usaré StackOverflow para mis preguntas adicionales, gracias por la respuesta y las explicaciones.

Sin embargo, hay algunas cosas que quiero expresar:

1. La parte "Tipo de problema: Pregunta: [sí/no]" es un poco engañosa con respecto a la directiva que mencionó. Interpreté esa sección como "El rastreador de problemas es el lugar adecuado para hacer preguntas".
2. "ejemplos": puedo ver 4 gramáticas de ejemplo en la carpeta examples/ . Sin embargo, en mi humilde opinión, ninguno de ellos es adecuado (bastante simple) para principiantes (como yo, o para mí) a excepción de "arithmetics.pegjs". Entiendo que PEG.js está en desarrollo (¿intenso?), por lo que es bastante comprensible que esté más centrado en problemas/escenarios complejos del mundo real. Solo esperaba ejemplos paso a paso desde gramáticas simples a complejas.

Por favor, considérelo como un comentario de recién llegado.

La parte "Tipo de problema: Pregunta: [sí/no]" es un poco engañosa con respecto a la directiva que mencionó. Interpreté esa sección como "El rastreador de problemas es el lugar adecuado para hacer preguntas".

Estoy de acuerdo. Quiero eliminar ese texto y lo pedí en 2017.

La razón por la que el texto está ahí es porque David, que ya no dirige esta biblioteca, estaba cansado de que la gente dijera "esto es un error" sin mirar los problemas y encontrar a la otra persona que pensó que había un error, y no lo había.

Este número, por ejemplo, tiene media docena de clones.

.

"Ejemplos": puedo ver 4 gramáticas de ejemplo en la carpeta Examples/. Sin embargo, en mi humilde opinión, ninguno de ellos es adecuado (bastante simple) para principiantes (como yo, o para mí) a excepción de "arithmetics.pegjs".

Estoy de acuerdo. Me gustaría escribir muchos de ellos.

.

Entiendo que PEG.js está en desarrollo (¿intenso?)

Ciertamente no lo es.

El autor original lo había dejado inactivo durante un año, por lo que pidió nuevos mantenedores.

El nuevo mantenedor que asumió el cargo en mayo de 2017 no ha publicado ni un solo byte de código en la rama maestra.

Comencé el proceso de agitación para una adquisición, porque el uso de la biblioteca está disminuyendo, la biblioteca no es compatible con javascript desde 2014, no ha habido readme en NPM durante casi tres años, las correcciones de AST de un solo carácter son sin respuesta durante un año en ediciones, y el nuevo mantenedor ha decidido desechar 2,5 años de una rama de funciones que ha marcado como el cierre de una tonelada de ediciones, y reemplazar toda la biblioteca con algo nuevo que él mismo escribió en un idioma diferente

.

es bastante comprensible que pueda estar más centrado en problemas/escenarios complejos del mundo real. Solo esperaba ejemplos paso a paso desde gramáticas simples a complejas.

Creo que la incorporación de usuarios es probablemente el problema más importante del mundo real en este momento después de que esta biblioteca vuelva a estar saludable

Para mayor claridad, no soy el autor original. @dmajda lo es.

Para mayor claridad, no soy el mantenedor. No hay mantenedor.

La parte "Tipo de problema: Pregunta: [sí/no]" es un poco engañosa con respecto a la directiva que mencionó. Interpreté esa sección como "El rastreador de problemas es el lugar adecuado para hacer preguntas".

@ceremcem , hiciste todo bien (aparte de que no miraste la descripción de PEG en wikipedia y no intentaste analizar tu gramática manualmente, después de lo cual tu pregunta, en mi humilde opinión, se resolvería). No puede saber que su pregunta es simplemente una pregunta o una descripción de un error en la biblioteca. Esto solo puede ser decidido por el desarrollador. Por lo tanto, no existe una regla GitHub solo para errores . Problema es problema incluso en África

en general , un rastreador de problemas está destinado a problemas, no a preguntas

ceremcem habría obtenido una respuesta en horas en stackoverflow. aquí, esperó nueve días, y si no hubiera hablado, creo que no habría obtenido una respuesta.

muchas preguntas similares como estas quedan sin respuesta aquí después de un año o más. hay media docena que tienen ocho años.

.

No puede saber que su pregunta es simplemente una pregunta o una descripción de un error en la biblioteca.

Si, el puede. Él estaba preguntando "¿cómo hago esto?"

A menos que crea que el analizador no puede hacer esto, eso nunca es un error.

Es básicamente lo más simple posible en un analizador, y creo que peg sigue siendo el analizador de javascript más utilizado, aunque eso está dejando de ser cierto rápidamente, y parece ser inteligente, así que no creo creía que un generador de analizadores no podía usar una regla más de una vez

En su mejor interés, es ideal dirigirlo a un recurso que está diseñado para preguntas, en lugar de reparación de bibliotecas, especialmente si el recurso de preguntas es muy activo, y el recurso de reparación de bibliotecas acaba de anunciar que está hundiendo tres años de trabajo y generalmente ignora preguntas como estas

No es coincidencia que esto quedara sin respuesta hasta que comencé a etiquetar personas, al igual que media docena de otros problemas hasta ahora.

No se están tomando decisiones. Le estaba dando un consejo.

Además, respondí su pregunta .

Por lo general, recibo una respuesta en pocas horas en StackOverflow, por lo que soy un usuario habitual. Sin embargo, no hubo actividades en mi pregunta SO , así que vine y pregunté aquí. Básicamente, los tiempos de respuesta son casi idénticos.

He visto todas las combinaciones de uso del rastreador de problemas:

• Solo para informes de errores, si se proporciona un foro o grupo de correo separado (PaperJS, por ejemplo),
• Tanto para preguntas como para informes de errores (RactiveJS <3, FreeCAD_Assembly3 <3)
• Por algo que en realidad no entiendo, junto con un foro separado, donde los sospechosos habituales se hicieron cargo y hablan en nombre de los propietarios del proyecto, lo que causa más frustración que cualquier otra cosa (como KiCAD (grrr))
• Para nada (Espruino, AFAIR). Cada problema se cierra de inmediato y se ve obligado a abrir un hilo apropiado en su foro.

No existe una mejor opción para eso (nadie se adapta a todos los casos), pero me gusta usar el rastreador de problemas para todo.

No puede saber que su pregunta es simplemente una pregunta o una descripción de un error en la biblioteca.

Hemos visto esto muchas veces en la biblioteca FreeCAD_Assembly3. Muchas de mis preguntas simples y tontas revelaron uno o más errores. Esto pasa, lo vi.

Estoy de acuerdo. Me gustaría escribir muchos de ellos.

Me gusta tu enfoque de esta biblioteca. Parece que te importa mucho.

así que no creo que creyera que un generador de analizadores no podía usar una regla más de una vez

Correcto. Mi intención no era un informe de errores. Simplemente no encontré la salida para reutilizar la misma regla para varias líneas.

Sin embargo, no hubo actividades en mi pregunta SO, así que vine y pregunté aquí.

Oh hombre, ¿la comunidad peg allí también murió?

Eso es muy triste ☹️

De acuerdo, si ya hiciste una publicación SO, entonces en ese momento estás 100% correcto para venir aquí.

.

He visto todas las combinaciones de uso del rastreador de problemas:

Sí, la gente viola las normas de la comunidad todo el tiempo.

.

Estoy de acuerdo. Me gustaría escribir muchos de ellos.

Me gusta tu enfoque de esta biblioteca. Parece que te importa mucho.

Mucho. Quería participar en la transición de propiedad de 2017, pero alguien me dio un plan con 17 lanzamientos importantes y el propietario anterior les creyó.

Esa persona renunció a su primer lanzamiento menor tres años después.

La verdad es que el software público es muy difícil de escribir. Casi todos los que conozco, incluyéndome a mí, tienen la tendencia de decir "este lanzamiento no está listo hasta que X, Y y Z estén listos".

Y luego, cuando termina Y, te das cuenta de que también necesitas V y W.

Y luego, cuando Z termina, te das cuenta de que también necesitas S, T y U.

Y luego, cuando V termina...

Así es como 0.11.0 comenzó con media docena de funciones en 2017 y murió con cien fusiones marcadas incorrectamente como cerradas en el rastreador en 2020

Parte de la disciplina del software público son los lanzamientos pequeños y frecuentes. Eso siempre fue un problema con peg, pero la calidad del software era tan alta que lo soportamos de todos modos.

Entonces dmajda se fue, y todo se detuvo.

Y esperamos, pacientemente, durante mucho tiempo.

Pero el chico nuevo ahora llama a esto su proyecto de pasatiempo, y dice que desechó todo a favor de algo nuevo e incompatible que escribió. E incluso si tuviera el mismo AST y el mismo conjunto de características y más, no tendría diez años de depuración comunitaria detrás, y no podría cambiar

Y ya sabes, si quiere escribir un analizador PEG nuevo y más potente, está bien, genial, adelante.

Pero él no puede matar a este pretendiendo ser un mantenedor y luego nunca mantener, luego tomando el control de la comunidad y la posición de la biblioteca de este, y poniendo su propio software que nunca se lanzará en su lugar.

Es hora de que un proceso saludable se recupere. El nuevo mantenedor creó una microcomunidad de desarrolladores junior, y en realidad abogan por mantener la biblioteca muerta en lugar de salvarla.

Está claro que el cambio es muy necesario.

.

Simplemente no encontré la salida para reutilizar la misma regla para varias líneas.

Si tiene problemas para encontrar respuestas nuevamente, siéntase libre de etiquetarme personalmente

Dicho esto, generalmente busco ejemplos en Google, y debido a que esta biblioteca alguna vez fue muy popular y se usó mucho (y puede volver a serlo si los asesinos de bibliotecas actuales simplemente hacen espacio en el banco para que otra persona ayude), hay ejemplos más que suficientes. por ahí para cubrir las cosas que necesitarás encontrar

Sin embargo, en general, lo que desearía que alguien me hubiera dicho cuando era nuevo es lo que dije debajo del comentario que comienza "La clave es aprender a leer las gramáticas PEG".

Una vez que aprende a leer las gramáticas PEG en esa forma de discusión, también se vuelve muy fácil pensar en ellas, y en ese punto, de repente, son trivialmente fáciles de escribir.

Es como un interruptor de luz. Sin rampa. Directo de lo imposible a lo fácil

Es como un interruptor de luz. Sin rampa. Directo de lo imposible a lo fácil

¡Me animaste! :) Así que no debería sentirme tan estúpido cuando solo podía ver algunos conjuntos de reglas de "galimatías" :)

Si tiene problemas para encontrar respuestas nuevamente, siéntase libre de etiquetarme personalmente

No quiero abusar de esto, por lo que será difícil llamar cada vez si vale la pena preguntar o debo buscar en la red un poco más. Esta fue una oferta generosa, gracias.

Está claro que el cambio es muy necesario.

Veo que habilitó la sección "problemas" en su bifurcación. Eso siempre es una buena señal de intentar volar un avión de pasajeros corriendo a la cabina cuando solo eras un pasajero. Eso es bueno.

Si hay una fuente de agua viva, siempre encontrará la forma de fluir, sin importar lo que ponga en su camino. Si no hay flujo porque su fuente está drenada, no hay nada que hacer. La fuente es la demanda. Tu actitud indica que la fuente del agua está muy viva.

Así que tengo curiosidad, ¿por qué no te haces cargo? Eso es lo que hice para la biblioteca de la barra de carga . Me di cuenta de que el desarrollo estaba estancado, así que asumí el control abordando los problemas a partir de los míos y creando solicitudes de incorporación de cambios para cada rama. Algún tiempo después, el autor original decidió continuar con su trabajo y estábamos listos para continuar. ¿Crees que esta es una solución factible?

¡Me animaste! :)

Me alegro.

.

Es como un interruptor de luz. Sin rampa. Directo de lo imposible a lo fácil

Así que no debería sentirme tan estúpido cuando solo pude ver algunos conjuntos de reglas de "galimatías" :)

No. Los analizadores son un caso extremo de "es simplemente ridículo y luego, de repente, es fácil".

Aquí está el truco: comparativamente hablando, la clavija es bastante fácil. Los otros a menudo son simplemente brutales.

Hay en mi opinión cuatro grandes problemas en el aprendizaje de peg.

1. No hay ningún material introductorio realmente bien estructurado.
2. Hay muchos ejemplos de nivel medio, pero tienes que ser bueno en Google para encontrarlos.
3. También hay malos ejemplos allí y se necesita experiencia para poder identificarlos.
4. Tienes que ser capaz de "pensar de esta manera", y eso no sucede de inmediato.

He estado pensando en hacer algunos tutoriales en vídeo. Creo que harían esto mucho más fácil de entender.

.

No quiero abusar de esto, por lo que será difícil llamar siempre si vale la pena preguntar.

Una vez a la semana está bien. Entiende que a veces soy lento para responder

.

Veo que habilitó la sección "problemas" en su bifurcación. Eso siempre es una buena señal de intentar volar un avión de pasajeros corriendo a la cabina cuando solo eras un pasajero. Eso es bueno.

Apenas he empezado. Primero quiero ver si el repositorio real puede ser rescatado

Hacer esto con un tenedor sería obscenamente más difícil. Perdería todos los PR y todas las referencias cruzadas, y todo el material cerrado no fusionado o cerrado eliminado, parte del cual es muy valioso

.

Así que tengo curiosidad, ¿por qué no te haces cargo?

Me gustaría.

En este momento, las contraseñas y la autenticación relevantes están en manos de una sola persona y aún no han respondido.

Ya veremos.

.

Me di cuenta de que el desarrollo estaba estancado, así que asumí el control abordando los problemas a partir de los míos y creando solicitudes de incorporación de cambios para cada rama.

este es un caso especial

Lo publicado es 0.10.0

El nuevo mantenedor permitió que la rama 0.11.0 creciera sin límites durante tres años, luego decidió cancelarla, a favor de un 0.12.0 que está escribiendo desde cero de forma aislada.

No hay nada a lo que poner relaciones públicas. Lo que hay en npm es de 2017, y lo que hay en github bajo el nuevo mantenedor se cancela después de tres años sin haber publicado nunca

.

Algún tiempo después, el autor original decidió continuar con su trabajo y estábamos listos para comenzar. ¿Crees que esta es una solución factible?

Si el mantenedor de reemplazo está dispuesto a permitirlo, esto es exactamente lo que quiero.

Dudo un poco que David regrese, pero si lo hace, sería fantástico.

Como tal, quiero volver a convertir esto en un proyecto estándar de código abierto.

¿Cuáles son los 3 temas más importantes aquí, según usted?

Creo que decir cuáles son los temas más importantes para mí es un poco peligroso, porque hay un buen número de personas aquí con más experiencia que yo en peg , y si dicen "en realidad es esta otra cosa, "Es probable que escuche.

Con ese fin, quiero advertir que si bien estoy feliz de desarrollar aquí, mi interés aquí es como mantenedor .

Creo que esto es algo que mucha gente no entiende: la codificación de desarrollo y mantenimiento es muy, muy diferente.

• Development coding quiere grandes ideas nuevas, nuevas características, nuevas ideas llamativas.
• Maintenance coding quiere solucionar pequeños problemas antes de que se acumulen y dejen algo bueno inutilizable.

Estoy feliz de hacer un poco de codificación de desarrollo, tal vez incluso con ganas de hacer algo, pero hay otras personas aquí que se adaptan mejor a esto. Y, entonces, quiero dejar en claro: mi objetivo real es hacer esto para que puedan contribuir con PR nuevamente, como solían hacerlo.

Dicho esto, para mostrar cuál es mi punto de vista personal:

1. Recuperar una cadencia regular de liberación

peg.js nunca debe volver a tener una rama mágica. Es como el jodido Anillo Único. Suena genial y poderoso, pero no funciona, y al final, eres Gollum. Esto no es svn . En la voz de Steve Ballmer, feature branches , feature branches , feature branches , feature branches .

Una versión debe ser el resultado de una función, no un punto de recopilación para un plan de funciones. No somos una empresa de los 80 y no deberíamos planificar como tal.

La única vez que más de una característica debe entrar al mismo tiempo es cuando es inevitable, como el resultado de parchear características para hacer frente a una actualización externa, o cosas que realmente no se pueden hacer por separado. Oh, ¿crees que eso está relacionado con otra función? Genial, ponlo en 2.31.0 , necesitamos sacar 2.29.0 y es probable que esta otra cosa sea 30 .

La gente ha estado tratando a los menores como si fueran mayores. Por eso nunca salió el menor: quedó colgado en la misma trampa conductual que cuelga a los mayores. Simplemente no hagas eso ™.

Ser especifico,

• La gente, creo, ha perdido en gran medida su fe en que esta biblioteca ya existe.
• Tres meses de lanzamientos semanales harían que la gente le diera otra oportunidad.
  
  
  
  • Tres meses de lanzamientos semanales en realidad serían muy fáciles de lograr
  
  
• Si no solo obtuviéramos 0.12.0 , sino también 0.13.0 , y noten que no digo lo que contienen, y creo que no importa, entonces tener una oportunidad real de 1.0.0
• Solo revisando las relaciones públicas abiertas y cerradas no fusionadas aquí, hay una gran cantidad de poder y belleza, con un comentario de 2015 más o menos como "Lo investigaré más tarde". Ser una persona generosa y encontrar espacio para compartir la autoridad ayudaría a peg no solo a cobrar vida, sino a florecer.
• Con ese fin, no quiero ser el artista. Quiero ser el curador.

2. Obtener la documentación y las pruebas en un lugar aceptable

Todo el mundo habla de esto, pero mi máquina de estados finitos de hobby actualmente tiene 3500 pruebas unitarias y una cobertura de documentación del 100 %, así que tómenme más en serio.

Realmente creo profundamente en las pruebas.

Hay otra biblioteca que escribí que tiene la mitad del tamaño y una complejidad significativamente menor que la máquina de estado. Es mucho más fácil hacer cambios radicales en el idioma de la máquina de estado que pequeños cambios en el controlador de red, porque el controlador de red está mal probado y debe esforzarse mucho para asegurarse de que algo esté bien.

¿El MEV? Nah, las pruebas son geniales, te atraparán

Este contraste específico me recuerda con una claridad brutal cada vez que toco cualquiera de ellos cuán importantes son las pruebas para que algo sea, al menos para mí, confiable.

Creo que una gran parte del problema de trabajar en peg.js es que las pruebas y la documentación son un desastre. Creo que es hora de que eso cambie.

3. Eliminando las tonterías hipster.

• No soy una persona de Ruby, pero la gente de Ruby tiene un punto real sobre la configuración por convención. No conozco Ruby en absoluto, pero aún puedo sentarme y saber cómo funciona un proyecto, porque así es como funcionan todos, y si no obtengo algo, puedo preguntarle a alguien, y no necesitan acceso, porque así es como funcionan todos
• peg se enfrenta a cuatro problemas en este sentido
  
  
  
  1. peg es una biblioteca javascript extremadamente temprana, y tomó un montón de decisiones fundamentales antes de que existieran las normas de la comunidad. de hecho, varias normas comunitarias se deben a david; antes de la vinculación, muchas personas pensaban que los empaques múltiples eran difíciles, por lo que ahora que uno de los pioneros en ese sentido está problemáticamente atrasado en el mismo aspecto, es un poco desgarrador. Dicho esto, además de las cosas brillantes que David hizo bien antes de tiempo, algunas cosas se equivocó y algunas cosas que eran correctas en ese momento ya no lo son. Muchos pequeños cambios darían como resultado un cambio radical en la experiencia del desarrollador.
  
  
  2. Deben restablecerse las normas comunitarias.
     
     
     
     
     
     1. Hay ciertas formas en que se supone que funciona un proyecto node . Eso incluye producir resultados dirigidos al navegador y, por lo tanto, un proyecto de nodo es claramente la forma moderna correcta de trabajar.
     
     
     
     2. Este sigue siendo un proyecto de navegador con automatización hecha a mano. eso debería cambiar
     
     
     
     3. Es un desafío de aprendizaje significativo ponerse en posición de editar correctamente el README . Después de tres años, el mantenedor actual aún no lo ha logrado (!), y tampoco el desarrollador original en las últimas dos versiones.
        
        
        
        
        
        
        
        • Esto es una estupidez. Piezas del proyecto que deberían ser triviales se rompen porque no se hacen de la manera normal y sencilla. Deben hacerse de la manera simple y normal, pero eso requiere alguien que conozca el nodo y esté listo para hacer un trabajo aburrido.
        
        
        
        
     
     
     
  
  
  3. peg es tanto el beneficiario como la víctima de la automatización extrema.
     
     
     
     
     
     • Es probable que dmajda no hubiera llegado tan lejos sin él. Ciertamente no puedo con mis cosas.
     
     
     
     • Sin embargo, esta es la automatización de 2011, no la automatización de 2020
     
     
     
     • También es la automatización de 2013, 2014, 2016 y 2018. Este material se distribuye en Zeit, ahora, páginas de github, una cuenta personal de Yahoo, gitlab, varios servicios extraños de seguimiento y de implementación automática, y probablemente un montón de cosas que aún no he encontrado.
     
     
     
     • Es solo una herramienta para sobrevivir a un colapso o jugar con lo nuevo y atractivo. La selección cuidadosa de herramientas conduce a la permanencia por diseño. Los repl reales duran casi diez años ahora. Todo lo demás también puede serlo, si "ooh brillante" se trata como una bandera roja.
     
     
     
     • Esto debe moverse a gh pages y gh actions , que todos entienden, y dejarlo así para siempre
     
     
     
  
  
  4. El nuevo mantenedor optó por profundizar en herramientas poco comunes y estrategias marginadas. Como resultado, debe instalar un nuevo administrador de paquetes para contribuir con las correcciones de errores y aprender un diseño de código fuente poco común que coexiste, de manera confusa, con un conjunto de código fuente no relacionado que parece ser el producto real, en el diseño de código fuente normal.
     
     
     
     
     
     • Cuando un tercero aportó una solución que permitía que el administrador de paquetes de idioma estándar también funcionara, la rechazó.
     
     
     
     • Este tipo de comportamiento es, francamente, inaceptable en un proyecto comunitario. Hace que la biblioteca sea mucho más difícil de contribuir.
     
     
     
     • Varias de estas herramientas extremistas han sido reemplazadas por otras herramientas extremistas, por lo que no busca cosas que conoce; está probando cosas. Mientras tanto, esperamos lo básico, como los errores ortográficos en el AST, como arreglar readme en npm , o fusionar es6 modules , durante tres años a la vez.
     
     
     
     • Francamente, en una nueva versión 0.12.0 , cosas como el módulo en el hilo del módulo simplemente saldrían. El material de construcción de David ha funcionado desde 2011. El material nuevo de 2018 ya está roto en 2020. No más tecnología diletante.
     
     
     
  
  
• Y PUEDO OBTENER UNA EXPORTACIÓN ES6

pero notará que ninguno de ellos es realmente sobre el software per se

no creo que el software aquí sea el problema

creo que el proceso es, y en menor grado, el proyecto

eso es lo que arreglaré, si @futagoza lo permite

esta biblioteca puede volver a la vida en 30 días si nos tragamos nuestro orgullo y elegimos las necesidades de la gran comunidad de la biblioteca sobre los intereses de nuestro proyecto de pasatiempo

deja que el hobby reescriba sea el tenedor

deja que un mantenedor comience a mantener

@StoneCypher Me gusta tu energía :-) Solía ​​usar pegjs en el pasado (en los tiempos de dmajda) y me gustaba mucho.

Solo bifurca y no pelees. Las cosas pueden y se calmarán más tarde. Si la comunidad lo sigue, entonces no necesita preocuparse por el "titular de la clave" existente ni nada por el estilo. Construir reputación toma tiempo pero es necesario. No pierdas el tiempo discutiendo más.

Ocho, tu tenedor lo hará "regresar al origen" en algún momento en el futuro o tendrá su propia vida. Ambas opciones son válidas y están bien en mi opinión.

Por favor, detente con la mierda de "hacer un tenedor". Hay cuatro de ellos y no sabes lo que son. Una bifurcación no salvará a ninguno de los consumidores intermedios existentes, no salvará los PR, no salvará los problemas, no llevará a la comunidad y no será visible.

La gente ha estado intentando eso durante tres años. NO FUNCIONA.

No continúe ofreciendo este consejo.

@futagoza : todos han renunciado a que hagas lo correcto. Cinco personas me han dicho que bifurque la biblioteca, porque esperan que te niegues a permitir la reparación y que mantengas el control de la biblioteca que estás destruyendo.

Creo que la razón por la que esperan esto es que he encontrado más de una docena de personas ofreciéndote ayuda para hacer lo que prometiste hacer y nunca hiciste, y cada vez que dices "no, lo haré pronto". "

Haz lo que deberías haber hecho en 2018 y dale mantenimiento a alguien que realmente mantendrá el proyecto. Dejen de matar a esta biblioteca, dejen de matar a esta comunidad y quítense de en medio.

@StoneCypher John, cuando sugerí crear una bifurcación, lo dije en serio. Bifurcar un proyecto es una gran opción que te ofrece el código abierto, especialmente si sientes que necesita cambios o que se está muriendo. Y no, no tengo ningún problema, no hace falta que me escribas DM solo para hacerme esta pregunta.

Cuando dije "no vuelvas a dar este consejo", también lo dije en serio.

Me encanta esta conversación.

@StoneCypher Tengo que estar en desacuerdo contigo aquí, porque vi justo lo contrario:

1. Decidí empezar a aprender FreeCAD. Sin embargo, había un problema: su "módulo de ensamblaje" no estaba completo, por lo que casi no pudimos crear ensamblajes complejos, lo que lo hace inútil para el trabajo profesional.
2. Un tipo, realthunder decidió resolver este problema. Necesitaba cambiar algunas propiedades centrales para lograr el objetivo, lo que a su vez hizo que su bifurcación fuera incompatible con la rama principal. Perdió todos los usuarios, casi toda la comunidad. A excepción de unas pocas personas, no tenía seguidores (eso fue lo que veo). Tampoco tenía usuarios activos, por lo que entendí.
3. Examiné su documentación ¹ y, a pesar del año de estancamiento en el desarrollo (eso fue lo que vi en ese momento), hice las matemáticas (una matemática interesante) y decidí darle una oportunidad.
4. Le hice muchas preguntas ¹ y él las respondió con paciencia. Mientras tanto, tomé notas sobre lo que aprendí , por lo que hice un buen material de introducción.
5. La gente desalentó ¹ a usar su rama alegando que él era el autor y mantenedor solitario y que no se debe confiar en su trabajo en términos de sostenibilidad. Simplemente los ignoré.
6. Su solicitud de extracción no se fusionó durante mucho tiempo (alrededor de un año).

Últimamente, su PR había comenzado a revisarse. Se había hecho una gran cantidad de trabajo y finalmente su rama y la corriente principal se vuelven compatibles. En el próximo lanzamiento, creo que su rama se fusionará con la corriente principal.

Mientras tanto, había un serio problema financiero. Él era el único mantenedor y la donación de unos pocos usuarios no pudo hacerlo sobrevivir. Decidí enseñar FreeCAD/Assembly3 aquí, Turquía, y vender el soporte para apoyar las finanzas. Le propuse y esto es aceptado. Hice todas las solicitudes necesarias para convertirme en formador en una fundación de gran reputación, que fue aceptada recientemente.

A veces 1 persona es suficiente para iniciar un incendio.

y sal del camino

Discrepar. Que se queden en el camino. Una buena motivación siempre encontrará la salida. Si no puede, es porque no era tan bueno.

No estoy recopilando explícita y claramente consejos sobre este tema.

Esta biblioteca necesita ser resucitada. Lo siento si no lo explico lo suficiente, pero las respuestas que estoy recibiendo no abordan ninguna de las preocupaciones prácticas planteadas.

La vida y el trabajo de las personas dependen de esto.