이것은 Ubuntu Online, Fedora Online, Windows 온라인 에뮬레이터 또는 MAC OS 온라인 에뮬레이터와 같은 여러 무료 온라인 워크스테이션 중 하나를 사용하여 OnWorks 무료 호스팅 제공자에서 실행할 수 있는 명령 perlhack입니다.
프로그램:
이름
perlhack - Perl 해킹 방법
기술
이 문서는 Perl 개발 방식을 설명합니다. Perl 5에 대한 자세한 내용도 포함되어 있습니다.
Porters 이메일 목록, Perl 저장소, Perlbug 버그 추적기, 패치 지침 및
Perl 개발 철학에 대한 해설.
슈퍼 빨리 반점 GUIDE
포드 수정, 버그 테스트와 같은 단일 작은 패치만 제출하려는 경우 주석을 남겨주세요.
수정 등, 정말 간단합니다! 방법은 다음과 같습니다.
· 소스 저장소를 확인하세요
Perl 소스는 git 저장소에 있습니다. 다음을 사용하여 저장소를 복제할 수 있습니다.
다음 명령 :
% git clone git://perl5.git.perl.org/perl.git perl
· 최신 조언을 따르고 있는지 확인하세요
이 가이드의 조언이 최근에 업데이트된 경우 최신 버전을 읽어보세요.
Perl 소스에서 직접:
% perldoc pod/perlhack.pod
· 변경하세요
해킹, 해킹, 해킹. Perl은 다양한 플랫폼에서 실행된다는 점을 명심하세요.
서로 다른 기능을 갖춘 서로 다른 운영 체제, 서로 다른 파일 시스템
조직, 심지어 다른 문자 집합도 있습니다. perlhacktips에서 이에 대한 조언을 얻을 수 있습니다.
· 변경 사항을 테스트하세요
다음 명령을 사용하여 모든 테스트를 실행할 수 있습니다.
% ./Configure -des -Dusedevel
% 테스트 만들기
테스트에 통과할 때까지 해킹을 계속하세요.
· 변경 사항을 적용하세요
작업을 커밋하면 변경 사항이 저장됩니다. on your 지방의 체계:
% git commit -a -m '커밋 메시지를 여기에 입력하세요'
커밋 메시지에는 변경 사항을 한 문장으로 설명해야 합니다. 예를 들어,
"perlhack.pod의 철자 오류를 수정했습니다."
· 변경 사항을 perlbug로 보내세요
다음 단계는 이메일을 통해 Perl 코어 티켓 시스템에 패치를 제출하는 것입니다.
변경 사항이 단일 git 커밋에 있는 경우 다음 명령을 실행하여 다음을 생성하세요.
패치 파일을 버그 보고서에 첨부하세요.
% git 포맷 패치 -1
% ./perl -Ilib utils/perlbug -p 0001-*.패치
perlbug 프로그램은 귀하의 이메일 주소와 관련하여 몇 가지 질문을 할 것입니다.
제출하려는 패치입니다. 답변을 완료하면 패치가 제출됩니다.
이메일.
변경 사항이 여러 커밋에 있는 경우 각 커밋에 대한 패치 파일을 생성하고
쉼표로 구분하여 perlbug의 "-p" 옵션에 제공하세요:
% git 포맷 패치 -3
% ./perl -Ilib utils/perlbug -p 0001-fix1.patch,0002-fix2.patch,\
> 0003-fix3.패치
메시지가 표시되면 변경 사항을 요약한 주제를 선택하세요.
· 감사합니다
Perl 개선에 도움을 주신 여러분의 시간에 감사드리며, 짐꾼들도 감사드립니다!
· 다음번
다음에 패치를 만들려면 최신 Perl에서 시작해야 합니다.
깨끗한 상태입니다. Perl에 로컬 변경 사항이나 추가된 파일이 없는지 확인하세요.
유지하고 싶은 항목을 체크아웃한 후 다음 명령을 실행하세요.
% git 풀
% git reset --hard origin/blead
% git clean -dxf
곤충 보고
Perl의 버그를 보고하려면 다음을 사용해야 합니다. 펄버그 명령줄 도구입니다.
이 도구는 버그 보고서에 모든 관련 시스템 및 구성이 포함되어 있는지 확인합니다.
정보.
기존 Perl 버그와 패치를 찾아보려면 웹 인터페이스를 사용할 수 있습니다.
<http://rt.perl.org/>.
perl5-porters 목록(아래 참조) 및/또는 버그 추적의 보관소를 확인하십시오.
버그 보고서를 제출하기 전에 시스템을 확인하세요. 버그가 보고된 경우를 종종 볼 수 있습니다.
이미.
버그 추적 시스템에 로그인하여 기존 버그 보고서에 의견을 남길 수 있습니다.
기존 버그에 대한 추가 정보가 있으면 추가해 주세요. 이렇게 하면 도움이 될 것입니다.
짐꾼이 버그를 고쳤다.
펄 5 짐꾼들
perl5-porters(p5p) 메일링 목록은 Perl 표준 배포판이 유지되는 곳입니다.
개발되었습니다. Perl을 유지하는 사람들을 "Perl 5 포터"라고도 합니다.
"p5p" 또는 "포터"라고만 불립니다.
검색 가능한 목록 보관소는 다음에서 사용할 수 있습니다.
<http://markmail.org/search/?q=perl5-porters>. 다음 위치에도 보관소가 있습니다.
<http://archive.develooper.com/perl5-porters@perl.org/>.
perl-변경 사항 메일 링 명부
perl5-changes 메일링 목록은 제출된 각 패치의 사본을 받습니다.
Perl 저장소의 유지 관리 및 개발 브랜치. 참조
<http://lists.perl.org/list/perl5-changes.html> 구독 및 보관 정보.
#p5p on IRC
많은 포터들도 활동하고 있습니다 채널입니다. 자유롭게 참여하세요.
채널을 통해 Perl 코어 해킹에 대한 질문을 해보세요.
시작하기 L' 펄 SOURCE
Perl의 모든 소스 코드는 Git 저장소에 중앙 보관됩니다. perl5.git.perl.org.
저장소에는 Perl 1부터의 많은 Perl 개정판과 다음부터의 모든 개정판이 포함되어 있습니다.
Perforce는 이전 버전 제어 시스템입니다.
Perl 저장소에서 git을 사용하는 방법에 대한 자세한 내용은 perlgit을 참조하세요.
읽기 ACCESS 를 통해 힘내
컴퓨터에 Git이 필요합니다. 저장소 사본을 가져올 수 있습니다.
git 프로토콜을 사용하여:
% git clone git://perl5.git.perl.org/perl.git perl
이렇게 하면 저장소가 복제되고 로컬 복사본이 생성됩니다. 펄 디렉토리.
방화벽 문제로 git 프로토콜을 사용할 수 없는 경우 http를 통해 복제할 수도 있습니다.
하지만 이것은 훨씬 더 느립니다.
% git 복제 http://perl5.git.perl.org/perl.git 펄
읽기 ACCESS 를 통해 전에, 웹
웹을 통해 저장소에 접속할 수 있습니다. 이를 통해 트리를 탐색하고 다음을 확인할 수 있습니다.
최근 커밋, 변경 사항에 대한 RSS 피드 구독, 특정 커밋 검색
더 많은 정보를 얻을 수 있습니다.http://perl5.git.perl.org/perl.git>. 거울
저장소는 다음에서 찾을 수 있습니다. .
읽기 ACCESS 를 통해 rsync
또한 rsync를 사용하여 현재 소스 트리의 복사본을 가져올 수도 있습니다.
bleadperl 브랜치와 모든 유지 관리 브랜치:
% rsync -avz rsync://perl5.git.perl.org/perl-current .
% rsync -avz rsync://perl5.git.perl.org/perl-5.12.x .
% rsync -avz rsync://perl5.git.perl.org/perl-5.10.x .
% rsync -avz rsync://perl5.git.perl.org/perl-5.8.x .
% rsync -avz rsync://perl5.git.perl.org/perl-5.6.x .
% rsync -avz rsync://perl5.git.perl.org/perl-5.005xx .
(남아 있는 파일을 제거하려면 "--delete" 옵션을 추가합니다.)
사용 가능한 동기화 지점의 전체 목록을 보려면:
% rsync perl5.git.perl.org::
쓰다 ACCESS 를 통해 자식
커밋 비트가 있는 경우 git 사용에 대한 자세한 내용은 perlgit을 참조하세요.
패치 펄
단일 소규모 수정보다 더 광범위한 작업을 계획하고 있다면 다음을 권장합니다.
아래 문서를 읽어보세요. 이렇게 하면 작업에 집중하고 패치를 만드는 데 도움이 될 것입니다.
Perl 소스에 통합하기가 더 쉽습니다.
미국 이민국에 패치
제출할 작은 패치가 있다면 perlbug를 통해 제출해 주세요.
직접 이메일로 보내세요 [이메일 보호]. perlbug에 전송된 메시지는 보류될 수 있습니다.
검토 대기 중이므로 즉시 답변을 받을 수 없습니다.
티켓에서 이메일을 받으면 제출이 처리되었음을 알 수 있습니다.
추적 시스템입니다. 이 이메일에서 티켓 번호를 알려드립니다. 패치가 완료되면
티켓 추적 시스템으로 전송되며, [이메일 보호] 명부.
패치는 p5p 목록에서 검토 및 논의됩니다. 간단하고 논란의 여지가 없는 패치는
일반적으로 논의 없이 적용됩니다. 패치가 적용되면 티켓이
업데이트된 내용이 이메일로 발송됩니다. 또한, p5p 목록에도 이메일이 발송됩니다.
다른 경우에는 패치에 더 많은 작업이나 논의가 필요할 수 있습니다. 이는 p5p에서 진행될 예정입니다.
명부.
토론에 참여하고 자신의 패치를 옹호해 주시기 바랍니다.
때로는 패치가 섞이면서 사라질 수도 있습니다. 알림을 보내는 것이 좋습니다.
한 달 동안 아무런 조치도 취하지 않으면 p5p로 이메일을 보내주세요. Perl 5는
개발자는 모두 자원봉사자이므로 예의를 갖춰야 합니다.
변경 사항은 항상 "blead"라고 하는 주요 개발 브랜치에 직접 적용됩니다. 일부
패치는 유지 관리 브랜치로 백포트될 수 있습니다. 패치가 적절하다고 생각되면
유지 관리 분기(perlpolicy의 "MAINTENANCE BRANCHES" 참조)에 대해 이유를 설명해 주십시오.
제출할 때.
교통 your 패치 접수
코드 패치를 제출하는 경우 다음을 도울 수 있는 몇 가지 방법이 있습니다.
Perl 5 Porters가 귀하의 패치를 수락합니다.
패치 스타일
git을 사용하여 Perl 소스를 체크아웃한 경우 "git format-patch"를 사용하면 다음이 생성됩니다.
Perl에 적합한 스타일로 패치합니다. "format-patch" 명령은 하나의 패치 파일을 생성합니다.
각 커밋에 대해. 모든 커밋에 대해 단일 패치를 보내려는 경우 다음을 수행할 수 있습니다.
"git diff"를 사용하세요.
% git checkout blead
% git 풀
% git diff bread my-branch-name
이렇게 하면 blead와 현재 브랜치의 차이를 기반으로 패치가 생성됩니다.
차이를 생성하기 전에 blead가 최신 상태인지 확인하는 것이 중요합니다.
먼저 "git pull"을 호출하세요.
가능하다면 git을 사용하는 것을 강력히 권장합니다. git을 사용하면 삶이 더 편리해질 것입니다.
우리도 마찬가지예요.
하지만 git을 사용하지 않더라도 적합한 패치를 생성할 수 있습니다.
diff 대상인 Perl 소스의 원본 사본입니다. 포터들은 통합 diff를 선호합니다.
GNU "diff"를 사용하면 다음과 같이 diff를 생성할 수 있습니다.
% diff -Npurd perl.pristine perl.mine
Perl 사본에서 "make realclean"을 실행하여 빌드 아티팩트를 제거했는지 확인하세요.
혼란스러운 결과가 나올 수도 있습니다.
커밋 메시지
Perl 코어에 제출하려는 각 패치를 작성할 때 다음을 작성하는 것이 중요합니다.
좋은 커밋 메시지. 제출물이 다음과 같은 내용으로 구성되는 경우 특히 중요합니다.
일련의 커밋.
커밋 메시지의 첫 번째 줄은 마침표 없이 짧은 설명이어야 합니다.
이메일 제목줄보다 길어서는 안 되며 50자가 좋은 규칙입니다.
무지.
많은 Git 도구(Gitweb, GitHub, git log --pretty=oneline, ...)는 다음만 표시합니다.
커밋 요약을 제시할 때 첫 줄(50자에서 제한)에 입력합니다.
커밋 메시지에는 패치가 수정하는 문제에 대한 설명이 포함되어야 합니다.
패치로 추가된 새로운 기능입니다.
일반적인 경험칙으로, 커밋 메시지는 다음을 아는 프로그래머에게 도움이 되어야 합니다.
Perl 코어는 당신이 무엇을 하려고 했는지, 어떻게 하려고 했는지 빠르게 이해합니다.
이 변화가 Perl에 중요한 이유
· 왜
커밋 메시지에는 변경 사항이 왜 중요한지 설명해야 합니다.
누군가가 6개월 후나 6년 후에 당신의 변화를 본다면, 당신의 의도는 분명해야 합니다.
나중에 다른 부분을 단순화하려는 의도로 기능을 사용하지 않는 경우
코드에 대해 그렇다고 말하세요. 성능 문제를 해결하거나 새로운 기능을 추가하는 경우
핵심의 다른 부분을 지원하고 싶다면 그것을 언급하세요.
· 무엇
커밋 메시지에는 Perl 코어의 어떤 부분을 변경하는지 설명해야 합니다.
패치를 통해 무엇을 기대하는지.
· 어떻게
문서 변경, 새로운 테스트 또는 사소한 패치에는 필요하지 않지만
변경 사항이 어떻게 작동하는지 설명하는 것이 종종 중요합니다. 오늘은 분명하게 알고 있더라도
다음 달이나 내년에 짐꾼에게 명확하게 전달되지 않을 수도 있습니다.
커밋 메시지는 코드의 주석을 대체하기 위한 것이 아닙니다. 커밋
메시지에는 변경 사항을 설명해야 하며 코드 주석에는 변경 사항을 설명해야 합니다.
코드의 현재 상태.
문서, 테스트 및 잘 주석 처리된 내용을 포함하여 새 기능을 구현했다면
코드의 경우 간단한 커밋 메시지만으로도 충분합니다. 하지만 방금 코드를 변경했다면
파서나 렉서에서 한 글자 깊이로 들어가면 작은 소설을 써야 할 수도 있습니다.
미래의 독자들이 당신이 무엇을 했고 왜 그렇게 했는지 이해할 수 있도록 하세요.
댓글, 댓글, 코멘트
코드에 적절한 주석을 달아주세요. 모든 줄에 주석을 달 필요는 없지만,
운영자의 부작용을 이용하여 변화를 만들어내는 모든 것
패치되는 기능 외부에서 느낄 수 있거나 다른 사람들이 혼란스러워할 수 있는 부분은 다음과 같습니다.
문서화되어 있습니다. 실수를 할 경우 너무 많은 것을 추가하는 쪽으로 실수를 하는 것이 좋습니다.
댓글이 너무 적습니다.
가장 좋은 댓글은 설명합니다 why 코드는 그 기능을 수행하지 않습니다. 뭐 it 하지.
스타일
일반적으로 패치하는 코드의 특정 스타일을 따르세요.
특히, Perl 소스에 패치를 적용하기 위한 일반적인 지침은 다음과 같습니다.
· 8개의 넓은 탭(예외 없음!)
· 코드에 대한 4개의 넓은 들여쓰기, 중첩된 CPP #define에 대한 2개의 넓은 들여쓰기
· 79열을 넘지 않도록 노력하세요.
· ANSI C 프로토타입
· 들여쓰기 제어 구문을 위한 Uncuddled elses 및 "K&R" 스타일
· C++ 스타일(//) 주석 없음
· 다시 방문해야 할 장소는 XXX로 표시하세요 (그리고 자주 방문하세요!)
· 조건이 여러 줄에 걸쳐 있는 경우 여는 중괄호는 "if"와 일치해야 합니다.
그렇지 않으면 줄 끝
· 함수 정의에서 이름은 열 0에서 시작합니다(반환 값 유형은 이전 열에 있음)
선)
· 괄호로 이어지는 키워드 뒤에는 공백이 하나 있고, 함수 사이에는 공백이 없습니다.
이름과 다음 괄호
· 조건문에서 할당을 피해야 하지만 불가피한 경우에는 추가 괄호를 사용하십시오. 예:
"만약 (a && (b = c)) ..."
· "return(foo);"보다는 "return foo;"를 사용하세요.
· "if (foo == FALSE) ..." 등보다는 "if (!foo) ..."가 더 좋습니다.
· "register"를 사용하여 변수를 선언하지 마세요. 최신 버전에서는 역효과가 있을 수 있습니다.
컴파일러이며 C++에서는 더 이상 사용되지 않으며 Perl 소스는 정기적으로 사용됩니다.
컴파일.
· XS 코드에서 액세스할 수 있는 헤더에 있는 인라인 함수는 다음을 수행할 수 있어야 합니다.
gcc와 같이 일반적으로 사용되는 추가 컴파일 플래그를 사용하여 경고 없이 컴파일하려면
switch 문에 "default"가 없을 때마다 경고하는 "-Wswitch-default"
이러한 추가 플래그를 사용하는 이유는 합법적인 C 코드에서 잠재적인 문제를 포착하기 위해서입니다.
Perl 애그리게이터, Linux 배포업체 등에서 자주 사용됩니다.
Test 스위트
패치가 코드를 변경하는 경우(문서만 변경하는 것이 아니라) 다음 사항도 수행해야 합니다.
수정하려는 버그를 설명하거나 새로운 버그를 검증하는 하나 이상의 테스트 사례를 포함합니다.
추가하려는 기능입니다. 일반적으로 기존 테스트 파일을 업데이트해야 합니다.
새로운 것을 만드는 것보다.
테스트 모음 추가는 일반적으로 다음 지침을 따라야 합니다(Gurusamy 제공)
사라티[이메일 보호]>):
· 무엇을 테스트하는지 파악하세요. 문서와 소스를 읽어보세요.
· 성공하기보다는 실패하는 경향이 있습니다.
· 결과를 엄격하게 해석하세요.
· 관련 없는 기능을 사용하세요(이렇게 하면 이상한 상호작용이 제거됩니다).
· 비표준 관용어를 사용하세요(그렇지 않으면 TIMTOWTDI를 테스트할 수 없습니다).
· 가능한 한 하드코딩된 테스트 번호를 사용하지 마십시오(EXPECTED/GOT에서 발견됨)
t/op/tie.t는 유지 관리가 훨씬 용이하고, 더 나은 실패 보고서를 제공합니다.
· 테스트가 실패하면 의미 있는 오류 메시지를 제공합니다.
· qx// 및 체계() 테스트하지 않는 한. 테스트하는 경우 사용한다면
모든 Perl 플랫폼을 다룰 수 있는지 확인하세요.
· 임시로 만든 파일의 연결을 해제하세요.
· 예상치 못한 경고를 $SIG{__WARN__}을 사용하여 오류로 승격합니다.
· 테스트 중인 버전과 함께 제공되는 라이브러리 및 모듈을 사용하십시오.
이미 설치된 것들.
· 테스트하려는 내용을 설명하는 주석을 코드에 추가합니다.
· '1..42' 문자열을 업데이트할 필요가 없도록 하세요. 또는 직접 업데이트하세요.
· 주어진 연산자, 라이브러리 또는 함수의 _모든_ 동작을 테스트합니다.
모든 선택적 인수를 테스트합니다.
다양한 컨텍스트(부울, 스칼라, 리스트, lvalue)에서 반환 값을 테스트합니다.
전역 변수와 어휘 변수를 모두 사용하세요.
예외적이고 병적인 경우도 잊지 마세요.
패치 a core 모듈
이 작업은 다른 작업을 패치하는 것과 마찬가지지만, 한 가지 고려해야 할 사항이 있습니다.
모듈 C팬/ 소스 트리의 디렉토리는 Perl 코어 외부에서 유지 관리됩니다.
작성자가 모듈을 업데이트하면 업데이트 내용이 코어에 복사됩니다.
모듈 설명서 또는 해당 목록http://search.cpan.org/> 자세한 내용은
버그 보고 및 패치 제출.
대부분의 경우, 모듈에 대한 패치는 C팬/ 상류로 보내야 하며, 보내서는 안 됩니다.
Perl 코어에 개별적으로 적용됩니다. 파일에 대한 패치가 C팬/ 절대 할 수 없어
수정 사항이 업스트림에 적용되어 CPAN에 릴리스되고 blead에 복사될 때까지 기다려야 합니다.
(또는 업데이트) "사용자 정의" 항목 "포팅/유지관리자.pl" 로컬을 플래그로 지정하는 파일
수정되었습니다. 참조하세요 "포팅/유지관리자.pl" 자세한 내용은.
이와 대조적으로, 모듈은 dist / 디렉토리는 코어에서 유지 관리됩니다.
업데이트 펄델타
보증할 만큼 중요한 변경 사항의 경우 포드/perl델타.포드 입구, 짐꾼들은
실제 변경 사항과 함께 델타 항목을 제출해 주시면 감사하겠습니다.
중요한 변경 사항은 다음을 포함하되 이에 국한되지 않습니다.
· 핵심 기능 추가, 폐기 또는 제거
· 핵심 또는 듀얼 라이프 모듈 추가, 사용 중단, 제거 또는 업그레이드
· 새로운 핵심 테스트 추가
· 핵심의 보안 문제 및 사용자에게 보이는 버그 수정
· Perl 또는 C 수준에서 기존 코드를 손상시킬 수 있는 변경 사항
· 상당한 성능 개선
· 문서 추가, 제거 또는 중대한 변경 현물 상환 지불/ 예배 규칙서
· 플랫폼별 중요 변경 사항
perldelta 항목을 올바른 섹션에 추가했는지 확인하세요.
포드/perl델타.포드. 좋은 perldelta 항목을 작성하는 방법에 대한 자세한 내용은 다음과 같습니다.
"스타일" 섹션에서 perldelta.pod 포팅/작성 방법.
뭐 브랜드 을 통한 a 좋은 반점?
언어의 새로운 기능과 확장 기능은 논쟁의 여지가 있습니다. 구체적인 설정은 없습니다.
추가되는 기능을 결정하는 기준이 있지만 여기에는 몇 가지 질문이 있습니다.
패치를 개발할 때 고려해야 할 사항:
가요 전에, 개념 일치 전에, 일반 목표 of 펄?
당사의 목표는 다음을 포함하지만 이에 국한되지 않습니다.
1. 빠르고, 간단하고, 유용하게 만들어라.
2. 기능/개념을 가능한 한 직교적으로 유지하세요.
3. 임의의 제한(플랫폼, 데이터 크기, 문화)이 없습니다.
4. Perl을 어디서나 사용하고, 패치하고, 옹호할 수 있도록 개방적이고 흥미로운 환경을 유지하세요.
5. 새로운 기술을 흡수하거나 새로운 기술로의 교량을 건설하세요.
어디에 is 전에, 구현?
세상의 모든 이야기는 실행 없이는 무의미합니다. 거의 모든 경우에,
새로운 기능을 주장하는 사람이나 사람들은 이를 구현하는 사람이 될 것으로 예상됩니다.
새로운 기능을 코딩할 수 있는 포터는 자신의 의제를 가지고 있으며 사용할 수 없습니다.
(아마도 좋은) 아이디어를 구현하는 것입니다.
뒤로 호환성
기존 Perl 프로그램을 손상시키는 것은 중대한 죄입니다. 새로운 경고는 다음과 같습니다.
논쟁의 여지가 있습니다. 일부는 경고를 내보내는 프로그램이 고장난 것이 아니라고 말하는 반면, 다른 사람들은
그렇습니다. 키워드를 추가하면 프로그램이 중단되어 의미가 변경될 수 있습니다.
기존 토큰 시퀀스나 함수가 프로그램을 손상시킬 수 있습니다.
Perl 5 코어에는 포터가 이전 버전과 호환되지 않는 변경 사항을 만드는 데 도움이 되는 메커니즘이 포함되어 있습니다.
기능 및 지원 중단 모듈과 같은 호환성이 더 높습니다. 이 모듈들을 사용하세요.
적당한.
수 it be a 모듈 대신에?
Perl 5에는 확장 메커니즘, 모듈 및 XS가 있어 특히 유지 관리가 필요하지 않습니다.
Perl 인터프리터를 변경합니다. 함수를 내보내는 모듈을 작성하고
이러한 함수 프로토타입을 사용하면 내장 함수처럼 호출할 수도 있습니다.
Perl 인터프리터의 런타임 데이터 구조를 엉망으로 만들기 위해 XS 코드를 작성하세요.
정말 복잡한 것을 구현하는 거죠.
가능한 경우 새로운 기능은 CPAN 모듈에서 프로토타입으로 제작되어야 합니다.
핵심으로 간주됨.
Is 전에, 기능 일반적인 충분히?
이것은 제출자가 언어에 추가하기를 원하는 것일 뿐인가요, 아니면 광범위하게
유용할까요? 때로는 집중적인 기능을 추가하는 대신 포터가
누군가가 보다 일반화된 기능을 구현할 때까지 기다리기로 결정했습니다.
가요 it 잠재적으로 소개 버그?
Perl 인터프리터의 큰 부분을 근본적으로 다시 작성하면 다음과 같은 문제가 발생할 가능성이 있습니다.
새로운 버그.
방법 큰 is 이것?
변화가 작고 지역적일수록 더 좋습니다. 마찬가지로 일련의 작은
하나의 큰 패치보다 패치를 여러 개 사용하는 것이 훨씬 더 좋습니다.
가요 it 배제하다 기타 바람직한 풍모?
향후 개발 경로를 차단하는 패치는 거부될 가능성이 높습니다.
예를 들어, 프로토타입에 대한 정확하고 최종적인 해석을 적용한 패치는 다음과 같습니다.
아직 개발되지 않은 프로토타입의 미래 옵션이 남아 있기 때문에 거부될 수 있습니다.
해결됨.
Is 전에, 이행 건장한?
좋은 패치(단단한 코드, 완전성, 정확성)는 들어갈 가능성이 더 높습니다. 엉성하거나
잘못된 패치는 호박이 고칠 시간이 있을 때까지 뒷전으로 미뤄질 수 있습니다.
또는 별도의 통지 없이 완전히 삭제될 수 있습니다.
Is 전에, 이행 일반적인 충분히 에 be 가지고 다닐 수 있는?
최악의 패치는 시스템 특정 기능을 사용합니다.
Perl 언어에 대한 이식 가능한 추가 기능은 허용됩니다.
Is 전에, 이행 테스트했어요?
동작을 변경하는 패치(버그 수정 또는 새로운 기능 도입)에는 다음이 포함되어야 합니다.
모든 것이 예상대로 작동하는지 확인하기 위한 회귀 테스트.
원래 작성자가 제공한 테스트 없이 다른 사람이 Perl을 어떻게 변경할 수 있습니까?
앞으로 그들이 무의식적으로 패치가 구현하는 동작을 망가뜨리지 않았는지 확인할 수 있을까요?
테스트 없이 패치 작성자는 자신이 열심히 노력한 결과가 패치에 반영되었다고 어떻게 확신할 수 있습니까?
나중에 누군가가 실수로 패치를 버리는 일이 없을까요?
Is 가 충분히 선적 서류 비치?
문서가 없는 패치는 아마도 제대로 생각되지 않았거나 불완전할 것입니다. 어떤 기능도
문서화 없이 추가되거나 변경될 수 있으므로 적절한 Pod에 대한 패치를 제출합니다.
문서와 소스 코드 모두 중요합니다.
Is 가 다른 방법 에 do 이것?
Larry는 "Perl 슬로건은 저기있다. 더 보기 보다 한 방법 에 Do It, 나는 주저한다
무언가를 하는 10가지 방법을 생각해 보세요. 이것은 탐색하기 까다로운 휴리스틱이지만 한 사람의
필수적인 추가 사항은 다른 사람의 무의미한 찌꺼기입니다.
가요 it 만들 너무 많은 일하세요?
호박을 위한 일, Perl 프로그래머를 위한 일, 모듈 작성자를 위한 일, ... Perl은
쉬운 것으로 여겨졌는데.
패치 말하다 크게 보다 말
허황된 아이디어보다는 작동하는 코드가 항상 더 좋습니다. 기능을 추가하는 패치가 필요합니다.
무작위 기능 요청보다 언어로 구현할 가능성이 훨씬 더 높습니다.
요청이 아무리 열렬하게 주장되더라도 말입니다. 이는 "유용할까요?"와 관련이 있습니다.
누군가가 패치를 만드는 데 시간을 들였다는 사실은 그것에 대한 강한 열망을 보여줍니다.
기능.
테스트
코어는 Perl의 나머지 부분과 동일한 테스트 스타일을 사용합니다. 간단한 "ok/not ok" 실행입니다.
Test::Harness와 유사하지만 몇 가지 특별한 고려 사항이 있습니다.
코어에서 테스트를 작성하는 방법은 세 가지가 있습니다: Test::More, t/test.pl 그리고 임시 "인쇄
$test ? "ok 42\n" : "not ok 42\n"". 어떤 것을 사용할지는 $test의 어떤 부분에 따라 달라집니다.
작업 중인 테스트 모음입니다. 이는 고수준 실패(예:
Config.pm이 손상되어 기본 기능 테스트가 실패하는 일이 없어졌습니다.
The t/test.pl 라이브러리는 Test::More의 일부 기능을 제공하지만 대부분의 기능을 로드하지 않습니다.
모듈을 사용하고 가능한 한 핵심 기능을 적게 사용합니다.
자신의 테스트를 작성하는 경우 Test Anything Protocol을 사용하세요.http://testanything.org>.
· t/베이스, t/comp 그리고 t/옵베이직
"require"가 작동하는지, 심지어 서브루틴이 작동하는지 알 수 없으므로 임시 테스트를 사용하십시오.
이 세 가지. 테스트 중인 기능을 사용하지 않도록 주의하세요. 테스트
t/옵베이직예를 들어, 거기에 배치된 것이 아니라 맨 위 왜냐하면 그들은 테스트하기 때문이다
기능이 있는 t/test.pl 이미 효과가 입증되었다고 추정합니다.
· 티/cmd, t/런, t/io 그리고 맨 위
이제 기본 require () 그리고 서브루틴이 테스트되면 다음을 사용할 수 있습니다. t/test.pl
도서관.
Config와 같은 특정 라이브러리를 조건부로 사용할 수도 있지만 다음을 건너뛰어야 합니다.
없으면 정상적으로 테스트해 보세요.
· 기타
이제 Perl의 핵심 기능이 테스트되었으므로 Test::More를 사용할 수 있으며, 사용해야 합니다. 또한
테스트에서 핵심 모듈의 전체 세트를 사용합니다.
"make test"라고 말할 때 Perl은 다음을 사용합니다. t/테스트 테스트 모음을 실행하는 프로그램(다음을 제외하고)
Win32에서 사용하는 곳 t/하네스 대신). 모든 테스트는 다음에서 실행됩니다. t/ 예배 규칙서, 지원 전에,
테스트가 포함된 디렉토리입니다. 이로 인해 테스트에 몇 가지 문제가 발생합니다. lib /그래서
패치를 적용할 수 있는 기회가 생겼습니다.
크로스 플랫폼 관련 문제를 세 배로 인식해야 합니다. 이는 일반적으로 다음을 사용하는 것으로 귀결됩니다.
File::Spec, 절대적으로 필요하지 않은 한 "fork()" 및 "system()"과 같은 항목을 피하고
주어진 문자가 특정 순서 값(코드 포인트)을 가지고 있다고 가정하지 않습니다.
UTF-8 표현은 특정 바이트로 구성됩니다.
문자와 코드 포인트를 이식 가능하게 지정하는 데 사용할 수 있는 여러 가지 기능이 있습니다.
테스트. 항상 미리 로드되는 함수 "utf8::unicode_to_native()"와 그 역함수
"utf8::native_to_unicode()"는 코드 포인트를 받아서 적절히 변환합니다. 파일
t/charset_tools.pl 여러 가지 유용한 기능이 있습니다. 다음 버전이 있습니다.
문자열을 입력으로 받는 이전 두 함수(단일 숫자 코드 포인트가 아님):
"uni_to_native()"와 "native_to_uni()". 개별 바이트를 확인해야 하는 경우
UTF-8로 인코딩된 문자열을 포함하는 "byte_utf8a_to_utf8n()"은 다음 문자열을 입력으로 받습니다.
ASCII 플랫폼에 대해 인코딩된 바이트를 반환하고 네이티브에서 동일한 문자열을 반환합니다.
플랫폼. 예를 들어, "byte_utf8a_to_utf8n("\xC2\xA0")"은 다음 바이트 시퀀스를 반환합니다.
"U+8A00"에 대한 UTF-0을 형성하는 현재 플랫폼은 "\xC2\xA0"이 UTF-8 바이트이기 때문입니다.
해당 코드 포인트에 대한 ASCII 플랫폼입니다. 이 함수는 ASCII 플랫폼에서 "\xC2\xA0"을 반환합니다.
플랫폼 및 EBCDIC 80 플랫폼의 "\x41\x1047".
그러나 가장 쉬운 방법은 "A" 또는 "%"와 같이 문자가 리터럴로 지정 가능한 경우 사용하는 것입니다.
그렇게 구체적으로 지정하지 않으면 부작용이 없다면 "\N{}"를 사용할 수 있습니다.
번거롭습니다. "\N{U+ZZ}" 대신 모든 문자를 16진수로 지정하기만 하면 됩니다.
"\xZZ". "\N{}"은 유니코드 이름이므로 항상 유니코드 문자가 제공됩니다.
"\N{U+41}"은 유니코드 코드 포인트가 0x41인 문자이므로 모든 문자에서 'A'입니다.
플랫폼. 부작용은 다음과 같습니다.
1) 이는 유니코드 규칙을 선택합니다. 즉, 큰따옴표로 묶인 문자열에서는 문자열이
항상 유니코드 해석을 강제하기 위해 UTF-8로 변환됩니다.
가능하다면 나중에 "utf8::downgrade()"를 실행하여 UTF8이 아닌 형식으로 다시 변환합니다.
표현 패턴의 경우 변환은 수행되지 않지만 문자 집합 수정자가 있는 경우
그렇지 않으면 "/d"가 되어야 하는데, "/u"로 변경됩니다.
2) "\N{ 형식을 사용하는 경우문자 이름}", charnames 모듈은 자동으로
로드되었습니다. 현재 진행 중인 시험 수준에는 적합하지 않을 수 있습니다.
로케일을 테스트하는 경우(perllocale 참조) 다음과 같은 도우미 함수가 있습니다. t/loc_tools.pl
현재 플랫폼에 어떤 로케일이 있는지 확인할 수 있습니다.
이달의 스페셜 "만들다 시험" 목표
Perl을 약간 다르게 테스트하는 데 사용할 수 있는 다양한 특수 타겟이 있습니다.
표준 "테스트" 목표보다 더 중요합니다. 모든 목표가 100% 성공률을 보장하는 것은 아닙니다.
이들 중 다수는 여러 별칭을 가지고 있으며, 이들 중 다수는 특정 운영 체제에서는 사용할 수 없습니다.
시스템.
· 테스트 포팅
이는 소스 트리에서 몇 가지 기본적인 정신 건강 테스트를 실행하고 기본 오류를 포착하는 데 도움이 됩니다.
패치를 제출하기 전에.
· 미니테스트
달리기 미니펄 on t/베이스, t/comp, 티/cmd, t/런, t/io, 맨 위, 티셔츠/유니 그리고 티/엠로 테스트.
· 테스트.valgrind 확인.valgrind
(Linux에서만) 메모리 누수 + 잘못된 메모리 액세스 도구를 사용하여 모든 테스트를 실행합니다.
"valgrind". 로그 파일의 이름은 다음과 같습니다. 테스트 이름.valgrind.
· 테스트_하네스
테스트 모음을 실행하세요 t/하네스 제어 프로그램 대신 t/테스트.
t/하네스 더 정교하고 Test::Harness 모듈을 사용하므로 이것을 사용합니다.
테스트 대상은 Perl이 대부분 작동한다고 가정합니다. 우리 목적에 가장 큰 장점은 다음과 같습니다.
실패한 테스트에 대한 자세한 요약을 마지막에 인쇄한다는 점입니다. 또한, t/테스트, 그
stderr을 stdout으로 리디렉션하지 않습니다.
Win32에서는 다음을 참고하세요. t/하네스 항상 대신 사용됩니다 t/테스트, 그래서 없다
특별한 "test_harness" 타겟.
Win32의 "테스트" 대상에서 TEST_SWITCHES 및 TEST_FILES 환경을 사용할 수 있습니다.
행동을 제어하는 변수 t/하네스. 이것은 당신이 말할 수 있다는 것을 의미합니다
nmake 테스트 TEST_FILES="op/*.t"
nmake 테스트 TEST_SWITCHES="-torture" TEST_FILES="op/*.t"
· 테스트-노티 테스트_노티
일반 테스트를 실행하기 전에 PERL_SKIP_TTY_TEST를 true로 설정합니다.
평행 테스트
핵심 배포판은 이제 Unix와 유사한 플랫폼에서 회귀 테스트를 병렬로 실행할 수 있습니다.
"make test"를 실행하는 대신 환경에서 "TEST_JOBS"를 테스트 수로 설정합니다.
병렬로 실행하고 "make test_harness"를 실행합니다. Bourne과 같은 쉘에서 이 작업을 수행할 수 있습니다.
as
TEST_JOBS=3 make test_harness # 3개의 테스트를 병렬로 실행
TAP::Harness 때문에 자체 병렬화 대신 환경 변수가 사용됩니다.
충돌하지 않는 개별 테스트 스크립트 자체를 예약할 수 있어야 하며
작업 스케줄러와 상호 작용하기 위해 유틸리티를 "만들기" 위한 표준 인터페이스가 없습니다.
현재 일부 테스트 스크립트는 병렬로 실행할 때 실패할 수 있습니다.
ext/IO/t/io_dir.t). 필요한 경우 실패한 스크립트만 순차적으로 다시 실행하고 다음을 확인하세요.
실패가 사라지면.
달리는 테스트 by 손
다음 명령 중 하나를 사용하여 테스트 모음의 일부를 수동으로 실행할 수 있습니다.
t/ 예배 규칙서:
./perl -I../ lib 테스트 목록 .t 파일
or
./perl -I../ lib 하네스 목록-.t-파일
(테스트 스크립트를 지정하지 않으면 전체 테스트 모음이 실행됩니다.)
사용 t/하네스 을 통한 테스트
테스트용으로 "하네스"를 사용하면 여러 가지 명령줄 옵션을 사용할 수 있습니다.
인수는 다음과 같으며, 함께 사용될 경우 나타나야 하는 순서대로 나열되어 있습니다.
테스트할 파일 목록
패턴 일치 목록
"테스트할 파일 목록"을 생략하면 매니페스트에서 파일 목록을 가져옵니다.
파일 목록에는 확장될 셸 와일드카드가 포함될 수 있습니다.
· -V
자세한 모드에서 테스트를 실행하면 어떤 테스트가 실행되었는지, 그리고 출력을 디버깅하는 방법을 볼 수 있습니다.
· -고문
일반적인 테스트와 마찬가지로 고문 테스트도 실행해 보세요.
· -re=패턴
모든 테스트 파일이 패턴과 일치하도록 파일 목록을 필터링합니다.
형태는 다음과 다릅니다 -레 LIST OF 패턴 아래 형식은 파일을 허용합니다.
목록도 제공될 예정입니다.
· -re 패턴 목록
모든 테스트 파일이 /(LIST|OF|PATTERNS)와 일치하도록 파일 목록을 필터링합니다./. 주의 사항
이 양식에서는 패턴이 '|'로 연결되고 목록을 제공할 수 없습니다.
파일 대신 테스트 파일은 MANIFEST에서 가져옵니다.
다음과 유사한 명령을 사용하여 개별 테스트를 실행할 수 있습니다.
./perl -I../ lib 경로/to/foo.t
단, 하네스는 실행에 영향을 줄 수 있는 일부 환경 변수를 설정합니다.
테스트의:
· 펄_코어=1
이 테스트가 Perl 코어 테스트 모음의 일부로 실행되고 있음을 나타냅니다.
CPAN에서 이중 수명을 갖는 모듈에 유용합니다.
· PERL 파괴 레벨=2
아직 설정되지 않았다면 2로 설정됩니다(perlhacktips의 "PERL_DESTRUCT_LEVEL" 참조).
· 펄
(사용만 가능 t/테스트) 설정된 경우 perl 실행 파일의 경로를 재정의합니다.
테스트를 실행하는 데 사용됩니다(기본값은 다음과 같습니다. ./perl).
· PERL_SKIP_TTY_테스트
설정된 경우, 터미널이 필요한 테스트를 건너뛰도록 합니다. 실제로는 자동으로 설정됩니다.
Makefile로 설정할 수도 있지만, 'make test_notty'를 실행하여 인위적으로 강제할 수도 있습니다.
기타 환경 변수 그 ５월 영향 테스트
· PERL_TEST_Net_Ping
이 변수를 설정하면 모든 Net::Ping 모듈 테스트가 실행되고 그렇지 않으면 일부 테스트가 실행됩니다.
외부 세계와의 상호 작용은 생략됩니다. perl58delta를 참조하세요.
· PERL_TEST_NOVREXX
이 변수를 설정하면 OS2::REXX에 대한 vrexx.t 테스트가 건너뜁니다.
· PERL 테스트 변환수
이는 op/numconvert.t에 변수를 설정합니다.
· PERL 테스트 메모리
이 변수를 설정하면 테스트가 포함됩니다. t/빅멤/. 이것은 다음으로 설정되어야 합니다.
테스트에 사용할 수 있는 메모리 용량(기가바이트) 예: "PERL_TEST_MEMORY=4"
4GiB의 사용 가능한 메모리가 필요한 테스트를 안전하게 실행할 수 있음을 나타냅니다.
자세한 환경 정보는 Test 및 Test::Harness 모듈에 대한 설명서도 참조하세요.
테스트에 영향을 미치는 변수.
성능 테스트
파일 t/perf/벤치마크 의도된 Perl 코드 조각이 포함되어 있습니다.
다양한 펄에 대해 벤치마킹됨 포팅/bench.pl 도구입니다. 수정하거나 향상시키면
성능 문제가 있는 경우 파일에 대표 코드 샘플을 추가한 다음 실행할 수 있습니다.
벤치.pl 이전 및 현재 펄과 비교하여 어떤 차이가 있는지 확인하고,
그 결과로 다른 것이 느려졌는지 여부.
파일 t/perf/opcount.t 특정 코드 조각이 테스트되었는지 확인하기 위해 설계되었습니다.
특정 op 유형을 지정된 개수만큼 포함하는 optree로 컴파일됩니다. 좋습니다.
"aelem" op를 변환하는 것과 같이 op를 변경하는 최적화가 있는지 테스트하기 위해
"aelemfast" 작전은 실제로 그런 일을 하고 있습니다.
파일들 t/perf/speed.t 그리고 t/re/speed.t 수천 개의 항목을 테스트하도록 설계되었습니다.
특정 최적화가 중단되면(예: utf8 길이 캐시) 몇 배 더 느려집니다.
긴 utf8 문자열의 경우). 일반적으로 몇 분의 XNUMX초가 걸리는 테스트를 추가하고
그렇지 않으면 테스트 파일이 실패로 인해 시간 초과됩니다.
추가 독서 위한 GUTS 해커
Perl의 내부를 해킹하려면 다음 내용을 읽어야 합니다.
· 펄소스
Perl 소스 트리 개요입니다. 원하는 파일을 찾는 데 도움이 될 것입니다.
에 대한.
· 펄린터프
Perl 인터프리터 소스 코드 개요 및 Perl이 어떤 작업을 수행하는지에 대한 세부 정보
그렇습니다.
· 펄핵터트
이 문서는 Perl C 코드에 작은 패치를 만드는 방법을 안내합니다.
Perl 코어 해킹을 막 시작하려는 사람이라면 이것이 어떻게 작동하는지 이해하는 데 도움이 될 것입니다.
작동합니다.
· 펄핵팁
Perl 코어 해킹에 대한 자세한 내용입니다. 이 문서는 하위 수준의 세부 사항에 중점을 둡니다.
예를 들어, 테스트를 작성하는 방법, 컴파일 문제, 이식성, 디버깅 등입니다.
진지하게 C 해킹을 할 계획이라면, 이 글을 꼭 읽어보세요.
· 펄구츠
이것은 무엇이 어디에 들어가는지 문서화하는 것이기 때문에 매우 중요합니다.
Perl 소스입니다. 몇 번 읽어보시면 이해가 되실 겁니다.
아직 그렇지 않더라도 걱정하지 마세요. 공부하는 가장 좋은 방법은 읽는 것입니다.
Perl 소스를 찔러보는 것과 관련이 있는데, 이 부분은 나중에 설명하겠습니다.
Gisle Aas의 "그림이 있는 펄구트"는 다음과 같이 알려져 있습니다. 일장춘몽, 매우 유용한 사진이 있습니다:
<http://search.cpan.org/dist/illguts/>
· 펄렉스스터트와 펄렉스스
XSUB 프로그래밍에 대한 실무 지식은 핵심 해킹에 매우 유용합니다.
PP 코드에서 가져온 기술을 사용합니다. 이는 실제로 실행되는 핵심 부분입니다.
Perl 프로그램. 간단한 예제를 통해 이러한 기술을 배우는 것이 훨씬 더 쉽습니다.
핵심 자체보다 설명이 더 중요합니다.
· 펄라피
Perl API에 대한 설명서에서는 일부 내부 함수가 수행하는 작업을 설명합니다.
소스에 사용된 다양한 매크로도 마찬가지입니다.
· 포팅/pumpkin.pod
이것은 Perl 포터를 위한 지혜의 말씀 모음입니다. 그 중 일부는 유용합니다.
호박 홀더에 대한 내용이지만 대부분은 Perl을 사용하고자 하는 모든 사람에게 적용됩니다.
개발.
CPAN 테스터 및 펄 스모커
CPAN 테스터( http://testers.cpan.org/ )는 CPAN을 테스트하는 자원봉사자 그룹입니다.
다양한 플랫폼의 모듈.
펄 스모커( http://www.nntp.perl.org/group/perl.daily-build/ 그리고
http://www.nntp.perl.org/group/perl.daily-build.reports/ ) Perl 소스를 자동으로 테스트합니다
다양한 구성을 갖춘 플랫폼에서 출시됩니다.
두 가지 활동 모두 자원봉사자를 환영합니다. 펄의 스모크 테스트에 참여하려면
그 자체 방문http://search.cpan.org/dist/Test-Smoke/>. 연기 테스트를 시작하려면
CPAN 모듈 방문http://search.cpan.org/dist/CPANPLUS-YACSmoke/> 또는
<http://search.cpan.org/dist/minismokebox/> 또는
<http://search.cpan.org/dist/CPAN-Reporter/>.
WHAT 다음?
문서에 있는 모든 문서와 위에 나열된 문서를 읽었다면
Perl을 해킹할 준비가 되었습니다.
몇 가지 추가 권장 사항은 다음과 같습니다.
· perl5-porters를 구독하고 패치를 따르고 이해하려고 노력하십시오.
당신이 명확히 알지 못하는 부분이 있다면 묻는 것을 두려워합니다. 누가 알겠습니까? 당신은 그것을 발굴할 수도 있습니다.
패치에 버그가 있어요...
· 운영 체제와 관련된 README(예: IBM의 README.aix)를 읽어보세요.
AIX OS. 누락된 부분이 있으면 해당 README에 대한 패치를 제공해 주시기 바랍니다.
또는 새로운 OS 릴리스로 변경되었습니다.
· 귀하에게 흥미로운 Perl 영역을 찾아 그것이 어떻게 작동하는지 확인하십시오.
작동합니다. 소스를 스캔하고 디버거에서 단계별로 실행해 보세요. 재생하고, 찔러보고,
조사해 봐, 엉뚱하게! 넌 아마 네가 선택한 지역뿐만 아니라
훨씬 더 넓은 범위 펄의 활동도 마찬가지이며, 아마도 여러분이 생각하는 것보다 더 빨리 일어날 것입니다.
" 도로 간다 적 on 그리고 하나이고, 아래 (down) 에 전에, 문 어디에 it 시작했다."
이러한 것들을 할 수 있다면 Perl 포팅을 향한 긴 여정을 시작한 것입니다. 감사합니다.
Perl을 더 좋게 만드는 데 기여하고 싶습니다. 해킹을 즐기세요!
은유적 견적
위의 도로에 대한 인용문을 알아보셨다면 운이 좋으신 겁니다.
대부분의 소프트웨어 프로젝트는 각 파일의 목적을 문자 그대로 설명하는 것으로 시작합니다.
Perl은 대신 각 파일의 목적에 대한 문학적 암시로 시작합니다.
많은 책의 장과 마찬가지로 모든 최상위 Perl 소스 파일(여기에 있는 몇 가지 다른 파일 포함)
그리고 거기) 간접적으로 암시하는 비문으로 시작합니다.
비유적으로 말해서, 당신이 읽으려고 하는 내용에 대한 것입니다.
인용문은 JRR Tolkien의 Legendarium과 관련된 글에서 발췌한 것입니다.
항상 ~로부터 The 지배자 of 전에, 반지. 장과 페이지 번호는 다음을 사용하여 제공됩니다.
다음 에디션:
· The 호빗JRR 톨킨의 작품입니다. 70년 하드커버 2007주년 기념판은
영국에서는 Harper Collins Publishers에서, 미국에서는 Houghton에서 출판되었습니다.
미플린 회사.
· The 지배자 of 전에, 반지JRR 톨킨의 50주년 기념 하드커버 에디션
2004년판은 영국에서는 Harper Collins Publishers에서, 미국에서는
호튼 미플린 회사.
· The 낳는다 of 벨레리안드JRR Tolkien이 쓴 책으로 그의 아들이 사후에 출판했습니다.
문학적 집행자 CJR Tolkien은 Christopher의 3권 중 12번째 권입니다.
거대한 연혁 of 중간 지구. 페이지 번호는 하드커버 버전에서 파생되었습니다.
1983년 George Allen & Unwin에서 처음 출판되었습니다. 페이지 번호는 변경되지 않았습니다.
3년 특별 2002권 옴니버스 에디션 또는 다양한 무역지 에디션, 모두
이제 다시 하퍼 콜린스나 호튼 미플린이 출시되었습니다.
따라서 인용을 위한 다른 JRRT 도서 박람회 게임에는 다음이 포함됩니다. The 모험 of 남자 이름 봄바딜,
The 실마릴리온, 미완성 이야기및 The 이야기 of 전에, 어린이 of 후린, 그러나 모두
CJRT가 사후에 처음으로 조립했습니다. 하지만 The 지배자 of 전에, 반지 그 자체로는 완벽히 괜찮습니다
적절한 견적을 찾을 수 있다면, 그 곳에서 견적을 받는 것이 가장 좋을 것입니다.
따라서 Perl에 추가할 새롭고 완전한 최상위 소스 파일을 제공하려면 다음을 수행해야 합니다.
적절한 인용문을 직접 선택하여 이 특이한 관행을 준수하십시오.
톨킨은 원래의 철자와 구두점을 유지하고 동일한 형식을 사용했습니다.
나머지 인용문은 그대로입니다. 간접적이고 비스듬한 표현도 괜찮습니다. 이것은 은유라는 점을 기억하세요.
그러니 결국 메타가 되는 게 그 목적이겠죠.
onworks.net 서비스를 사용하여 온라인으로 perlhack을 사용하세요
