Pegjs: 새로운 유지사를 구합니다

지난 몇 개월 동안 PEG.js를 사용하기 시작했고 정말 좋아합니다. 문법은 배우기 쉽고 개념의 수가 상당히 적습니다. 문서는 약간 가볍지만 필요한 모든 것을 찾았습니다. 또한 javascript.pegjs 예제가 없었다면 JavaScript 방언을 시작하지도 않았을 것입니다. 덕분에 작업량이 크게 줄었습니다.

현재 상태에서 어떤 이점이 있습니까? 저에게는 프로토타입을 만드는 것이 매우 쉽습니다. 많은 양의 데이터에 대해서는 느릴 수 있다는 단점이 있지만 지금은 그런 것에 신경 쓰지 않습니다. 경쟁자는 무엇입니까? 계속해서 성장하기를 원하십니까, 아니면 누군가 버전 2.0을 만들어 주기를 원하십니까? 현재 안정적이라면 문서를 조금 더 추가하여 그대로 두는 것이 좋습니다.

로드맵의 경우 코드 현대화는 무엇을 제공합니까? 더 빠르게? 유지 보수가 더 쉽습니까? 아니면 그냥 "최신"? 유지 관리를 쉽게 하기 위해 Make 대신 Gulp를 사용하는 것을 이해할 수 있습니다. 정리는 현재 1.0이라고 부르는 거의 1.5로 비싸게 들립니다. "성능을 크게 향상시키는 것"은 1.0의 목표가 너무 큽니다. 나는 현재가 1.0이라고 느낀다. 그것은 매우 안정적이고 좋은 오류 메시지, 모든 기능 작업 등입니다. 소프트웨어 1.0이 "하나"일 필요는 없습니다. 2.0, 3.0 등이 더 많습니다.

유지 보수에 도움이 될 수 있을지 모르겠지만 사이트, Google 그룹 등이 계속 살아 있는 것을 보고 싶습니다.

@mikeaustin 의견 주셔서 감사합니다. 귀하의 질문에 신속하게 답변해 드리겠습니다(이 문제를 보고 있는 다른 사람들에게도 유용할 수 있음).

현재 상태에서 어떤 이점이 있습니까? 저에게는 프로토타입을 만드는 것이 매우 쉽습니다.

프로토타이핑은 정규 표현식 및 다양한 대화형 도구에 너무 복잡한 작은 언어/DSL 구문 분석과 함께 지배적인 사용 사례였습니다. 원래 PEG가 좋은 문법 구문을 제공하고 이를 사용하고 좋은 오류 메시지를 생성할 수 있는 JavaScript 파서 생성기가 없었기 때문에 PEG.js를 만들었습니다.

많은 양의 데이터에 대해서는 느릴 수 있다는 단점이 있지만 지금은 그런 것에 신경 쓰지 않습니다.

많은 사람들이 그렇게 하기 때문에 성능 작업이 로드맵에 포함됩니다.

경쟁자는 무엇입니까?

지슨 , 니 어리

계속해서 성장하기를 원하십니까, 아니면 누군가 버전 2.0을 만들어 주기를 원하십니까? 현재 안정적이라면 문서를 조금 더 추가하여 그대로 두는 것이 좋습니다.

그것은 새로운 관리자에게 달려 있습니다. 그러나 나는 PEG.js가 현재 기능 세트에 영원히 정체되는 것을 원하지 않습니다. 그것보다 더 많은 가능성이 있습니다.

코어 변경 없이 비교적 쉽게 추가할 수 있는 유용한 기능이 많이 있습니다(#30, #38, #107, #45, #285). 그런 다음 핵심 개념(#11, #217)을 다시 생각하거나 API를 변경(#327, #430)해야 하는 오랜 문제/사용 사례가 있습니다. 이 모든 것을 볼 가치가 있다고 생각합니다.

로드맵의 경우 코드 현대화는 무엇을 제공합니까? 더 빠르게? 유지 보수가 더 쉽습니까? 아니면 그냥 "최신"?

유지 관리가 더 쉽고 최신 상태입니다(이는 부분적으로는 PR 결정입니다. 이전 기술과 새 기술 사이에 약간의 생산성 차이만 있어도 프로젝트가 기술적으로 오래되어 보이는 경우 좋지 않습니다).

나는 현재가 1.0이라고 느낀다. 그것은 매우 안정적이고 좋은 오류 메시지, 모든 기능 작업 등입니다. 소프트웨어 1.0이 "하나"일 필요는 없습니다. 2.0, 3.0 등이 더 많습니다.

수 있습니다 :-) 1.0에 대한 제 정의는 항상 "만족할 때"였습니다. 이것은 어떻게 든 결코 오지 않았습니다. 부분적으로는 저를 가장 괴롭히는 일 대신에 결국 사용자를 가장 괴롭히는 일과 현실 세계에서 PEG.js를 사용하는 데 필요합니다. 나의 완벽주의적 성격도 도움이 되지 않았다.

1.0을 정의하는 것은 새로운 관리자에게 달려 있습니다.

https://github.com/futagoza/epeg.js 😊 ( 나열된 기능의 대부분은 현재 구현되지 않았지만 한 시점 또는 다른 시점에서 일부 포크 또는 관련 없는 프로젝트에 있었지만 대부분의 GitHub에 올린 적이 없음)

나는 모든 것이 괜찮지 만 유일한 문제는 테스트를 유지하는 것입니다 😞

@dmajda는 PEG.js 에 대해 많은 감사를 드립니다. 매우 유용합니다. 이 프로젝트가 계속되기를 바랍니다.

@futagoza 명확히

나는 모든 것이 좋지만 유일한 문제는 테스트를 유지하는 것입니다.

정확히 어떤 문제?

@dmajda 예, 유지 관리에 관심이 있을 것입니다 😄

나는 모든 것이 좋지만 유일한 문제는 테스트를 유지하는 것입니다.

정확히 어떤 문제?

내 말은 내가 보통 진행하면서 코딩하고 디버그하지만, 여기에서 하는 것처럼 테스트를 만들려고 하면 테스트를 유지 관리하는 데 문제가 발생하기 시작하므로 일반적으로 최종 결과를 볼 수 있는 테스트를 만들거나 그냥 둡니다. 다른 사람에 대한 사양 및 벤치마크 테스트, 돌이켜 보면 일부 프로젝트의 개발 시간이 늘어납니다 😆

@dmajda 저는 현재 MSc 프로젝트의 일부로 PEG.js를 사용하고 있습니다. 유용할 뿐만 아니라 흥미롭고 멋진 작업입니다. 누군가를 가치 있는 PEG.js 상속자로 간주하기를 진심으로 바랍니다.

@futagoza 문제 설명에서 다음과 같이 썼습니다.

저는 파싱 및 파서 생성기가 어떻게 작동하는지 깊이 이해하고, 강한 동기 부여, 오픈 소스 개발 경험, PEG.js 개발을 어디로 이끌 것인지(현재 로드맵과 일치하거나 일치하지 않을 수 있음) 명확한 아이디어를 갖고 있는 사람을 찾고 있습니다.

귀하의 의견에서 ePEG.js에 대한 링크만 제공했는데, 그 자체로는 귀하가 위의 설명에 맞는지 확인하기에 충분하지 않습니다(ePEG.js의 TODO 목록은 귀하가 어디로 리드 PEG.js 개발).

나는 당신이 당신의 작업과 웹 존재가 스스로 말하게 하고 싶어할 것이라고 생각했습니다. 그래서 나는 당신의 웹사이트를 보고 Twitter와 LinkedIn 링크를 클릭했지만 둘 다 죽었습니다. 상상하다. 그 후, 나는 포기했다. ePEG.js의 경우 현재 단계에서 위시리스트 이상으로 취급하기 어렵습니다.

따라서 몇 가지 구체적인 질문을 드리겠습니다.

• 당신의 배경은 무엇입니까? 특히, 파서 및 파서 생성기에 대한 지식 수준은 어느 정도입니까? 어디서 그 지식을 얻었습니까?

• PEG.js 작업을 하게 된 동기는 무엇입니까? 특히 개인 또는 업무 프로젝트에서 PEG.js(또는 ePEG.js)를 사용합니까? PEG.js를 유지 관리하는 것이 일상 업무의 일부입니까, 아니면 여가 시간에 하시겠습니까?

• 오픈 소스 프로젝트에 대한 귀하의 경험 수준은 어느 정도입니까? 특히, PEG.js에 필적하는 오픈 소스 프로젝트(주로 사용자 수)를 유지하거나 유지하고 있습니까?

• PEG.js가 현재 누락되었거나 제대로 하지 않고 있는 상위 5가지 사항이 무엇이라고 생각하십니까? 또한 프로젝트를 수행하고 싶은 위치를 설명할 수 있습니까? 1년에 어디에서 보고 싶습니까?

질문에 답변해 주셔서 감사합니다. 그들은 당신이 PEG.js의 올바른 미래 관리자가 될 것인지 결정하는 데 도움이 될 것입니다.

그래서 나는 당신의 웹사이트를 보고 트위터와 링크드인 링크를 클릭했지만 둘 다 죽었습니다

그 사이트는 2010년에 Vitron Prince라는 이름으로 갔을 때 만든 예전 웹사이트를 복사/붙여넣기한 것이므로 링크가 대부분 더 이상 유효하지 않거나 더 이상 유지 관리하지 않는 사이트/프로필로 연결됩니다. 사이트가 제대로 완료되지 않았습니다. 요즘 내가 온라인에 실제로 존재하는 유일한 존재는 GitHub와 PlayStation 😆입니다. 주로 제가 전일제 간병인이라는 사실 때문입니다.

당신의 배경은 무엇입니까? 특히, 파서 및 파서 생성기에 대한 지식 수준은 어느 정도입니까? 어디서 그 지식을 얻었습니까?

요약하자면 지난 5년 간 스스로 스트링과 버퍼 토큰화, 메모이제이션을 하면서 AST를 빠르고 정확하게 생성하는 다양한 방법을 배웠고, 다른 컴퓨터 언어를 최적의 언어로 변환하기 위한 다양한 방법을 주로 공부했습니다. JavaScript 및 C++, 컴파일 속도를 높이기 위해 단일 패스로 압축할 수 있는 패스를 식별하는 동시에 최상의 성능을 위해 서로 다른 패스에 서로 다른 AST 방문자를 사용합니다.

파서 생성기의 경우, 내가 아는 것은 PEG.js용 파서 생성기를 연구하고 숫자를 비교하는 것이 문자열을 비교하는 것보다 더 빠르다는 지식을 통해 배웠기 때문에 String#charAt 보다 String#charCodeAt 를 선호 String#charAt . options.optimize = "size" 사용하여 파서를 생성하는 것과 관련된 부분을 이해하는 데 여전히 문제가 있지만 speed with accuracy 에 중점을 두었기 때문에 파서 생성의 이 부분을 공부할 동기를 전혀 얻지 못했습니다.

참고 사항: 꽤 많이 배웠지만 용어를 기억하는 데 문제가 있습니다 😊

PEG.js 작업을 하게 된 동기는 무엇입니까? 특히 개인 또는 업무 프로젝트에서 PEG.js(또는 ePEG.js)를 사용합니까? PEG.js를 유지 관리하는 것이 일상 업무의 일부입니까, 아니면 여가 시간에 하시겠습니까?

PEG.js 작업에 대한 저의 동기는 CXLang을 개발하고 게임 에서 사용할 다양한 텍스트 기반 리소스 파일에 대한 사용자 정의 파서를 만드는 것이므로 개인 및 업무 프로젝트 모두에 사용한다고 말하고 싶습니다. ePEG.js와 마찬가지로 PEG.js를 유지 관리하는 것은 대부분 자유 시간에 할 것입니다.

내가 지금 개발하는 데 주로 집중하고 있는 것은 (기능해야 하는 순서대로):

• PEG.js 또는 https://github.com/futagoza/epeg.js
• https://github.com/cx-lang/cx-lang
• Roxby, C++ 게임 엔진 및 Node.js 기반 SDK로 매끄럽지만 사용자 정의 가능한 3D 세계 구축
• 크로스 플랫폼 및 게임에 구애받지 않는 모드 시스템인 Xross M
• 게임에 구애받지 않는 컴패니언 앱인 Xross C
• 크로스 플랫폼 멀티 플레이어 및 멀티 플랫폼 저장에 중점을 둔 마인크래프트 클론
• 포켓 월드를 통합한 1개의 매끄럽고 거대한 인터랙티브 세계를 배경으로 하는 MMORPG 게임
• 내 MMORPG에 등장하는 동일한 포켓 세계를 기반으로 한 일련의 싱글 플레이어 게임

CXLang, Roxby 및 Xross에서 PEG.js를 사용한다는 점에 유의해야 합니다. 현재 PEG.js는 일반 텍스트로 다양한 자산을 만든 다음 PEG.js를 사용할 수 있기 때문에 게임 개발의 매우 중요한 부분입니다. 및 사용자 정의 컴파일러는 게임, 기타 프로그램/도구 또는 라이브러리 코드에서 사용되는 기본 코드로 변환합니다.

오픈 소스 프로젝트에 대한 귀하의 경험 수준은 어느 정도입니까? 특히, PEG.js에 필적하는 오픈 소스 프로젝트(주로 사용자 수)를 유지하거나 유지하고 있습니까?

아니요, 저는 2013년부터 간병인으로 일해왔기 때문에 비디오 게임, 한국 드라마 또는 다양한 C++/Node.js 프로젝트(대부분 위에서 언급한 프로젝트)에서 자유 시간을 보냈습니다. 코드를 공유하고 싶습니다. 다른 코드에는 미래에 상용 제품을 만들기 위해 개발 중인 개인 프로젝트에 대한 코드가 포함되어 있기 때문에 랩톱에 보관하고 있습니다.

CXLang은 이미 오픈 소스이지만(여기저기서 거의 테스트하지 않고 계속 개발하기 때문에 다양한 부분이 아직 GitHub에 제공되지 않았기 때문에) 내 게임.

PEG.js가 현재 누락되었거나 제대로 하지 않고 있는 상위 5가지 사항이 무엇이라고 생각하십니까? 또한 프로젝트를 수행하고 싶은 위치를 설명할 수 있습니까? 1년에 어디에서 보고 싶습니까?

• ePEG.js 또는 대안을 만들지 않는 이유 😛
• 현재 바이트코드 생성기는 현재 자바스크립트 생성기에서만 유용합니다.
  
  
  
  • 컴파일러 패스의 일부가 아니어야 하지만 생성기를 위한 선택적 도우미입니다.
  
  
  • 모든 언어로 파서를 생성하는 데 도움이 되도록 바이트코드 및 AST를 생성해야 합니다(플러그인별).
  
  
  • 옵션에 따라 파서 생성기를 안내하는 선택적 바이트 코드 생성
  
  
• PEG.js 문법 구문 내의 작업 및 문자열 리터럴은 파서 생성기와 소스 유형을 제한합니다.
  
  
  
  • 규칙에서 사용하는 작업의 반환 유형을 설정하는 속성( <strong i="27">@returns</strong> ... 또는 [returns = ...] )
  
  
  • 시퀀스 선택 및 추출을 위한 구문 = 더 적은 작업 및 특정 언어에 대한 덜 의존
  
  
  • 숫자 리터럴을 통한 버퍼 지원, 일반 텍스트 소스 코드 이외의 파일용 파서 개발
  
  
• 파서를 보다 빠르게 개발할 수 있는 구문:
  
  
  
  • PEG.js 문법을 적게 작성하기 위한 템플릿
  
  
  • 내부 패스 또는 플러그인의 출력을 쉽게 관리하기 위한 속성(사전 정의 및 사용자 정의)
  
  
  • 개발자가 파일 이름으로 규칙을 쉽게 추적할 수 있도록 다른 문법에서 규칙 가져오기
  
  
• 현재 플러그인 시스템은 API를 변경하고 편집기에서 사용하기 위해 PEG.js를 최적화하기 어렵게 만듭니다.
• 파서 생성기는 너무 복잡하고 플러그인 친화적이지 않습니다. 다른 파일로 분할해야 합니다.

현재 PEG.js(웹사이트 또는 GitHub 리포지토리에서)에 대해 가장 먼저 읽은 내용은 다음과 같습니다.

PEG.js는 뛰어난 오류 보고 기능으로 빠른 파서를 생성하는 JavaScript용 간단한 파서 생성기입니다. 이를 사용하여 복잡한 데이터 또는 컴퓨터 언어를 처리하고 변환기, 인터프리터, 컴파일러 및 기타 도구를 쉽게 구축할 수 있습니다.

위의 이유를 해결하면 이 단락이 약속하는 것을 뒷받침할 뿐만 아니라 개발자가 파서를 개발할 때 더 많은 자유를 얻을 수 있다고 믿습니다.

솔직히 말해서 현재 일정을 감안할 때 1년 후가 어떨지 알 수 없지만 PEG.js에 대한 로드맵은 다음과 같습니다.

• __PEG.js v1__ - 0.11 이정표가 설명하는 대부분을 포함하지만 다중 파일 지원
• __PEG.js v1.x__ - 유지 릴리스(현재 LTS)
• __PEG.js v2.x__ - ECMAScript 2015로 작성된 코드 기반으로 위의 기능 대부분을 구현합니다.
• __PEG.js v3.x__ - LTS 릴리스
• __PEG.js v4.x__ - ECMAScript 2017 코드 기반, 버퍼 지원, 새로운 플러그인 인터페이스
• __PEG.js v5.x__ - LTS 릴리스
• __PEG.js v6.x__ - ECMAScript 20xx 코드 기반, 복잡한 데이터 구조 , 새로운 JavaScript 파서 생성기
• __PEG.js v7.x__ - LTS 릴리스
• __PEG.js v8.x__ - ECMAScript 20xx 코드 기반, 더 많은 도우미 및 선택적 패스, 편집기 중심 지원
• __PEG.js v9.x__ - 최종 LTS 릴리스, ECMAScript 20xx+ 코드 기반

이 로드맵의 이유는 내 작업과 사용자 문제를 더 쉽게 나누는 데 도움이 되는 동시에 파서 생성기에 대해 더 많이 배우고 더 나은 플러그인 인터페이스를 계획하고 __PEG.js v4.x__ 및 __PEG에 대해 스스로 준비할 수 있는 여지를 주기 위함입니다. .js v6.x__

또한 @dmajda 를 언급 Twitter 계정 및 Google 그룹 과 같은 측면을 중재자에게 맡기고 벤치마크 및 테스트 를 구성하고 유지 관리하는 데 기여자로부터 도움을 받는 반면 유지 관리자는 LTS 릴리스를 관리하는 데 도움을 줄 수 있습니다.

나는 마크다운 파서를 작성하기 위해 peg를 사용하고 있습니다, 감사합니다 😀

저는 프론트엔드 개발자이고 웹사이트를 개선할 수 있습니다. 이 조직에 합류하도록 저를 초대할 수 있습니까? 감사 해요!

@futagoza 먼저 답변이 느린 점 사과드립니다. 지난 주 동안 귀하가 작성하신 내용을 읽고, 생각하고, 답장을 작성하는 데 연속적인 시간을 내기 어려웠습니다.

당신이 쓴 것을 보면 당신이 의욕이 넘치고 자격이 탄탄하다는 것을 알 수 있습니다. PEG.js에 대한 귀하의 아이디어는 사용자가 인식하는 PEG.js의 가장 큰 문제라고 생각하는 것과도 잘 맞습니다. 나는 특히 당신이 더 많은 기여자들을 참여시키고 싶다는 것을 좋아합니다. 이것은 내가 유지 보수로서 다소 실패한 영역 중 하나라고 생각합니다.

내가 조금 걱정하는 것은 많은 기능이 도입되는 것을 보고 싶어한다는 것입니다. 많은 PEG.js 사용자가 단순함을 높이 평가합니다.

어쨌든 위의 모든 것을 감안할 때 다른 누구도 PEG.js를 인수하는 데 관심이 없다는 점을 감안할 때 PEG.js 유지 관리를 전달하지 않을 이유가 없습니다.

이로써 PEG.js의 새로운 관리자를 선언합니다.

축하합니다!

잠시 후 트위터와 Google 그룹에 변경 사항을 발표하겠습니다. 그런 다음 프로젝트 자산 이전에 대한 세부 정보가 포함된 이메일을 보내드리겠습니다. 전송이 완료되면 프로젝트에서 완전히 물러나겠습니다.

PEG.js를 잘 관리하셔서 여러분의 손에 있는 미래가 밝았으면 좋겠습니다 :-)

저는 프론트엔드 개발자이고 웹사이트를 개선할 수 있습니다. 이 조직에 합류하도록 저를 초대할 수 있습니까? 감사 해요!

@ericjjj 제안에 감사드립니다. 이것은 이제 달려 있습니다.

@futagoza 😂 축하합니다. 저는 프론트엔드 개발자이며 웹사이트를 개선할 수 있습니다. 이 조직에 합류하도록 초대해 주시겠습니까? 감사 해요!

@dmajda 감사합니다 😄 최선을 다하겠습니다.

기능 크립도 걱정했기 때문에 위의 로드맵에 LTS 일정을 추가했지만 위에서 언급한 것처럼 아직 확정된 것은 아닙니다.

@ericjjj m8 제안 감사합니다 👍

가장 해야 할 일이 무엇인지 설명하겠습니다. 하지만 웹사이트는 이미 업데이트할 일 목록에 있습니다.

전송 프로세스가 완료되고 유지 관리자 변경 사항을 반영하기 위해 웹사이트에 약간의 업데이트가 이루어지면 웹사이트의 저장소 에서 새 문제를 열 ​​계획입니다. 여기에서 변경, 추가 또는 제거할 계획을 검토할 것입니다.

내가 이슈를 만들 때, 나는 당신을 언급할 것입니다. 그래야 당신이 언제 뛰어들어 당신의 아이디어를 보여주고 당신의 생각을 공유할 수 있는지 알 수 있습니다. 웹사이트를 어디로 갈지 결정한 후, 여전히 저를 도와주실 의향이 있다면 초대하겠습니다 😆

@futagoza 네 , 감사합니다 😀

나는 조직에 추가되면 기여할 것이다

더 큰 단계별 자습서를 위해 무언가를 모을 수 있습니다. 핵심이 제거된 JavaScript와 같은 매우 기본적인 언어는 PEG.js를 사용하는 방법을 배우는 데 도움이 되었을 것입니다. 또한 AST를 통과하는 가장 좋은 방법을 아는 것은 다른 곳에서 찾아야 하는 것이었습니다.

예제는 작은 계산기에서 완전한 JavaScript 파서로 이동합니다. 나는 그 사이에 무언가가 있고 그것에 대한 튜토리얼이 있으면 좋을 것이라고 생각합니다.

내가 작성한 예시 기사:
https://structura.quora.com/Extension-Methods-in-JavaScript

그래서 @futagoza 는 새로운 PEG.js 관리자입니다.
그런데 왜 문제가 여전히 열려 있습니까?

BTW, 훌륭한 프로젝트에 감사드립니다!
내 첫 번째 프로그램 중 하나는 C++로 작성된 Pascal 언어 파서였습니다.
JavaScript + PEG.js는 이러한 작업을 훨씬 더 쉽게 만듭니다.

그리고 현재 저는 이 프로젝트를 사용하여 bash와 같은 언어(qmake 프로필)용으로 꽤 복잡한 파서를 만들고 있으며 이미 기능 부족에 직면해 있습니다. 예를 들어 하나의 큰 문법 파일을 여러 개의 작은 파일로 분할하는 기능이 없습니다.
그러한 구현을 돕기 위해 내가 무엇을 할 수 있습니까?

그런데 왜 문제가 여전히 열려 있습니까?

나는 그것을 닫는 것을 잊었다. 지금 하고 있습니다.