perlhack - Online na nuvem

PROGRAMA:

NOME

perlhack - Como hackear Perl

DESCRIÇÃO

Este documento explica como funciona o desenvolvimento em Perl. Inclui detalhes sobre o Perl 5
Lista de e-mail de Porters, o repositório Perl, o rastreador de bug Perlbug, diretrizes de patch e
comentário sobre a filosofia de desenvolvimento Perl.

SUPER QUICK PATCH GUIA

Se você deseja apenas enviar um único pequeno patch, como uma correção de pod, um teste para um bug, comente
correções, etc., é fácil! Veja como:

· Confira o repositório de origem

A fonte perl está em um repositório git. Você pode clonar o repositório com o
seguinte comando:

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

· Certifique-se de seguir os conselhos mais recentes

Caso o conselho neste guia tenha sido atualizado recentemente, leia a versão mais recente
diretamente da fonte perl:

% perldoc pod / perlhack.pod

· Faça sua mudança

Hack, hack, hack. Tenha em mente que Perl roda em muitas plataformas diferentes, com
diferentes sistemas operacionais que têm diferentes recursos, diferentes sistemas de arquivos
organizações e até mesmo conjuntos de caracteres diferentes. perlhacktips dá conselhos sobre isso.

· Teste sua mudança

Você pode executar todos os testes com os seguintes comandos:

% ./Configure -des -Dusedevel
% fazer teste

Continue hackeando até que os testes passem.

· Comprometa sua mudança

Comprometer seu trabalho salvará a mudança on os local .:

% git commit -a -m 'Mensagem de confirmação vai aqui'

Certifique-se de que a mensagem de confirmação descreve sua mudança em uma única frase. Por exemplo,
"Corrigidos erros de grafia em perlhack.pod".

· Envie sua mudança para perlbug

A próxima etapa é enviar seu patch para o sistema de tíquetes do núcleo Perl por e-mail.

Se suas alterações estiverem em um único git commit, execute os seguintes comandos para gerar o
arquivo de patch e anexe-o ao seu relatório de bug:

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

O programa perlbug fará algumas perguntas sobre o seu endereço de e-mail e o
patch que você está enviando. Depois de respondê-las, ele enviará seu patch via
o email.

Se suas alterações forem em vários commits, gere um arquivo de patch para cada um e
forneça-os para a opção "-p" do perlbug separados por vírgulas:

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

Quando solicitado, escolha um assunto que resuma suas mudanças.

· Obrigado

Os porteiros apreciam o tempo que você gastou ajudando a tornar o Perl melhor. Obrigado!

· Próxima vez

Na próxima vez que você quiser fazer um patch, você precisa começar do último perl em um
estado primitivo. Verifique se você não tem nenhuma alteração local ou arquivos adicionados em seu perl
check-out que você deseja manter e, em seguida, execute estes comandos:

% git pull
% git reset --hard origin / blead
% git limpo -dxf

ERRO RELATÓRIOS

Se você quiser relatar um bug no Perl, você deve usar o perlbug ferramenta de linha de comando. Esse
ferramenta irá garantir que o seu relatório de bug inclui todo o sistema e configuração relevantes
informações.

Para navegar pelos bugs e patches existentes do Perl, você pode usar a interface da web em
<http://rt.perl.org/>.

Por favor, verifique o arquivo da lista perl5-porters (veja abaixo) e / ou o rastreamento de bugs
sistema antes de enviar um relatório de bug. Freqüentemente, você descobrirá que o bug foi relatado
já.

Você pode entrar no sistema de rastreamento de bugs e comentar sobre os relatórios de bugs existentes. Se você
tiver informações adicionais sobre um bug existente, adicione-as. Isso vai ajudar o
carregadores corrigem o bug.

PERL 5 PORTEIROS

A lista de discussão perl5-porters (p5p) é onde a distribuição padrão Perl é mantida
e desenvolvido. As pessoas que mantêm Perl também são chamadas de "Perl 5 Porters",
"p5p" ou apenas os "porteiros".

Um arquivo pesquisável da lista está disponível em
<http://markmail.org/search/? q = perl5-porters>. Também existe um arquivo em
<http://archive.develooper.com/perl5-porters@ perl.org />.

Perl-changes correspondência Lista
A lista de discussão perl5-changes recebe uma cópia de cada patch enviado ao
ramos de manutenção e desenvolvimento do repositório perl. Ver
<http://lists.perl.org/list/perl5-changes.html> para inscrição e informações de arquivo.

# p5p on IRC
Muitos carregadores também são ativos no canal. Sinta-se à vontade para entrar
o canal e faça perguntas sobre como hackear o núcleo Perl.

OBTENDO A PERL FONTE

Todo o código-fonte do Perl é mantido centralmente em um repositório Git em perl5.git.perl.org.
O repositório contém muitas revisões Perl de Perl 1 em diante e todas as revisões de
Perforce, o sistema de controle de versão anterior.

Para obter mais detalhes sobre o uso do git com o repositório Perl, consulte perlgit.

Leia Acesso via Git
Você precisará de uma cópia do Git para o seu computador. Você pode buscar uma cópia do repositório
usando o protocolo git:

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

Isso clona o repositório e faz uma cópia local no perl diretório.

Se você não pode usar o protocolo git por motivos de firewall, você também pode clonar via http,
embora seja muito mais lento:

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

Leia Acesso via da web
Você pode acessar o repositório pela web. Isso permite que você navegue na árvore, consulte
commits recentes, inscreva-se em feeds RSS para as mudanças, pesquise por commits específicos e
mais. Você pode acessá-lo emhttp://perl5.git.perl.org/perl.git>. Um espelho do
repositório é encontrado em .

Leia Acesso via rsync
Você também pode optar por usar o rsync para obter uma cópia da árvore de origem atual para o
ramo bleadperl e todos os ramos de manutenção:

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

(Adicione a opção "--delete" para remover arquivos restantes.)

Para obter uma lista completa dos pontos de sincronização disponíveis:

% rsync perl5.git.perl.org ::

Escreva Acesso via git
Se você tem um bit de commit, por favor veja perlgit para mais detalhes sobre como usar o git.

REMENDO PERL

Se você está planejando fazer um trabalho mais extenso do que uma única pequena correção, nós o encorajamos a
leia a documentação abaixo. Isso ajudará você a focar seu trabalho e fazer seus patches
mais fácil de incorporar na fonte Perl.

Submetendo a solicitação do remendos
Se você tiver um pequeno patch para enviar, envie-o via perlbug. Você também pode enviar
e-mail diretamente para [email protegido]. Por favor, note que as mensagens enviadas para perlbug podem ser retidas
em uma fila de moderação, para que você não receba uma resposta imediatamente.

Você saberá que seu envio foi processado quando receber um e-mail de nosso tíquete
sistema de rastreamento. Este e-mail fornecerá um número de tíquete. Assim que o seu patch estiver pronto
para o sistema de rastreamento de tíquetes, ele também será enviado para o [email protegido] Lista.

Os patches são revisados ​​e discutidos na lista p5p. Patches simples e incontroversos irão
geralmente é aplicado sem qualquer discussão. Quando o patch for aplicado, o tíquete será
atualizado e você receberá e-mail. Além disso, um e-mail será enviado para a lista p5p.

Em outros casos, o patch precisará de mais trabalho ou discussão. Isso vai acontecer no p5p
Lista.

Você é incentivado a participar da discussão e defender seu patch.
Às vezes, seu patch pode se perder no shuffle. É apropriado enviar um lembrete
e-mail para p5p se nenhuma ação tiver sido realizada em um mês. Lembre-se de que o Perl 5
os desenvolvedores são todos voluntários e sejam educados.

As alterações são sempre aplicadas diretamente ao branch principal de desenvolvimento, denominado "blead". Algum
patches podem ser portados para uma filial de manutenção. Se você acha que seu patch é apropriado
para o ramo de manutenção (ver "FILIAIS DE MANUTENÇÃO" na perlpolicy), explique o porquê
quando você o enviar.

Obtendo os remendo aceito
Se você estiver enviando um patch de código, há várias coisas que você pode fazer para ajudar o
Perl 5 Porters aceita seu patch.

Remendo estilo

Se você usou git para verificar o código-fonte Perl, usar "git format-patch" produzirá um
patch em um estilo adequado para Perl. O comando "format-patch" produz um arquivo de patch
para cada commit que você fez. Se você preferir enviar um único patch para todos os commits, você pode
use "git diff".

% git checkout sangrento
% git pull
% git diff blead nome-meu-ramo

Isso produz um patch baseado na diferença entre blead e seu branch atual. Isso é
importante ter certeza de que o blead está atualizado antes de produzir o diff, é por isso que
chame "git pull" primeiro.

Recomendamos fortemente que você use o git, se possível. Isso tornará sua vida mais fácil, e
o nosso também.

No entanto, se você não estiver usando o git, ainda poderá produzir um patch adequado. Você vai precisar de um
cópia original da fonte Perl para comparação. Os carregadores preferem diffs unificados.
Usando GNU "diff", você pode produzir um diff como este:

% diff -Npurd perl.pristine perl.mine

Certifique-se de "fazer uma limpeza real" em sua cópia do Perl para remover quaisquer artefatos de construção, ou
você pode obter um resultado confuso.

COMPROMETA-SE mensagem

Conforme você cria cada patch que pretende enviar para o núcleo Perl, é importante escrever um
boa mensagem de commit. Isso é especialmente importante se o seu envio consistir em um
série de confirmações.

A primeira linha da mensagem de confirmação deve ser uma breve descrição sem ponto. Isto
não deve ultrapassar o assunto de um e-mail, sendo 50 caracteres uma boa regra de
polegar.

Muitas ferramentas Git (Gitweb, GitHub, git log --pretty = oneline, ...) exibirão apenas o
primeira linha (corte em 50 caracteres) ao apresentar resumos de commit.

A mensagem de confirmação deve incluir uma descrição do problema que o patch corrige ou
nova funcionalidade que o patch adiciona.

Como regra geral, sua mensagem de commit deve ajudar um programador que conhece o
Perl core rapidamente entender o que você estava tentando fazer, como você estava tentando fazer, e
por que a mudança é importante para o Perl.

· Por que

Sua mensagem de confirmação deve descrever porque a mudança que você está fazendo é importante. Quando
Se alguém olhar sua mudança em seis meses ou seis anos, sua intenção deve ser clara.

Se você está descontinuando um recurso com a intenção de posteriormente simplificar um pouco mais de
código, diga isso. Se você está corrigindo um problema de desempenho ou adicionando um novo recurso ao
apoiar alguma outra parte do núcleo, mencione isso.

· O que

Sua mensagem de confirmação deve descrever que parte do núcleo Perl você está mudando e
o que você espera que seu patch faça.

· Quão

Embora não seja necessário para mudanças na documentação, novos testes ou patches triviais, é
frequentemente vale a pena explicar como sua mudança funciona. Mesmo que esteja claro para você hoje, pode
não ficar claro para um porteiro no próximo mês ou no próximo ano.

Uma mensagem de confirmação não tem a intenção de substituir os comentários em seu código. Comprometer-se
as mensagens devem descrever a mudança que você fez, enquanto os comentários do código devem descrever o
estado atual do código.

Se você acabou de implementar um novo recurso, completo com doc, testes e comentários bem comentados
código, uma breve mensagem de confirmação será suficiente. Se, no entanto, você acabou de mudar um
único caractere profundo no analisador ou lexer, você pode precisar escrever um pequeno romance para
certifique-se de que os leitores futuros entendam o que você fez e por que o fez.

Comentários, Comentários, Comentários

Certifique-se de comentar adequadamente seu código. Embora comentar cada linha seja desnecessário,
qualquer coisa que aproveite os efeitos colaterais dos operadores, que crie mudanças que irão
ser sentido fora da função que está sendo corrigida, ou que outros possam achar confuso deveria ser
documentado. Se você vai errar, é melhor errar por adicionar muitos
comentários do que poucos.

Os melhores comentários explicam porque o código faz o que faz, não o que it parece.

Style

Em geral, siga o estilo específico do código que você está corrigindo.

Em particular, siga estas diretrizes gerais para corrigir fontes Perl:

· Abas de 8 (sem exceções!)

· Recuos de 4 largos para código, recuos de 2 largos para CPP aninhado # define

· Tente ao máximo não exceder 79 colunas

· Protótipos ANSI C

· Elses desimpedidos e estilo "K&R" para indentação de construções de controle

· Sem comentários de estilo C ++ (//)

· Marque lugares que precisam ser revisitados com XXX (e revisite com frequência!)

· Abrindo linhas de chave com "if" quando condicional abrange várias linhas; deveria estar em
fim de linha, caso contrário

· Nas definições de função, o nome começa na coluna 0 (o tipo de valor de retorno está no anterior
linha)

· Espaço único após as palavras-chave seguidas de parênteses, sem espaço entre as funções
nome e parênteses seguintes

· Evite atribuições em condicionais, mas se forem inevitáveis, use parênteses extras, por exemplo
"if (a && (b = c)) ..."

· "Return foo;" em vez de "return (foo);"

· "If (! Foo) ..." em vez de "if (foo == FALSE) ..." etc.

· Não declare variáveis ​​usando "registrar". Pode ser contraproducente com o moderno
compiladores, e está obsoleto em C ++, sob o qual a fonte Perl é regularmente
compilado.

· As funções in-line que estão em cabeçalhos acessíveis ao código XS precisam ser capazes de
para compilar sem avisos com sinalizadores de compilação extra comumente usados, como gcc's
"-Wswitch-default" que avisa sempre que uma instrução switch não tem um "default"
caso. O uso dessas sinalizações extras é para detectar problemas potenciais no código C legal,
e é freqüentemente usado por agregadores Perl, como distribuidores Linux.

Teste suíte

Se o seu patch muda o código (em vez de apenas mudar a documentação), você também deve
incluem um ou mais casos de teste que ilustram o bug que você está corrigindo ou validam o novo
funcionalidade que você está adicionando. Em geral, você deve atualizar um arquivo de teste existente em vez
do que criar um novo.

As adições de sua suíte de teste geralmente devem seguir estas diretrizes (cortesia de Gurusamy
Sarathy[email protegido]>):

· Saiba o que você está testando. Leia a documentação e a fonte.

· Tendem ao fracasso, não têm sucesso.

· Interprete os resultados estritamente.

· Use recursos não relacionados (isso eliminará interações bizarras).

· Use expressões idiomáticas não padrão (caso contrário, você não está testando o TIMTOWTDI).

· Evite usar números de teste codificados sempre que possível (o ESPERADO / GOT encontrado em
t / op / tie.t é muito mais fácil de manter e fornece melhores relatórios de falha).

· Fornece mensagens de erro significativas quando um teste falha.

· Evite usar qx // e sistema() a menos que você esteja testando para eles. Se você os usar,
certifique-se de cobrir _todas_ as plataformas perl.

· Desvincule todos os arquivos temporários que você criar.

· Promova avisos imprevistos de erros com $ SIG {__ WARN__}.

· Certifique-se de usar as bibliotecas e módulos enviados com a versão que está sendo testada, não
aqueles que já foram instalados.

· Adicione comentários ao código explicando o que você está testando.

· Torne a atualização da string '1..42' desnecessária. Ou certifique-se de atualizá-lo.

· Teste _todos_ os comportamentos de um determinado operador, biblioteca ou função.

Teste todos os argumentos opcionais.

Teste os valores de retorno em vários contextos (booleano, escalar, lista, lvalue).

Use variáveis ​​globais e lexicais.

Não se esqueça dos casos excepcionais e patológicos.

Patching a core módulo
Isso funciona como corrigir qualquer outra coisa, com uma consideração extra.

Módulos no cpan / O diretório da árvore de origem é mantido fora do núcleo Perl.
Quando o autor atualiza o módulo, as atualizações são simplesmente copiadas para o núcleo. Veja isso
documentação do módulo ou sua listagem emhttp://search.cpan.org/> para mais informações sobre
relatando bugs e enviando patches.

Na maioria dos casos, patches para módulos em cpan / deve ser enviado a montante e não deve ser
aplicado ao núcleo Perl individualmente. Se um patch para um arquivo em cpan / absolutamente não pode
aguarde a correção ser feita no upstream, liberada para CPAN e copiada para blead, você deve adicionar
(ou atualizar) uma entrada "PERSONALIZADA" no "Porting / Maintainers.pl" arquivo para sinalizar que um local
modificação foi feita. Ver "Porting / Maintainers.pl" para mais detalhes.

Em contraste, os módulos no dist / diretório são mantidos no núcleo.

Atualizando perldelta
Para mudanças significativas o suficiente para justificar um pod / perldelta.pod entrada, os carregadores irão
Agradecemos imensamente se você enviar uma entrada delta junto com sua alteração real.
Mudanças significativas incluem, mas não estão limitadas a:

· Adicionar, descontinuar ou remover recursos principais

· Adicionar, descontinuar, remover ou atualizar módulos centrais ou dual-life

· Adicionar novos testes básicos

· Correção de problemas de segurança e bugs visíveis ao usuário no núcleo

· Mudanças que podem quebrar o código existente, seja no nível perl ou C

· Melhorias significativas de desempenho

· Adicionar, remover ou alterar significativamente a documentação no pod / anuário

· Importantes mudanças específicas da plataforma

Certifique-se de adicionar a entrada perldelta à seção correta dentro
pod / perldelta.pod. Mais informações sobre como escrever boas entradas de perldelta estão disponíveis
na seção "Estilo" de Porting / how_to_write_a_perldelta.pod.

O Quê faz for a Bom estado, com sinais de uso patch?
Novos recursos e extensões para a linguagem podem ser controversos. Não há um conjunto específico
de critérios que determinam quais recursos são adicionados, mas aqui estão algumas perguntas para
considere ao desenvolver um patch:

Será que da conceito partida da geral metas of Perl?

Nossos objetivos incluem, mas não estão limitados a:

1. Mantenha-o rápido, simples e útil.

2. Mantenha os recursos / conceitos o mais ortogonais possível.

3. Sem limites arbitrários (plataformas, tamanhos de dados, culturas).

4. Mantenha-o aberto e estimulante para usar / patch / defender Perl em todos os lugares.

5. Assimile novas tecnologias ou construa pontes para elas.

Onde is da implementação?

Toda a conversa do mundo é inútil sem uma implementação. Em quase todos os casos, o
espera-se que a pessoa ou pessoas que defendem um novo recurso sejam as que implementam
isto. Porteiros capazes de codificar novos recursos têm suas próprias agendas e não estão disponíveis
para implementar sua ideia (possivelmente boa).

Para trás compatibilidade

É um pecado capital quebrar programas Perl existentes. Novos avisos podem ser
controverso - alguns dizem que um programa que emite avisos não está quebrado, enquanto outros dizem
isto é. Adicionar palavras-chave tem o potencial de interromper programas, mudando o significado de
sequências ou funções de token existentes podem interromper programas.

O núcleo do Perl 5 inclui mecanismos para ajudar os portadores a fazer alterações incompatíveis com versões anteriores
mais compatível, como o recurso e os módulos obsoletos. Use-os quando
apropriado.

Poderia it be a módulo em vez de?

Perl 5 possui mecanismos de extensão, módulos e XS, especificamente para evitar a necessidade de manter
alterando o interpretador Perl. Você pode escrever módulos que exportam funções, você pode fornecer
esses protótipos de funções para que possam ser chamados como funções integradas, você pode até
escrever código XS para mexer com as estruturas de dados em tempo de execução do interpretador Perl se você quiser
para implementar coisas realmente complicadas.

Sempre que possível, novos recursos devem ser prototipados em um módulo CPAN antes de serem
considerado para o núcleo.

Is da integrado genérico o suficiente?

Isso é algo que apenas o remetente deseja adicionar ao idioma ou é amplamente
útil? Às vezes, em vez de adicionar um recurso com um foco restrito, os carregadores podem
decida esperar até que alguém implemente o recurso mais generalizado.

Será que it potencialmente introduzir novo insetos?

Reescritas radicais de grandes pedaços do interpretador Perl têm o potencial de introduzir
novos bugs.

Como funciona o dobrador de carta de canal big is isso?

Quanto menor e mais localizada a mudança, melhor. Da mesma forma, uma série de pequenas
patches é muito preferido em vez de um único patch grande.

Será que it impedir de outros desejável características?

Um patch provavelmente será rejeitado se fechar futuras avenidas de desenvolvimento. Para
por exemplo, um patch que colocou uma interpretação verdadeira e final nos protótipos provavelmente
ser rejeitado porque ainda há opções para o futuro de protótipos que não foram
endereçado.

Is da implementação robusto?

Boas correções (código restrito, completo, correto) têm mais chance de entrar.
remendos incorretos podem ser colocados em banho-maria até que o bombeamento tenha tempo para consertar,
ou pode ser totalmente descartado sem aviso prévio.

Is da implementação genérico suficiente para be portátil?

Os piores patches usam recursos específicos do sistema. É altamente improvável que
adições portáteis à linguagem Perl serão aceitas.

Is da implementação testado?

Patches que mudam o comportamento (corrigindo bugs ou introduzindo novos recursos) devem incluir
testes de regressão para verificar se tudo funciona conforme o esperado.

Sem os testes fornecidos pelo autor original, como alguém pode mudar o perl no
futuro, certifique-se de que eles não quebraram inadvertidamente o comportamento que o patch implementa?
E sem testes, como o autor do patch pode ter certeza de que seu trabalho árduo foi colocado em
o patch não será acidentalmente jogado fora por alguém no futuro?

Is lá suficiente documentação?

Patches sem documentação são provavelmente mal pensados ​​ou incompletos. Nenhum recurso pode
ser adicionado ou alterado sem documentação, portanto, enviar um patch para o pod apropriado
documentos, bem como o código-fonte é importante.

Is lá outra maneira para do isso?

Larry disse: "Embora o Slogan Perl seja Há Mais Do que completa Maneira para Do It, Eu hesito em
faça 10 maneiras de fazer algo ". Esta é uma heurística complicada de navegar, no entanto - para um homem
o acréscimo essencial é a porcaria inútil de outro homem.

Será que it crio também muito funciona?

Trabalho para o bombeamento, trabalho para programadores Perl, trabalho para autores de módulos, ... Perl é
deveria ser fácil.

Patches falar Louder do que palavras

O código de trabalho é sempre preferível a ideias fantásticas. Um patch para adicionar um recurso está
uma chance muito maior de chegar ao idioma do que uma solicitação de recurso aleatório, não
importa o quão fervorosamente argumentado o pedido possa ser. Isso está vinculado a "Será útil?", Como
o fato de que alguém se deu ao trabalho de fazer o patch demonstra um forte desejo pelo
recurso.

TESTE

O núcleo usa o mesmo estilo de teste que o resto do Perl, uma execução simples de "ok / não ok"
Teste :: Arnês, mas existem algumas considerações especiais.

Existem três maneiras de escrever um teste no núcleo: Teste :: Mais, t / test.pl e ad hoc "imprimir
$ test? "ok 42 \ n": "não ok 42 \ n" ". A decisão de qual usar depende de qual parte do
o conjunto de testes em que você está trabalhando. Esta é uma medida para evitar uma falha de alto nível (como
como quebra de Config.pm) de fazer com que os testes de funcionalidade básica falhem.

O t / test.pl biblioteca fornece alguns dos recursos de Test :: More, mas evita carregar a maioria
módulos e usa o mínimo de recursos básicos possível.

Se você escrever seu próprio teste, use o protocolo Test Anythinghttp://testanything.org>.

· t / base, t / comp e t / opbasic

Já que não sabemos se "requer" funciona, ou mesmo sub-rotinas, use testes ad hoc para
Estes três. Avance com cuidado para evitar o uso do recurso que está sendo testado. Testes em
t / opbasic, por exemplo, foram colocados lá em vez de em principal porque eles testam
funcionalidade que t / test.pl presume que já tenha funcionado.

· t / cmd, t / run, t / io e principal

Agora esse básico requer () e as sub-rotinas são testadas, você pode usar o t / test.pl
biblioteca.

Você também pode usar certas bibliotecas como o Config condicionalmente, mas certifique-se de pular o
teste normalmente se não estiver lá.

· Todo o resto

Agora que o núcleo do Perl foi testado, Test :: More pode e deve ser usado. Você também pode
use o conjunto completo de módulos principais nos testes.

Quando você diz "fazer teste", Perl usa o t / TESTE programa para executar o conjunto de testes (exceto em
Win32 onde ele usa t / arnês em vez de). Todos os testes são executados a partir do t/ diretório, não da
diretório que contém o teste. Isso causa alguns problemas com os testes em lib /, assim
aqui está uma oportunidade para algum patch.

Você deve estar triplamente consciente das preocupações entre plataformas. Isso geralmente se resume a usar
File :: Spec, evitando coisas como "fork ()" e "system ()" a menos que seja absolutamente necessário, e
não presumindo que um determinado caractere tem um valor ordinal particular (ponto de código) ou que
sua representação UTF-8 é composta de bytes específicos.

Existem várias funções disponíveis para especificar caracteres e pontos de código portáveis ​​em
testes. As funções sempre pré-carregadas "utf8 :: unicode_to_native ()" e seu inverso
"utf8 :: native_to_unicode ()" pega pontos de código e traduz de forma apropriada. O arquivo
t / charset_tools.pl tem várias funções que podem ser úteis. Tem versões do
as duas funções anteriores que usam strings como entradas - e não pontos de código numérico simples:
"uni_to_native ()" e "native_to_uni ()". Se você deve olhar para os bytes individuais
compreendendo uma string codificada em UTF-8, "byte_utf8a_to_utf8n ()" leva como entrada uma string de
esses bytes codificados para uma plataforma ASCII e retorna a string equivalente no nativo
plataforma. Por exemplo, "byte_utf8a_to_utf8n (" \ xC2 \ xA0 ")" retorna a sequência de bytes no
plataforma atual que forma o UTF-8 para "U + 00A0", uma vez que "\ xC2 \ xA0" são os bytes UTF-8 em
uma plataforma ASCII para esse ponto de código. Esta função retorna "\ xC2 \ xA0" em um ASCII
plataforma e "\ x80 \ x41" em um EBCDIC 1047.

Mas o mais fácil é, se o caractere for especificável como um literal, como "A" ou "%", para usar
naquela; se não for especificável, você pode usar "\ N {}", se os efeitos colaterais não forem
problemático. Simplesmente especifique todos os seus caracteres em hexadecimal, usando "\ N {U + ZZ}" em vez de
"\ xZZ". "\ N {}" é o nome Unicode e, portanto, sempre fornece o caractere Unicode.
"\ N {U + 41}" é o caractere cujo ponto de código Unicode é 0x41, portanto, é 'A' em todos
plataformas. Os efeitos colaterais são:

1) Estas regras de seleção Unicode. Isso significa que em strings com aspas duplas, a string é
sempre convertido para UTF-8 para forçar uma interpretação Unicode (você pode
"utf8 :: downgrade ()" depois para converter de volta para não UTF8, se possível). No regular
padrões de expressão, a conversão não é feita, mas se o modificador do conjunto de caracteres
caso contrário, seria "/ d", ele é alterado para "/ u".

2) Se você usar o formulário "\ N {personagem nome}", o módulo charnames obtém automaticamente
carregado. Isso pode não ser adequado para o nível de teste que você está fazendo.

Se você estiver testando localidades (ver perllocale), existem funções auxiliares em t / loc_tools.pl
para permitir que você veja quais localidades existem na plataforma atual.

Destaque "faço teste" tem como alvo
Existem vários alvos especiais que podem ser usados ​​para testar o Perl de forma ligeiramente diferente
do que o alvo de "teste" padrão. Nem todos devem dar uma taxa de sucesso de 100%.
Muitos deles têm vários apelidos, e muitos deles não estão disponíveis em determinados
sistemas.

· Test_porting

Isso executa alguns testes básicos de sanidade na árvore de origem e ajuda a detectar erros básicos
antes de enviar um patch.

· Miniteste

Execute miniperl on t / base, t / comp, t / cmd, t / run, t / io, principal, t / uni e t / mro testes.

· Test.valgrind check.valgrind

(Apenas no Linux) Execute todos os testes usando o vazamento de memória + ferramenta de acesso à memória impertinente
"valgrind". Os arquivos de log serão nomeados nomedoteste.valgrind.

· equipamento de teste

Execute o conjunto de testes com o t / arnês programa de controle, em vez de t / TESTE.
t / arnês é mais sofisticado e usa o módulo Test :: Harness, usando assim este
alvo de teste supõe que perl funciona principalmente. A principal vantagem para nossos propósitos é
que imprima um resumo detalhado dos testes que falharam no final. Além disso, ao contrário t / TESTE, É
não redireciona stderr para stdout.

Observe que no Win32 t / arnês é sempre usado em vez de t / TESTE, então não há
alvo especial "test_harness".

No destino de "teste" do Win32, você pode usar o ambiente TEST_SWITCHES e TEST_FILES
variáveis ​​para controlar o comportamento de t / arnês. Isso significa que você pode dizer

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

· Test-notty test_notty

Define PERL_SKIP_TTY_TEST como verdadeiro antes de executar o teste normal.

Paralelo testes
A distribuição central agora pode executar seus testes de regressão em paralelo em plataformas do tipo Unix.
Em vez de executar "make test", defina "TEST_JOBS" em seu ambiente para o número de testes
para executar em paralelo e executar "make test_harness". Em um shell do tipo Bourne, isso pode ser feito
as

TEST_JOBS = 3 make test_harness # Run 3 testes em paralelo

Uma variável de ambiente é usada, ao invés de fazer-se paralelamente, porque TAP :: Harness
precisa ser capaz de programar scripts de teste individuais não conflitantes, e há
nenhuma interface padrão para "criar" utilitários para interagir com seus planejadores de trabalho.

Observe que atualmente alguns scripts de teste podem falhar quando executados em paralelo (mais notavelmente
ext / IO / t / io_dir.t) Se necessário, execute apenas os scripts com falha novamente em sequência e veja
se as falhas desaparecerem.

Corrida testes by mão
Você pode executar parte do conjunto de testes manualmente usando um dos seguintes comandos do
t/ diretório:

./perl -I ../ lib Lista de TESTE de arquivos .t

or

./perl -I ../ lib aproveitar a lista de arquivos .t

(Se você não especificar scripts de teste, todo o conjunto de testes será executado.)

utilização t / arnês for ensaio
Se você usar "chicote" para teste, terá várias opções de linha de comando disponíveis.
Os argumentos são os seguintes e estão na ordem em que devem aparecer se usados ​​juntos.

arnês -v -torture -re = ​​padrão LISTA DE ARQUIVOS PARA TESTAR
arnês -v -tortura -re LISTA DE PADRÕES PARA CORRESPONDER

Se "LISTA DE ARQUIVOS PARA TESTE" for omitido, a lista de arquivos será obtida do manifesto. o
a lista de arquivos pode incluir curingas de shell que serão expandidos.

· -V

Execute os testes no modo detalhado para que você possa ver quais testes foram executados e depurar a saída.

· -Tortura

Execute os testes de tortura, bem como o conjunto normal.

· -Re = PADRÃO

Filtre a lista de arquivos para que todos os arquivos de teste executados correspondam a PATTERN. Observe que este
forma é distinta da -ré LISTA OF PADRÕES formulário abaixo em que permite o arquivo
lista a ser fornecida também.

· -Re LISTA DE PADRÕES

Filtre a lista de arquivos para que todos os arquivos de teste executados correspondam a / (LISTA | DE | PADRÕES)/. Note
que com esta forma os padrões são unidos por '|' e você não pode fornecer uma lista de
arquivos, em vez disso, os arquivos de teste são obtidos do MANIFEST.

Você pode executar um teste individual por um comando semelhante a

./perl -I ../ lib caminho / para / foo.t

exceto que os chicotes configuram algumas variáveis ​​de ambiente que podem afetar a execução
do teste:

· PERL_CORE = 1

indica que estamos executando este teste como parte do conjunto de testes do núcleo perl. Isto é
útil para módulos que têm uma vida dupla no CPAN.

· PERL_DESTRUCT_LEVEL = 2

é definido como 2 se ainda não estiver definido (consulte "PERL_DESTRUCT_LEVEL" em dicas de perlhack).

· PERL

(usado apenas por t / TESTE) se definido, substitui o caminho para o executável perl que deveria ser
usado para executar os testes (o padrão sendo ./perl).

· PERL_SKIP_TTY_TEST

se definido, diz para pular os testes que precisam de um terminal. Na verdade, é definido automaticamente
pelo Makefile, mas também pode ser forçado artificialmente executando 'make test_notty'.

Outros meio Ambiente variáveis que pode influência testes

· PERL_TEST_Net_Ping

Definir esta variável executa todos os testes dos módulos Net :: Ping, caso contrário, alguns testes que
interagir com o mundo exterior são ignorados. Veja perl58delta.

· PERL_TEST_NOVREXX

Definir esta variável ignora os testes vrexx.t para OS2 :: REXX.

· PERL_TEST_NUMCONVERTS

Isso define uma variável em op / numconvert.t.

· PERL_TEST_MEMORY

Definir esta variável inclui os testes em t / bigmem /. Isso deve ser definido como
número de gigabytes de memória disponível para teste, por exemplo. "PERL_TEST_MEMORY = 4"
indica que os testes que requerem 4GiB de memória disponível podem ser executados com segurança.

Consulte também a documentação dos módulos Teste e Teste :: Harness, para obter mais informações sobre o ambiente
variáveis ​​que afetam o teste.

Performance ensaio
O arquivo t / perf / benchmarks contém trechos de código perl que se destinam a ser
comparada em uma série de perls pelo Porting / bench.pl ferramenta. Se você corrigir ou aprimorar um
problema de desempenho, você pode querer adicionar uma amostra de código representativa ao arquivo e, em seguida, executar
banco.pl contra os perls anteriores e atuais para ver que diferença fez, e
se alguma outra coisa diminuiu como consequência.

O arquivo t / perf / opcount.t é projetado para testar se um determinado trecho de código foi
compilado em uma optree contendo números específicos de tipos específicos de op. Isso é bom
para testar se as otimizações que alteram as operações, como a conversão de uma operação "aelem" em
uma operação "aelemfast", estão realmente fazendo isso.

Os arquivos t / perf / velocidade.t e t / re / speed.t são projetados para testar coisas que rodam milhares
muitas vezes mais lento se uma otimização específica for interrompida (por exemplo, o cache de comprimento utf8
em longas strings utf8). Adicione um teste que normalmente levará uma fração de segundo e
minutos caso contrário, fazendo com que o tempo limite do arquivo de teste se esgote em caso de falha.

MAIS READING PARA ENTRANHAS HACKERS

Para hackear as entranhas do Perl, você precisará ler o seguinte:

· Perlsource

Uma visão geral da árvore de origem do Perl. Isso ajudará você a encontrar os arquivos que está procurando
para.

· Perlinterp

Uma visão geral do código-fonte do interpretador Perl e alguns detalhes sobre como o Perl faz o que
ele faz.

· Perlhacktut

Este documento percorre a criação de um pequeno patch para o código C do Perl. Se vocês são
apenas começando com o hacking de núcleo Perl, isso ajudará você a entender como
obras.

· Dicas de perlhack

Mais detalhes sobre como hackear o núcleo Perl. Este documento se concentra em detalhes de nível inferior
como escrever testes, problemas de compilação, portabilidade, depuração, etc.

Se você planeja fazer hacking sério em C, certifique-se de ler isto.

· Perlguts

Isso é de suma importância, pois é a documentação do que vai e onde
a fonte Perl. Leia algumas vezes e pode começar a fazer sentido -
não se preocupe se ainda não, porque a melhor maneira de estudá-lo é lê-lo em
em conjunto com cutucar a fonte Perl, e faremos isso mais tarde.

"Perlguts ilustrados" de Gisle Aas, também conhecido como Illguts, tem fotos muito úteis:

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

· Perlxstut e perlxs

Um conhecimento prático de programação XSUB é incrivelmente útil para hacking de núcleo; XSUBs
usar técnicas retiradas do código PP, a parte do intestino que realmente executa
um programa Perl. É muito mais suave aprender essas técnicas a partir de exemplos simples e
explicação do que a partir do próprio núcleo.

· Perlapi

A documentação para a API Perl explica o que algumas das funções internas fazem, como
bem como as muitas macros usadas na fonte.

· Porting / pumpkin.pod

Esta é uma coleção de palavras de sabedoria para um porteiro Perl; alguns deles são apenas úteis
para o porta-abóbora, mas a maior parte se aplica a qualquer um que queira fazer Perl
desenvolvimento.

CPAN TESTADORES E PERL FUMADORES

Os testadores CPAN ( http://testers.cpan.org/ ) são um grupo de voluntários que testam o CPAN
módulos em uma variedade de plataformas.

Fumantes Perl ( http://www.nntp.perl.org/group/perl.daily-build/ e
http://www.nntp.perl.org/group/perl.daily-build.reports/ ) testar automaticamente a fonte Perl
lançamentos em plataformas com várias configurações.

Ambos os esforços acolhem voluntários. A fim de se envolver no teste de fumaça do perl
própria visitahttp://search.cpan.org/dist/Test-Smoke/>. Para iniciar o teste de fumaça
Visita aos módulos CPANhttp://search.cpan.org/dist/CPANPLUS-YACSmoke/> ou
<http://search.cpan.org/dist/minismokebox/> ou
<http://search.cpan.org/dist/CPAN-Reporter/>.

O QUE PRÓXIMO?

Se você leu toda a documentação do documento e as listadas acima, você
mais do que pronto para hackear Perl.

Aqui estão mais algumas recomendações

· Assine o perl5-porters, siga os patches e tente entendê-los; não seja
medo de perguntar se há uma parte da qual você não está claro - quem sabe, você pode descobrir um
bug no patch ...

· Leia o README associado ao seu sistema operacional, por exemplo, README.aix no IBM
AIX OS. Não hesite em fornecer patches para esse README se você encontrar algo faltando
ou alterado em uma nova versão do sistema operacional.

· Encontre uma área do Perl que pareça interessante para você, e veja se você consegue descobrir como isso
trabalho. Faça uma varredura na fonte e passe por cima dela no depurador. Jogue, cutuque,
investigue, violino! Você provavelmente entenderá não apenas sua área escolhida, mas também uma
gama muito mais ampla de perlatividade de também, e provavelmente mais cedo do que você imagina.

"O Road vai sempre on e um; down da da porta onde it começou."
Se você pode fazer essas coisas, você começou no longo caminho para a portabilidade do Perl. Obrigado por
querendo ajudar a tornar o Perl melhor - e feliz hacking!

Metafórico Citações
Se você reconheceu a citação sobre a estrada acima, você está com sorte.

A maioria dos projetos de software começa cada arquivo com uma descrição literal da finalidade de cada arquivo.
Em vez disso, Perl começa cada um com uma alusão literária ao propósito daquele arquivo.

Como capítulos em muitos livros, todos os arquivos-fonte Perl de nível superior (junto com alguns outros aqui
e lá) começar com uma inscrição epigramática que alude, indiretamente e
metaforicamente, para o material que você está prestes a ler.

As citações são tiradas de escritos de JRR Tolkien pertencentes ao seu Legendarium, quase
sempre de O Senhor of da Anéis. Os capítulos e os números das páginas são fornecidos usando o
seguintes edições:

· O Hobbit, por JRR Tolkien. A capa dura, edição do 70º aniversário de 2007 foi
usado, publicado no Reino Unido pela Harper Collins Publishers e nos EUA pela Houghton
Companhia Mifflin.

· O Senhor of da Anéis, por JRR Tolkien. A edição de capa dura do 50º aniversário de
2004 foi usado, publicado no Reino Unido pela Harper Collins Publishers e nos EUA pela
Companhia Houghton Mifflin.

· O Lays of Beleriand, por JRR Tolkien e publicado postumamente por seu filho e
executor literário, CJR Tolkien, sendo o terceiro dos 3 volumes da obra de Christopher
mamute História of Coração Terra. Os números das páginas derivam da edição de capa dura,
publicado pela primeira vez em 1983 por George Allen & Unwin; nenhum número de página alterado para o
edição especial omnibus de 3 volumes de 2002 ou as várias edições de jornal comercial, todas
novamente agora por Harper Collins ou Houghton Mifflin.

Outros livros JRRT jogo justo para citações incluiriam, portanto, O Adventures of Tom bombadil,
O Silmarillion, Inacabado Tal e O Conto of da Crianças of Hurin, todos menos o
primeiro reunido postumamente pelo CJRT. Mas O Senhor of da Anéis em si está perfeitamente bem
e provavelmente é melhor citar, desde que você possa encontrar uma citação adequada lá.

Portanto, se você for fornecer um arquivo fonte novo, completo e de nível superior para adicionar ao Perl, você deve
conformar-se a esta prática peculiar selecionando você mesmo uma citação apropriada de
Tolkien, mantendo a grafia e pontuação originais e usando o mesmo formato do
o resto das citações estão dentro. Indireta e oblíqua estão bem; lembre-se, é uma metáfora,
então, ser meta é, afinal, para que serve.

Use perlhack online usando serviços onworks.net