| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
While trying to understand a bug report at
http://www.perlmonks.org/?node_id=906466
I realized that the documentation for $! was not crystal clear. For example
If used numerically, yields the current value of the
C C<errno> variable, or in other words,
if a system or library call fails, it sets this variable.
That's not "in other words", these are totally different
concepts. And it isn't clear whether this variable refers to
errno or $! (I assumed the latter, and was wrong, as Devel::Peek
demonstrated). And $! cannot be undef, as asserted (later),
because errno always contains a value, however irrelevant.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In pod/perldata it is described that the DATA filehandle starts
reading after the __DATA__ token. In reality, it starts reading on the
line following the __DATA__ token.
Example:
print while <DATA>; __DATA__ foo
bar
This prints "bar", not "foo\nbar".
The attached patch fixes the documentation in pod/perldata.pod.
|
| |
|
| |
|
| |
|
|
|
|
| |
1c2e8ccaafb0b2b1 fixed a typo in a comment in the XS code.
|
|
|
|
| |
1b95d04f713d9c56 changed HvKEYS() to HvUSEDKEYS() in the XS code.
|
|
|
|
|
|
|
|
|
|
| |
Previous perldeltas have been inconsistent with each other as to whether to
use L<> to C<> (but internally consistent). perldelta5140.pod uses L<>, which
is more useful, as it provides a direct link to fuller documentation at the
point where the reader is likely to want to follow it.
Switch the two existing entries from C<> to L<>, and update the perldelta
template to suggest L<>.
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
| |
The example commands for using `git format-patch' and `perlbug' have
been streamlined, and (most importantly) single quotes have been
replaced with double quotes for constructing the argument to `-s'.
Signed-off-by: Michael Witten <mfwitten@gmail.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Currently perl attempts to clear a hash 100 times before panicking.
So for example, if a naughty destructor keeps adding things back into the
hash, this will eventually panic.
Note that this can usually only occur with %h=() or undef(%h), since
when freeing a hash, there's usually no reference to the hash that a
destructor can use to mess with the hash.
Remove this limit (so it may potentially loop forever).
My reasoning is that (a) if the user wants to keep adding things back into
the hash, who are we to stop her? (b) as part of of the process of making
sv_clear() non-recursive when freeing hashes, I'm trying to reduce the
amount of state that must be maintained between each iteration.
Note that arrays currently don't have a limit.
|
| |
|
| |
|
|
|
|
|
| |
pod/perlre.pod: (*COMMIT) should be grouped under "Verbs without an
argument".
|
| |
|
|
|
|
| |
print a big "ABORTED" if it dies.
|
|
|
|
|
| |
make it clear that the cannot find '=head1 NAME' warning isn't fatal,
and split it over two lines ofr clarity with long filenames
|
| |
|
|
|
|
| |
Signed-off-by: Michael Witten <mfwitten@gmail.com>
|
|
|
|
|
|
|
|
|
|
|
|
| |
* Add copy constructor and arrange for it to be called
appropriately, problem found by David Madore and Alexandr
Ciornii.
* Correctly format polarwise when a numeric format specifier is
given, problem found by TomC.
* More stable great_circle_direction algorithm, problem found
by Daniel Burr.
|
|
|
|
|
|
|
| |
- Fix broken linkage on Windows with gcc 3.4 seen with ActivePerl,
report from Christian Walde [rt.cpan.org #61648], fix derived
from Vincent Pit.
- Jump through hoops to avoid compiler warnings.
|
|
|
|
|
|
|
|
|
|
|
|
| |
I think it's about time--by say 20 years--that we stop passing around
filehandles as strings, especially if we don't use Symbol::qualify_to_ref()
to fix the package. Plus it isn't strict-safe. All fixed now.
I am somewhat concerned about the final comment regarding read
and sysread, as I don't know whether PerlIO encoding translation
issues affect this picture.
--tom
|
| |
|
| |
|
|
|
|
| |
Subject: [perl #89490] PATCH: perlop.pod
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
things, but does not address the "this version" != 5.14 and the
perlio issues. I believe that these at least should be addressed
as soon as possible (I don't know whether that means 5.14;
probably not). It has to either say the particular version that
applies. We can't keep releasing things that say this version:
they are not trustable.
--tom
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Formats are compiled down to a sequence of U32 opcodes in doparseform().
Previously the block of opcodes was stored in the buffer of SvPVX() after
the raw string by extending the buffer, and calculating the first U32 aligned
address after SvCUR(). A flag bit on the scalar was set to signal this hackery,
tested with SvCOMPILED()
The flag bit used happened to be the same as one of the two used by to signal
Boyer-Moore compiled scalars. The assumption was that no scalar can be used for
both. Unfortunately, this isn't quite true.
Given that the scalar is alway upgraded to PVMG to add PERL_MAGIC_fm magic,
to clear the cached compiled version, there's no extra memory cost in using
mg_ptr in the MAGIC struct to point directly to the block of U32 opcodes. The
test for "is there a compiled version" can switch to mg_find(..., PERL_MAGIC_fm)
returning a pointer, and the use of a flag bit abolished.
Retain SvCOMPILED() and SvCOMPILED_{on,off}() as compatibility for XS code on
CPAN - the first is always 0, the other two now no-ops.
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
The table makes more sense moved; some accompanying wording cleanup.
|
|
|
|
| |
This should come right after the text about '.', as they are related.
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
| |
The X<> have spaces between them which was causing the =head to
generate a different anchor than expected
|
|
|
|
|
|
| |
The reason there are links broken to this is that the X<>
were part of the heading, and the spaces between them are
significant
|
| |
|