perlhack - Online în cloud

PROGRAM:

NUME

perlhack - Cum să piratați pe Perl

DESCRIERE

Acest document explică cum funcționează dezvoltarea Perl. Include detalii despre Perl 5
Lista de e-mail Porters, depozitul Perl, instrumentul de urmărire a erorilor Perlbug, liniile directoare pentru corecții și
comentariu asupra filozofiei de dezvoltare Perl.

SUPER RAPID PLASTURE GHID

Dacă doriți doar să trimiteți un singur patch mic, cum ar fi o remediere a podului, un test pentru o eroare, comentați
remedieri etc., e usor! Iată cum:

· Verificați depozitul sursă

Sursa perl este într-un depozit git. Puteți clona depozitul cu
următoarea comandă:

% git clone git://perl5.git.perl.org/perl.git perl

· Asigurați-vă că urmați cele mai recente sfaturi

În cazul în care sfaturile din acest ghid au fost actualizate recent, citiți cea mai recentă versiune
direct din sursa perl:

% perldoc pod/perlhack.pod

· Faceți schimbarea

Hack, hack, hack. Rețineți că Perl rulează pe multe platforme diferite, cu
sisteme de operare diferite care au capacități diferite, sistem de fișiere diferit
organizații și chiar seturi de caractere diferite. perlhacktips oferă sfaturi în acest sens.

· Testează-ți schimbarea

Puteți rula toate testele cu următoarele comenzi:

% ./Configure -des -Dusedevel
% fac test

Continuați să piratați până când testele trec.

· Angajați-vă schimbarea

Angajarea muncii dvs. va salva schimbarea on ta local sistem:

% git commit -a -m „Mesajul de comitere ajunge aici”

Asigurați-vă că mesajul de confirmare descrie schimbarea dvs. într-o singură propoziție. De exemplu,
„S-au remediat erorile de ortografie în perlhack.pod”.

· Trimiteți modificarea către perlbug

Următorul pas este să trimiteți patch-ul la sistemul de bilete de bază Perl prin e-mail.

Dacă modificările dvs. sunt într-un singur commit git, rulați următoarele comenzi pentru a genera
fișier de corecție și atașați-l la raportul dvs. de eroare:

% git format-patch -1
% ./perl -Ilib utils/perlbug -p 0001-*.patch

Programul perlbug vă va pune câteva întrebări despre adresa dvs. de e-mail și despre
patch-ul pe care îl trimiteți. Odată ce le-ați răspuns, vă va trimite patch-ul prin
e-mail.

Dacă modificările dvs. sunt în mai multe comiteri, generați un fișier de corecție pentru fiecare și
furnizați-le opțiunii „-p” a lui perlbug, separate prin virgule:

% git format-patch -3
% ./perl -Ilib utils/perlbug -p 0001-fix1.patch,0002-fix2.patch,\
> 0003-fix3.patch

Când vi se solicită, alegeți un subiect care rezumă modificările dvs.

· Mulțumesc

Portarii apreciază timpul petrecut contribuind la îmbunătățirea Perlului. Mulțumesc!

· Data viitoare

Data viitoare când doriți să faceți un patch, trebuie să începeți de la cel mai recent perl din a
stare curată. Verificați dacă nu aveți modificări locale sau fișiere adăugate în perl
check-out pe care doriți să le păstrați, apoi rulați aceste comenzi:

% git pull
% git reset --hard origine/blead
% git clean -dxf

GÂNDAC RAPORTAREA

Dacă doriți să raportați o eroare în Perl, trebuie să utilizați perlbug instrument de linie de comandă. Acest
instrumentul se va asigura că raportul dvs. de eroare include tot sistemul și configurația relevante
informaţii.

Pentru a căuta erori și corecții Perl existente, puteți utiliza interfața web la
<http://rt.perl.org/>.

Vă rugăm să verificați arhiva listei perl5-porters (vezi mai jos) și/sau urmărirea erorilor
sistem înainte de a trimite un raport de eroare. Adesea, veți descoperi că eroarea a fost raportată
deja.

Vă puteți conecta la sistemul de urmărire a erorilor și puteți comenta rapoartele de erori existente. daca tu
aveți informații suplimentare cu privire la un bug existent, vă rugăm să îl adăugați. Acest lucru va ajuta
hamalii remediază problema.

PERL 5 PORTARI

Lista de corespondență perl5-porters (p5p) este locul în care este menținută distribuția standard Perl
și dezvoltată. Oamenii care întrețin Perl sunt denumiți și „Porterii Perl 5”,
„p5p” sau doar „portarii”.

O arhivă care poate fi căutată a listei este disponibilă la
<http://markmail.org/search/?q=perl5-porters>. Există și o arhivă la
<http://archive.develooper.com/perl5-porters@perl.org/>.

perl-modificări discuții listă
Lista de corespondență perl5-changes primește o copie a fiecărui patch care este trimis către
ramurile de întreținere și dezvoltare ale depozitului perl. Vedea
<http://lists.perl.org/list/perl5-changes.html> pentru informații despre abonament și arhivare.

#p5p on IRC
Mulți hamali sunt, de asemenea, activi pe canal. Simțiți-vă liber să vă alăturați
canalul și pune întrebări despre hacking-ul pe nucleul Perl.

PRIMII THE PERL SOURCE

Tot codul sursă al lui Perl este păstrat central într-un depozit Git la perl5.git.perl.org.
Depozitul conține multe versiuni Perl de la Perl 1 și toate versiunile de la
Perforce, sistemul de control al versiunii anterioare.

Pentru mai multe detalii despre utilizarea git cu depozitul Perl, consultați perlgit.

Citiți acces de merge
Veți avea nevoie de o copie a Git pentru computerul dvs. Puteți prelua o copie a depozitului
folosind protocolul git:

% git clone git://perl5.git.perl.org/perl.git perl

Acest lucru clonează depozitul și face o copie locală în perl director.

Dacă nu puteți utiliza protocolul git din motive de firewall, puteți și clona prin http,
deși acest lucru este mult mai lent:

% clona git http://perl5.git.perl.org/perl.git perl

Citiți acces de il web
Puteți accesa depozitul de pe web. Acest lucru vă permite să răsfoiți arborele, vedeți
comiteri recente, abonați-vă la fluxuri RSS pentru modificări, căutați anumite comite și
Mai Mult. Îl puteți accesa lahttp://perl5.git.perl.org/perl.git>. O oglindă a
depozitul se găsește la .

Citiți acces de rsync
De asemenea, puteți alege să utilizați rsync pentru a obține o copie a arborelui sursă curent pentru
filiala bleadperl și toate ramurile de întreținere:

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

(Adăugați opțiunea „--delete” pentru a elimina fișierele rămase.)

Pentru a obține o listă completă a punctelor de sincronizare disponibile:

% rsync perl5.git.perl.org::

Scrie acces de merge
Dacă aveți un bit de comitere, vă rugăm să vedeți perlgit pentru mai multe detalii despre utilizarea git.

PETICAREA PERL

Dacă intenționați să faceți o muncă mai amplă decât o singură reparație mică, vă încurajăm să o faceți
citiți documentația de mai jos. Acest lucru vă va ajuta să vă concentrați munca și să vă creați patch-urile
mai ușor de încorporat în sursa Perl.

Trimiterea patch-uri
Dacă aveți un mic patch de trimis, vă rugăm să îl trimiteți prin perlbug. De asemenea, puteți trimite
e-mail direct la [e-mail protejat]. Vă rugăm să rețineți că mesajele trimise către perlbug pot fi reținute
într-o coadă de moderare, așa că nu veți primi un răspuns imediat.

Veți ști că trimiterea dvs. a fost procesată când veți primi un e-mail de la biletul nostru
sistem de urmărire. Acest e-mail vă va oferi un număr de bilet. Odată ce plasturele a făcut-o
către sistemul de urmărire a biletelor, acesta va fi trimis și către [e-mail protejat] listă.

Patch-urile sunt revizuite și discutate pe lista p5p. Patch-uri simple, necontroversate vor
de obicei se aplică fără nicio discuție. Când plasturele este aplicat, biletul va fi
actualizat și veți primi e-mail. În plus, va fi trimis un e-mail către lista p5p.

În alte cazuri, patch-ul va necesita mai multă muncă sau discuții. Asta se va întâmpla pe p5p
listă.

Sunteți încurajat să participați la discuție și să susțineți plasturele.
Uneori, plasturele dumneavoastră se poate pierde în amestecare. Este indicat să trimiteți un memento
e-mail către p5p dacă nu a fost luată nicio măsură într-o lună. Vă rugăm să rețineți că Perl 5
Dezvoltatorii sunt toți voluntari și fiți politicoși.

Modificările sunt întotdeauna aplicate direct la ramura principală de dezvoltare, numită „blead”. niste
patch-urile pot fi portate înapoi la o ramură de întreținere. Dacă considerați că plasturele dumneavoastră este adecvat
pentru ramura de întreținere (vezi „SUCURSALE DE ÎNTREȚINERE” în ​​perlpolicy), vă rugăm să explicați de ce
când îl depuneți.

Noțiuni de bază ta plasture admis
Dacă trimiteți un patch de cod, există mai multe lucruri pe care le puteți face pentru a ajuta
Perl 5 Porters vă acceptă patch-ul.

Plasture stil

Dacă ați folosit git pentru a verifica sursa Perl, atunci folosirea „git format-patch” va produce a
patch într-un stil potrivit pentru Perl. Comanda „format-patch” produce un fișier de corecție
pentru fiecare angajament pe care l-ați făcut. Dacă preferați să trimiteți un singur patch pentru toate comitările, puteți
utilizați „git diff”.

% git checkout blead
% git pull
% git diff blead numele-sucursala-mea

Acest lucru produce un plasture bazat pe diferența dintre blead și ramura dvs. actuală. este
important să ne asigurăm că blead este la zi înainte de a produce diferența, de aceea noi
apelați mai întâi „git pull”.

Vă recomandăm insistent să utilizați git dacă este posibil. Îți va face viața mai ușoară și
si ale noastre.

Cu toate acestea, dacă nu utilizați git, puteți produce în continuare un patch adecvat. Veți avea nevoie de un
copie originală a sursei Perl cu care se face dif. Portarii preferă diferențele unificate.
Folosind „diff” GNU, puteți produce o diferență ca aceasta:

% diff -Npurd perl.pristine perl.mine

Asigurați-vă că faceți „realclean” în copia dvs. de Perl pentru a elimina orice artefacte de construcție sau
este posibil să obțineți un rezultat confuz.

Comite mesaj

Pe măsură ce creați fiecare patch pe care intenționați să îl trimiteți nucleului Perl, este important să scrieți a
mesaj de comitere bun. Acest lucru este important mai ales dacă trimiterea dvs. va consta dintr-un
serie de comisii.

Prima linie a mesajului de confirmare ar trebui să fie o scurtă descriere fără punct. Aceasta
nu trebuie să depășească subiectul unui e-mail, 50 de caractere fiind o regulă bună pentru
deget mare.

O mulțime de instrumente Git (Gitweb, GitHub, git log --pretty=oneline, ...) vor afișa doar
primul rând (decupat la 50 de caractere) atunci când se prezintă rezumatele de comitere.

Mesajul de confirmare ar trebui să includă o descriere a problemei pe care patch-ul o corectează sau
nouă funcționalitate pe care patch-ul le adaugă.

Ca regulă generală, mesajul dvs. de confirmare ar trebui să ajute un programator care cunoaște
Nucleul Perl înțelege rapid ce ai încercat să faci, cum ai încercat să o faci și
de ce schimbarea contează pentru Perl.

· De ce

Mesajul dvs. de confirmare ar trebui să descrie de ce este importantă schimbarea pe care o faceți. Când
cineva se uită la schimbarea ta în șase luni sau șase ani, intenția ta ar trebui să fie clară.

Dacă renunțați la o caracteristică cu intenția de a simplifica ulterior încă un pic de
cod, spune asa. Dacă remediați o problemă de performanță sau adăugați o nouă funcție la
susține o altă parte din nucleu, menționează asta.

· Ce

Mesajul dvs. de confirmare ar trebui să descrie ce parte a nucleului Perl schimbați și
ceea ce vă așteptați să facă plasturele dvs.

· Cum

Deși nu este necesar pentru modificări de documentație, teste noi sau patch-uri banale, este
deseori merită să explicați cum funcționează schimbarea dvs. Chiar dacă îți este clar astăzi, s-ar putea
să nu fie clar pentru un portar luna viitoare sau anul viitor.

Un mesaj de confirmare nu este destinat să ia locul comentariilor în codul dvs. Angajează-te
mesajele ar trebui să descrie modificarea pe care ați făcut-o, în timp ce comentariile de cod ar trebui să descrie
starea curentă a codului.

Dacă tocmai ați implementat o nouă funcție, completați cu documente, teste și bine comentate
cod, un scurt mesaj de confirmare va fi adesea suficient. Dacă, totuși, tocmai ați schimbat un
un singur caracter adânc în analizatorul sau lexerul, s-ar putea să fie nevoie să îi scrieți un mic roman
asigurați-vă că viitorii cititori înțeleg ce ați făcut și de ce ați făcut-o.

comentarii, comentarii, Comentarii

Asigurați-vă că comentați în mod adecvat codul. În timp ce comentați fiecare rând nu este necesar,
orice profită de efectele secundare ale operatorilor, care creează schimbări care vor
să fie simțit în afara funcției care este corectată sau că alții ar putea găsi confuză ar trebui să fie
documentat. Dacă ai de gând să greșești, este mai bine să greșești pe partea de a adăuga prea multe
comentarii decât prea puține.

Cele mai bune comentarii explică de ce codul face ceea ce face, nu ceea ce it face.

Stil

În general, vă rugăm să urmați stilul special al codului pe care îl corectați.

În special, urmați aceste instrucțiuni generale pentru corecția surselor Perl:

· File cu 8 largi (fără excepții!)

· 4 indentări late pentru cod, 2 indentări late pentru CPP imbricat #defines

· Încercați din greu să nu depășiți 79 de coloane

· Prototipuri ANSI C

· Uncuddled elses și stil „K&R” pentru indentarea constructelor de control

· Fără comentarii în stil C++ (//).

· Marcați locurile care trebuie să fie revizuite cu XXX (și revedeți des!)

· Acolade de deschidere se aliniază cu „dacă” atunci când condiționalul se întinde pe mai multe linii; ar trebui să fie la
sfârşitul liniei altfel

· În definițiile funcției, numele începe în coloana 0 (valoare-return-type este pe precedent
linia)

· Un singur spațiu după cuvintele cheie care sunt urmate de părinte, fără spațiu între funcție
numele și următorul părinte

· Evitați sarcinile în condiționale, dar dacă acestea sunt inevitabile, utilizați un parante suplimentar, de ex
„dacă (a && (b = c))...”

· „întoarce-te foo;” mai degrabă decât „return(foo);”

· „dacă (!foo) ...” mai degrabă decât „dacă (foo == FALS) ...” etc.

· Nu declara variabile folosind „register”. Poate fi contraproductiv cu modernul
compilatoare și este depreciat în C++, în care sursa Perl este în mod regulat
compilat.

· Funcțiile în linie care sunt în anteturi care sunt accesibile codului XS trebuie să fie capabile
pentru a compila fără avertismente cu steaguri de compilare suplimentare utilizate în mod obișnuit, cum ar fi gcc
„-Wswitch-default” care avertizează de fiecare dată când o instrucțiune de comutare nu are un „implicit”
caz. Utilizarea acestor steaguri suplimentare este pentru a surprinde probleme potențiale în codul C legal,
și este adesea folosit de agregatorii Perl, cum ar fi distribuitorii Linux.

Testare suită

Dacă patch-ul tău schimbă codul (în loc să schimbe doar documentația), ar trebui și tu
includeți unul sau mai multe cazuri de testare care ilustrează eroarea pe care o remediați sau validați noul
funcționalitatea pe care o adăugați. În general, ar trebui să actualizați mai degrabă un fișier de testare existent
decât să creeze unul nou.

Adăugările dvs. de suită de testare ar trebui, în general, să urmeze aceste linii directoare (cu amabilitatea lui Gurusamy
Sarathy[e-mail protejat]>):

· Aflați ce testați. Citiți documentele și sursa.

· Tind să eșueze, nu să reușească.

· Interpretați rezultatele cu strictețe.

· Utilizați funcții care nu au legătură (acest lucru va elimina interacțiunile bizare).

· Folosiți expresii non-standard (altfel nu testați TIMTOWTDI).

· Evitați utilizarea numerelor de test codificate ori de câte ori este posibil (așteptat/ obținut găsit în
t/op/tie.t este mult mai ușor de întreținut și oferă rapoarte de eșec mai bune).

· Dați mesaje de eroare semnificative atunci când un test eșuează.

· Evitați utilizarea qx// și sistem() cu excepția cazului în care le testezi. Daca le folosesti,
asigurați-vă că acoperiți _toate_ platformele perl.

· Deconectați toate fișierele temporare pe care le creați.

· Promovați avertismente neprevăzute la erori cu $SIG{__WARN__}.

· Asigurați-vă că utilizați bibliotecile și modulele livrate împreună cu versiunea testată, nu
cele care erau deja instalate.

· Adăugați comentarii la cod care explică pentru ce testați.

· Nu este necesară actualizarea șirului „1..42”. Sau asigurați-vă că îl actualizați.

· Testați _toate_ comportamentele unui anumit operator, bibliotecă sau funcție.

Testați toate argumentele opționale.

Testați valorile returnate în diverse contexte (boolean, scalar, list, lvalue).

Folosiți atât variabile globale, cât și lexicale.

Nu uita de cazurile excepționale, patologice.

patching a CORE modul
Acest lucru funcționează la fel ca orice altceva, cu o considerație suplimentară.

Modulele din cpan/ directorul arborelui sursă sunt menținute în afara nucleului Perl.
Când autorul actualizează modulul, actualizările sunt pur și simplu copiate în nucleu. Vezi asta
documentația modulului sau listarea acestuia pehttp://search.cpan.org/> pentru mai multe informatii despre
raportarea erorilor și trimiterea de corecții.

În cele mai multe cazuri, corecțiile la module în cpan/ ar trebui trimis în amonte și nu ar trebui să fie
aplicat la nucleul Perl individual. Dacă un patch la un fișier în cpan/ absolut nu poate
așteptați ca remedierea să fie făcută în amonte, eliberată în CPAN și copiată în blead, trebuie să adăugați
(sau actualizați) o intrare „PERSONALIZATĂ” în „Porting/Matainers.pl” fișier pentru a semnala că este local
modificarea a fost făcută. Vedea „Porting/Matainers.pl” pentru mai multe detalii.

În schimb, modulele din dist / directorul sunt menținute în nucleu.

Actualizarea perldelta
Pentru modificări suficient de semnificative pentru a justifica a pod/perldelta.pod intrarea, hamalii vor
apreciez foarte mult dacă trimiteți o intrare delta împreună cu modificarea dvs. reală.
Modificările semnificative includ, dar nu se limitează la:

· Adăugarea, deprecierea sau eliminarea caracteristicilor de bază

· Adăugarea, deprecierea, eliminarea sau actualizarea modulelor de bază sau cu durată duală

· Adăugarea de noi teste de bază

· Remedierea problemelor de securitate și a erorilor vizibile de utilizator în nucleu

· Modificări care ar putea rupe codul existent, fie la nivel perl, fie la nivel C

· Îmbunătățiri semnificative ale performanței

· Adăugarea, eliminarea sau modificarea semnificativă a documentației în păstăi/ director

· Modificări importante specifice platformei

Asigurați-vă că adăugați intrarea perldelta în secțiunea potrivită din interior
pod/perldelta.pod. Sunt disponibile mai multe informații despre cum să scrieți intrări bune perldelta
în secțiunea „Stil” din Portare/how_to_write_a_perldelta.pod.

Ce face pentru a bine plasture?
Noile funcții și extensii ale limbii pot fi controversate. Nu există un set anume
de criterii care determină ce caracteristici sunt adăugate, dar iată câteva întrebări
luați în considerare atunci când dezvoltați un plasture:

Face il concept Meci il general goluri of Perl?

Obiectivele noastre includ, dar nu se limitează la:

1. Păstrați-l rapid, simplu și util.

2. Păstrați caracteristicile/conceptele cât mai ortogonale posibil.

3. Fără limite arbitrare (platforme, dimensiuni ale datelor, culturi).

4. Păstrați-l deschis și interesant de a utiliza/patch-uri/susține Perl peste tot.

5. Fie asimilați noile tehnologii, fie construiți punți către ele.

Unde is il implementare?

Toate discuțiile din lume sunt inutile fără o implementare. În aproape toate cazurile,
Se așteaptă ca persoana sau persoanele care pledează pentru o nouă caracteristică să fie cele care implementează
aceasta. Portarii capabili să codifice noi funcții au propriile lor agende și nu sunt disponibili
pentru a-ți implementa ideea (posibil bună).

Înapoi compatibilitate

Este un păcat capital să rupi programele Perl existente. Pot fi noi avertismente
contencios -- unii spun că un program care emite avertismente nu este întrerupt, în timp ce alții spun
este. Adăugarea de cuvinte cheie are potențialul de a rupe programe, schimbând sensul
secvențele sau funcțiile de token existente ar putea rupe programe.

Nucleul Perl 5 include mecanisme pentru a ajuta portatorii să facă schimbări incompatibile cu înapoi
mai compatibile, cum ar fi modulele caracteristice și depreciate. Vă rugăm să le folosiți când
corespunzătoare.

Ar putea it be a modul in schimb?

Perl 5 are mecanisme de extensie, module și XS, special pentru a evita necesitatea păstrării
schimbarea interpretului Perl. Puteți scrie module care exportă funcții, puteți da
acele funcții prototipuri, astfel încât să poată fi numite ca funcții încorporate, puteți chiar
scrie cod XS pentru a te încurca cu structurile de date de rulare ale interpretului Perl, dacă vrei
pentru a implementa lucruri cu adevărat complicate.

Ori de câte ori este posibil, noile funcții ar trebui să fie prototipate într-un modul CPAN înainte de a fi
considerat pentru nucleu.

Is il trăsătură generic suficient?

Este ceva pe care doar persoana care trimite mesajul vrea să fie adăugat la limbă sau este în general
util? Uneori, în loc să adauge o caracteristică cu o concentrare strictă, hamalii ar putea
decideți să așteptați până când cineva implementează caracteristica mai generalizată.

Face it potenţial introduce nou gandaci?

Rescrierile radicale ale unor bucăți mari ale interpretului Perl au potențialul de a fi introduse
bug-uri noi.

Cum mare is aceasta?

Cu cât schimbarea este mai mică și mai localizată, cu atât mai bine. În mod similar, o serie de mici
plasturii este mult preferat față de un singur plasture mare.

Face it exclude alte dezirabil caracteristici?

Este posibil ca un patch să fie respins dacă închide căile viitoare de dezvoltare. Pentru
De exemplu, un patch care a plasat o interpretare adevărată și finală pe prototipuri este probabil să o facă
să fie respins deoarece există încă opțiuni pentru viitorul prototipurilor care nu au fost
adresat.

Is il implementarea robust?

Patch-urile bune (cod strict, complet, corect) au mai multe șanse de a intra. Neîngrijit sau
pe arzătorul din spate ar putea fi plasate petice incorecte până când pomparea are timp să se repare,
sau ar putea fi eliminate complet fără notificare ulterioară.

Is il implementarea generic suficient de la be portabil?

Cele mai proaste patch-uri folosesc caracteristici specifice sistemului. Este foarte puțin probabil ca non-
vor fi acceptate completări portabile în limbajul Perl.

Is il implementarea testat?

Patch-urile care schimbă comportamentul (remedierea erorilor sau introducerea de noi funcții) trebuie să includă
teste de regresie pentru a verifica dacă totul funcționează conform așteptărilor.

Fără teste furnizate de autorul original, cum poate altcineva să schimbe perl în
viitor să fii sigur că nu au rupt fără să vrea comportamentul implementat de plasture?
Și fără teste, cum poate autorul patch-ului să fie încrezător că munca sa asiduă a depus-o
plasturele nu va fi aruncat accidental de cineva în viitor?

Is acolo suficient de documentație?

Patch-urile fără documente sunt probabil prost gândite sau incomplete. Nicio caracteristică nu poate
să fie adăugate sau modificate fără documente, deci trimiterea unui patch pentru podul corespunzător
documentele, precum și codul sursă sunt importante.

Is acolo un alt mod la do aceasta?

Larry a spus: „Deși sloganul Perl este Există Mai Mult Decât O Cale la Do It, ezit
face 10 moduri de a face ceva". Aceasta este o euristică dificilă de navigat, totuși - a unui bărbat
adaosul esențial este cruft fără rost al altui om.

Face it crea de asemenea mult funcționează?

Lucru pentru pumpking, muncă pentru programatori Perl, muncă pentru autorii de module, ... Perl este
ar trebui să fie ușor.

Patch-uri vorbi mai tare decât cuvinte

Codul de lucru este întotdeauna preferat ideilor cu plăcintă în cer. Un patch pentru a adăuga o caracteristică
o șansă mult mai mare de a ajunge în limbă decât o solicită o funcție aleatorie, nu
indiferent cât de fervent ar fi argumentată cererea. Acest lucru se leagă de „Va fi util?”, așa cum
faptul că cineva și-a luat timp să facă plasturele demonstrează o dorință puternică pentru
caracteristică.

TESTARE

Nucleul folosește același stil de testare ca și restul Perl, o simplă rulare „ok/not ok”.
Test::Hamul, dar există câteva considerații speciale.

Există trei moduri de a scrie un test în nucleu: Test::Mai mult, t/test.pl și ad-hoc „print
$test ? "ok 42\n" : "nu este ok 42\n"". Decizia pe care să o utilizați depinde de ce parte a
suita de teste la care lucrați. Aceasta este o măsură pentru a preveni o defecțiune la nivel înalt (cum ar fi
ca întreruperea Config.pm) de la eșecul testelor de funcționalitate de bază.

t/test.pl biblioteca oferă unele dintre caracteristicile Test::More, dar evită încărcarea celor mai multe
module și utilizează cât mai puține funcții de bază.

Dacă scrieți propriul test, utilizați protocolul Test Anythinghttp://testanything.org>.

· t/bază, t/comp și t/opbazic

Deoarece nu știm dacă „require” funcționează sau chiar subrutine, folosiți teste ad-hoc pentru
acestea trei. Faceți cu atenție pentru a evita utilizarea funcției testate. Teste în
t/opbazic, de exemplu, au fost plasate acolo mai degrabă decât în top pentru că ei testează
funcţionalitate care t/test.pl s-a demonstrat deja că presupune că funcționează.

· t/cmd, t/alergă, t/io și top

Acum că de bază require () iar subrutinele sunt testate, puteți utiliza t/test.pl
bibliotecă.

De asemenea, puteți utiliza anumite biblioteci, cum ar fi Config, în mod condiționat, dar asigurați-vă că omiteți
testați cu grație dacă nu este acolo.

· Orice altceva

Acum că nucleul Perl este testat, Test::More poate și ar trebui să fie folosit. Poti de asemenea
utilizați suita completă de module de bază în teste.

Când spui „face test”, Perl folosește t/TEST program pentru a rula suita de teste (cu excepția sub
Win32 unde folosește t/ham in schimb). Toate testele sunt efectuate de la t/ director, nu il
directorul care conține testul. Acest lucru cauzează unele probleme cu testele în lib /, asa de
iată o oportunitate pentru niște patch-uri.

Trebuie să fii de trei ori conștient de preocupările pe mai multe platforme. Acest lucru se rezumă de obicei la utilizare
File::Spec, evitând lucruri precum „furcătură()” și „sistem()”, dacă nu este absolut necesar și
fără a presupune că un anumit caracter are o anumită valoare ordinală (punct de cod) sau că
reprezentarea sa UTF-8 este compusă din anumiți octeți.

Există mai multe funcții disponibile pentru a specifica caractere și puncte de cod în mod portabil
teste. Funcțiile întotdeauna preîncărcate „utf8::unicode_to_native()” și inversul acesteia
„utf8::native_to_unicode()” preia puncte de cod și traduce în mod corespunzător. Fișierul
t/charset_tools.pl are mai multe funcții care pot fi utile. Are versiuni ale
două funcții anterioare care iau șiruri de caractere ca intrări -- nu puncte de cod numeric unice:
„uni_to_native()” și „native_to_uni()”. Dacă trebuie să vă uitați la octeții individuali
cuprinzând un șir codificat UTF-8, „byte_utf8a_to_utf8n()” ia ca intrare un șir de
acești octeți codificați pentru o platformă ASCII și returnează șirul echivalent în versiunea nativă
platformă. De exemplu, „byte_utf8a_to_utf8n(”\xC2\xA0”)” returnează secvența de octeți pe
platforma actuală care formează UTF-8 pentru „U+00A0”, deoarece „\xC2\xA0” sunt octeții UTF-8 de pe
o platformă ASCII pentru acel punct de cod. Această funcție returnează „\xC2\xA0” pe un ASCII
platformă și „\x80\x41” pe unul EBCDIC 1047.

Dar cel mai ușor este, dacă caracterul poate fi specificat ca un literal, cum ar fi „A” sau „%”, de utilizat
acea; dacă nu este atât de specific, puteți folosi „\N{}”, dacă efectele secundare nu sunt
supărătoare. Pur și simplu specificați toate caracterele în hexadecimal, folosind „\N{U+ZZ}” în loc de
„\xZZ”. „\N{}” este numele Unicode și, prin urmare, vă oferă întotdeauna caracterul Unicode.
„\N{U+41}” este caracterul al cărui punct de cod Unicode este 0x41, prin urmare este „A” pe toate
platforme. Efectele secundare sunt:

1) Acestea selectează reguli Unicode. Asta înseamnă că în șirurile de caractere duble, șirul este
întotdeauna convertit la UTF-8 pentru a forța o interpretare Unicode (puteți
„utf8::downgrade()” apoi pentru a se converti înapoi în non-UTF8, dacă este posibil). În regulat
modele de expresie, conversia nu se face, dar dacă modificatorul setului de caractere
altfel ar fi „/d”, se schimbă în „/u”.

2) Dacă utilizați formularul „\N{caracter Nume}", modulul Charnames devine automat
încărcat. Este posibil să nu fie potrivit pentru nivelul de testare pe care îl faceți.

Dacă testați localități (consultați perllocale), există funcții de ajutor în t/loc_tools.pl
pentru a vă permite să vedeți ce localități există pe platforma curentă.

Special "face Test" obiective
Există diverse ținte speciale care pot fi folosite pentru a testa Perl ușor diferit
decât ținta standard de „test”. Nu se așteaptă ca toți să ofere o rată de succes de 100%.
Multe dintre ele au mai multe pseudonime, iar multe dintre ele nu sunt disponibile pentru anumite operațiuni
sisteme.

· test_portare

Acest lucru rulează câteva teste de bază pe arborele sursă și ajută la identificarea erorilor de bază
înainte de a trimite un patch.

· minitest

Alerga miniperl on t/bază, t/comp, t/cmd, t/alergă, t/io, top, t/uni și t/mro teste.

· test.valgrind verificare.valgrind

(Numai în Linux) Rulați toate testele folosind instrumentul de scurgere de memorie + instrument de acces la memorie obraznic
„valgrind”. Fișierele jurnal vor fi denumite testname.valgrind.

· ham_test

Rulați suita de teste cu t/ham program de control, în loc de t/TEST.
t/ham este mai sofisticat și folosește modulul Test::Harness, folosindu-l astfel
ținta testului presupune că perl funcționează în mare parte. Principalul avantaj pentru scopurile noastre este
că tipărește un rezumat detaliat al testelor nereușite la sfârșit. De asemenea, spre deosebire de t/TEST, Aceasta
nu redirecționează stderr către stdout.

Rețineți că sub Win32 t/ham este întotdeauna folosit în loc de t/TEST, deci nu există
țintă specială „test_harness”.

Sub ținta „test” Win32, puteți utiliza mediul TEST_SWITCHES și TEST_FILES
variabile pentru a controla comportamentul t/ham. Asta înseamnă că poți spune

nmake test TEST_FILES="op/*.t"
nmake test TEST_SWITCHES="-torture" TEST_FILES="op/*.t"

· test-notty test_notty

Setează PERL_SKIP_TTY_TEST la adevărat înainte de a rula testul normal.

Paralel teste
Distribuția de bază își poate rula acum testele de regresie în paralel pe platforme asemănătoare Unix.
În loc să rulați „make test”, setați „TEST_JOBS” în mediul dvs. la numărul de teste
să ruleze în paralel și să ruleze „make test_harness”. Pe o coajă asemănătoare Bourne, acest lucru se poate face
as

TEST_JOBS=3 make test_harness # Rulați 3 teste în paralel

Se folosește o variabilă de mediu, mai degrabă decât se face în paralel, deoarece TAP::Harness
trebuie să poată programa în sine scripturi de testare individuale, fără conflicte, și există
nu există o interfață standard pentru a „face” utilitare care să interacționeze cu programatorii lor de locuri de muncă.

Rețineți că, în prezent, unele scripturi de testare pot eșua atunci când sunt rulate în paralel (mai ales
ext/IO/t/io_dir.t). Dacă este necesar, executați din nou doar scripturile eșuate, secvenţial și vedeţi
dacă eșecurile dispar.

Alergare teste by mână
Puteți rula o parte din suita de teste manual, utilizând una dintre următoarele comenzi de la
t/ director:

./perl -I../ lib TEST lista de fișiere .t

or

./perl -I../ lib exploatează lista de fișiere .t

(Dacă nu specificați scripturi de testare, va fi rulată întreaga suită de teste.)

Utilizarea t/ham pentru de testare
Dacă utilizați „harness” pentru testare, aveți la dispoziție mai multe opțiuni de linie de comandă.
Argumentele sunt după cum urmează și sunt în ordinea în care trebuie să apară dacă sunt folosite împreună.

harness -v -torture -re=pattern LISTA FIȘIERE DE TESTAT
ham -v -tortura -re LISTA DE MODELE DE POTRIVIT

Dacă „LIST OF FILES TO TEST” este omis, lista de fișiere este obținută din manifest. The
lista de fișiere poate include metacaracterele shell care vor fi extinse.

· -v

Rulați testele în modul verbose, astfel încât să puteți vedea ce teste au fost executate și să remediați rezultatul.

· -tortura

Rulați testele de tortură, precum și setul normal.

· -re=PATTERN

Filtrați lista de fișiere astfel încât toate fișierele de testare rulate să se potrivească cu PATTERN. Rețineți că aceasta
forma este distinctă de -re LISTA OF MODELELOR formularul de mai jos prin faptul că permite fișierul
lista care urmează să fie furnizată de asemenea.

· -re LISTA DE MODELE

Filtrați lista de fișiere astfel încât toate fișierele de testare rulate să se potrivească cu /(LISTA|OF|PATTERNS)/. notițe
că cu această formă modelele sunt unite prin '|' și nu puteți furniza o listă de
fișierele, în schimb fișierele de testare sunt obținute din MANIFEST.

Puteți rula un test individual printr-o comandă similară cu

./perl -I../ lib cale/spre/picior.t

cu excepția faptului că hamurile stabilesc unele variabile de mediu care pot afecta execuția
a testului:

· PERL_CORE=1

indică faptul că rulăm acest test ca parte a suitei de teste de bază perl. Aceasta este
util pentru modulele care au o durată de viață duală pe CPAN.

· PERL_DESTRUCT_LEVEL=2

este setat la 2 dacă nu este deja setat (vezi „PERL_DESTRUCT_LEVEL” în perlhacktips).

· PERL

(utilizat numai de t/TEST) dacă este setat, suprascrie calea către executabilul perl care ar trebui să fie
folosit pentru a rula testele (prestabilit fiind ./perl).

· PERL_SKIP_TTY_TEST

dacă este setat, spune să săriți peste testele care necesită un terminal. De fapt, este setat automat
de Makefile, dar poate fi forțat și artificial prin rularea „make test_notty”.

Altele mediu inconjurator variabile acea Mai influență teste

· PERL_TEST_Net_Ping

Setarea acestei variabile rulează toate testele modulelor Net::Ping, altfel unele teste
interacționarea cu lumea exterioară sunt ignorate. Vezi perl58delta.

· PERL_TEST_NOVREXX

Setarea acestei variabile omite testele vrexx.t pentru OS2::REXX.

· PERL_TEST_NUMCONVERTS

Aceasta setează o variabilă în op/numconvert.t.

· PERL_TEST_MEMORY

Setarea acestei variabile include testele în t/bigmem/. Acesta ar trebui setat la
numărul de gigaocteți de memorie disponibili pentru testare, de ex. „PERL_TEST_MEMORY=4”
indică faptul că testele care necesită 4GiB de memorie disponibilă pot fi executate în siguranță.

Consultați și documentația pentru modulele Test și Test::Harness, pentru mai mult mediu
variabile care afectează testarea.

Performanţă de testare
Fișierul t/perf/benchmarks conține fragmente de cod perl care sunt destinate să fie
comparat într-o gamă de perls de către Portare/bancă.pl instrument. Dacă remediați sau îmbunătățiți un
problema de performanță, poate doriți să adăugați un eșantion de cod reprezentativ la fișier, apoi să rulați
bancă.pl față de perlurile anterioare și actuale pentru a vedea ce diferență a făcut și
dacă altceva a încetinit ca o consecință.

Fișierul t/perf/opcount.t este conceput pentru a testa dacă un anumit fragment de cod a fost
compilate într-un arbore opt care conține un număr specificat de anumite tipuri de operațiuni. Este bun
pentru a testa dacă optimizările care modifică operațiunile, cum ar fi conversia unei operațiuni „aelem” în
o opțiune „aelemfast”, chiar fac asta.

Fișierele t/perf/viteză.t și t/re/viteza.t sunt concepute pentru a testa lucruri care rulează mii
de ori mai lent dacă o anumită optimizare este întreruptă (de exemplu, memoria cache de lungime utf8
pe șiruri lungi de utf8). Adaugă un test care va dura o fracțiune de secundă în mod normal și
minute în caz contrar, ceea ce face ca fișierul de test să expire în caz de eșec.

MAI MULT CITIND PENTRU GUTS HACKERI

Pentru a pirata curajul Perl, va trebui să citiți următoarele lucruri:

· perlsource

O prezentare generală a arborelui sursă Perl. Acest lucru vă va ajuta să găsiți fișierele pe care le căutați
pentru.

· perlinterp

O prezentare generală a codului sursă al interpretului Perl și câteva detalii despre modul în care Perl face ce
da.

· perlhacktut

Acest document parcurge crearea unui mic patch la codul C al Perl. Daca esti
tocmai am început cu hacking-ul de bază Perl, acest lucru vă va ajuta să înțelegeți cum se face
funcționează.

· sfaturi perlhack

Mai multe detalii despre piratarea nucleului Perl. Acest document se concentrează pe detalii de nivel inferior
cum ar fi cum să scrieți teste, probleme de compilare, portabilitate, depanare etc.

Dacă intenționați să faceți hacking serios C, asigurați-vă că citiți acest lucru.

· perlguts

Acest lucru este de o importanță capitală, deoarece este documentarea a ceea ce merge unde se află
sursa Perl. Citiți-l de câteva ori și poate începe să aibă sens -
nu-ți face griji dacă nu este încă, pentru că cel mai bun mod de a-l studia este să-l citești
împreună cu accesarea sursei Perl, și vom face asta mai târziu.

„Perlguts ilustrat” al lui Gisle Aas, cunoscut și ca illguts, are poze foarte utile:

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

· perlxstut și perlxs

O cunoaștere de lucru a programării XSUB este incredibil de utilă pentru hacking-ul de bază; XSUB-uri
utilizați tehnici extrase din codul PP, porțiunea din curajul care se execută efectiv
un program Perl. Este mult mai blând să înveți acele tehnici din exemple simple și
explicație decât din miezul însuși.

· perlapi

Documentația pentru API-ul Perl explică ce fac unele dintre funcțiile interne, cum ar fi
precum și numeroasele macrocomenzi utilizate în sursă.

· Portare/dovleac.pod

Aceasta este o colecție de cuvinte de înțelepciune pentru un portar Perl; unele dintre ele sunt doar utile
pentru suportul de dovleac, dar cea mai mare parte se aplică oricui dorește să se ocupe de Perl
de dezvoltare.

CPAN TESTERE AND PERL FUMATORII

Testerii CPAN ( http://testers.cpan.org/ ) sunt un grup de voluntari care testează CPAN
module pe o varietate de platforme.

Perl fumători ( http://www.nntp.perl.org/group/perl.daily-build/ și
http://www.nntp.perl.org/group/perl.daily-build.reports/ ) testează automat sursa Perl
lansări pe platforme cu diverse configurații.

Ambele eforturi salută voluntari. Pentru a se implica în testarea fumului perl
însuși vizitahttp://search.cpan.org/dist/Test-Smoke/>. Pentru a începe testarea fumului
Vizita modulelor CPANhttp://search.cpan.org/dist/CPANPLUS-YACSmoke/> sau
<http://search.cpan.org/dist/minismokebox/> sau
<http://search.cpan.org/dist/CPAN-Reporter/>.

CE URMĂTORUL?

Dacă ați citit toată documentația din document și pe cele enumerate mai sus, sunteți
mai mult decât gata să pirateze Perl.

Iată mai multe recomandări

· Abonați-vă la perl5-porters, urmați patch-urile și încercați să le înțelegeți; nu fii
frică să întrebi dacă există o porțiune pe care nu ești clar - cine știe, s-ar putea să descoperi o
bug in patch...

· Citiți README asociat cu sistemul dumneavoastră de operare, de exemplu README.aix pe IBM
OS AIX. Nu ezitați să furnizați patch-uri pentru acel README dacă găsiți ceva lipsă
sau schimbat cu o nouă lansare a sistemului de operare.

· Găsiți o zonă din Perl care vi se pare interesantă și vedeți dacă puteți înțelege cum
lucrări. Scanați prin sursă și treceți peste ea în depanator. Joacă, împinge,
investighează, lăutarule! Probabil vei ajunge să înțelegi nu doar zona aleasă, ci și a
gamă mult mai largă de perlactivitatea lui și, probabil, mai devreme decât ați crede.

" drum merge vreodată on și ea jos din il uşă Unde it a început."
Dacă puteți face aceste lucruri, ați început drumul lung către portarea Perl. Multumesc pentru
dorind să contribuie la îmbunătățirea Perl - și hacking fericit!

Metaforic Cotațiile
Dacă ai recunoscut citatul despre Drum de mai sus, ai noroc.

Majoritatea proiectelor software încep fiecare fișier cu o descriere literală a scopului fiecărui fișier.
În schimb, Perl începe fiecare cu o aluzie literară la scopul acelui fișier.

Asemenea capitolelor din multe cărți, toate fișierele sursă Perl de nivel superior (împreună cu alte câteva aici
și acolo) încep cu o inscripție epigramatică care face aluzie, indirect și
metaforic, la materialul pe care urmează să-l citiți.

Citatele sunt luate din scrierile lui JRR Tolkien referitoare la Legendarium-ul său, aproape
mereu din facand of il Inele. Capitolele și numerele paginilor sunt date folosind
următoarele ediții:

· Hobbit, de JRR Tolkien. Copertul cartonat, ediția a 70-a aniversare din 2007 a fost
folosit, publicat în Marea Britanie de Harper Collins Publishers și în SUA de Houghton
Compania Mifflin.

· facand of il Inele, de JRR Tolkien. Copertă cartonată, ediția a 50-a aniversare a
A fost folosit 2004, publicat în Marea Britanie de Harper Collins Publishers și în SUA de către
Compania Houghton Mifflin.

· Lays of Beleriand, de JRR Tolkien și publicat postum de fiul său și
executor literar, CJR Tolkien, fiind al 3-lea din cele 12 volume din cartea lui Christopher.
mamut Istorie of De mijloc Pământ. Numerele paginilor provin din ediția hardcover,
publicat pentru prima dată în 1983 de George Allen & Unwin; nu s-au schimbat numere de pagină pentru
ediția specială omnibus în 3 volume din 2002 sau diferitele ediții comerciale, toate
iar acum de Harper Collins sau Houghton Mifflin.

Alte cărți JRRT joc echitabil pentru citate ar include astfel aventuri of Tom Bombadil,
Silmarillion, Neterminat Tales și Poveste of il Copii of Hurin, toate în afară de
prima dată asamblată postum de CJRT. Dar facand of il Inele în sine este perfect în regulă
și probabil cel mai bine să citați, cu condiția să găsiți acolo o cotație potrivită.

Deci, dacă ar trebui să furnizați un fișier sursă nou, complet, de nivel superior, pe care să îl adăugați la Perl, ar trebui
conformați-vă acestei practici deosebite selectând singur un citat adecvat din
Tolkien, păstrând ortografia și punctuația originale și folosind același format
restul citatelor sunt în. Indirect și oblic este foarte bine; ține minte, este o metaforă,
deci a fi meta este, la urma urmei, pentru ce este.

Utilizați perlhack online folosind serviciile onworks.net