perlhack - ออนไลน์ในคลาวด์

โครงการ:

ชื่อ

perlhack - วิธีแฮ็คบน Perl

DESCRIPTION

เอกสารนี้อธิบายวิธีการทำงานของการพัฒนา Perl ประกอบด้วยรายละเอียดเกี่ยวกับ Perl 5
รายชื่ออีเมลของ Porters, ที่เก็บ Perl, ตัวติดตามจุดบกพร่อง Perlbug, แนวทางแก้ไข และ
ความเห็นเกี่ยวกับปรัชญาการพัฒนา Perl

SUPER QUICK ปะ GUIDE

หากคุณต้องการส่งแพตช์เล็กๆ ตัวเดียว เช่น การแก้ไขพ็อด การทดสอบจุดบกพร่อง แสดงความคิดเห็น
แก้ไข ฯลฯ ง่ายนิดเดียว! โดยใช้วิธีดังนี้:

· ตรวจสอบที่เก็บซอร์ส

แหล่งที่มาของ Perl อยู่ในที่เก็บ git คุณสามารถโคลนที่เก็บด้วย
คำสั่งต่อไปนี้:

% git โคลน git://perl5.git.perl.org/perl.git perl

·ให้แน่ใจว่าคุณปฏิบัติตามคำแนะนำล่าสุด

ในกรณีที่คำแนะนำในคู่มือนี้ได้รับการปรับปรุงเมื่อเร็ว ๆ นี้ โปรดอ่านเวอร์ชันล่าสุด
โดยตรงจากแหล่ง Perl:

% พ็อด perldoc/perlhack.pod

· ทำการเปลี่ยนแปลงของคุณ

แฮก แฮก แฮก. โปรดทราบว่า Perl ทำงานบนหลายแพลตฟอร์มด้วย
ระบบปฏิบัติการต่างๆ ที่มีความสามารถต่างกัน ระบบไฟล์ต่างกัน
องค์กรและแม้กระทั่งชุดอักขระที่แตกต่างกัน perlhacktips ให้คำแนะนำในเรื่องนี้

·ทดสอบการเปลี่ยนแปลงของคุณ

คุณสามารถรันการทดสอบทั้งหมดด้วยคำสั่งต่อไปนี้:

% ./Configure -des -Dusevel
% ทำแบบทดสอบ

แฮ็คต่อไปจนกว่าการทดสอบจะผ่าน

·ยอมรับการเปลี่ยนแปลงของคุณ

ความมุ่งมั่นในการทำงานของคุณจะบันทึกการเปลี่ยนแปลง on ธุรกิจ ในประเทศ ระบบ:

% git commit -a -m 'Commit message ไปที่นี่'

ตรวจสอบให้แน่ใจว่าข้อความยืนยันอธิบายการเปลี่ยนแปลงของคุณในประโยคเดียว ตัวอย่างเช่น,
"แก้ไขข้อผิดพลาดในการสะกดคำใน perlhack.pod"

· ส่งการเปลี่ยนแปลงของคุณไปที่ perlbug

ขั้นตอนต่อไปคือการส่งแพตช์ของคุณไปยังระบบตั๋ว Perl core ทางอีเมล

หากการเปลี่ยนแปลงของคุณอยู่ในคอมมิต git เดียว ให้รันคำสั่งต่อไปนี้เพื่อสร้าง
แก้ไขไฟล์และแนบไปกับรายงานข้อบกพร่องของคุณ:

% รูปแบบ git-patch -1
% ./perl -Ilib utils/perlbug -p 0001-*.patch

โปรแกรม perlbug จะถามคำถามสองสามข้อเกี่ยวกับที่อยู่อีเมลของคุณและ
โปรแกรมแก้ไขที่คุณกำลังส่ง เมื่อคุณตอบคำถามแล้ว จะส่งแพตช์ของคุณผ่านทาง
ส่งอีเมล์

หากการเปลี่ยนแปลงของคุณอยู่ในการคอมมิตหลายครั้ง ให้สร้างไฟล์แพตช์สำหรับแต่ละอันและ
ระบุตัวเลือก "-p" ของ perlbug โดยคั่นด้วยเครื่องหมายจุลภาค:

% รูปแบบ git-patch -3
% ./perl -Ilib utils/perlbug -p 0001-fix1.patch,0002-fix2.patch,\
> 0003-fix3.patch

เมื่อได้รับแจ้ง ให้เลือกหัวข้อที่สรุปการเปลี่ยนแปลงของคุณ

· ขอขอบคุณ

พนักงานขนกระเป๋าชื่นชมเวลาที่คุณใช้ช่วยทำให้ Perl ดีขึ้น ขอขอบคุณ!

· คราวหน้า

ครั้งต่อไปที่คุณต้องการสร้างแพตช์ คุณต้องเริ่มจาก Perl ล่าสุดใน a
รัฐที่เก่าแก่ ตรวจสอบว่าคุณไม่มีการเปลี่ยนแปลงในเครื่องหรือไฟล์ที่เพิ่มใน Perl . ของคุณ
เช็คเอาท์ที่คุณต้องการเก็บไว้ จากนั้นรันคำสั่งเหล่านี้:

% คอมไพล์ดึง
% รีเซ็ต git - แหล่งกำเนิดยาก / เลือดออก
% git สะอาด -dxf

BUG รายงาน

หากคุณต้องการรายงานจุดบกพร่องใน Perl คุณต้องใช้ เพิร์ลบั๊ก เครื่องมือบรรทัดคำสั่ง นี้
เครื่องมือจะทำให้แน่ใจว่ารายงานข้อผิดพลาดของคุณรวมถึงระบบและการกำหนดค่าที่เกี่ยวข้องทั้งหมด
ข้อมูล

ในการเรียกดูข้อบกพร่องและแพตช์ของ Perl ที่มีอยู่ คุณสามารถใช้เว็บอินเตอร์เฟสที่
<http://rt.perl.org/>.

โปรดตรวจสอบที่เก็บถาวรของรายการ perl5-porters (ดูด้านล่าง) และ/หรือการติดตามจุดบกพร่อง
ระบบก่อนส่งรายงานข้อผิดพลาด บ่อยครั้งคุณจะพบว่ามีการรายงานจุดบกพร่อง
แล้ว.

คุณสามารถเข้าสู่ระบบติดตามจุดบกพร่องและแสดงความคิดเห็นในรายงานจุดบกพร่องที่มีอยู่ ถ้าคุณ
มีข้อมูลเพิ่มเติมเกี่ยวกับจุดบกพร่องที่มีอยู่ โปรดเพิ่มเข้าไป นี้จะช่วยให้
พนักงานยกกระเป๋าแก้ไขข้อผิดพลาด

PERL 5 พนักงานยกกระเป๋า

รายชื่อผู้รับจดหมาย perl5-porters (p5p) คือที่ที่การกระจายมาตรฐาน Perl ยังคงอยู่
และพัฒนา คนที่ดูแล Perl ก็เรียกอีกอย่างว่า "Perl 5 Porters"
"p5p" หรือเพียงแค่ "ลูกหาบ"

สามารถค้นหาไฟล์เก็บถาวรของรายการได้ที่
<http://markmail.org/search/?q=perl5-porters>. นอกจากนี้ยังมีที่เก็บถาวรที่
<http://archive.develooper.com/perl5-porters@perl.org/>.

perl-การเปลี่ยนแปลง ทางไปรษณีย์ รายการ
รายชื่อส่งเมลการเปลี่ยนแปลง perl5 จะได้รับสำเนาของแพตช์แต่ละรายการที่ส่งไปยัง
สาขาการบำรุงรักษาและการพัฒนาของที่เก็บ Perl ดู
<http://lists.perl.org/list/perl5-changes.html> สำหรับการสมัครและเก็บข้อมูล

#พีทูพี on ไออาร์ซี
พนักงานขนของจำนวนมากยังใช้งานอยู่บน ช่อง. เข้าร่วมได้เลยนะครับ
ช่องทางและถามคำถามเกี่ยวกับการแฮ็คบน Perl core

การเดินทาง DIE PERL แหล่งที่มา

ซอร์สโค้ดของ Perl ทั้งหมดถูกเก็บไว้ที่ส่วนกลางในที่เก็บ Git ที่ perl5.git.perl.org.
พื้นที่เก็บข้อมูลมีการแก้ไข Perl จำนวนมากตั้งแต่ Perl 1 เป็นต้นไปและการแก้ไขทั้งหมดจาก
Perforce ระบบควบคุมเวอร์ชันก่อนหน้า

สำหรับรายละเอียดเพิ่มเติมเกี่ยวกับการใช้ git กับที่เก็บ Perl โปรดดูที่ perlgit

อ่าน เข้า ผ่านทาง ไป
คุณจะต้องมีสำเนาของ Git สำหรับคอมพิวเตอร์ของคุณ คุณสามารถดึงสำเนาของที่เก็บ
ใช้โปรโตคอล git:

% git โคลน git://perl5.git.perl.org/perl.git perl

สิ่งนี้จะโคลนที่เก็บและทำสำเนาในเครื่องใน Perl ไดเรกทอรี

หากคุณไม่สามารถใช้โปรโตคอล git ได้ด้วยเหตุผลของไฟร์วอลล์ คุณสามารถโคลนผ่าน http
แม้ว่าจะช้ากว่ามาก:

% git โคลน http://perl5.git.perl.org/perl.git Perl

อ่าน เข้า ผ่านทาง เว็บ
คุณสามารถเข้าถึงที่เก็บผ่านทางเว็บ นี้ทำให้คุณสามารถเรียกดูต้นไม้ ดู
คอมมิตล่าสุด, สมัครรับฟีด RSS สำหรับการเปลี่ยนแปลง, ค้นหาคอมมิตเฉพาะและ
มากกว่า. เข้าไปได้ที่http://perl5.git.perl.org/perl.git>. กระจกเงาของ
ที่เก็บข้อมูลอยู่ที่ .

อ่าน เข้า ผ่านทาง rsync
คุณยังสามารถเลือกใช้ rsync เพื่อรับสำเนาของแผนผังต้นทางปัจจุบันสำหรับ
bleadperl branch และสาขาการบำรุงรักษาทั้งหมด:

% 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::

เขียน เข้า ผ่านทาง คอมไพล์
หากคุณมีคอมมิตบิต โปรดดูที่ perlgit สำหรับรายละเอียดเพิ่มเติมเกี่ยวกับการใช้ git

แพทช์ PERL

หากคุณกำลังวางแผนที่จะทำงานที่กว้างขวางมากกว่าการแก้ไขปัญหาเล็กๆ น้อยๆ เราขอแนะนำให้คุณ
อ่านเอกสารด้านล่าง สิ่งนี้จะช่วยให้คุณมีสมาธิกับงานและทำแพทช์ของคุณ
ง่ายต่อการรวมเข้ากับแหล่ง Perl

กำลังส่ง แพทช์
หากคุณมีแพตช์เล็ก ๆ ที่จะส่ง โปรดส่งผ่าน perlbug คุณยังสามารถส่ง
ส่งอีเมลโดยตรงถึง [ป้องกันอีเมล]. โปรดทราบว่าข้อความที่ส่งไปยัง perlbug อาจถูกระงับ
ในคิวการกลั่นกรอง ดังนั้นคุณจะไม่ได้รับการตอบกลับทันที

คุณจะรู้ว่าการส่งของคุณได้รับการประมวลผลเมื่อคุณได้รับอีเมลจากตั๋วของเรา
ระบบติดตาม. อีเมลนี้จะให้หมายเลขตั๋วแก่คุณ เมื่อแพทช์ของคุณทำเสร็จแล้ว
ไปยังระบบติดตามตั๋วก็จะถูกส่งไปที่ [ป้องกันอีเมล] รายการ.

แพตช์ได้รับการตรวจสอบและอภิปรายในรายการ p5p แพทช์ที่เรียบง่ายและไม่ขัดแย้งจะ
มักจะนำไปใช้โดยไม่มีการพูดคุยใดๆ เมื่อแพทช์ถูกนำไปใช้ ตั๋วจะเป็น
อัปเดตแล้วคุณจะได้รับอีเมล นอกจากนี้ อีเมลจะถูกส่งไปยังรายการ p5p

ในกรณีอื่นๆ โปรแกรมแก้ไขจะต้องทำงานหรือพูดคุยกันมากกว่านี้ ที่จะเกิดขึ้นบน p5p
รายการ.

คุณได้รับการสนับสนุนให้เข้าร่วมในการอภิปรายและสนับสนุนโปรแกรมแก้ไขของคุณ
บางครั้งแพตช์ของคุณอาจหายไปในการสับเปลี่ยน เป็นการเหมาะสมที่จะส่งการเตือนความจำ
ส่งอีเมลไปที่ p5p หากไม่มีการดำเนินการใด ๆ ในหนึ่งเดือน โปรดจำไว้ว่า Perl 5
นักพัฒนาทุกคนล้วนเป็นอาสาสมัครและต้องสุภาพ

การเปลี่ยนแปลงจะมีผลโดยตรงกับสาขาการพัฒนาหลักที่เรียกว่า "blead" บาง
แพตช์อาจถูกแบ็คพอร์ตไปยังสาขาการบำรุงรักษา หากคุณคิดว่าแพตช์ของคุณเหมาะสม
สำหรับสาขาการบำรุงรักษา (ดู "สาขาการบำรุงรักษา" ใน perlpolicy) โปรดอธิบายว่าทำไม
เมื่อคุณส่งมัน

ได้รับ ธุรกิจ ปะ ได้รับการยอมรับ
หากคุณกำลังส่งโปรแกรมแก้ไขโค้ด มีหลายสิ่งที่คุณสามารถทำได้เพื่อช่วย
Perl 5 Porters ยอมรับแพทช์ของคุณ

ปะ สไตล์

หากคุณใช้ git เพื่อตรวจสอบแหล่งที่มาของ Perl การใช้ "git format-patch" จะสร้างa
แพทช์ในสไตล์ที่เหมาะกับ Perl คำสั่ง "format-patch" สร้างไฟล์แพทช์หนึ่งไฟล์
สำหรับแต่ละความมุ่งมั่นที่คุณทำ หากคุณต้องการส่งแพตช์เดียวสำหรับคอมมิตทั้งหมด คุณสามารถ
ใช้ "git diff"

% git เช็คเอาต์เบลด
% คอมไพล์ดึง
% git diff blead ชื่อสาขาของฉัน

สิ่งนี้จะสร้างแพตช์ตามความแตกต่างระหว่างเบลดและแบรนช์ปัจจุบันของคุณ มันคือ
สิ่งสำคัญคือต้องแน่ใจว่า blead เป็นข้อมูลล่าสุดก่อนที่จะสร้างความแตกต่าง นั่นคือเหตุผลที่เรา
เรียก "git pull" ก่อน

เราขอแนะนำให้คุณใช้ git ถ้าเป็นไปได้ มันจะทำให้ชีวิตของคุณง่ายขึ้นและ
ของเราด้วย

อย่างไรก็ตาม หากคุณไม่ได้ใช้ git คุณยังสามารถสร้างแพตช์ที่เหมาะสมได้ คุณจะต้อง
สำเนาที่เก่าแก่ของแหล่ง Perl ที่จะแตกต่าง คนเฝ้าประตูชอบความแตกต่างแบบรวมเป็นหนึ่ง
การใช้ GNU "diff" คุณสามารถสร้างส่วนต่างดังนี้:

% ส่วนต่าง -Npurd perl.pristine perl.mine

ตรวจสอบให้แน่ใจว่าคุณ "สร้าง realclean" ในสำเนา Perl ของคุณเพื่อลบสิ่งประดิษฐ์บิลด์หรือ
คุณอาจได้รับผลลัพธ์ที่สับสน

กระทำ ข่าวสาร

ในขณะที่คุณสร้างแพตช์แต่ละแพตช์ที่คุณตั้งใจจะส่งไปยัง Perl core สิ่งสำคัญคือต้องเขียน
ข้อความยืนยันที่ดี นี่เป็นสิ่งสำคัญอย่างยิ่งหากการส่งของคุณจะประกอบด้วยa
ชุดของการกระทำ

บรรทัดแรกของข้อความยืนยันควรเป็นคำอธิบายสั้นๆ โดยไม่มีจุด มัน
ไม่ควรยาวเกินหัวเรื่องของอีเมล 50 ตัวอักษรเป็นกฎที่ดีของ
นิ้วหัวแม่มือ

เครื่องมือ Git จำนวนมาก (Gitweb, GitHub, git log --pretty=oneline, ...) จะแสดงเฉพาะ
บรรทัดแรก (ตัดที่ 50 ตัวอักษร) เมื่อนำเสนอบทสรุปการคอมมิต

ข้อความยืนยันควรมีคำอธิบายของปัญหาที่โปรแกรมแก้ไขแก้ไขหรือ
ฟังก์ชันใหม่ที่แพตช์เพิ่มเข้ามา

ตามกฎทั่วไป ข้อความยืนยันของคุณควรช่วยโปรแกรมเมอร์ที่รู้จัก
Perl core เข้าใจอย่างรวดเร็วว่าคุณกำลังพยายามทำอะไร พยายามทำอะไร และ
เหตุใดการเปลี่ยนแปลงจึงสำคัญกับ Perl

· ทำไม

ข้อความยืนยันของคุณควรอธิบายว่าเหตุใดการเปลี่ยนแปลงที่คุณทำจึงมีความสำคัญ เมื่อไหร่
บางคนมองการเปลี่ยนแปลงของคุณในหกเดือนหรือหกปี เจตนาของคุณควรมีความชัดเจน

หากคุณกำลังเลิกใช้งานคุณลักษณะโดยมีจุดประสงค์เพื่อลดความซับซ้อนอีกเล็กน้อยของ
รหัสพูดอย่างนั้น หากคุณกำลังแก้ไขปัญหาด้านประสิทธิภาพหรือเพิ่มคุณสมบัติใหม่ให้กับ
สนับสนุนแกนหลักอื่น ๆ พูดถึงสิ่งนั้น

· อะไร

ข้อความยืนยันของคุณควรอธิบายว่าคุณกำลังเปลี่ยนแปลงส่วนใดของแกน Perl และ
สิ่งที่คุณคาดหวังให้โปรแกรมแก้ไขของคุณทำ

· ยังไง

แม้ว่าจะไม่จำเป็นสำหรับการเปลี่ยนแปลงเอกสาร การทดสอบใหม่ หรือแพตช์เล็กๆ น้อยๆ ก็ตาม
มักจะคุ้มค่าที่จะอธิบายว่าการเปลี่ยนแปลงของคุณทำงานอย่างไร แม้ว่าวันนี้จะชัดเจนสำหรับคุณ แต่ก็อาจ
ไม่ชัดเจนกับพนักงานยกกระเป๋าในเดือนหน้าหรือปีหน้า

ข้อความยืนยันไม่ได้มีวัตถุประสงค์เพื่อแทนที่ความคิดเห็นในโค้ดของคุณ ให้สัญญา
ข้อความควรอธิบายการเปลี่ยนแปลงที่คุณทำ ในขณะที่ความคิดเห็นเกี่ยวกับโค้ดควรอธิบายถึง
สถานะปัจจุบันของรหัส

หากคุณเพิ่งใช้คุณลักษณะใหม่ พร้อมเอกสาร การทดสอบ และการแสดงความคิดเห็นที่ดี
รหัสข้อความยืนยันสั้น ๆ มักจะพอเพียง อย่างไรก็ตาม หากคุณเพิ่งเปลี่ยน a
อักขระตัวเดียวลึกใน parser หรือ lexer คุณอาจต้องเขียนนวนิยายขนาดเล็กถึง
ตรวจสอบให้แน่ใจว่าผู้อ่านในอนาคตเข้าใจสิ่งที่คุณทำและทำไมคุณถึงทำ

ความคิดเห็น ความคิดเห็น ความคิดเห็น

อย่าลืมแสดงความคิดเห็นโค้ดของคุณอย่างเพียงพอ ในขณะที่การแสดงความคิดเห็นทุกบรรทัดนั้นไม่จำเป็น
อะไรก็ตามที่ใช้ประโยชน์จากผลข้างเคียงของตัวดำเนินการ ที่สร้างการเปลี่ยนแปลงที่จะ
รู้สึกว่าอยู่นอกเหนือฟังก์ชันที่ได้รับการแก้ไข หรือผู้อื่นอาจพบว่าสับสนควร
เอกสาร หากคุณกำลังจะผิดพลาด ทางที่ดีคือการเพิ่มมากเกินไป
แสดงความคิดเห็นน้อยกว่าน้อยเกินไป

ความคิดเห็นที่ดีที่สุดอธิบาย ทำไม รหัสทำในสิ่งที่มันไม่ อะไร it ทำ.

สไตล์

โดยทั่วไป โปรดปฏิบัติตามรูปแบบเฉพาะของโค้ดที่คุณกำลังแก้ไข

โดยเฉพาะอย่างยิ่ง ให้ปฏิบัติตามแนวทางทั่วไปเหล่านี้สำหรับการแก้ไขแหล่งที่มาของ Perl:

· แถบกว้าง 8 แถบ (ไม่มีข้อยกเว้น!)

· เยื้องทั้ง 4 ด้านสำหรับโค้ด, การเยื้อง 2 ด้านสำหรับ CPP ที่ซ้อนกัน #defines

· พยายามอย่าให้เกิน 79 คอลัมน์

· ต้นแบบ ANSI C

· Uncuddled elses และรูปแบบ "K&R" สำหรับการเยื้องโครงสร้างการควบคุม

·ไม่มีความคิดเห็นสไตล์ C++ (//)

· ทำเครื่องหมายสถานที่ที่ต้องไปอีกครั้งด้วย XXX (และกลับมาบ่อยๆ!)

· วงเล็บปีกกาเปิดขึ้นตรงกับ "if" เมื่อเงื่อนไขครอบคลุมหลายบรรทัด ควรอยู่ที่
ปลายสาย

· ในการกำหนดฟังก์ชัน ชื่อจะเริ่มต้นในคอลัมน์ 0 (ประเภทค่าที่ส่งกลับจะอยู่ที่ค่าก่อนหน้า
ไลน์)

· เว้นวรรคหลังคีย์เวิร์ดที่ตามด้วย parens ไม่มีช่องว่างระหว่างฟังก์ชัน
ชื่อและนามสกุลหลัง

· หลีกเลี่ยงการมอบหมายแบบมีเงื่อนไข แต่ถ้าหลีกเลี่ยงไม่ได้ ให้ใช้วงเล็บเสริม เช่น
"ถ้า (a && (b = c)) ..."

· "กลับฟู;" มากกว่า "return(foo);"

· "if (!foo) ..." แทนที่จะเป็น "if (foo == FALSE) ..." เป็นต้น

· ห้ามประกาศตัวแปรโดยใช้ "register" มันอาจจะต่อต้านกับความทันสมัย
คอมไพเลอร์และเลิกใช้แล้วใน C ++ โดยที่แหล่ง Perl เป็นประจำ
รวบรวม

· ฟังก์ชันอินไลน์ที่อยู่ในส่วนหัวที่สามารถเข้าถึงโค้ด XS ได้จะต้องสามารถ
เพื่อคอมไพล์โดยไม่มีการเตือนด้วยแฟล็กการคอมไพล์พิเศษที่ใช้กันทั่วไป เช่น gcc's
"-Wswitch-default" ซึ่งจะเตือนเมื่อใดก็ตามที่คำสั่ง switch ไม่มี "default"
กรณี. การใช้แฟล็กพิเศษเหล่านี้คือการตรวจจับปัญหาที่อาจเกิดขึ้นในรหัส C ทางกฎหมาย
และมักใช้โดยผู้รวบรวม Perl เช่นผู้จัดจำหน่าย Linux

เอกสาร ชุด

หากโปรแกรมแก้ไขของคุณเปลี่ยนรหัส (แทนที่จะเปลี่ยนเอกสาร) คุณควร
รวมกรณีทดสอบอย่างน้อยหนึ่งกรณีที่แสดงข้อบกพร่องที่คุณกำลังแก้ไขหรือตรวจสอบใหม่
ฟังก์ชันที่คุณกำลังเพิ่ม โดยทั่วไป คุณควรอัปเดตไฟล์ทดสอบที่มีอยู่แทน
กว่าจะสร้างใหม่

การเพิ่มชุดทดสอบของคุณโดยทั่วไปควรเป็นไปตามแนวทางเหล่านี้ (ได้รับความอนุเคราะห์จาก Gurusamy
สารภี[ป้องกันอีเมล]>):

·รู้ว่าคุณกำลังทดสอบอะไร อ่านเอกสารและแหล่งที่มา

· ล้มเหลวแต่ไม่สำเร็จ

· ตีความผลลัพธ์อย่างเคร่งครัด

· ใช้คุณสมบัติที่ไม่เกี่ยวข้อง (สิ่งนี้จะล้างการโต้ตอบที่แปลกประหลาดออกไป)

· ใช้สำนวนที่ไม่ได้มาตรฐาน (มิฉะนั้น คุณจะไม่ได้ทดสอบ TIMTOWTDI)

· หลีกเลี่ยงการใช้หมายเลขทดสอบแบบฮาร์ดโค้ดทุกครั้งที่ทำได้ (พบ EXPECTED/GOT ใน
t/op/tie.t สามารถบำรุงรักษาได้มากกว่า และให้รายงานความล้มเหลวที่ดีกว่า)

· ให้ข้อความแสดงข้อผิดพลาดที่มีความหมายเมื่อการทดสอบล้มเหลว

· หลีกเลี่ยงการใช้ qx// และ ระบบ() เว้นแต่คุณกำลังทดสอบพวกเขา ถ้าคุณใช้มัน
ตรวจสอบให้แน่ใจว่าคุณครอบคลุมแพลตฟอร์ม _all_ perl

· ยกเลิกการเชื่อมโยงไฟล์ชั่วคราวที่คุณสร้าง

· ส่งเสริมคำเตือนที่ไม่คาดฝันถึงข้อผิดพลาดด้วย $SIG{__WARN__}

· ตรวจสอบให้แน่ใจว่าใช้ไลบรารีและโมดูลที่มาพร้อมกับเวอร์ชันที่กำลังทดสอบ ไม่ใช่
ที่ติดตั้งไว้แล้ว

· เพิ่มความคิดเห็นในโค้ดเพื่ออธิบายสิ่งที่คุณกำลังทดสอบ

· ไม่จำเป็นต้องอัปเดตสตริง '1..42' หรือให้แน่ใจว่าคุณอัปเดต

· ทดสอบพฤติกรรม _all_ ของโอเปอเรเตอร์ ไลบรารี หรือฟังก์ชันที่กำหนด

ทดสอบอาร์กิวเมนต์ที่ไม่บังคับทั้งหมด

ทดสอบค่าที่ส่งคืนในบริบทต่างๆ (บูลีน สเกลาร์ รายการ lvalue)

ใช้ทั้งตัวแปรส่วนกลางและคำศัพท์

อย่าลืมกรณีพิเศษทางพยาธิวิทยา

ปะ a แกน โมดูล
การทำงานนี้เหมือนกับการแพตช์อย่างอื่นโดยมีข้อพิจารณาพิเศษอย่างหนึ่ง

โมดูลใน ซีแพน/ ไดเร็กทอรีของแผนผังต้นทางถูกรักษาไว้ภายนอก Perl core
เมื่อผู้เขียนอัปเดตโมดูล การอัปเดตจะถูกคัดลอกลงในแกนหลัก เห็นว่า
เอกสารประกอบของโมดูลหรือรายการบนhttp://search.cpan.org/> สำหรับข้อมูลเพิ่มเติมเกี่ยวกับ
การรายงานจุดบกพร่องและการส่งแพตช์

ในกรณีส่วนใหญ่ แพตช์ไปยังโมดูลใน ซีแพน/ ควรส่งต้นน้ำและไม่ควร
นำไปใช้กับแกน Perl ทีละรายการ หากแพตช์เป็นไฟล์ใน ซีแพน/ ไม่สามารถทำได้อย่างแน่นอน
รอให้โปรแกรมแก้ไขอัปสตรีม ปล่อยไปที่ CPAN และคัดลอกไปที่ blead คุณต้องเพิ่ม
(หรืออัปเดต) รายการ "กำหนดเอง" ใน "การพอร์ต/maintainers.pl" ไฟล์เพื่อตั้งค่าสถานะว่า local
ได้มีการปรับเปลี่ยน ดู "การพอร์ต/maintainers.pl" .

ในทางตรงกันข้าม โมดูลใน dist / ไดเร็กทอรีจะยังคงอยู่ในแกนหลัก

ปรับปรุง เพิร์ลเดลต้า
สำหรับการเปลี่ยนแปลงที่สำคัญพอที่จะรับประกัน a พ็อด/perldelta.pod เข้ามา คนเฝ้าประตูจะ
รู้สึกยินดีเป็นอย่างยิ่งหากคุณส่งรายการเดลต้าพร้อมกับการเปลี่ยนแปลงที่แท้จริงของคุณ
การเปลี่ยนแปลงที่สำคัญรวมถึงแต่ไม่จำกัดเพียง:

· การเพิ่ม การเลิกใช้ หรือการลบคุณสมบัติหลัก

· การเพิ่ม การเลิกใช้ การถอด หรือการอัพเกรดโมดูลหลักหรือโมดูลชีวิตคู่

· เพิ่มการทดสอบหลักใหม่

· แก้ไขปัญหาด้านความปลอดภัยและจุดบกพร่องที่ผู้ใช้มองเห็นได้ในคอร์

· การเปลี่ยนแปลงที่อาจทำลายรหัสที่มีอยู่ ทั้งในระดับ Perl หรือ C

· การปรับปรุงประสิทธิภาพที่สำคัญ

· การเพิ่ม การลบ หรือการเปลี่ยนแปลงเอกสารสำคัญใน ฝัก/ ไดเรกทอรี

· การเปลี่ยนแปลงเฉพาะแพลตฟอร์มที่สำคัญ

โปรดตรวจสอบให้แน่ใจว่าคุณได้เพิ่มรายการ perldelta ลงในส่วนที่ถูกต้องภายใน
พ็อด/perldelta.pod. มีข้อมูลเพิ่มเติมเกี่ยวกับวิธีการเขียนรายการ Perldelta ที่ดี
ในส่วน "สไตล์" ของ การย้าย/how_to_write_a_perldelta.pod.

อะไร ทำให้ สำหรับ a ดี ปะ?
คุณลักษณะและส่วนขยายใหม่ๆ ของภาษาอาจเป็นข้อโต้แย้งได้ ไม่มีชุดเฉพาะ
ของเกณฑ์ที่กำหนดว่าจะเพิ่มคุณสมบัติใดบ้าง แต่นี่คือคำถามบางส่วนที่จะ
พิจารณาเมื่อพัฒนาโปรแกรมแก้ไข:

ไม่ แนวคิด การจับคู่ ทั่วไป เป้าหมาย of เพิร์ล?

เป้าหมายของเรารวมถึงแต่ไม่จำกัดเพียง:

1. ทำให้มันรวดเร็ว เรียบง่าย และมีประโยชน์

2. รักษาคุณลักษณะ/แนวคิดให้เป็นมุมฉากให้ได้มากที่สุด

3. ไม่มีข้อจำกัดตามอำเภอใจ (แพลตฟอร์ม ขนาดข้อมูล วัฒนธรรม)

4. ให้มันเปิดกว้างและน่าตื่นเต้นในการใช้/แก้ไข/สนับสนุน Perl ทุกที่

5. ดูดซับเทคโนโลยีใหม่ ๆ หรือสร้างสะพานเชื่อมกับพวกมัน

ที่ไหน is การดำเนินการ?

การพูดคุยทั้งหมดในโลกนี้ไร้ประโยชน์หากไม่มีการนำไปปฏิบัติ ในเกือบทุกกรณี
บุคคลหรือผู้ที่โต้แย้งสำหรับคุณสมบัติใหม่จะถูกคาดหวังให้เป็นผู้ดำเนินการ
มัน. พนักงานขนของสามารถเขียนโค้ดคุณลักษณะใหม่ ๆ มีวาระของตนเองและไม่พร้อมใช้งาน
เพื่อนำความคิด (อาจจะดี) ของคุณไปใช้

ย้อนกลับ ความเข้ากันได้

การทำลายโปรแกรม Perl ที่มีอยู่ถือเป็นบาปที่สำคัญ คำเตือนใหม่สามารถ
เป็นที่ถกเถียงกัน บางคนบอกว่าโปรแกรมที่ส่งคำเตือนไม่เสียหาย ในขณะที่บางคนพูดว่า
มันคือ. การเพิ่มคีย์เวิร์ดมีศักยภาพที่จะทำลายโปรแกรมเปลี่ยนความหมายของ
ลำดับโทเค็นหรือฟังก์ชันที่มีอยู่อาจทำให้โปรแกรมเสียหาย

คอร์ Perl 5 มีกลไกที่ช่วยให้พนักงานยกกระเป๋าทำการเปลี่ยนแปลงที่เข้ากันไม่ได้แบบย้อนหลัง
เข้ากันได้มากขึ้น เช่น คุณลักษณะและโมดูลที่เลิกใช้แล้ว โปรดใช้เมื่อ
เหมาะสม

ได้ it be a โมดูล แทน?

Perl 5 มีกลไกการขยาย โมดูล และ XS โดยเฉพาะเพื่อหลีกเลี่ยงความจำเป็นในการเก็บ
เปลี่ยนล่าม Perl คุณสามารถเขียนโมดูลที่ส่งออกฟังก์ชันได้ คุณสามารถให้
ฟังก์ชันเหล่านั้นเป็นต้นแบบเพื่อให้สามารถเรียกได้เหมือนฟังก์ชันในตัว คุณยังสามารถ
เขียนโค้ด XS เพื่อยุ่งกับโครงสร้างข้อมูลรันไทม์ของล่าม Perl หากคุณต้องการ
เพื่อนำสิ่งที่ซับซ้อนจริงๆ ไปใช้

เมื่อใดก็ตามที่เป็นไปได้ คุณลักษณะใหม่ควรจะสร้างต้นแบบในโมดูล CPAN ก่อนที่พวกเขาจะเป็น
ถือเป็นแก่นของ

Is ลักษณะ ทั่วไป พอ?

นี่คือสิ่งที่เฉพาะผู้ส่งต้องการเพิ่มในภาษาหรือเป็นอย่างกว้าง ๆ
มีประโยชน์? บางครั้ง แทนที่จะเพิ่มคุณลักษณะที่มีโฟกัสแน่น พนักงานยกกระเป๋าอาจ
ตัดสินใจที่จะรอจนกว่าจะมีคนใช้คุณลักษณะทั่วไปมากขึ้น

ไม่ it ที่อาจเกิดขึ้น แนะนำ ใหม่ ข้อบกพร่อง?

การเขียนซ้ำครั้งใหญ่ของล่าม Perl ชิ้นใหญ่มีศักยภาพที่จะแนะนำ
ข้อบกพร่องใหม่

สรุป ความน่าเชื่อถือของ Olymp Trade? ใหญ่ is มันได้หรือไม่

การเปลี่ยนแปลงที่เล็กกว่าและแปลเป็นภาษาท้องถิ่นได้มากเท่าไหร่ก็ยิ่งดีเท่านั้น ในทำนองเดียวกัน ชุดของเล็ก
แพตช์เป็นที่ต้องการมากกว่าแพตช์ขนาดใหญ่เพียงอันเดียว

ไม่ it ดักคอ อื่น ๆ น่าพอใจ คุณสมบัติ?

แพทช์มีแนวโน้มที่จะถูกปฏิเสธหากปิดเส้นทางการพัฒนาในอนาคต สำหรับ
ตัวอย่าง แพทช์ที่วางการตีความที่แท้จริงและขั้นสุดท้ายบนต้นแบบมีแนวโน้มที่จะ
ถูกปฏิเสธเพราะยังมีทางเลือกสำหรับอนาคตของต้นแบบที่ยังไม่ได้
ที่กล่าวถึง

Is การดำเนินงาน แข็งแกร่ง?

แพทช์ที่ดี (โค้ดแน่น สมบูรณ์ ถูก) มีโอกาสเข้ามากกว่า เลอะเทอะหรือ
แพทช์ที่ไม่ถูกต้องอาจถูกวางไว้บนเตาด้านหลังจนกว่าฟักทองจะมีเวลาแก้ไข
หรืออาจถูกละทิ้งโดยสิ้นเชิงโดยไม่ต้องแจ้งให้ทราบล่วงหน้า

Is การดำเนินงาน ทั่วไป พอ ไปยัง be แบบพกพา?

แพทช์ที่แย่ที่สุดใช้ประโยชน์จากคุณลักษณะเฉพาะของระบบ ไม่น่าเป็นไปได้อย่างยิ่งที่การไม่
การเพิ่มเติมแบบพกพาสำหรับภาษา Perl จะได้รับการยอมรับ

Is การดำเนินงาน ทดสอบ?

แพตช์ที่เปลี่ยนพฤติกรรม (แก้ไขข้อบกพร่องหรือแนะนำคุณสมบัติใหม่) จะต้องประกอบด้วย
การทดสอบการถดถอยเพื่อตรวจสอบว่าทุกอย่างทำงานได้ตามที่คาดไว้

หากไม่มีการทดสอบโดยผู้เขียนดั้งเดิม คนอื่นจะเปลี่ยน Perl ใน . ได้อย่างไร
ในอนาคตต้องแน่ใจว่าพวกเขาไม่ได้ทำลายพฤติกรรมที่โปรแกรมแก้ไขใช้โดยไม่ได้ตั้งใจ?
และหากปราศจากการทดสอบ ผู้เขียนแพตช์จะมั่นใจได้อย่างไรว่างานหนักของเขา/เธอทุ่มเทให้กับ
แพทช์จะไม่ถูกใครบางคนโยนทิ้งไปโดยไม่ได้ตั้งใจในอนาคต?

Is มี พอ เอกสาร?

แพทช์ที่ไม่มีเอกสารประกอบอาจเป็นการคิดไม่ดีหรือไม่สมบูรณ์ ไม่มีคุณสมบัติสามารถ
เพิ่มหรือเปลี่ยนแปลงโดยไม่ต้องมีเอกสารประกอบ ดังนั้นให้ส่งโปรแกรมแก้ไขสำหรับพ็อดที่เหมาะสม
เอกสารและซอร์สโค้ดเป็นสิ่งสำคัญ

Is มี อื่น ทาง ไปยัง do มันได้หรือไม่

แลร์รี่กล่าวว่า "ถึงแม้ว่าสโลแกนของ Perl จะเป็น มี เพิ่มเติม กว่า หนึ่ง ทาง ไปยัง Do It, ฉันลังเลที่จะ
ทำ 10 วิธีในการทำบางสิ่งบางอย่าง" นี่เป็นฮิวริสติกที่ยุ่งยากในการนำทาง แม้ว่า-- ของผู้ชายคนเดียว
นอกจากนี้ที่สำคัญคือความหยาบคายที่ไร้จุดหมายของชายอีกคนหนึ่ง

ไม่ it สร้าง เกินไป มาก ทำงานอย่างไร

ทำงานให้กับ Pumpking, ทำงานให้กับโปรแกรมเมอร์ Perl, ทำงานให้กับผู้เขียนโมดูล, ... Perl is
น่าจะง่าย

แพทช์ พูด ดัง กว่า คำ

รหัสการทำงานมักนิยมใช้กับแนวคิดแบบพายในท้องฟ้า แพตช์เพื่อเพิ่มฟีเจอร์ย่อ
มีโอกาสสร้างภาษามากกว่าคำขอคุณสมบัติแบบสุ่ม no
ไม่ว่าคำขอนั้นจะโต้เถียงกันอย่างแรงกล้าเพียงใด สิ่งนี้เชื่อมโยงกับ "มันจะมีประโยชน์หรือไม่" เช่น
ความจริงที่ว่ามีคนใช้เวลาในการทำแพทช์แสดงให้เห็นถึงความปรารถนาอย่างแรงกล้าสำหรับ
ลักษณะ

ทดสอบ

แกนกลางใช้รูปแบบการทดสอบเดียวกันกับ Perl ที่เหลือ โดยเรียกใช้ "ok/not ok" อย่างง่าย
การทดสอบ::สายรัด แต่มีข้อควรพิจารณาพิเศษบางประการ

มีสามวิธีในการเขียนการทดสอบในแกนหลัก: Test::More, t/test.pl และเฉพาะกิจ "พิมพ์
$ทดสอบ ? "ok 42\n" : "not ok 42\n"" การตัดสินใจที่จะใช้ขึ้นอยู่กับว่าส่วนไหนของ
ชุดทดสอบที่คุณกำลังทำงานอยู่ เป็นมาตรการป้องกันความล้มเหลวในระดับสูง (เช่น
เนื่องจาก Config.pm แตก) จากการทำให้การทดสอบฟังก์ชันพื้นฐานล้มเหลว

การขอ t/test.pl ห้องสมุดมีคุณสมบัติบางอย่างของ Test :: More แต่หลีกเลี่ยงการโหลดมากที่สุด
โมดูลและใช้คุณลักษณะหลักให้น้อยที่สุด

หากคุณเขียนการทดสอบของคุณเอง ให้ใช้ Test Anything Protocolhttp://testanything.org>.

· t/เบส, เสื้อ/เปรียบเทียบ และ เสื้อ/opbasic

เนื่องจากเราไม่รู้ว่า "จำเป็น" ใช้งานได้หรือไม่ หรือแม้แต่รูทีนย่อย ให้ใช้การทดสอบเฉพาะกิจสำหรับ
สามคนนี้ ดำเนินการอย่างระมัดระวังเพื่อหลีกเลี่ยงการใช้คุณลักษณะที่กำลังทดสอบ การทดสอบใน
เสื้อ/opbasicตัวอย่างเช่น ถูกวางไว้ที่นั่นมากกว่าใน สูงสุด เพราะพวกเขาทดสอบ
ฟังก์ชันที่ t/test.pl สันนิษฐานได้แสดงให้เห็นแล้วว่าใช้งานได้

· เสื้อ/ซม, เสื้อ / วิ่ง, เสื้อ/ไอโอ และ สูงสุด

ตอนนี้พื้นฐาน ต้องการ () และทดสอบรูทีนย่อยแล้ว คุณสามารถใช้ t/test.pl
ห้องสมุด.

คุณยังสามารถใช้ไลบรารีบางตัว เช่น Config แบบมีเงื่อนไข แต่อย่าลืมข้าม
ทดสอบอย่างสง่างามถ้าไม่มี

· อย่างอื่น

ตอนนี้แกนของ Perl ได้รับการทดสอบแล้ว Test::More can and should be used. นอกจากนี้คุณยังสามารถ
ใช้ชุดโมดูลหลักแบบเต็มในการทดสอบ

เมื่อคุณพูดว่า "ทำการทดสอบ" Perl จะใช้ เสื้อ/ทดสอบ โปรแกรมเพื่อรันชุดทดสอบ (ยกเว้น under
Win32 ที่มันใช้ เสื้อ/สายรัด แทนที่). การทดสอบทั้งหมดดำเนินการจาก 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")" ส่งคืนลำดับไบต์บน
แพลตฟอร์มปัจจุบันที่สร้าง UTF-8 สำหรับ "U+00A0" เนื่องจาก "\xC2\xA0" เป็นไบต์ UTF-8
แพลตฟอร์ม ASCII สำหรับจุดโค้ดนั้น ฟังก์ชันนี้ส่งคืน "\xC2\xA0" บน ASCII
แพลตฟอร์ม และ "\x80\x41" บน EBCDIC 1047

แต่ที่ง่ายที่สุดคือ หากระบุอักขระเป็นตัวอักษรได้ เช่น "A" หรือ "%" ให้ใช้
นั่น; หากไม่เจาะจงคุณสามารถใช้ use "\N{}" ได้ หากผลข้างเคียงไม่
ลำบาก เพียงระบุอักขระทั้งหมดของคุณเป็นฐานสิบหก โดยใช้ "\N{U+ZZ}" แทน
"\xZZ". "\N{}" คือชื่อ Unicode ดังนั้นจึงให้อักขระ Unicode แก่คุณเสมอ
"\N{U+41}" เป็นอักขระที่มีจุดรหัส Unicode คือ 0x41 ดังนั้นจึงเป็น 'A' ทั้งหมด
แพลตฟอร์ม ผลข้างเคียงคือ:

1) กฎ Unicode ที่เลือกเหล่านี้ นั่นหมายความว่าในสตริง double-quotish สตริง is
แปลงเป็น UTF-8 เสมอเพื่อบังคับการตีความ Unicode (คุณสามารถ
"utf8::downgrade()" หลังจากนั้นให้แปลงกลับเป็นไม่ใช่ UTF8 หากเป็นไปได้) เป็นประจำ
รูปแบบนิพจน์การแปลงจะไม่เสร็จสิ้น แต่ถ้าตัวแก้ไขชุดอักขระ
มิฉะนั้นจะเป็น "/d" มันถูกเปลี่ยนเป็น "/u"

2) หากคุณใช้แบบฟอร์ม "\N{ตัวอักษร ชื่อ}", โมดูล charnames จะได้รับโดยอัตโนมัติ
โหลดแล้ว ซึ่งอาจไม่เหมาะกับระดับการทดสอบที่คุณทำอยู่

หากคุณกำลังทดสอบโลแคล (ดู perllocale) มีฟังก์ชันตัวช่วยใน t/loc_tools.pl
เพื่อให้คุณเห็นว่ามีสถานที่ใดบ้างบนแพลตฟอร์มปัจจุบัน

พิเศษ "ทำ ทดสอบ" เป้าหมาย
มีเป้าหมาย make พิเศษต่างๆ ที่สามารถใช้ทดสอบ Perl ได้แตกต่างกันเล็กน้อย
กว่าเป้าหมาย "ทดสอบ" มาตรฐาน ไม่ใช่ทั้งหมดที่พวกเขาคาดว่าจะให้อัตราความสำเร็จ 100%
หลายชื่อมีนามแฝงหลายตัว และหลายชื่อไม่พร้อมใช้งานในบางระบบปฏิบัติการ
ระบบ

· test_porting

การดำเนินการนี้จะเรียกใช้การทดสอบสุขภาพจิตพื้นฐานบนแผนผังต้นทางและช่วยตรวจจับข้อผิดพลาดพื้นฐาน
ก่อนที่คุณจะส่งแพตช์

· มินิเทส

วิ่ง มินิเพิร์ล on t/เบส, เสื้อ/เปรียบเทียบ, เสื้อ/ซม, เสื้อ / วิ่ง, เสื้อ/ไอโอ, สูงสุด, เสื้อ/ยูนิ และ ตัน/ม การทดสอบ

· test.valgrind ตรวจสอบ.valgrind

(เฉพาะใน Linux) เรียกใช้การทดสอบทั้งหมดโดยใช้หน่วยความจำรั่ว + เครื่องมือเข้าถึงหน่วยความจำที่ซุกซน
"วาลกรินด์". ไฟล์บันทึกจะมีชื่อว่า ชื่อทดสอบ.valgrind.

· test_harness

เรียกใช้ชุดทดสอบด้วย the เสื้อ/สายรัด ควบคุมโปรแกรมแทน เสื้อ/ทดสอบ.
เสื้อ/สายรัด มีความซับซ้อนมากขึ้น และใช้โมดูล Test::Harness จึงใช้สิ่งนี้
เป้าหมายการทดสอบสมมติว่า Perl ใช้งานได้เป็นส่วนใหญ่ ข้อได้เปรียบหลักสำหรับวัตถุประสงค์ของเราคือ
ที่พิมพ์สรุปรายละเอียดของการทดสอบที่ล้มเหลวในตอนท้าย ไม่เหมือน เสื้อ/ทดสอบมัน
ไม่เปลี่ยนเส้นทาง stderr ไปที่ stdout

โปรดทราบว่าภายใต้ Win32 เสื้อ/สายรัด ใช้แทน .เสมอ เสื้อ/ทดสอบดังนั้นจึงไม่มี
เป้าหมาย "test_harness" พิเศษ

ภายใต้เป้าหมาย "การทดสอบ" ของ Win32 คุณสามารถใช้สภาพแวดล้อม TEST_SWITCHES และ TEST_FILES
ตัวแปรควบคุมพฤติกรรมของ เสื้อ/สายรัด. นี่หมายความว่าคุณสามารถพูดได้

nmake ทดสอบ TEST_FILES="op/*.t"
nmake ทดสอบ TEST_SWITCHES="-torture" TEST_FILES="op/*.t"

· ทดสอบ notty test_notty

ตั้งค่า PERL_SKIP_TTY_TEST เป็นจริงก่อนที่จะรันการทดสอบปกติ

Parallel การทดสอบ
การกระจายหลักสามารถรันการทดสอบการถดถอยแบบคู่ขนานบนแพลตฟอร์มที่เหมือน Unix
แทนที่จะรัน "make test" ให้ตั้งค่า "TEST_JOBS" ในสภาพแวดล้อมของคุณเป็นจำนวนการทดสอบ
เพื่อทำงานแบบขนานและเรียกใช้ "make test_harness" บนเปลือกที่เหมือนบอร์น สามารถทำได้
as

TEST_JOBS=3 ทำ test_harness # รัน 3 การทดสอบแบบขนาน

มีการใช้ตัวแปรสภาพแวดล้อมแทนที่จะสร้างตัวมันเองเพราะ TAP::Harness
จะต้องสามารถกำหนดเวลาสคริปต์ทดสอบที่ไม่ขัดแย้งกันแต่ละรายการได้เองและมี
ไม่มีอินเทอร์เฟซมาตรฐานสำหรับ "สร้าง" ยูทิลิตี้เพื่อโต้ตอบกับตัวกำหนดตารางเวลางาน

โปรดทราบว่าขณะนี้สคริปต์ทดสอบบางตัวอาจล้มเหลวเมื่อรันแบบขนาน (ที่โดดเด่นที่สุด
ต่อ/IO/t/io_dir.t). หากจำเป็น ให้รันเฉพาะสคริปต์ที่ล้มเหลวอีกครั้งตามลำดับและดู
หากความล้มเหลวหายไป

เล่น การทดสอบ by มือ
คุณสามารถเรียกใช้ชุดทดสอบบางส่วนด้วยมือโดยใช้คำสั่งใดคำสั่งหนึ่งต่อไปนี้จาก
t/ ไดเรกทอรี:

./perl -ฉัน../ lib ทดสอบ list-of-.t-files

or

./perl -ฉัน../ lib สายรัด list-of-.t-files

(หากคุณไม่ระบุสคริปต์ทดสอบ ระบบจะเรียกใช้ชุดการทดสอบทั้งหมด)

การใช้ เสื้อ/สายรัด สำหรับ การทดสอบ
หากคุณใช้ "harness" ในการทดสอบ คุณจะมีตัวเลือกบรรทัดคำสั่งหลายตัวเลือก
อาร์กิวเมนต์มีดังนี้ และอยู่ในลำดับที่ต้องปรากฏหากใช้ร่วมกัน

สายรัด -v -torture -re=pattern รายการไฟล์ที่จะทดสอบ
สายรัด -v -torture -re รายการรูปแบบที่จะจับคู่

หากละเว้น "รายการไฟล์ที่จะทดสอบ" รายการไฟล์จะได้รับจากรายการ ดิ
รายการไฟล์อาจมีสัญลักษณ์แทนเชลล์ซึ่งจะถูกขยายออก

· -v

รันการทดสอบภายใต้โหมด verbose เพื่อให้คุณเห็นว่าการทดสอบใดถูกเรียกใช้ และดีบักเอาต์พุต

· -ทรมาน

เรียกใช้การทดสอบการทรมานเช่นเดียวกับชุดปกติ

· -re=รูปแบบ

กรองรายการไฟล์เพื่อให้ไฟล์ทดสอบทั้งหมดทำงานตรงกับ PATTERN โปรดทราบว่าสิ่งนี้
รูปแบบแตกต่างจาก -re รายการ OF รูปแบบ แบบฟอร์มด้านล่างเพื่อให้ไฟล์
รายการที่จะให้ด้วย

· -re รายการรูปแบบ

กรองรายการไฟล์เพื่อให้ไฟล์ทดสอบทั้งหมดทำงานตรงกัน /(LIST|OF|PATTERNS)/. หมายเหตุ
ด้วยรูปแบบนี้รูปแบบจะถูกรวมด้วย '|' และคุณไม่สามารถจัดหารายการของ
ไฟล์ แทนที่จะได้ไฟล์ทดสอบจาก MANIFEST

คุณสามารถรันการทดสอบแต่ละรายการโดยใช้คำสั่งที่คล้ายกับ

./perl -ฉัน../ lib เส้นทาง/to/foo.t

ยกเว้นว่าสายรัดจะตั้งค่าตัวแปรสภาพแวดล้อมบางอย่างที่อาจส่งผลต่อการดำเนินการ
ของการทดสอบ:

· PERL_CORE=1

แสดงว่าเรากำลังรันการทดสอบนี้โดยเป็นส่วนหนึ่งของชุดทดสอบ Perl core นี่คือ
มีประโยชน์สำหรับโมดูลที่มีชีวิตคู่บน CPAN

· PERL_DESTRUCT_LEVEL=2

ถูกตั้งค่าเป็น 2 หากยังไม่ได้ตั้งค่า (ดู "PERL_DESTRUCT_LEVEL" ใน perlhacktips)

· เพิร์ล

(ใช้โดย .เท่านั้น เสื้อ/ทดสอบ) หากตั้งค่าไว้ ให้แทนที่พาธไปยังไฟล์สั่งการ perl ที่ควรจะเป็น
ใช้ในการรันการทดสอบ (ค่าเริ่มต้นเป็น ./เพิร์ล).

· PERL_SKIP_TTY_TEST

ถ้าตั้งค่าไว้ บอกให้ข้ามการทดสอบที่ต้องใช้เทอร์มินัล มันถูกตั้งค่าโดยอัตโนมัติจริง ๆ
โดย Makefile แต่สามารถบังคับเทียมได้ด้วยการเรียกใช้ 'make test_notty'

อื่นๆ สิ่งแวดล้อม ตัวแปร ที่ อาจ มีอิทธิพล การทดสอบ

· PERL_TEST_Net_Ping

การตั้งค่าตัวแปรนี้จะรันการทดสอบโมดูล Net::Ping ทั้งหมด มิฉะนั้นการทดสอบบางอย่างนั้น
โต้ตอบกับโลกภายนอกจะถูกข้าม ดู perl58delta

· PERL_TEST_NOVREXX

การตั้งค่าตัวแปรนี้จะข้ามการทดสอบ vrexx.t สำหรับ OS2::REXX

· PERL_TEST_NUM CONVERTS

สิ่งนี้ตั้งค่าตัวแปรใน op/numconvert.t

· PERL_TEST_MEMORY

การตั้งค่าตัวแปรนี้รวมถึงการทดสอบใน ที/bigmem/. ควรตั้งค่านี้เป็น
จำนวนหน่วยความจำกิกะไบต์ที่สามารถทดสอบได้ เช่น "PERL_TEST_MEMORY=4"
ระบุว่าการทดสอบที่ต้องใช้หน่วยความจำ 4GiB นั้นสามารถทำงานได้อย่างปลอดภัย

ดูเอกสารประกอบสำหรับโมดูล Test and Test::Harness สำหรับสภาพแวดล้อมเพิ่มเติม
ตัวแปรที่ส่งผลต่อการทดสอบ

ประสิทธิภาพ การทดสอบ
ไฟล์ t/perf/เกณฑ์มาตรฐาน มีตัวอย่างโค้ด perl ซึ่งมีวัตถุประสงค์เพื่อเป็น
เปรียบเทียบกับช่วงของ Perls โดย การย้าย/bench.pl เครื่องมือ. หากคุณแก้ไขหรือปรับปรุง
ปัญหาด้านประสิทธิภาพ คุณอาจต้องการเพิ่มตัวอย่างรหัสตัวแทนไปยังไฟล์ จากนั้นเรียกใช้
ม้านั่ง.pl เทียบกับ perls ก่อนหน้าและปัจจุบันเพื่อดูว่ามันสร้างความแตกต่างอย่างไรและ
ไม่ว่าจะมีอะไรช้าลงเป็นผล

ไฟล์ t/perf/opcount.t ได้รับการออกแบบมาเพื่อทดสอบว่าข้อมูลโค้ดใดได้รับ
รวบรวมเป็น optree ที่มีจำนวนที่ระบุของประเภท op เฉพาะ ดีจัง
สำหรับการทดสอบว่าการเพิ่มประสิทธิภาพซึ่งเปลี่ยนแปลง ops เช่นการแปลง "aelem" op เป็น
op "aelemfast" กำลังทำอย่างนั้นจริงๆ

ไฟล์ t/perf/speed.t และ t/re/speed.t ออกแบบมาเพื่อทดสอบสิ่งต่าง ๆ ที่ใช้เป็นพัน
ช้าลงหลายเท่าหากการปรับให้เหมาะสมบางอย่างใช้งานไม่ได้ (เช่น แคชความยาว utf8
บนสตริง utf8 แบบยาว) เพิ่มการทดสอบที่จะใช้เวลาเสี้ยววินาทีตามปกติและ
มิฉะนั้น ทำให้ไฟล์ทดสอบหมดเวลาเมื่อเกิดข้อผิดพลาด

เพิ่มเติม การอ่าน สำหรับ GUTS แฮกเกอร์

ในการแฮ็กความกล้าของ Perl คุณจะต้องอ่านสิ่งต่อไปนี้:

· เพิร์ลซอร์ส

ภาพรวมของทรีซอร์สของ Perl สิ่งนี้จะช่วยคุณค้นหาไฟล์ที่คุณกำลังค้นหา
สำหรับ

· เชื่อมต่อ

ภาพรวมของซอร์สโค้ดล่าม Perl และรายละเอียดบางอย่างเกี่ยวกับวิธีที่ Perl ทำอะไร
มันทำ

· เพิร์ลแฮ็กตุต

เอกสารนี้จะอธิบายเกี่ยวกับการสร้างแพตช์ขนาดเล็กสำหรับโค้ด C ของ Perl ถ้าคุณคือ
เพิ่งเริ่มต้นใช้งาน Perl core hacking มันจะช่วยให้คุณเข้าใจวิธีการของมัน
โรงงาน

· perlhacktips

รายละเอียดเพิ่มเติมเกี่ยวกับการแฮ็ค Perl core เอกสารนี้เน้นรายละเอียดระดับล่าง
เช่น วิธีเขียนการทดสอบ ปัญหาการคอมไพล์ การพกพา การดีบัก เป็นต้น

หากคุณวางแผนที่จะทำการแฮ็ก C อย่างจริงจังโปรดอ่านสิ่งนี้

· perlgus

นี่เป็นสิ่งสำคัญยิ่ง เนื่องจากเป็นเอกสารของสิ่งที่เกิดขึ้นใน
แหล่งที่มาของ Perl อ่านสองสามรอบแล้วเริ่มเข้าใจ -
อย่าเพิ่งกังวลหากยังไม่ได้ เพราะวิธีที่ดีที่สุดในการศึกษาคือการอ่านใน
ร่วมกับการเจาะที่แหล่ง Perl แล้วเราจะทำในภายหลัง

Gisle Aas's "ภาพประกอบ perlgut" หรือที่เรียกว่า ความโง่เขลามีรูปภาพที่เป็นประโยชน์มาก:

<http://search.cpan.org/dist/illguts/>

· perlxstut และ perlxs

ความรู้ในการทำงานของการเขียนโปรแกรม XSUB นั้นมีประโยชน์อย่างเหลือเชื่อสำหรับการแฮ็กหลัก XSUBs
ใช้เทคนิคที่ดึงมาจากรหัส PP ส่วนของความกล้าที่ทำได้จริง
โปรแกรม Perl มันง่ายกว่ามากที่จะเรียนรู้เทคนิคเหล่านั้นจากตัวอย่างง่ายๆ และ
คำอธิบายมากกว่าจากแกนหลักเอง

· เพอลาพิ

เอกสารประกอบสำหรับ Perl API อธิบายการทำงานของฟังก์ชันภายในบางส่วน เช่น
รวมถึงมาโครจำนวนมากที่ใช้ในแหล่งที่มา

· ขนย้าย/pumpkin.pod

นี่คือชุดคำศัพท์สำหรับคนเฝ้าประตู Perl; บางอย่างก็มีประโยชน์
ถึงผู้ถือฟักทอง แต่ส่วนใหญ่ใช้กับทุกคนที่ต้องการไปเกี่ยวกับ Perl
พัฒนาการ

ซีแพน ผู้ทดสอบ AND PERL ผู้สูบบุหรี่

ผู้ทดสอบ CPAN ( http://testers.cpan.org/ ) คือกลุ่มอาสาสมัครที่ทำการทดสอบ CPAN
โมดูลบนแพลตฟอร์มที่หลากหลาย

ผู้สูบบุหรี่ Perl ( http://www.nntp.perl.org/group/perl.daily-build/ และ
http://www.nntp.perl.org/group/perl.daily-build.reports/ ) ทดสอบแหล่งที่มาของ Perl โดยอัตโนมัติ
เผยแพร่บนแพลตฟอร์มที่มีการกำหนดค่าต่างๆ

ความพยายามทั้งสองยินดีต้อนรับอาสาสมัคร เพื่อมีส่วนร่วมในการทดสอบควันของ perl
เยี่ยมชมตัวเองhttp://search.cpan.org/dist/Test-Smoke/>. เพื่อเริ่มการทดสอบควัน
เยี่ยมชมโมดูล CPANhttp://search.cpan.org/dist/CPANPLUS-YACSmoke/> หรือ
<http://search.cpan.org/dist/minismokebox/> หรือ
<http://search.cpan.org/dist/CPAN-Reporter/>.

WHAT ต่อไป?

หากคุณได้อ่านเอกสารทั้งหมดในเอกสารและรายการข้างต้นแล้ว แสดงว่าคุณ
มากกว่าพร้อมที่จะแฮ็ค Perl

มีคำแนะนำเพิ่มเติมดังนี้

· สมัครสมาชิก perl5-porters ทำตามแพตช์และพยายามทำความเข้าใจ ไม่ต้อง
กลัวถามว่ามีส่วนไม่ชัดเจนหรือเปล่า ใครจะรู้ คุณอาจค้นพบ
บั๊กในแพทช์...

· อ่าน README ที่เกี่ยวข้องกับระบบปฏิบัติการของคุณ เช่น README.aix บน IBM
ระบบปฏิบัติการ AIX อย่าลังเลที่จะจัดหาแพตช์ให้กับ README นั้นหากคุณพบว่ามีอะไรขาดหายไป
หรือเปลี่ยนจากระบบปฏิบัติการรุ่นใหม่

· ค้นหาพื้นที่ของ Perl ที่คุณสนใจและดูว่าคุณสามารถหาวิธีได้หรือไม่
ทำงาน สแกนต้นทางและข้ามผ่านในดีบักเกอร์ เล่น สะกิด
สอบสวน ซอ! คุณอาจจะได้ทำความเข้าใจไม่ใช่แค่พื้นที่ที่คุณเลือกแต่ a
ช่วงที่กว้างกว่ามากของ Perlกิจกรรมต่างๆ ด้วยเช่นกัน และอาจจะเร็วกว่าที่คุณคิด

" ถนน ไป เคย on และ หนึ่ง; ลง จาก ประตู ที่ไหน it เริ่ม."
หากคุณสามารถทำสิ่งเหล่านี้ได้ แสดงว่าคุณได้เริ่มต้นบนเส้นทางยาวสู่การย้ายพอร์ต Perl ขอบคุณสำหรับ
ต้องการช่วยให้ Perl ดีขึ้น - และแฮ็คอย่างมีความสุข!

อุปมา ใบเสนอราคา
หากคุณจำคำพูดเกี่ยวกับถนนข้างต้นได้แสดงว่าคุณโชคดี

โครงการซอฟต์แวร์ส่วนใหญ่เริ่มต้นแต่ละไฟล์ด้วยคำอธิบายตามตัวอักษรของวัตถุประสงค์ของแต่ละไฟล์
Perl เริ่มต้นด้วยการพาดพิงถึงวัตถุประสงค์ของไฟล์นั้น

เช่นเดียวกับบทต่างๆ ในหนังสือหลายเล่ม ไฟล์ต้นฉบับ Perl ระดับบนสุดทั้งหมด (รวมถึงส่วนอื่นๆ อีกสองสามไฟล์ที่นี่
และที่นั่น) เริ่มต้นด้วยจารึก epigrammatic ที่พาดพิงถึงโดยอ้อมและ
เปรียบเทียบเนื้อหาที่คุณกำลังอ่าน

ใบเสนอราคานำมาจากงานเขียนของ JRR Tolkien ที่เกี่ยวข้องกับ Legendarium ของเขาเกือบ
เสมอจาก การขอ เจ้า of แหวน. บทที่และหมายเลขหน้าจะได้รับโดยใช้
ฉบับต่อไปนี้:

· การขอ ฮอบบิท, โดย เจอาร์อาร์ โทลคีน. ปกแข็ง ฉบับครบรอบ 70 ปี 2007 คือ
ใช้เผยแพร่ในสหราชอาณาจักรโดย Harper Collins Publishers และในสหรัฐอเมริกาโดย Houghton
บริษัท มิฟฟลิน

· การขอ เจ้า of แหวน, โดย เจอาร์อาร์ โทลคีน. ปกแข็ง ฉบับครบรอบ 50 ปี
ค.ศ. 2004 ถูกใช้ จัดพิมพ์ในสหราชอาณาจักรโดย Harper Collins Publishers และในสหรัฐอเมริกาโดย the
บริษัท โฮตัน มิฟฟลิน

· การขอ วาง of เบอริอันด์, โดย JRR Tolkien และตีพิมพ์โดยลูกชายของเขาและ .ต้อ
ผู้ดำเนินการวรรณกรรม CJR Tolkien เป็นเล่มที่ 3 ใน 12 เล่มของคริสโตเฟอร์
มหึมา ประวัติขององค์กร of กลาง อีกครั้ง. เลขหน้ามาจากฉบับปกแข็ง
ตีพิมพ์ครั้งแรกในปี 1983 โดย George Allen & Unwin; ไม่มีการเปลี่ยนหมายเลขหน้าสำหรับ
ฉบับพิเศษ 3 เล่ม ประจำปี พ.ศ. 2002 หรือฉบับกระดาษทางการค้าต่างๆ ทั้งหมด
อีกครั้งโดย Harper Collins หรือ Houghton Mifflin

เกมอื่น ๆ ที่ยุติธรรมสำหรับหนังสือ JRRT สำหรับราคาจะรวมถึง การขอ การผจญภัย of ทอม บอมบาดิ,
การขอ ซิลมาริลเลียน, ยังไม่เสร็จ Talesและ การขอ นิทาน of เด็ก of ฮูริน, ทั้งหมดยกเว้น
ประกอบมรณกรรมครั้งแรกโดย CJRT แต่ การขอ เจ้า of แหวน ตัวเองก็สบายดี
และอาจเสนอราคาได้ดีที่สุดหากคุณสามารถหาใบเสนอราคาที่เหมาะสมได้ที่นั่น

ดังนั้น หากคุณต้องจัดหาไฟล์ต้นฉบับระดับบนสุดใหม่ที่สมบูรณ์เพื่อเพิ่มลงใน Perl คุณควร
ปฏิบัติตามการปฏิบัติที่แปลกประหลาดนี้ด้วยตัวเองโดยเลือกใบเสนอราคาที่เหมาะสมจาก
โทลคีน โดยคงตัวสะกดและเครื่องหมายวรรคตอนดั้งเดิมไว้และใช้รูปแบบเดียวกัน the
คำพูดที่เหลืออยู่ในนั้น ทางอ้อมและเฉียงก็ใช้ได้ จำไว้ว่ามันเป็นอุปมา
ดังนั้นการเป็นเมต้าจึงมีไว้เพื่ออะไร

ใช้ perlhack ออนไลน์โดยใช้บริการ onworks.net