Pegjs: PEG.js에서 패턴과 여러 번 일치하도록 규칙을 정의하는 방법은 무엇입니까?

peg 예제 문법을 읽어보세요. 여기에는 버그가 없습니다. 문제 추적기는 도움 요청을 위한 것이 아닙니다. 예제 문법 중 하나는 정확히 당신이 요구하는 것입니다.

도움 요청을 위한 적절한 장소는 StackOverflow입니다. 이슈 트래커는 개발자가 무엇이 고장났는지 추적하기 위해 사용하는 것과 프로젝트 품질을 측정하기 위해 어떤 패키지 리포지토리가 사용하는 것입니다.

Document
  = ClassRow+

ClassID
  = "G04"

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

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

이것을 본 후에는 이 문제를 닫으십시오. 감사 해요.

핵심은 PEG 문법을 읽는 법을 배우는 것입니다. 그것은 말한다:

1. " Document 는 하나 이상의 ClassRow 입니다."
2. "A ClassID 는 고정 문자열 "G04" 입니다."
3. " ClassTitle 는 다음 줄 바꿈까지의 모든 텍스트입니다. 하지만 이를 "제목"이라고 부를 것입니다. 제목을 문자 배열이 아닌 문자열로 반환합니다."
4. "A ClassRow 는 ClassID 다음에 ClassRow 입니다.

ClassRow가 개행으로 끝나기 때문에 개행은 효과적으로 새 행을 시작합니다.

추가 질문에 StackOverflow를 사용하겠습니다. 답변과 설명에 감사드립니다.

그러나 다음과 같이 표현하고 싶은 것이 있습니다.

1. "문제 유형: 질문: [예/아니요]" 부분은 귀하가 언급한 지시문과 관련하여 약간 오해의 소지가 있습니다. 나는 그 섹션을 "문제 추적기가 질문하기에 적합한 장소"라고 해석했습니다.
2. "examples": examples/ 폴더에서 4개의 예제 문법을 볼 수 있습니다. 그러나 IMHO는 "arithmetics.pegjs"를 제외하고는 초보자(나 또는 저와 같은)에게 적합하지 않습니다(충분히 간단함). PEG.js가 (무거운?) 개발 중이라는 것을 이해하므로 복잡한 실제 문제/시나리오에 더 집중할 수 있다는 것은 충분히 이해할 수 있습니다. 간단한 문법에서 복잡한 문법에 이르기까지 단계별 예제를 예상했습니다.

신규 사용자 피드백으로 고려하십시오.

"문제 유형: 질문: [예/아니요]" 부분은 귀하가 언급한 지시문과 관련하여 약간 오해의 소지가 있습니다. 나는 그 섹션을 "문제 추적기가 질문하기에 적합한 장소"라고 해석했습니다.

나는 동의한다. 그 텍스트를 제거하고 싶고 2017년에 요청했습니다.

텍스트가 있는 이유는 이 라이브러리를 더 이상 운영하지 않는 David가 이슈를 보지 않고 버그가 있다고 생각하는 다른 사람을 찾지 않고 "이것은 버그입니다"라고 말하는 사람들에 지쳤고 버그가 없었기 때문입니다.

예를 들어 이 문제에는 6개의 클론이 있습니다.

.

"Examples": examples/ 폴더에서 4개의 예제 문법을 볼 수 있습니다. 그러나 IMHO는 "arithmetics.pegjs"를 제외하고는 초보자(나 또는 저와 같은)에게 적합하지 않습니다(충분히 간단함).

나는 동의한다. 많이 쓰고 싶습니다.

.

PEG.js가 (무거운?) 개발 중이라는 것을 이해합니다.

그것은 가장 확실하지 않습니다.

원래 작성자는 1년 동안 유휴 상태로 두었기 때문에 새 유지 관리자를 요청했습니다.

2017년 5월에 인수한 새로운 관리자는 마스터 브랜치에 단 한 바이트의 코드도 공개하지 않았습니다.

나는 인수를 위해 동요하는 과정을 시작했다. 라이브러리의 사용량이 떨어지고 있고, 라이브러리가 2014년부터 javascript를 지원하지 않고, 거의 3년 동안 NPM에 readme 가 없었고, 단일 문자 AST 수정이 1년 동안 문제에 대한 답변이 없었고, 새로운 관리자는 2.5년 동안 수많은 문제를 해결한 것으로 표시된 기능 분기를 버리고 전체 라이브러리를 다른 언어로 직접 작성한 새로운 것으로 교체하기로 결정했습니다.

.

복잡한 실제 문제/시나리오에 더 집중할 수 있다는 것은 충분히 이해할 수 있습니다. 간단한 문법에서 복잡한 문법에 이르기까지 단계별 예제를 예상했습니다.

나는 사용자 온보딩이 아마도 이 라이브러리를 다시 건강하게 만든 다음 현재 가장 중요한 현실 세계의 문제라고 생각합니다.

명확히 하자면 저는 원작자가 아닙니다. @dmajda 입니다.

명확히 하자면, 저는 관리자가 아닙니다. 유지 보수가 없습니다.

"문제 유형: 질문: [예/아니요]" 부분은 귀하가 언급한 지시문과 관련하여 약간 오해의 소지가 있습니다. 나는 그 섹션을 "문제 추적기가 질문하기에 적합한 장소"라고 해석했습니다.

@ceremcem , 당신은 모든 것을 올바르게했습니다 (wikipedia에서 PEG의 설명을 보지 않고 문법을 수동으로 구문 분석하지 않은 것 외에는 귀하의 질문, IMHO가 해결될 것입니다). 귀하의 질문이 단순히 질문이거나 라이브러리의 버그에 대한 설명이라는 것을 알 수 없습니다. 이것은 개발자만이 결정할 수 있습니다. 따라서 버그만을 위한 GitHub 규칙은 없습니다. 문제는 아프리카에서도 문제다

일반적 으로 문제 추적기는 질문이 아니라 문제를 위한 것입니다.

ceremcem은 stackoverflow에서 몇 시간 만에 답변을 얻었을 것입니다. 여기에서 그는 9일을 기다렸고 내가 말을 하지 않았다면 답을 얻지 못했을 것입니다.

이와 같은 많은 유사한 질문은 1년 또는 그 이상이 지난 후에도 여기에 답이 없습니다. 여덟 살짜리 여섯 개가 있습니다.

.

귀하의 질문이 단순히 질문이거나 라이브러리의 버그에 대한 설명이라는 것을 알 수 없습니다.

예, 할 수 있습니다. 그는 "이 작업을 어떻게 수행합니까?"라고 묻고 있었습니다.

그가 파서가 이것을 할 수 없다고 믿지 않는 한, 그것은 결코 버그가 아닙니다.

그것은 기본적으로 파서에서 가능한 가장 간단한 것이며 peg 가 여전히 가장 많이 사용되는 자바스크립트 파서라고 생각합니다. 그러나 그것이 빠르게 사실이 아님에도 불구하고 그는 지적인 것처럼 보이기 때문에 제 생각에는 그렇게 생각하지 않습니다. 그는 파서 생성기가 한 번 이상 규칙을 사용할 수 없다고 믿었습니다.

그의 최선의 이익을 위해, 특히 질문 리소스가 매우 활동적인 리소스이고 도서관 수리 리소스가 3년의 작업과 일반적으로 다음과 같은 질문을 무시합니다.

내가 사람들을 태그하기 시작할 때까지 이것이 답이 없었던 것은 우연이 아닙니다. 지금까지 6개의 다른 문제도 마찬가지였습니다.

결정이 내려지지 않습니다. 나는 그에게 조언을 해주고 있었다.

또한 나는 그의 질문에 답했다 .

나는 보통 StackOverflow에서 몇 시간 안에 답변을 얻습니다. 그래서 저는 그것을 일반 사용자입니다. 그러나 내 SO 질문 에 대한 활동이 없었으므로 여기에 와서 질문했습니다. 기본적으로 응답 시간은 거의 동일합니다.

문제 추적기 사용의 모든 조합을 보았습니다.

• 버그 리포트의 경우에만 별도의 포럼이나 메일 그룹이 제공되는 경우(예: PaperJS),
• 질문 및 버그 보고서 모두(RactiveJS <3, FreeCAD_Assembly3 <3)
• 내가 실제로 이해하지 못하는 것에 대해 별도의 포럼과 함께 일반적인 용의자가 프로젝트 소유자를 대신하여 이야기를 하고 있어 다른 어떤 것보다 더 많은 좌절을 야기합니다(예: KiCAD(grrr)).
• 아무것도 아닙니다(Espruino, AFAIR). 모든 문제는 즉시 종료되며 해당 포럼에서 적절한 스레드를 열어야 합니다.

이에 대한 최선의 선택은 없지만(모든 경우에 맞는 사람은 없음) 모든 것에 문제 추적기를 사용하는 것을 좋아합니다.

귀하의 질문이 단순히 질문이거나 라이브러리의 버그에 대한 설명이라는 것을 알 수 없습니다.

우리는 FreeCAD_Assembly3 라이브러리에서 이것을 여러 번 보았습니다. 내 단순하고 멍청한 질문 중 많은 부분이 하나 이상의 버그를 드러냈습니다. 이런 일이, 나는 보았다.

나는 동의한다. 많이 쓰고 싶습니다.

나는 이 도서관에 대한 당신의 접근 방식을 좋아합니다. 신경을 많이 쓰시는 것 같습니다.

그래서 나는 그가 파서 생성기가 한 번 이상 규칙을 사용할 수 없다고 믿었다고 생각하지 않습니다.

옳은. 내 의도는 버그 보고서가 아니 었습니다. 여러 줄에 동일한 규칙을 재사용하는 방법을 찾지 못했습니다.

그런데 제 SO 질문에 활동이 없어서 여기까지 오게 되었습니다.

어머, 거기 페그 커뮤니티도 죽었나요?

너무 슬프다 ☹️

좋아요, 이미 SO 게시물을 작성했다면 그 시점에서 여기 오는 것이 100% 맞습니다.

.

문제 추적기 사용의 모든 조합을 보았습니다.

예, 사람들은 항상 커뮤니티 규범을 위반합니다.

.

나는 동의한다. 많이 쓰고 싶습니다.

나는 이 도서관에 대한 당신의 접근 방식을 좋아합니다. 신경을 많이 쓰시는 것 같습니다.

흠뻑. 2017 소유권 전환에 참여하고 싶었지만 누군가가 17개의 주요 릴리스에 대한 계획을 제안했고 이전 소유자는 이를 믿었습니다.

그 사람은 3년 후에 첫 번째 마이너 릴리스를 포기했습니다.

사실 공개 소프트웨어는 작성하기가 정말 어렵습니다. 나를 포함하여 내가 아는 거의 모든 사람들은 "이 릴리스는 X, Y, Z가 완료될 때까지 준비되지 않았습니다."라고 말하는 경향이 있습니다.

그리고 Y가 끝나면 V와 W도 필요하다는 것을 깨닫게 됩니다.

그리고 Z가 끝나면 S, T, U도 필요하다는 것을 깨닫게 됩니다.

그리고 V가 끝나면 ...

이것이 0.11.0 이 2017년에 6개의 기능으로 시작하여 2020년에 추적기에서 닫힘으로 잘못 표시된 100개의 병합으로 사망한 방법입니다.

공개 소프트웨어 분야의 일부는 빈번한 소규모 릴리스입니다. 그것은 항상 peg의 문제였지만 소프트웨어의 품질이 너무 높아서 어쨌든 참았습니다.

그런 다음 dmajda는 떠났고 모든 것이 멈췄습니다.

그리고 우리는 참을성 있게 오랫동안 기다렸습니다.

그러나 새로운 사람은 이제 이것을 취미 프로젝트라고 부르며 자신이 쓴 새롭고 호환되지 않는 무언가를 위해 모든 것을 폐기했다고 말합니다. 그리고 동일한 AST와 동일한 기능 세트 등이 있더라도 10년 동안 커뮤니티 디버깅을 수행하지 않았을 것입니다.

그리고 그가 더 강력하고 새로운 PEG 파서를 작성하기를 원한다면, 훌륭합니다. 계속하십시오.

그러나 그는 메인테이너인 척 한 다음 유지하지 않는 척 한 다음 라이브러리 커뮤니티와 위치를 인수하고 그 자리에 결코 릴리스되지 않을 자신의 소프트웨어를 배치하여 이것을 죽일 수 없습니다.

이제 건강한 과정이 다시 시작될 때입니다. 새로운 관리자는 주니어 개발자로 구성된 마이크로 커뮤니티를 구축했으며 실제로 라이브러리를 저장하는 것보다 죽은 상태로 유지하는 것을 옹호하고 있습니다.

변화가 절실히 필요한 것은 분명하다

.

여러 줄에 동일한 규칙을 재사용하는 방법을 찾지 못했습니다.

답변을 다시 찾는 데 문제가 있으면 언제든지 저를 개인적으로 태그해 주세요.

그렇긴 하지만 일반적으로 나는 예를 찾기 위해 구글링을 하는데, 이 라이브러리는 한때 너무 유명하고 많이 사용되었기 때문에(현재 도서관 살인범이 다른 사람이 도울 수 있도록 벤치에 공간을 만들면 다시 사용할 수 있음) 충분한 예가 있습니다. 당신이 찾아야 할 것들을 다루기 위해 거기 밖으로

그러나 일반적으로 내가 새내기였을 때 누군가가 나에게 말했으면 하는 것은 "핵심은 PEG 문법을 읽는 법을 배우는 것"으로 시작하는 주석 아래에 말한 것입니다.

그 토론 형식에서 PEG 문법을 읽는 법을 배우면 그것에 대해 생각하는 것도 매우 쉬워지고 그 시점에서 갑자기 쓰기가 사소해집니다.

전등 스위치와 같습니다. 램프가 없습니다. 불가능한 것에서 쉬운 것까지

전등 스위치와 같습니다. 램프가 없습니다. 불가능한 것에서 쉬운 것까지

당신은 나를 격려했다! :) 그래서 내가 "횡설수설한" 규칙 세트만 볼 수 있을 때 그렇게 어리석다고 생각해서는 안 됩니다. :)

답변을 다시 찾는 데 문제가 있으면 언제든지 저를 개인적으로 태그해 주세요.

나는 이것을 남용하고 싶지 않으므로 물어볼 가치가 있는지 또는 인터넷을 더 검색해야하는지 매번 전화하기가 어려울 것입니다. 이것은 관대 한 제안이었습니다. 감사합니다.

변화가 절실히 필요한 것은 분명하다

포크에서 "문제" 섹션을 활성화한 것으로 나타났습니다. 그것은 항상 승객일 때 조종석으로 돌진하여 여객기를 조종하려는 좋은 징조입니다. 좋은 일이야.

살아있는 물 소스가 있다면, 당신이 가는 길에 무엇을 놓아도 항상 흘러갈 길을 찾을 것입니다. 소스가 배수되어 흐름이 없으면 할 일이 없습니다. 출처는 수요입니다. 당신의 태도는 물의 근원이 매우 살아 있음을 나타냅니다.

그래서 궁금해서요. 그냥 인수해 주시지 않겠습니까? 그것이 내가 로딩 바 라이브러리를 위해 한 일입니다. 개발이 멈춘 것을 깨달았고, 내 문제부터 시작하여 각 지점에 대한 pull 요청을 생성하여 문제를 해결했습니다. 얼마 후, 원저자는 그의 작업을 계속하기로 결정했고 우리는 가기에 좋았습니다. 이것이 실현 가능한 해결책이라고 생각하십니까?

당신은 나를 격려했다! :)

다행이다.

.

전등 스위치와 같습니다. 램프가 없습니다. 불가능한 것에서 쉬운 것까지

따라서 일부 "횡설수설한" 규칙 집합만 볼 수 있을 때 그렇게 어리석다고 생각해서는 안 됩니다. :)

아니. 파서는 "그냥 우스꽝스럽다가 갑자기 쉬워진다"는 극단적인 경우입니다.

여기 키커가 있습니다. 상대적으로 말해서 페그는 매우 쉽습니다. 다른 것들은 종종 그냥 잔인합니다.

내 의견으로는 학습 페그에는 네 가지 큰 문제가 있습니다.

1. 제대로 구성된 소개 자료가 없습니다.
2. 중간 수준의 예제가 많이 있지만 찾으려면 Google을 잘해야 합니다.
3. 나쁜 예도 있고 그것을 식별할 수 있으려면 경험이 필요합니다.
4. 당신은 "이런 식으로 생각"할 수 있어야 합니다. 그리고 그것은 즉시 일어나지 않습니다

몇 가지 비디오 자습서를 만드는 것을 고려했습니다. 그들은 이것을 _훨씬_ 이해하기 쉽게 만들 것이라고 믿습니다.

.

나는 이것을 남용하고 싶지 않으므로 물어볼 가치가 있다면 매번 전화하기 어려울 것입니다.

일주일에 한 번은 괜찮습니다. 가끔 반응이 느리다는 점 이해해주세요

.

포크에서 "문제" 섹션을 활성화한 것으로 나타났습니다. 그것은 항상 승객일 때 조종석으로 돌진하여 여객기를 조종하려는 좋은 징조입니다. 좋은 일이야.

이제 막 시작했습니다. 먼저 실제 repo가 ​​구출될 수 있는지 확인하고 싶습니다.

포크에서 이것을 하는 것은 엄청나게 더 어려울 것입니다. 나는 모든 PR과 모든 상호 참조, 폐쇄된 병합되지 않거나 폐쇄된 삭제된 자료를 모두 잃게 됩니다. 그 중 일부는 매우 가치가 있습니다.

.

그래서 궁금해서요. 그냥 인수해 주시지 않겠습니까?

하고 싶습니다.

이 때 해당 비밀번호와 인증은 한 사람의 손에 달려 있어 아직까지 아무런 대응도 하지 않고 있다.

우리는 볼 것이다.

.

개발이 멈췄다는 것을 깨닫고 내 문제부터 시작하여 각 지점에 대한 pull 요청을 생성하여 문제를 인계받았습니다.

이것은 특별한 경우입니다

게시된 내용은 0.10.0 입니다.

새 유지 관리자는 0.11.0 분기가 3년 동안 무제한으로 성장할 수 있도록 허용한 다음, 0.12.0 가 처음부터 격리되어 작성하기 위해 취소되기로 결정했습니다.

PR을 할 일이 없습니다. npm 에 있는 것은 2017년이고, 새 관리자 아래 github 에 있는 것은 게시하지 않고 3년 후에 취소됩니다.

.

얼마 후, 원저자는 그의 작업을 계속하기로 결정했고 우리는 가기에 좋았습니다. 이것이 실현 가능한 해결책이라고 생각하십니까?

교체 유지 관리자가 기꺼이 허용한다면 이것이 내가 원하는 것과 거의 일치합니다.

David가 돌아올지 의심스럽긴 하지만 그가 돌아온다면 환상적일 것입니다.

따라서 이것을 표준 오픈 소스 프로젝트로 다시 바꾸고 싶습니다.

당신에 따르면 여기에서 가장 중요한 3가지 문제는 무엇입니까?

나에게 가장 중요한 문제가 무엇인지 말하는 것은 약간 위험하다고 생각합니다. 왜냐하면 여기에는 peg 보다 더 많은 경험을 가진 사람들이 많이 있기 때문입니다. " 듣게 될 것 같다.

이를 위해 여기에서 개발하게 되어 기쁩니다. 하지만 여기에서 내가 관심을 가지는 것은 메인테이너 입니다.

이것은 많은 사람들이 이해하지 못하는 것입니다. 개발 및 유지 관리 코딩은 정말, 정말 다릅니다.

• Development coding 는 새롭고 멋진 아이디어, 새로운 기능, 멋진 아이디어를 원합니다.
• Maintenance coding 는 작은 문제가 집계되어 사용할 수 없게 만들기 전에 수정하려고 합니다.

개발 코딩을 하게 되어 기쁩니다. 일부는 기대하기도 합니다. 하지만 여기에 더 적합한 다른 사람들이 있습니다. 그래서 저는 분명히 하고 싶습니다. 제 실제 목표는 그들이 예전처럼 다시 PR에 기여할 수 있도록 하는 것입니다.

즉, 내 개인적인 견해가 무엇인지 보여주기 위해 :

1. 정규 릴리스 주기를 되돌리기

peg.js 는 다시는 매직 브랜치를 가지지 않아야 합니다. 빌어먹을 One Ring과 비슷합니다. 그것은 훌륭하고 강력하게 들리지만 그것은 빌어먹을 일이 아니며 결국 당신은 골룸입니다. 이것은 svn 가 아닙니다. 스티브 발머의 목소리에서 feature branches , feature branches , feature branches , feature branches .

버전은 기능 계획의 수집 지점이 아니라 기능의 결과여야 합니다. 우리는 1980년대 회사가 아니며 그런 회사를 계획해서는 안 됩니다.

동시에 둘 이상의 기능이 들어가야 하는 유일한 경우는 외부 업그레이드에 대처하기 위해 기능을 패치한 결과 또는 진정으로 분리할 수 없는 일과 같이 불가피한 경우입니다. 오, 다른 기능과 관련이 있다고 생각하십니까? 좋습니다. 2.31.0 에 넣고 2.29.0 를 꺼내야 하고 저기 있는 다른 것은 30 것입니다.

사람들은 미성년자를 전공자처럼 대했습니다. 이것이 미성년자가 나오지 않은 이유입니다. 미성년자는 메이저를 걸고 동일한 행동 함정에 걸린 것입니다. 그냥 하지 마세요 ™.

구체적으로 말하자면,

• 사람들은 이 도서관이 더 이상 존재한다는 믿음을 크게 잃었습니다.
• 3개월의 주간 릴리스는 사람들에게 또 다른 기회를 줄 것입니다.
  
  
  
  • 3개월의 주간 릴리스는 실제로 달성하기 매우 쉽습니다.
  
  
• 0.12.0 뿐만 아니라 0.13.0 도 가져왔다면 - 그리고 내가 그 안에 무엇이 들어 있는지 말하는 것이 아니라 그것이 중요하지 않다고 생각한다는 것을 알아차리면 - 그러면 우리는 1.0.0 에서 실제 기회를 잡으세요
• 여기에서 공개 및 비공개 병합되지 않은 PR을 살펴보면 2015년 정도에 "나중에 살펴보겠습니다."와 같은 댓글과 함께 엄청난 양의 힘과 아름다움이 있습니다. 관대한 사람이 되고 권위를 공유할 수 있는 공간을 찾는 것은 peg 에 도움이 될 뿐만 아니라 꽃을 피우는 데 도움이 됩니다.
• 그런 의미에서 나는 예술가가 되고 싶지 않다. 큐레이터가 되고 싶습니다.

2. 문서화 및 테스트를 수용 가능한 장소에 가져오기

모두가 이것에 대해 이야기하지만 내 취미 유한 상태 기계는 현재 3500 단위 테스트와 100% 문서 적용 범위를 가지고 있으므로 더 심각하게 생각하십시오.

저는 테스트를 정말 깊이 믿습니다.

내가 작성한 또 다른 라이브러리는 크기가 절반이고 상태 머신보다 복잡성이 훨씬 낮습니다. 네트워크 핸들러가 제대로 테스트되지 않았고 무언가가 올바른지 확인하기 위해 많은 노력을 기울여야 하기 때문에 네트워크 핸들러를 약간 변경하는 것보다 상태 머신에 대해 포괄적인 언어 변경을 하는 것이 훨씬 쉽습니다.

FSM? 아니, 테스트는 훌륭합니다. 그들은 당신을 잡을 것입니다

이 특정한 대조는 내가 둘 중 하나를 만질 때마다 잔인할 정도로 명확하게 나에게 테스트가 실제로 어떤 것이, 적어도 나에게 신뢰할 수 있는 것이 얼마나 중요한지를 상기시켜줍니다.

peg.js 작업의 가장 큰 문제는 테스트와 문서화가 엉망이라는 점입니다. 이제는 바뀌어야 할 때라고 생각합니다.

3. 힙스터의 넌센스 제거.

• 나는 Ruby 사람이 아니지만 Ruby 사람들은 관습에 따른 구성에 대한 진정한 요점을 가지고 있습니다. 나는 Ruby를 전혀 사용하지 않지만 여전히 앉아서 프로젝트가 어떻게 작동하는지 알 수 있습니다. 왜냐하면 그것이 모두가 작동하는 방식이기 때문입니다. 그리고 내가 무언가를 얻지 못하면 누군가에게 요청할 수 있고 그들은 액세스할 필요가 없기 때문에 그것이 그들이 모두 일하는 방식입니다
• peg 는 이와 관련하여 4가지 문제에 직면해 있습니다.
  
  
  
  1. peg 는 매우 초기의 javascript 라이브러리이며 커뮤니티 규범이 존재하기 전에 많은 기본 선택을 했습니다. 사실, 여러 커뮤니티 규범은 David 때문입니다 . 페그 이전에는 많은 사람들이 멀티패키징이 어렵다고 생각했는데, 그런 면에서 선구자 중 한 명이 같은 면에서 문제가 있어 뒤처져 있어서 마음이 아픕니다. 그렇긴 하지만, David가 미리 얻은 훌륭한 것들 외에도 그가 잘못한 것들, 그리고 그 당시에 있었던 것들 중 일부는 더 이상 그렇지 않습니다. 많은 작은 변화가 개발자 경험에 근본적인 변화를 가져올 것입니다.
  
  
  2. 커뮤니티 규범을 재정립해야 합니다.
     
     
     
     
     
     1. node 프로젝트가 작동해야 하는 특정한 방법이 있습니다. 여기에는 브라우저 대상 출력 생성이 포함되므로 노드 프로젝트는 분명히 올바른 현대식 작업 방식입니다.
     
     
     
     2. 이것은 여전히 ​​손으로 만든 자동화가 적용된 브라우저 프로젝트입니다. 그건 바뀌어야 한다
     
     
     
     3. README 를 올바르게 편집할 수 있는 위치에 들어가는 것은 중요한 학습 과제입니다. 3년이 지난 후에도 현재 유지 관리자는 여전히 이를 해제 하지 않았으며(!) 지난 두 버전의 원래 개발자도 없었습니다.
        
        
        
        
        
        
        
        • 아시닌입니다. 사소해야 할 프로젝트의 조각들이 단순하고 정상적인 방식으로 수행되지 않기 때문에 깨지고 있습니다. 그들은 단순하고 정상적인 방법으로 수행되어야 하지만, 이를 위해서는 노드를 알고 지루한 작업을 할 준비가 된 사람이 필요합니다.
        
        
        
        
     
     
     
  
  
  3. peg 는 극단적 자동화의 수혜자이자 피해자입니다.
     
     
     
     
     
     • dmajda 이(가) 없었으면 지금까지 하지 못했을 것입니다. 나는 확실히 내 물건에 할 수 없습니다.
     
     
     
     • 그러나 이것은 2011 자동화가 아니라 2020 자동화입니다.
     
     
     
     • 또한 2013, 2014, 2016 및 2018 자동화입니다. 이 내용은 zeit, 현재 github 페이지, yahoo 개인 계정, gitlab, 여러 이상한 추적 및 자동 배포 서비스, 그리고 아마도 내가 아직 찾지 못한 많은 것들에 퍼져 있습니다.
     
     
     
     • 붕괴에서 살아남거나 뜨거운 새로운 것을 가지고 노는 것은 단지 도구를 휘두르는 것입니다. 신중한 도구 선택은 영구적인 설계로 이어집니다. 실제 repl 는 이제 거의 10년 동안 사용할 수 있습니다. "ooh Shiny"가 위험 신호로 취급된다면 다른 모든 것도 가능합니다.
     
     
     
     • 이것은 gh pages 및 gh actions 로 옮겨야 합니다. 모두가 이해하고 영원히 남겨둡니다.
     
     
     
  
  
  4. 새로운 관리자는 흔하지 않은 도구와 소외된 전략에 대해 자세히 알아보기로 했습니다. 결과적으로 버그 수정에 기여하기 위해 새 패키지 관리자를 설치해야 하고 , 일반 소스 레이아웃에서 실제 제품으로 보이는 관련 없는 소스 세트와 혼동되는 방식으로 공존하는 흔하지 않은 소스 레이아웃을 배워야 합니다.
     
     
     
     
     
     • 제3자가 표준 언어 패키지 관리자도 작동하도록 하는 수정 사항을 제공했을 때 그는 이를 거부했습니다.
     
     
     
     • 이러한 종류의 행동은 솔직히 커뮤니티 프로젝트에서 용납될 수 없습니다. 라이브러리를 기여하기가 훨씬 더 어렵습니다.
     
     
     
     • 이러한 극단주의 도구 중 일부는 다른 극단주의 도구로 대체되었으므로 그는 자신이 아는 것을 사용하지 않습니다. 그는 여러 가지를 시도하고 있습니다. 그 동안 우리는 $#$12 readme 에서 npm 를 수정하거나 es6 modules 병합과 같은 AST의 철자 오류와 같은 기본 사항을 한 번에 3년 동안 기다립니다.
     
     
     
     • 솔직히 말해서 0.12.0 리베이크에서는 모듈 원사 재료의 모듈과 같은 것들이 나올 것입니다. David의 빌드 항목은 2011년부터 작동했습니다. 2018년의 새로운 항목은 2020년에 이미 깨졌습니다. 더 이상 dilettante 기술은 없습니다.
     
     
     
  
  
• 그리고 ES6 내보내기를 할 수 있습니까?

그러나 그 중 어느 것도 실제로 소프트웨어 자체에 관한 것이 아님을 알게 될 것입니다.

나는 여기 소프트웨어가 문제라고 생각하지 않는다

나는 그 과정이, 그리고 그 정도는 덜하지만,

@futagoza 가 허용한다면 수정하겠습니다.

이 도서관은 자부심을 삼키고 취미 프로젝트 관심보다 도서관의 대규모 커뮤니티 요구 사항을 선택하면 30일 만에 다시 살아날 수 있습니다.

취미 다시 쓰기가 포크가되게하십시오

관리자가 유지 관리를 시작하게하십시오

@StoneCypher 나는 당신의 에너지를 좋아합니다 :-) 나는 과거 (dmajda의 시대에) pegjs를 사용하고 그것을 많이 좋아했습니다.

그냥 포크하고 싸우지 마십시오. 상황은 나중에 해결될 수 있고 해결될 것입니다. 커뮤니티가 팔로우하면 기존 "키 홀더"나 이와 유사한 것에 대해 신경 쓸 필요가 없습니다. 명성을 쌓는 데는 시간이 걸리지만 반드시 필요합니다. 더 이상 논쟁에 시간을 낭비하지 마십시오.

8번의 포크는 미래의 어느 시점에서 "원점으로 돌아가게" 만들거나 고유한 수명을 갖게 됩니다. 두 옵션 모두 유효하고 훌륭한 IMO입니다.

"make fork" 헛소리로 멈춰주세요. 4가지가 있는데 그게 뭔지 잘 모르시더라구요. 포크는 기존 다운스트림 소비자를 저장하지 않고, PR을 저장하지 않으며, 문제를 저장하지 않으며, 커뮤니티를 전달하지 않으며, 표시되지 않습니다.

사람들은 3년 동안 그것을 시도했습니다. 작동하지 않습니다.

이 조언을 계속 제공하지 마십시오.

@futagoza - 모두가 당신이 옳은 일을 하는 것을 포기했습니다. 5명의 사람들이 나에게 라이브러리를 포크하라고 말했습니다. 왜냐하면 그들은 당신이 수리를 허용하지 않고 죽이고 있는 라이브러리를 계속 제어할 수 있기를 기대하기 때문입니다.

그들이 이것을 기대하는 이유는 당신이 약속했지만 하지 않은 일을 하는 데 도움을 주겠다고 제안하는 12명 이상의 사람들을 찾았고 당신이 "아니요, 곧 할 것입니다. "

2018년에 했어야 할 일을 하고 실제로 프로젝트를 유지 관리할 사람에게 유지 관리를 제공합니다. 이 라이브러리를 죽이는 것을 멈추고, 이 커뮤니티를 죽이는 것을 멈추고, 비켜주세요.

@StoneCypher John, 포크를 만들자고 제안했을 때 정말 의미가 있었습니다. 프로젝트 포크는 특히 변경이 필요하거나 죽어 가고 있다고 느낄 때 오픈 소스가 제공하는 훌륭한 옵션입니다. 그리고 아니요, 저는 문제가 없습니다. 이 질문을 하기 위해 저에게 DM을 보낼 필요가 없습니다.

"다시는 이런 충고 하지마"라고 한 것도 진심이었다.

나는 이 대화를 좋아한다.

@StoneCypher 나는 반대를 보았기 때문에 여기에 동의하지 않습니다.

1. 저는 FreeCAD를 배우기로 결정했습니다. 그러나 문제가 있었습니다. "어셈블리 모듈"이 완전하지 않았기 때문에 전문적인 작업에 쓸모가 없는 복잡한 어셈블리를 거의 만들 수 없었습니다.
2. realthunder 라는 사람이 이 문제를 해결하기로 결정했습니다. 그는 목표를 달성하기 위해 몇 가지 핵심 속성을 변경해야 했고, 그 결과 포크가 주류 브랜치와 호환되지 않았습니다. 그는 모든 사용자, 거의 모든 커뮤니티를 잃었습니다. 소수의 사람들을 제외하고는 지지자가 없었습니다(제가 본 것입니다). 내가 이해하는 한 그는 또한 활성 사용자가 없었습니다.
3. 나는 그의 문서 ¹ 를 조사했고 개발이 지연된 해에도 불구하고(당시 내가 본 것) 수학(흥미로운 수학)을 만들고 시도해 보기로 결정했습니다.
4. 나는 많은 질문을 ¹ 했고 그는 참을성 있게 대답했습니다. 그동안 배운 내용을 메모 하여 좋은 소개 자료를 만들었습니다.
5. 사람들은 ¹ 가 외로운 저자이자 유지 관리자이며 지속 가능성 측면에서 그의 작업을 신뢰할 수 없다고 주장하면서 그의 지점을 사용하는 것을 낙담했습니다. 그냥 무시했습니다.
6. 그의 pull 요청은 오랫동안(약 1년 정도) 병합되지 않았습니다.

최근 그의 PR이 검토되기 시작했다. 많은 작업이 완료되었고 마침내 그의 지부와 주류가 호환 가능하게 되었습니다. 다음 릴리스에서는 그의 지점이 주류로 병합될 것이라고 믿습니다.

그러는 동안 심각한 재정 문제가 있었습니다. 그는 유일한 유지 관리인이었고 몇몇 사용자의 기부로 그를 살아남을 수 없었습니다. 여기 터키에서 FreeCAD/Assembly3를 가르치고 재정 지원을 위해 지원을 판매하기로 결정했습니다. 나는 그에게 제안했고 이것은 받아들여졌다. 나는 최근에 승인된 유명한 재단에서 트레이너가 되기 위해 필요한 모든 지원을 했습니다.

때로는 한 사람이 불을 지피기에 충분합니다.

그리고 비켜

동의하지 않는다. 그들이 길을 가도록 내버려 두십시오. 좋은 동기는 항상 탈출구를 찾을 것입니다. 그렇지 못하다면 좋지 않았기 때문이다.

나는 이 주제에 대한 조언을 명확하고 명확하게 수집하지 않습니다.

이 라이브러리는 부활해야 합니다. 제가 충분히 설명하지 못했다면 유감입니다. 그러나 제가 받는 응답은 제기된 실질적인 문제를 해결하지 못합니다.

사람들의 삶과 직업이 여기에 달려 있습니다.