perl

 view release on metacpan or  search on metacpan

Porting/epigraphs.pod  view on Meta::CPAN

  The poor world is almost six thousand years old, and in all
  this time there was not any man died in his own person,
  videlicit, in a love-cause. Troilus had his brains dashed
  out with a Grecian club; yet he did what he could to die
  before, and he is one of the patterns of love. Leander, he
  would have lived many a fair year, though Hero had turned
  nun, if it had not been for a hot midsummer night; for, good
  youth, he went but forth to wash him in the Hellespont and
  being taken with the cramp was drowned and the foolish
  coroners of that age found it was 'Hero of Sestos.' But these
  are all lies: men have died from time to time and worms have
  eaten them, but not for love.

=head2 v5.14.2 -  L<< Larry Wall, January 12, 1988 <992@devvax.JPL.NASA.GOV>  |http://groups.google.com/group/comp.sources.d/msg/5d17fa68c250b9b2 >>

L<Announced on 2011-09-26 by Florian Ragwitz|http://www.nntp.perl.org/group/perl.perl5.porters/2011/09/msg177618.html>

It's not so much that people don't value the programs after they have them--they
do value them.  But they're not the sort of thing that would ever catch on if
they had to overcome the marketing barrier.  (I don't yet know if perl will

ext/Pod-Html/corpus/perlpodspec-copy.pod  view on Meta::CPAN

  =end outer

  Z

  =end inner

This latter is improper because when the "=end outer" command is seen, the
currently open region has the formatname "inner", not "outer".  (It just
happens that "outer" is the format name of a higher-up region.)  This is
an error.  Processors must by default report this as an error, and may halt
processing the document containing that error.  A corollary of this is that
regions cannot "overlap" -- i.e., the latter block above does not represent
a region called "outer" which contains X and Y, overlapping a region called
"inner" which contains Y and Z.  But because it is invalid (as all
apparently overlapping regions would be), it doesn't represent that, or
anything at all.

Similarly, this is invalid:

  =begin thing

pod/perlguts.pod  view on Meta::CPAN

    POP*()

For a detailed description of calling conventions from C to Perl,
consult L<perlcall>.

=head2 Putting a C value on Perl stack

A lot of opcodes (this is an elementary operation in the internal perl
stack machine) put an SV* on the stack.  However, as an optimization
the corresponding SV is (usually) not recreated each time.  The opcodes
reuse specially assigned SVs (I<target>s) which are (as a corollary)
not constantly freed/created.

Each of the targets is created only once (but see
L</Scratchpads and recursion> below), and when an opcode needs to put
an integer, a double, or a string on the stack, it just sets the
corresponding parts of its I<target> and puts the I<target> on stack.

The macro to put this target on stack is C<PUSHTARG>, and it is
directly used in some opcodes, as well as indirectly in zillions of
others, which use it via C<(X)PUSH[iunp]>.

pod/perlguts.pod  view on Meta::CPAN

(but slightly more complicated).  This tree reflects the way Perl
parsed your code, but has nothing to do with the execution order.
There is an additional "thread" going through the nodes of the tree
which shows the order of execution of the nodes.  In our simplified
example above it looks like:

     $b ---> $c ---> + ---> $a ---> assign-to

But with the actual compile tree for C<$a = $b + $c> it is different:
some nodes I<optimized away>.  As a corollary, though the actual tree
contains more nodes than our simplified example, the execution order
is the same as in our example.

=head2 Examining the tree

If you have your perl compiled for debugging (usually done with
C<-DDEBUGGING> on the C<Configure> command line), you may examine the
compiled tree by specifying C<-Dx> on the Perl command line.  The
output takes several lines per node, and for C<$b+$c> it looks like
this:

pod/perlpodspec.pod  view on Meta::CPAN

  =end outer

  Z

  =end inner

This latter is improper because when the "=end outer" command is seen, the
currently open region has the formatname "inner", not "outer".  (It just
happens that "outer" is the format name of a higher-up region.)  This is
an error.  Processors must by default report this as an error, and may halt
processing the document containing that error.  A corollary of this is that
regions cannot "overlap". That is, the latter block above does not represent
a region called "outer" which contains X and Y, overlapping a region called
"inner" which contains Y and Z.  But because it is invalid (as all
apparently overlapping regions would be), it doesn't represent that, or
anything at all.

Similarly, this is invalid:

  =begin thing