Pegjs: Как определить правило для многократного совпадения с шаблоном в PEG.js?

Пожалуйста, прочтите пример грамматики привязки. Здесь нет ошибки. Трекеры проблем не предназначены для запросов о помощи. Один из примеров грамматики - это именно то, что вы просите.

Подходящим местом для запросов о помощи является StackOverflow. Трекеры ошибок — это то, что разработчики используют для отслеживания того, что сломано, и какие репозитории пакетов используют для измерения качества проекта.

Document
  = ClassRow+

ClassID
  = "G04"

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

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

Как только вы это увидите, пожалуйста, закройте эту тему. Спасибо.

Ключ в том, чтобы научиться читать грамматики PEG. Это говорит:

1. « Document — это один или несколько ClassRow s».
2. « ClassID — это фиксированная строка "G04" ».
3. « ClassTitle — это любой текст до следующей новой строки, но не включая ее. Вы назовете это «заголовком». Возвращайте заголовок в виде строки, а не массива символов».
4. « ClassRow — это ClassID , за которым следует ClassRow .

Поскольку ClassRow заканчивается новой строкой, новая строка фактически начинает новую строку.

Я буду использовать StackOverflow для дальнейших вопросов, спасибо за ответ и пояснения.

Тем не менее, есть некоторые вещи, которые я хочу выразить:

1. Часть «Тип проблемы: вопрос: [да/нет]» немного вводит в заблуждение относительно упомянутой вами директивы. Я интерпретировал этот раздел как «Отслеживание проблем — это подходящее место, чтобы задавать вопросы».
2. "examples": я вижу 4 примера грамматики в папке examples/ . Однако, ИМХО, ни один из них не подходит (достаточно простой) для новичков (как я, или для меня) кроме "arithmetics.pegjs". Я понимаю, что PEG.js находится в стадии (интенсивной?) разработки, поэтому вполне понятно, что вы можете быть больше сосредоточены на сложных реальных проблемах/сценариях. Я просто ожидал пошаговых примеров от простых к сложным грамматикам.

Пожалуйста, считайте это отзывом новичка.

Часть «Тип проблемы: вопрос: [да/нет]» немного вводит в заблуждение относительно упомянутой вами директивы. Я интерпретировал этот раздел как «Отслеживание проблем — это подходящее место, чтобы задавать вопросы».

Я согласен. Я хочу удалить этот текст и попросил об этом в 2017 году.

Причина этого текста в том, что Дэвид, который больше не управляет этой библиотекой, устал от людей, говорящих «это ошибка», не просматривая проблемы и не находя другого человека, который думал, что это ошибка, а ее не было.

У этого номера, например, полдюжины клонов.

.

«Примеры»: я вижу 4 примера грамматики в папке examples/. Однако, ИМХО, ни один из них не подходит (достаточно простой) для новичков (как я, или для меня) кроме "arithmetics.pegjs".

Я согласен. Я хотел бы написать их много.

.

Я понимаю, что PEG.js находится в стадии (тяжелой?) разработки

Это определенно не так.

Первоначальный автор оставил его без дела на год, поэтому он попросил новых сопровождающих.

Новый сопровождающий, вступивший в должность в мае 2017 года, не выпустил ни единого байта кода для основной ветки.

Я начал процесс агитации за поглощение, потому что использование библиотеки падает, библиотека не поддерживает javascript с 2014 года, на NPM нет readme почти три года, исправления односимвольных AST без ответа в течение года в проблемах, и новый сопровождающий решил выбросить 2,5 года функциональной ветки, которую он пометил как закрывающую массу проблем, и заменить всю библиотеку чем-то новым, что он написал сам на другом языке

.

вполне понятно, что вы можете быть больше сосредоточены на сложных проблемах/сценариях реального мира. Я просто ожидал пошаговых примеров от простых к сложным грамматикам.

Я считаю, что адаптация пользователей, вероятно, является самой важной проблемой в реальном мире прямо сейчас после восстановления работоспособности этой библиотеки.

Для ясности, я не оригинальный автор. @dmajda есть.

Для ясности, я не сопровождающий. Сопровождающего нет.

Часть «Тип проблемы: вопрос: [да/нет]» немного вводит в заблуждение относительно упомянутой вами директивы. Я интерпретировал этот раздел как «Отслеживание проблем — это подходящее место, чтобы задавать вопросы».

@ceremcem , вы все сделали правильно (кроме того, что вы не посмотрели описание PEG в википедии и не пытались разобрать вам грамматику вручную, после чего ваш вопрос, ИМХО, был бы решен). Вы не можете знать, что ваш вопрос — это просто вопрос или описание ошибки в библиотеке. Это может решить только разработчик. Поэтому нет правила GitHub только для багов . Проблема есть проблема даже в Африке

в общем трекер проблем предназначен для проблем, а не вопросов

ceremcem получил бы ответ через несколько часов на stackoverflow. здесь он ждал девять дней, и если бы я не заговорил, думаю, он бы не получил ответа.

многие подобные вопросы, подобные этим, остаются без ответа здесь через год или более. есть полдюжины восьмилетних.

.

Вы не можете знать, что ваш вопрос — это просто вопрос или описание ошибки в библиотеке.

Да он может. Он спрашивал: «Как мне это сделать?»

Если он не считает, что синтаксический анализатор не может этого сделать, это никогда не является ошибкой.

По сути, это самая простая вещь в парсере, и я считаю, что peg по-прежнему является наиболее часто используемым парсером javascript, хотя это быстро перестает быть правдой, и он кажется умным, так что я не думаю он считал, что генератор синтаксических анализаторов не может использовать правило более одного раза

В его интересах было бы идеально направить его к ресурсу, предназначенному для вопросов, а не к ремонту библиотеки, особенно если ресурс вопросов является очень активным, а ресурс ремонта библиотеки только что объявил, что три года работы заканчиваются, и обычно игнорирует такие вопросы

Это не совпадение, что это осталось без ответа, пока я не начал отмечать людей, как и полдюжины других вопросов до сих пор.

Никаких решений не принимается. Я давал ему советы.

Кроме того, я ответил на его вопрос .

Обычно я получаю ответ через несколько часов в StackOverflow, так что я его постоянный пользователь. Однако по моему ТАК-вопросу не было никаких действий, поэтому я пришел и спросил здесь. В основном время отклика почти одинаковое.

Я видел каждую комбинацию использования системы отслеживания проблем:

• Только для отчетов об ошибках, если предусмотрен отдельный форум или почтовая группа (например, PaperJS),
• Как для вопросов, так и для отчетов об ошибках (RactiveJS <3, FreeCAD_Assembly3 <3)
• За что-то, чего я на самом деле не получаю, вместе с отдельным форумом, где обычные подозреваемые взяли верх и говорят от имени владельцев проектов, что вызывает больше разочарования, чем что-либо еще (типа KiCAD (гррр))
• Ни за что (Эспруино, AFAIR). Каждый вопрос немедленно закрывается, и вы вынуждены открывать соответствующую тему на их форуме.

Для этого нет единственного лучшего варианта (никто не подходит для всех случаев), но мне нравится использовать трекер проблем для всего.

Вы не можете знать, что ваш вопрос — это просто вопрос или описание ошибки в библиотеке.

Мы видели это много раз в библиотеке FreeCAD_Assembly3. Многие из моих простых, глупых вопросов выявили одну или несколько ошибок. Такое бывает, я видел.

Я согласен. Я хотел бы написать их много.

Мне нравится ваш подход к этой библиотеке. Вы, кажется, очень заботитесь.

так что я не думаю, что он верил, что генератор парсера не может использовать правило более одного раза

Правильный. Моим намерением не было сообщение об ошибке. Я просто не нашел способа повторно использовать одно и то же правило для нескольких строк.

Однако по моему вопросу SO не было никаких действий, поэтому я пришел и спросил здесь.

О, чувак, там тоже умерло сообщество привязки?

Это так грустно ☹️

Хорошо, если вы уже сделали ТАК пост, то на данный момент вы правы на 100%, что пришли сюда.

.

Я видел каждую комбинацию использования системы отслеживания проблем:

Да, люди постоянно нарушают нормы сообщества.

.

Я согласен. Я хотел бы написать их много.

Мне нравится ваш подход к этой библиотеке. Вы, кажется, очень заботитесь.

Очень. Я хотел участвовать в передаче прав собственности в 2017 году, но кто-то дал план с 17 крупными релизами, и старый владелец им поверил.

Этот человек отказался от своего первого второстепенного релиза три года спустя.

Правда в том, что общедоступное программное обеспечение очень сложно написать. Почти все, кого я знаю, в том числе и я, часто говорят: «Этот релиз не готов, пока не будут сделаны X, Y и Z».

А затем, когда Y заканчивается, вы понимаете, что вам также нужны V и W.

А затем, когда Z заканчивается, вы понимаете, что вам также нужны S, T и U.

А потом, когда Ви заканчивает...

Вот так 0.11.0 начали с полдюжины функций в 2017 году и умерли с сотней слияний, неправильно помеченных закрытыми в трекере в 2020 году.

Часть дисциплины общедоступного программного обеспечения — частые небольшие выпуски. Это всегда было проблемой привязки, но качество программного обеспечения было настолько высоким, что мы все равно мирились с этим.

Потом дмайда ушла, и все остановилось.

И мы ждали, терпеливо, в течение долгого времени.

Но новый парень теперь называет это своим хобби-проектом и говорит, что отказался от всего этого в пользу чего-то нового и несовместимого, что он написал. И даже если бы у него был тот же AST, тот же набор функций и даже больше, за ним не было бы десяти лет отладки сообщества, и я бы не смог переключиться

И знаете, если он хочет написать новый, более мощный анализатор PEG, отлично, отлично, вперед.

Но он не может убить этого, притворяясь сопровождающим, а затем никогда не поддерживая, затем принимая на себя библиотечное сообщество и положение этого, и ставя на его место свое собственное программное обеспечение, которое никогда не будет выпущено.

Настало время вернуться к здоровому процессу. Новый сопровождающий создал микро-сообщество младших разработчиков, и они на самом деле выступают за то, чтобы библиотека не работала, а не сохранялась.

Ясно, что изменения крайне необходимы

.

Я просто не нашел способа повторно использовать одно и то же правило для нескольких строк.

Если у вас снова возникнут проблемы с поиском ответов, отметьте меня лично

Тем не менее, обычно я ищу примеры в Google, и, поскольку эта библиотека когда-то была очень популярной и интенсивно используемой (и может быть снова, если нынешние библиотечные убийцы просто уступят место на скамейке для другого человека, чтобы помочь), примеров более чем достаточно. там, чтобы покрыть вещи, которые вам нужно найти

Однако, как правило, я хотел бы, чтобы кто-нибудь сказал мне, когда я был новичком, это то, что я сказал под комментарием, начинающимся со слов «Ключ в том, чтобы научиться читать грамматики PEG».

Как только вы научитесь читать грамматики PEG в форме обсуждения, вам станет очень легко о них думать, и в этот момент их станет тривиально легко писать.

Это как выключатель света. Нет пандуса. Прямо от невозможного к легкому

Это как выключатель света. Нет пандуса. Прямо от невозможного к легкому

Вы меня обнадежили! :) Так что я не должен чувствовать себя таким глупым, когда вижу только некоторые "тарабарские" наборы правил :)

Если у вас снова возникнут проблемы с поиском ответов, отметьте меня лично

Я не хочу злоупотреблять этим, так что каждый раз будет тяжело звонить, стоит ли спрашивать, или мне следует поискать в сети еще немного. Это было щедрое предложение, спасибо.

Ясно, что изменения крайне необходимы

Я вижу, что вы включили раздел «проблемы» в своей вилке. Это всегда хороший признак того, что вы пытаетесь управлять авиалайнером, бросаясь в кабину, когда вы были всего лишь пассажиром. Это хорошая вещь.

Если есть живой источник воды, он всегда найдет, куда течь, что бы вы ни поставили на его пути. Если потока нет из-за того, что его источник истощен, то делать нечего. Источник – спрос. Ваше отношение указывает на то, что источник воды очень живой.

Так что мне любопытно, почему бы вам просто не взять на себя? Это то, что я сделал для библиотеки панели загрузки . Я понял, что разработка застопорилась, поэтому взялся за решение проблем, начиная со своих собственных, и создавая пулл-реквесты для каждой ветки. Некоторое время спустя первоначальный автор решил продолжить свою работу, и мы были готовы к работе. Как вы думаете, это осуществимое решение?

Вы меня обнадежили! :)

Я рад.

.

Это как выключатель света. Нет пандуса. Прямо от невозможного к легкому

Так что я не должен чувствовать себя таким глупым, когда вижу только некоторые «тарабарские» наборы правил :)

Неа. Парсеры — крайний случай того, что «это просто смешно, а потом вдруг становится легко».

Вот кикер - сравнительно говоря, привязка довольно проста. Другие часто просто жестоки.

На мой взгляд, в обучении привязке есть четыре большие проблемы.

1. Нет хорошо структурированного вводного материала
2. Есть много примеров среднего уровня, но вы должны хорошо разбираться в Google, чтобы найти их.
3. Есть и плохие примеры, и нужен опыт, чтобы их идентифицировать.
4. Вы должны уметь «думать таким образом», а это происходит не сразу.

Я подумывал сделать несколько видеоуроков. Я полагаю, они сделали бы это _намного_ более понятным.

.

Я не хочу злоупотреблять этим, так что каждый раз будет тяжело звонить, стоит ли спрашивать.

Раз в неделю нормально. Поймите, что я иногда медлю с ответом

.

Я вижу, что вы включили раздел «проблемы» в своей вилке. Это всегда хороший признак того, что вы пытаетесь управлять авиалайнером, бросаясь в кабину, когда вы были всего лишь пассажиром. Это хорошая вещь.

Я едва начал. Сначала я хочу посмотреть, можно ли просто спасти настоящее репо.

Делать это из вилки было бы неприлично сложнее. Я бы потерял все PR и все перекрестные ссылки, а также все закрытые не объединенные или закрытые удаленные материалы, некоторые из которых очень ценны.

.

Так что мне любопытно, почему бы вам просто не взять на себя?

Я хотел бы.

В настоящее время соответствующие пароли и аутентификация находятся в руках одного человека, и они еще не ответили.

Посмотрим.

.

Я понял, что разработка застопорилась, поэтому взялся за решение проблем, начиная со своих собственных, и создавая пулл-реквесты для каждой ветки.

это особый случай

Опубликовано 0.10.0

Новый сопровождающий позволил ветке 0.11.0 неограниченно расти в течение трех лет, а затем решил ее отменить в пользу ветки 0.12.0 , которую он пишет с нуля в изоляции.

Не к чему ставить пиар. То, что находится в npm , относится к 2017 году, а то, что находится в github при новом сопровождающем, отменяется через три года без публикации.

.

Некоторое время спустя первоначальный автор решил продолжить свою работу, и мы были готовы к работе. Как вы думаете, это осуществимое решение?

Если заменяющий сопровождающий согласен это разрешить, это примерно то, что я хочу.

Я немного сомневаюсь, что Дэвид вернется, но если он вернется, это было бы здорово.

Таким образом, я хочу снова превратить это в стандартный проект с открытым исходным кодом.

Какие, по вашему мнению, здесь самые важные 3 вопроса?

Я думаю, говорить о том, что для меня самое важное, немного опасно, потому что здесь достаточно много людей с большим опытом, чем у меня в peg , и если они скажут: «На самом деле это другое дело, "Я, пожалуй, послушаю.

В связи с этим я хочу предупредить, что, хотя я рад развиваться здесь, я заинтересован здесь в качестве сопровождающего .

Это, я думаю, то, что многие люди не понимают: кодирование разработки и сопровождения очень, очень разные.

• Development coding хочет новых больших идей, новых функций, новых ярких идей.
• Maintenance coding хочет исправить небольшие проблемы до того, как они соберутся воедино и сделают что-то хорошее непригодным для использования.

Я рад заняться кодированием для разработки - может быть, даже с нетерпением жду этого - но здесь есть другие люди, которые лучше подходят для этого. Итак, я хочу прояснить: моя настоящая цель — сделать так, чтобы они снова могли вносить PR, как раньше.

Тем не менее, чтобы показать, какова моя личная точка зрения:

1. Возврат к обычному ритму релизов

У peg.js больше никогда не должно быть волшебной ветки. Это как чертово Кольцо Всевластия. Звучит здорово и мощно, но это ни черта не работает, и, в конце концов, ты Голлум. Это не svn . Голосом Стива Балмера: feature branches , feature branches , feature branches , feature branches .

Версия должна быть результатом функции, а не точкой сбора плана функций. Мы не компания 1980-х годов, и мы не должны планировать, как она.

Единственный случай, когда более одной функции должны выполняться одновременно, — это когда это неизбежно, например, в результате исправления функций, чтобы справиться с внешним обновлением, или вещей, которые действительно нельзя сделать отдельно. О, вы думаете, что это связано с другой особенностью? Отлично, поместите это в 2.31.0 , нам нужно получить 2.29.0 , а вот это другое, вероятно, будет 30 .

Люди относятся к несовершеннолетним, как к майорам. Вот почему минор так и не вышел: его повесили на ту же поведенческую ловушку, что и мажоров. Просто, черт возьми, не делай этого ™.

Чтобы быть конкретным,

• Я полагаю, что люди в значительной степени утратили веру в то, что эта библиотека больше не существует.
• Три месяца еженедельных выпусков заставят людей дать ему еще один шанс.
  
  
  
  • Три месяца еженедельных выпусков на самом деле было бы очень легко достичь
  
  
• Если бы мы получили не только 0.12.0 , но и 0.13.0 — и заметьте, я не говорю, что в них, и я думаю, что это не имеет значения — тогда мы бы есть реальный шанс на 1.0.0
• Просто просматривая здесь открытые и закрытые-необъединенные PR, вы увидите огромное количество силы и красоты с комментарием примерно 2015 года, например: «Я посмотрю на это позже». Быть щедрым человеком и найти возможность поделиться властью поможет peg не просто возродиться, но и расцвести.
• Поэтому я не хочу быть художником. Я хочу быть куратором.

2. Размещение документации и тестирования в приемлемом месте

Все об этом говорят, но у моего хобби конечного автомата сейчас 3500 юнит-тестов и 100% документация, так что отнеситесь ко мне серьезнее.

Я действительно глубоко верю в тестирование.

Я написал еще одну библиотеку, которая в два раза меньше по размеру и значительно ниже по сложности, чем конечный автомат. Гораздо проще внести радикальные языковые изменения в конечный автомат, чем небольшие изменения в сетевой обработчик, потому что сетевой обработчик плохо протестирован, и вам нужно приложить реальные усилия, чтобы убедиться, что что-то работает правильно.

ФШМ? Нет, тесты отличные, они тебя поймают

Этот специфический контраст каждый раз, когда я прикасаюсь к любому из них, с жестокой ясностью напоминает мне о том, насколько важным на самом деле является тестирование для чего-то, заслуживающего доверия, по крайней мере для меня.

Я думаю, что действительно большая часть проблемы с работой над peg.js заключается в том, что тестирование и документация находятся в руинах. Я думаю, пришло время это изменить.

3. Удаление хипстерского бреда.

• Я не человек, работающий с Ruby, но люди, работающие с Ruby, серьезно относятся к конфигурации по соглашению. Я вообще не владею Ruby, но я все равно могу сесть и узнать, как работает проект, потому что все они так работают, и если я чего-то не получаю, я могу спросить кого-нибудь, и им не нужен доступ, потому что так они все работают
• peg сталкивается с четырьмя проблемами в этом отношении
  
  
  
  1. peg — очень ранняя библиотека javascript , и она сделала целый ряд основополагающих решений до того, как появились нормы сообщества. на самом деле, благодаря Давиду появилось несколько общественных норм; до привязки многие люди думали, что мультиупаковка - это сложно, так что теперь, когда один из первопроходцев в этом отношении проблематично отстает в том же отношении, это немного душераздирающе. Тем не менее, в дополнение к блестящим вещам, которые Дэвид сделал заранее, некоторые вещи он сделал неправильно, а некоторые вещи, которые были правильными тогда, больше не являются. Множество небольших изменений привели бы к радикальному изменению опыта разработчиков.
  
  
  2. Нормы сообщества должны быть восстановлены.
     
     
     
     
     
     1. Есть только определенные способы работы проекта node . Это включает в себя создание ориентированного на браузер вывода, и, таким образом, проект узла, безусловно, является правильным современным способом работы.
     
     
     
     2. Это пока браузерный проект с ручной автоматизацией. Это должно измениться
     
     
     
     3. Научиться правильно редактировать README . Спустя три года нынешний сопровождающий до сих пор не справился с этим (!), как и первоначальный разработчик в последних двух версиях.
        
        
        
        
        
        
        
        • Это глупо. Части проекта, которые должны быть тривиальными, ломаются, потому что они не выполняются простым обычным способом. Их нужно делать простым обычным способом, но для этого нужен кто-то, кто знает node и готов выполнять скучную работу.
        
        
        
        
     
     
     
  
  
  3. peg является одновременно и бенефициаром, и жертвой экстремальной автоматизации.
     
     
     
     
     
     • Вполне вероятно, что dmajda не смог бы продвинуться так далеко без него. Я, конечно, не могу на мои вещи.
     
     
     
     • Однако это автоматизация 2011 года, а не автоматизация 2020 года.
     
     
     
     • Это также автоматизация 2013, 2014, 2016 и 2018 годов. Этот материал разбросан по zeit, now, страницам github, личной учетной записи yahoo, gitlab, нескольким странным сервисам отслеживания и автоматического развертывания и, возможно, куче вещей, которые я еще не нашел.
     
     
     
     • Это просто инструмент, чтобы либо пережить крах, либо поиграть с горячей новинкой. Тщательный выбор инструмента обеспечивает долговечность конструкции. Фактический срок службы repl составляет почти десять лет. Все остальное тоже может быть, если "оооооооооооооооооооооооооооооооооооооооооооооооооооооооооооооооооооооооооооооооооооооооооооооооооооооооооооооооооооооооооооооооооооооооооооооооооооооооооооооооооооооооооооооооооооооооооооооооооооо!
     
     
     
     • Это надо переместить в gh pages и gh actions , что всем понятно, и оставить в покое навсегда
     
     
     
  
  
  4. Новый сопровождающий решил углубиться в необычные инструменты и маргинальные стратегии. В результате вы должны установить новый менеджер пакетов, чтобы вносить исправления, и изучать необычный макет исходного кода, который запутанным образом сосуществует с несвязанным набором исходных текстов, который кажется реальным продуктом в обычном макете исходного кода.
     
     
     
     
     
     • Когда третья сторона внесла исправление, позволяющее также работать диспетчеру пакетов стандартного языка, он отклонил его.
     
     
     
     • Честно говоря, такое поведение неприемлемо в общественном проекте. Это значительно усложняет работу с библиотекой.
     
     
     
     • Некоторые из этих экстремистских инструментов были заменены другими экстремистскими инструментами, поэтому он не собирается использовать то, что знает; он пробует вещи. А пока мы ждем основ, таких как орфографические ошибки в AST, например, исправление readme на npm или слияние es6 modules на три года за один раз.
     
     
     
     • Откровенно говоря, в перепекании 0.12.0 такие вещи, как модуль в модульной пряже, просто вышли бы. Сборка Дэвида работает с 2011 года. Новые вещи 2018 года уже сломаны в 2020 году. Больше никаких дилетантских технологий.
     
     
     
  
  
• И МОГУ ЛИ Я ПОЛУЧИТЬ ЭКСПОРТ ES6

но вы заметите, что ни один из них на самом деле не касается программного обеспечения как такового.

я не думаю, что программное обеспечение здесь проблема

я думаю, что процесс и в меньшей степени проект

вот что я исправлю, если @futagoza позволит

эта библиотека может вернуться к жизни через 30 дней, если мы проглотим нашу гордость и выберем потребности большого сообщества библиотеки, а не интересы нашего хобби-проекта.

пусть переписывание хобби будет вилкой

позволить сопровождающему начать обслуживание

@StoneCypher Мне нравится твоя энергия :-) Раньше я использовал pegjs (во времена dmajda), и мне это очень нравилось.

Просто раскошельтесь и не боритесь. Все может и уляжется позже. Если сообщество следует за вами, вам не нужно заботиться о существующем «держателе ключей» или чем-то подобном. Создание репутации требует времени, но необходимо. Не тратьте больше время на споры.

Восемь, ваша вилка в какой-то момент в будущем «вернется к истоку», или у нее будет своя собственная жизнь. Оба варианта действительны и прекрасны IMO.

Пожалуйста, прекратите это дерьмо "сделай вилку". Их четыре, и вы не знаете, какие они. Форк не спасет ни одного из существующих нижестоящих потребителей, не сохранит PR, не сохранит проблемы, не будет поддерживать сообщество и не будет видимым.

Люди пытались это сделать в течение трех лет. ЭТО НЕ РАБОТАЕТ.

Не продолжайте давать этот совет.

@futagoza - все разочаровались в том, что ты поступаешь правильно. Пять человек сказали мне разветвить библиотеку, потому что они ожидают, что вы откажетесь разрешать ремонт и сохраните контроль над библиотекой, которую вы убиваете.

Я полагаю, причина, по которой они ожидают этого, заключается в том, что я нашел более дюжины людей, предлагающих вам помочь сделать то, что вы обещали сделать, но так и не сделали, и каждый раз, когда вы говорите: «Нет, я скоро это сделаю. "

Делайте то, что вы должны были сделать в 2018 году, и отдайте поддержку тому, кто на самом деле будет поддерживать проект. Прекратите убивать эту библиотеку, перестаньте убивать это сообщество и уйдите с дороги.

@StoneCypher Джон, когда я предложил создать форк, я действительно имел это в виду. Разветвление проекта — отличный вариант с открытым исходным кодом, особенно если вы чувствуете, что он нуждается в изменениях или умирает. И нет, у меня нет никаких проблем, вам не нужно писать мне в личные сообщения, чтобы задать мне этот вопрос.

Когда я сказал «больше не давайте этот совет», я имел в виду именно это.

Я люблю этот разговор.

@StoneCypher Я должен с вами не согласиться, потому что я видел как раз обратное:

1. Я решил начать изучать FreeCAD. Однако была проблема: его «Модуль сборки» был неполным, поэтому мы практически не могли создавать сложные сборки, что делало его бесполезным для профессиональной работы.
2. Парень, realthunder решил решить эту проблему. Ему нужно было изменить некоторые основные свойства для достижения цели, что, в свою очередь, сделало его форк несовместимым с основной ветвью. Он потерял всех пользователей, почти все сообщество. Кроме нескольких человек, у него не было сторонников (это то, что я вижу). У него тоже не было активных пользователей, насколько я понял.
3. Я изучил его документацию ¹ и, несмотря на год застоя в разработке (это то, что я видел в то время), я сделал математику (интересная математика) и решил попробовать.
4. Я задавал много-много вопросов ¹ , и он терпеливо отвечал на них. Тем временем я делал заметки о том, что я узнаю , таким образом, получился хороший вводный материал.
5. Люди отговаривали ¹ использовать его ветку, утверждая, что он был одиноким автором и сопровождающим, и его работа не заслуживает доверия с точки зрения устойчивости. Я просто проигнорировал их.
6. Его пулреквест не мержится уже давно (около года).

В последнее время его PR начали пересматривать. Была проделана огромная работа, и, наконец, его ветвь и мейнстрим стали совместимы. В следующем релизе, я думаю, его ветвь будет объединена с основной.

Между тем возникла серьезная финансовая проблема. Он был единственным сопровождающим, и пожертвования нескольких пользователей не помогли ему выжить. Я решил преподавать FreeCAD/Assembly3 здесь, в Турции, и продать поддержку, чтобы обеспечить финансирование. Я предложил ему, и это принято. Я подал все необходимые заявки, чтобы стать тренером в пользующемся хорошей репутацией фонде, который недавно был принят.

Иногда достаточно 1 человека, чтобы разжечь огонь.

и уйти с дороги

Не согласен. Пусть остаются в пути. Хорошая мотивация всегда найдет выход. Если не может, то это потому, что это было не так уж хорошо.

Я явно и явно не собираю советов по этой теме.

Эту библиотеку нужно возродить. Извините, если я недостаточно объясняю, но ответы, которые я получаю, не затрагивают ни одной из поднятых практических проблем.

От этого зависят жизни и рабочие места людей.