Karl Williamson [Mon, 9 May 2011 14:57:29 +0000 (08:57 -0600)]
fold_grind.t: Add testing of multi-char folds in pattern
Previously these were skipped. Now skip just the ones that don't make
sense or aren't implemented.
Karl Williamson [Mon, 9 May 2011 14:43:29 +0000 (08:43 -0600)]
regcomp.c: Add two tricky fold cases
These two characters fold to lower-case characters that are involved
in tricky folds, and hence these can be too.
Karl Williamson [Wed, 18 May 2011 22:23:17 +0000 (16:23 -0600)]
Revamp podcheck.t
This new podcheck.t catches more problems, and tests more pods than
the current one, while suppressing some existing warnings that really
aren't problems.
It takes longer to execute. I have profiled it, and most of the increased
time appears to be because of testing more pods.
A complete pod for its usage is included
David Mitchell [Wed, 11 May 2011 15:50:45 +0000 (16:50 +0100)]
improve api entries for hv_clear() and hv_undef()
The =apidoc entries for hv_clear() and hv_undef() were a bit spartan.
Make it clearer what the two functions actually do, and the relationship
between them.
David Mitchell [Wed, 11 May 2011 15:17:08 +0000 (16:17 +0100)]
ensure hash iterator gets deleted
The recent commits to make sv_clear() iterative when freeing a hash,
introduced a bug. If the hash only has one key, and that becomes the
iterator, and is then deleted; then when the hash is freed, the LAZYDEL
feature is skipped, and the iterated hash value fails to get deleted.
The fix is simple: check for LAZYDEL before return is keys == 0.
David Mitchell [Wed, 11 May 2011 14:31:40 +0000 (15:31 +0100)]
assume cleared hv can't be re-blessed
followup to previous commit. I'm fairly confident now that a HV being
freed in sv_clear() can never get re-blessed, and thus its SvSTASH field is
*always* safe to use.
The logic behind this is that once you get to sv_clear(), the HV has a
refcnt of zero, which means either:
* nothing references this, so there's no way to bless it;
* we're in SVf_BREAK territory, in which case something may still
hold a reference to it, but all destructors will have already been
called, so nothing can call bless.
David Mitchell [Wed, 11 May 2011 11:07:14 +0000 (12:07 +0100)]
make hv freeing iterative rather than recursive
make sv_clear() iteratively free the elements of a hash, rather than
recursing. This stops freeing deeply nested hash of hash structures from
blowing the stack.
This commit is relatively straightfoward, now that
a) the infrastruure is already in place in sv_clear to iteratively
free AVs;
b) the long sequence of commits leading up to this has provided us with
the hfree_next_entry() function, which returns just the next sv in the
hash that needs freeing.
When starting to free a new hash, we have to save the old value of iter_sv
somewhere; we do this by sticking it in the unused SvSTASH slot of the HV.
This slot shouldn't get messed with, since, but this time we've already
called the destructor on this object, and we should have a refcount of
zero, so no destructor should be able to see us to rebless us.
Ideally we'd like to be able to save the old index into HvARRAY when
freeing a new HV, but I couldn't think of anywhere to hide it.
So we get sub-optimal scanning of the parent's HvARRAY when freeing hashes
of hashes.
David Mitchell [Tue, 10 May 2011 18:06:45 +0000 (19:06 +0100)]
add hfree_next_entry(), hv_free_ent_ret()
Move body of hfreeentries()' central loop into a new function,
hfree_next_entry(); leaving hfreeentries() as a simple loop that calls
hfree_next_entry() until there are no entries left.
This will in future allow sv_clear() to free a hash iteratively rather
than recursively.
Similarly, turn hv_free_ent() into a thin wrapper around a new function,
hv_free_ent_ret(), which doesn't free HeVAL(), but rather just returns the
SV instead.
David Mitchell [Tue, 10 May 2011 16:24:29 +0000 (17:24 +0100)]
remove 'hfreeentries failed to free hash' panic
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.
David Mitchell [Tue, 10 May 2011 12:52:48 +0000 (13:52 +0100)]
hv_free_ent: free SV as last action
Move the freeing of the SV from near the beginning to the end of
hv_free_ent(); i.e. free the HE before the SV. Ideally, this should cause
no change in behaviour, but will make using an iterative HV freeing
scheme easier.
David Mitchell [Tue, 3 May 2011 16:16:29 +0000 (17:16 +0100)]
HV backrefs: another simplification
Now that HV backrefs are only stored in HvAUX, don't go looking for them
in magic too in sv_clear()
David Mitchell [Tue, 3 May 2011 16:10:46 +0000 (17:10 +0100)]
assert that HvARRAY is NULL when freeing an HV
The code path that leads to HvAUX being empty and thus HvARRAY being
freed, is non-obvious: so put in an assert against any future failure.
David Mitchell [Tue, 3 May 2011 15:41:06 +0000 (16:41 +0100)]
S_hfreeentries: collapse two loops
S_hfreeentries() has two nested infinite loops: the inner one
does one sweep through all buckets, freeing all entries in each bucket;
the outer loop repeats the process if new keys have been added in the
meantime.
Collapse these two into a single 'while (keys) {}' loop.
Should be functionally the same, but simpler.
David Mitchell [Tue, 3 May 2011 15:07:51 +0000 (16:07 +0100)]
hfreeentries zeros HvARRAY now, so skip manual
Formerly, hv_clear() and hv_undef() zeroed the contents of
HvARRAY after calling hfreeentries(), but that sub now zeroes
each elements as a by-product of its deleting algorithm.
So we can skip the Zero().
David Mitchell [Tue, 3 May 2011 10:41:27 +0000 (11:41 +0100)]
simplify HV backref code
Now that HV backref data is always stored in HvAUX and never in magic,
update the various backref handling functions to account for that.
David Mitchell [Tue, 3 May 2011 09:51:17 +0000 (10:51 +0100)]
make hash emptying non-atomic
Currently, when empting a hash of its elements (e.g. via
undef(%h), or %h=()), HvARRAY field is temporarily zeroed, so that
any destructors called on the freed elements see an empty hash.
Change this so that they see any remaining elements. Thus,
%h=() becomes more like C<delete $h{$_} for keys %h>.
The atomic behaviour was introduced (by me) in 2003 with commit
2f86008e34264, to fix RT #3096. This concerned element destructors
that messed with the hash being undeffed, causing unrefed var errors
and the like.
At the time, simply setting HvARRAY to null for the duration seemed like a
simple fix. However, it didn't take account of destructors adding new
elements to the list, thus re-creating HvARRAY. This was subsequently
fixed. Then, the HvAUX structure was invented, which meant that optional
hash fields were hidden away at the end of HvARRAY. This meant that
hfreeentries() acquired a whole bunch of extra code to copy these fields
around between the original HvARRAY and the new HvARRAY and then back
again, and temporarily squirrelling the backref array in backref magic
rather than in HvAUX.
In short, hfreeentries() became a 200 line sprawling mess.
This commit reduces it back to 70, and makes everything conceptually
simpler.
It does however change user-level visible behaviour (back to pre-2003),
but note that the new behaviour now matches the behaviour that arrays have
always had (i.e. destructors see a partially-emptied array).
Note that backref magic for HVs is now always stored in HvAUX
David Mitchell [Thu, 28 Apr 2011 15:33:35 +0000 (16:33 +0100)]
unify PERL_HASH and PERL_HASH_INTERNAL
Those two macros expand into two large, almost identical chunks of code.
The only difference between the two is the source of the hash seed.
So parameterize this into a new PERL_HASH_INTERNAL_() macro.
Also, there are a couple of places in hv.c that do the rough equivalent of
if (HvREHASH(hv))
key = PERL_HASH_INTERNAL(...)
else
key = PERL_HASH(...)
which incorporates two complete macro expansions into the code.
Reorganise them to be
key = PERL_HASH_INTERNAL_(..., HvREHASH(hv))
David Mitchell [Tue, 26 Apr 2011 15:07:50 +0000 (16:07 +0100)]
simplify hv_clear
Don't use a goto when an else will do
i.e. replace
if (..) {
A
goto reset
}
B
reset:
with
if (..) {
A
}
else {
B
}
Michael Witten [Fri, 8 Apr 2011 00:20:48 +0000 (00:20 +0000)]
Perl_ck_split: Avoid unnecessary assignment
Signed-off-by: Michael Witten <mfwitten@gmail.com>
Tom Christiansen [Thu, 19 May 2011 05:06:54 +0000 (22:06 -0700)]
[perl #90594] PATCH for 5.14.1 perlop.pod
Father Chrysostomos [Thu, 19 May 2011 13:13:40 +0000 (06:13 -0700)]
Increase t::OptreeCheck’s version
cmp_version.t was complaining.
Why does this even *have* a version?
Marcel Grünauer [Thu, 19 May 2011 04:56:51 +0000 (21:56 -0700)]
[perl #90306] Fix simple typos
Father Chrysostomos [Thu, 19 May 2011 04:53:23 +0000 (21:53 -0700)]
Increase B::Concise’s version
because of the upcoming patch
Niko Tyni [Thu, 19 May 2011 04:44:06 +0000 (21:44 -0700)]
[perl #90122] Make h2ph correctly search gcc include directories
System header conversion with "h2ph -a" is currently broken on Ubuntu
Natty and Oneiric (unless the gcc-multilib package is installed for
backward compatibility), resulting in things like
# perl -e 'require "syscall.ph"'
Can't locate asm/unistd.ph in @INC [...]
This happens because Ubuntu has switched to a 'multiarch' setup, see
<https://wiki.ubuntu.com/MultiarchSpec> for details.
The asm subdirectory isn't in $Config{usrinc} anymore: /usr/include/asm
is now /usr/include/x86_64-linux-gnu/asm. (The third component of the
new path varies with the actual architecture.)
gcc --print-search-dirs doesn't really tell anything about where gcc
looks for the include directories, it was just used to find the gcc
internal directory prefix.
Parse the output of "gcc -v -E" instead, and append $Config{usrinc}
for safety. Duplicates shouldn't matter.
The h2ph "-a" switch isn't currently tested automatically, and that
seems nontrivial to do portably. Manual testing was done with
# mkdir ttt
# ./perl -Ilib ./utils/h2ph -a -d $(pwd)/ttt syscall.h
The gcc invocation has been tested to work with gcc 4.6, 4.1, and 3.3.
http://bugs.debian.org/625808
https://bugs.launchpad.net/bugs/777903
Nicholas Clark [Fri, 13 May 2011 09:48:07 +0000 (10:48 +0100)]
Remove PERL_UNUSED_ARG() from Perl_magic_clearsig(), missed by
179c85a2d774d3be
Nicholas Clark [Thu, 19 May 2011 10:07:29 +0000 (11:07 +0100)]
Remove duplicate code from pp_study(), caused by
a4f4e9060b702ac8.
The duplicated code could have had no effect - for the case of pos <= 0
pp_study had already returned NO. The second call to SvPV() would have had no
side effects, because scalars with side effects don't have SvPOK() true, so
would also have already returned NO.
Nicholas Clark [Sat, 14 May 2011 21:28:58 +0000 (22:28 +0100)]
Create open_print_header() to avoid duplicate parameters to open_new().
Nicholas Clark [Sat, 14 May 2011 21:28:08 +0000 (22:28 +0100)]
Rename do_not_edit() to open_print_header(), and move open_new() into it.
This removes duplication of open_new() calls.
Nicholas Clark [Sat, 14 May 2011 21:13:56 +0000 (22:13 +0100)]
Add a 'quote' argument to read_only_top(), to pass in an optional Tolkien.
Use this in embed.pl for perlapi.c, and reentr.pl for reentr.c.
Nicholas Clark [Sat, 14 May 2011 20:59:38 +0000 (21:59 +0100)]
Add an optional third argument to open_new(), to invoke read_only_top() with.
Merge together many calls to open_new() and read_only_top().
Nicholas Clark [Sat, 14 May 2011 18:11:27 +0000 (19:11 +0100)]
In regen/uconfig_h.pl use read_only_bottom_close_and_rename().
This eliminates the only remaining external caller of read_only_bottom(), so
inline read_only_bottom() into read_only_bottom_close_and_rename().
Nicholas Clark [Sat, 14 May 2011 17:16:50 +0000 (18:16 +0100)]
Merge safer_close() and rename_if_different() into close_and_rename()
Inline safer_rename() into its only caller, close_and_rename().
Nicholas Clark [Sat, 14 May 2011 16:22:55 +0000 (17:22 +0100)]
Add an optional 'mode' argument to open_new(), to open for appending.
Use this in regen/uconfig_h.pl
Nicholas Clark [Sat, 14 May 2011 16:08:56 +0000 (17:08 +0100)]
Rename safer_open() to open_new(), and eliminate the first parameter.
Update the SHA256s where necessary in the generated files.
Nicholas Clark [Sat, 14 May 2011 15:30:01 +0000 (16:30 +0100)]
In makemeta, pass the final file name as the second argument to safer_open()
With this change, all callers to safer_open() pass 2 arguments.
Nicholas Clark [Thu, 19 May 2011 09:14:16 +0000 (10:14 +0100)]
study uses I32 internally for offsets, so should be skipped for long strings.
It already skips for anything that isn't a plain byte string with non-zero
length. Otherwise it risks becoming confused for strings longer than 2**31.
Nicholas Clark [Thu, 19 May 2011 08:56:20 +0000 (09:56 +0100)]
Remove empty #ifdef/#else/#endif block.
This was added (with contents) in
b162af07ec759e1b. The contents were moved
elsewhere in the refactoring of
ac09da3b9065d6e7, but that change failed to
remove the block it had now emptied.
Nicholas Clark [Mon, 16 May 2011 11:17:21 +0000 (12:17 +0100)]
Avoid make distclean failing if t/tmp* matches a directory.
Some of the tests in t/ make directories with names generated by the test.pl
tempfile(), and if they exit abnormally without deleting them, this would cause
distclean to fail. So change `rm -f t/tmp*` to `rm -rf t/tmp*`
Remove other cruft from the same line in the Makefile.
t/misctmp* hasn't been generated since
7a7e49369367a634.
t/forktmp* hasn't been generated since
1c25d394345c1b97.
t/io/fs.t has deleted t/c itself since
44a8e56aa037ed0f.
(Whilst it might abort and fail to delete it, there's no special treatment
in the Makefile for the other file that it creates, "t/TEST$$")
Nicholas Clark [Thu, 19 May 2011 08:21:56 +0000 (09:21 +0100)]
bdec6fb9 changed utils/Makefile.SH - this needs replicating in utils/Makefile
(There's a less than idea situation with a somewhat complex history of trying
to resolve it, where utils/Makefile is in the repository for the use of
platforms unable to run utils/Makefile.SH)
Nicholas Clark [Mon, 11 Apr 2011 19:51:06 +0000 (20:51 +0100)]
In t/op/reset.t, don't eval "" in void context - die if something goes wrong.
Because sometimes the "it can never happen" does. For example, "panic: free
from wrong pool". And it's awfully confusing if the error message is eaten.
There's not even a "I barfed you an error but then I eated it" caption to give
a clue about what happened.
Nicholas Clark [Mon, 11 Apr 2011 19:31:29 +0000 (20:31 +0100)]
In Perl_op_clear(), uncomment the call to mad_free()
Free the MADPROPs when freeing their parent OP, now that all the other bugs are
fixed.
Nicholas Clark [Mon, 11 Apr 2011 19:25:04 +0000 (20:25 +0100)]
In S_fold_constants() under MAD, need to copy the SV representing the result.
For the non-MAD case (the historical default), it was fine to use pad_swipe()
(which doesn't adjust any part of the OS), because the OS was freed soon after.
However, the MAD code doesn't free the OS, hence as-was, without this change,
the OS still thought that it owned the pad slot, and much jollity resulted as
two different parts of the code fought over whichever SV had the bad luck to
next be billeted there.
Nicholas Clark [Mon, 11 Apr 2011 19:18:49 +0000 (20:18 +0100)]
Under ithreads, convert SVOPs stored in MADPROPs to PADOPs.
Else if a child thread attempts to free an optree with MADPROPs containing OPs
pointing directly to SVs, it will by trying to free SVs to the wrong
interpreter, at which point bad things(tm) happen.
(There still seems to be some fixing needed for the MADPROPs direct pointers,
but as no tests are failing because of them, I'm postponing them until the
failures are addressed)
Nicholas Clark [Mon, 11 Apr 2011 19:14:34 +0000 (20:14 +0100)]
Allocate MADPROPs using PerlMemShared_malloc()
As the MADPROPs are referenced from the optree, which is itself shared,
MADPROPs can't use the default malloc(), which is per i-thread, lest a
child thread frees the optree, and bad things(tm) happen. (a "free to wrong
pool" panic if you're on Win32, or elsewhere if you've got DEBUGGING)
David Leadbeater [Sat, 14 May 2011 12:57:21 +0000 (13:57 +0100)]
scan_heredoc could reallocate PL_parser->linestr's PV
Since f0e67a1 it was possible the freed buffer may be read from when
parsing a heredoc. This adds a call to lex_grow_linestr to grow the
buffer and ensure the pointers in PL_parser are updated.
The bug is pretty hard to reproduce, hence no test. I'm able to
reproduce it with the following:
perl -Meverywhere=re,debug -MParams::Util -e1
Karl Williamson [Thu, 19 May 2011 03:57:25 +0000 (21:57 -0600)]
regcomp.c: Fix regression memory leak
I carelessly added this memory leak which happens in a bracketed
character class under /i when there is both a above 255 code point
listed plus one of the several below 256 code points that participate
in a fold with ones above 256.
For 5.16, as the use of the inversion list data structure expands, an
automatic method of freeing space will need to be put in place. But
this should be sufficient for 5.14.1.
Johan Vromans [Thu, 19 May 2011 03:42:43 +0000 (20:42 -0700)]
[perl #90060] Fix location of (*COMMIT) in pod/perlre.pod
pod/perlre.pod: (*COMMIT) should be grouped under "Verbs without an
argument".
Moritz Lenz [Fri, 29 Apr 2011 17:44:52 +0000 (19:44 +0200)]
Remove long-stading limitation from FindBin
The FindBin documentation states as a known bug that it will return
a wrong result if a script of the same name as the current one exists in
$PATH, and is executable.
This patch removes the functionality of searching through $PATH.
According to Graham Barr it was only necessary because the SysV shell on
Sun4OS4 was broken - a system where I can't imagine anybody wanting
(and successfully compiling) a modern perl.
On Linux this part wasn't necessary in the case of `perl -S scriptname',
tests on other platforms are very welcome.
As a side effect, this patch also removes some IO operations, speeding up
FindBin slightly.
This patch is based on discussions with Tina Müller.
Further "discussion": http://www.perlmonks.org/?node_id=41213
Father Chrysostomos [Thu, 19 May 2011 03:40:16 +0000 (20:40 -0700)]
Increase version for ExtUtils::CBuilder
Johan Vromans [Thu, 19 May 2011 03:28:23 +0000 (20:28 -0700)]
[perl #90054] Fix typo in universal.c
At XS(XS_UNIVERSAL_DOES), invocant is spelled wrong.
Niko Tyni [Thu, 28 Apr 2011 06:18:54 +0000 (09:18 +0300)]
Append CFLAGS and LDFLAGS to their Config.pm counterparts in EU::CBuilder
Since ExtUtils::CBuilder 0.27_04 (bleadperl commit
06e8058f27e4),
CFLAGS and LDFLAGS from the environment have overridden the Config.pm
ccflags and ldflags settings. This can cause binary incompatibilities
between the core Perl and extensions built with EU::CBuilder.
Append to the Config.pm values rather than overriding them.
Karl Williamson [Sun, 8 May 2011 15:59:13 +0000 (09:59 -0600)]
/iaa doesn't work when the result is trie'd
It turns out that caseless tries currently only work on UTF-8 EXACTFU
nodes. The code attempted to test that by using UNI_SEMANTICS, but that
doesn't actually work; what is important is the semantics of the current
node.
Craig A. Berry [Sun, 15 May 2011 20:34:34 +0000 (15:34 -0500)]
Correct perldoc search path for VMS.
Father Chrysostomos [Thu, 19 May 2011 03:13:15 +0000 (20:13 -0700)]
Add Kevin Woolley to AUTHORS
Kevin J. Woolley [Thu, 19 May 2011 01:22:36 +0000 (18:22 -0700)]
[perl #88812] INSTALL file changes (post-5.14)
- minor spelling, punctuation corrections
Martin Becker [Thu, 19 May 2011 01:15:40 +0000 (18:15 -0700)]
[perl #88496] missing dependencies in perl core makefiles
I have spotted a couple of missing dependencies in the makefiles
utils/Makefile.SH and x2p/Makefile.SH that prevent json_pp, s2p,
psed, and find2perl from being rebuilt after configuration changes.
This could cause trouble if the install prefix has been changed,
so that the shebang line of these scripts from a previous build
no longer matches the target location of the perl binary.
A workaround would be to always "make clean" after changes to
the configuration, which sounds reasonable anyway. That said,
most of the other tools do have config.sh properly listed as a
dependency and I don't see why those four should not.
I have attached a small patch against perl-5.13.11 to fix this.
The bug is also present in the latest stable release as of this
writing, perl-5.12.3, except that json_pp is not included there.
Father Chrysostomos [Thu, 19 May 2011 03:11:53 +0000 (20:11 -0700)]
Increase perl5db.pl’s $VERSION
Louis Strous [Thu, 19 May 2011 01:07:52 +0000 (18:07 -0700)]
[perl #87740] perl debugger restart fails on Windows
Start debugger for some perl script, enter "R" command to restart.
Get no restart, but error message about POSIX macro _SC_OPEN_MAX and
termination of debugged program. Entering "R" again yields a similar
error message and terminates the debugger.
Lines 3332-3335 of perl5db.pl read:
>>
my $max_fd = 1024; # default if POSIX can't be loaded
if (eval { require POSIX }) {
$max_fd = POSIX::sysconf(POSIX::_SC_OPEN_MAX());
}
<<
POSIX Is available but POSIX::_SC_OPEN_MAX is not defined on Windows.
This yields an exception, which means that the "restart" code follow-
ing these lines is not executed, so no proper restart is done. If
POSIX weren't available at all, then a default value of 1024 would be
used for $max_fd.
A workaround is to not cause an exception if _SC_OPEN_MAX is not
defined, but instead use the default value that has already been
defined in case POSIX cannot be loaded at all. Do this by wrapping
line 3334 of perl5db.pl in an eval { }. Then on Windows the default
value of 1024 gets used for $max_fd, just like if POSIX were not
available at all. This seems to work OK for me on Windows 7. I can
now restart the debugger, and breakpoints are retained.
Father Chrysostomos [Thu, 19 May 2011 01:04:47 +0000 (18:04 -0700)]
Add Louis Strous to AUTHORS
Father Chrysostomos [Thu, 19 May 2011 01:02:59 +0000 (18:02 -0700)]
Confusing comment typo in Deparse
Michael Witten [Mon, 16 May 2011 01:18:00 +0000 (01:18 +0000)]
Clean: Remove confusing comment from a test
As per:
Re: [PATCH 2/2] Clean: Actually use HvUSEDKEYS() instead of HvKEYS()
Sun, 15 May 2011 20:29:05 +0000
Message-Id: <
2a28ed668b6641e6b5f6e0fb4e5374b4-mfwitten@gmail.com>
the text in question was introduced along with the test in this commit:
$ c=
58da6fbcb8d595318b667d7d7cc8739f5feb15f3
$ git log -1 $c
commit
58da6fbcb8d595318b667d7d7cc8739f5feb15f3
Author: Max Maischein <corion@corion.net>
Date: Mon Jun 1 14:18:42 2009 +0200
Add benchmark test for keys() on empty hashes (RT26188)
I believe the text in question is an allusion to the code introduced in
the parent commit:
$ git log -1 $c^
commit
900ac0519e4b408fd93443b14b734cc330c59698
Author: Max Maischein <corion@corion.net>
Date: Sun May 31 23:50:12 2009 +0200
Fix RT26188, speed up keys() on empty hash
namely the code starting at line 2132 of
900ac0519e4b408fd93443b14b734cc330c59698:hv.c:
/* At start of hash, entry is NULL. */
...
if (HvKEYS(hv) || (flags & HV_ITERNEXT_WANTPLACEHOLDERS)) {
...
}
...
return entry;
It is best just to remove the text in question, as it is of no
real use.
Signed-off-by: Michael Witten <mfwitten@gmail.com>
Michael Witten [Mon, 14 Mar 2011 06:57:43 +0000 (06:57 +0000)]
Clean: Actually use HvUSEDKEYS() instead of HvKEYS()
This:
commit
8aacddc1ea3837f8f1a911d90c644451fc7cfc86
Author: Nick Ing-Simmons <nik@tiuk.ti.com>
Date: Tue Dec 18 15:55:22 2001 +0000
Tidied version of Jeffrey Friedl's <jfriedl@yahoo.com> restricted hashes
- added delete of READONLY value inhibit & test for same
- re-tabbed
p4raw-id: //depot/perlio@13760
essentially deprecated HvKEYS() in favor of HvUSEDKEYS(); this is
explained in line 144 (now 313) of file `hv.h':
/*
* HvKEYS gets the number of keys that actually exist(), and is provided
* for backwards compatibility with old XS code. The core uses HvUSEDKEYS
* (keys, excluding placeholdes) and HvTOTALKEYS (including placeholders)
*/
This commit simply puts that into practice, and is equivalent to running
the following (at least with
a35ef416833511da752c4b5b836b7a8915712aab
checked out):
git grep -l HvKEYS | sed /hv.h/d | xargs sed -i s/HvKEYS/HvUSEDKEYS/
Notice that HvKEYS is currently just an alias for HvUSEDKEYS:
$ git show
a35ef416833511da752c4b5b836b7a8915712aab:hv.h | sed -n 318p
#define HvKEYS(hv) HvUSEDKEYS(hv)
According to `make tests':
All tests successful.
Leo Lapworth [Sun, 3 Apr 2011 08:20:04 +0000 (09:20 +0100)]
README.macosx - clarify requirement of apple developer tools
Leo Lapworth [Sun, 3 Apr 2011 08:06:56 +0000 (09:06 +0100)]
README.macosx - remove Carbon reference
Leo Lapworth [Sun, 3 Apr 2011 08:04:06 +0000 (09:04 +0100)]
README.macosx - cleanup/update copy, remove 'MacPerl'
Leo Lapworth [Sun, 3 Apr 2011 07:48:14 +0000 (08:48 +0100)]
Cleanup README.macosx
- Direct people for README.macosx straight away
- Make synopsis copy shorter and clearer
Leo Lapworth [Sun, 3 Apr 2011 07:49:58 +0000 (08:49 +0100)]
Update AUTHORS file (add myself)
Father Chrysostomos [Wed, 18 May 2011 23:17:38 +0000 (16:17 -0700)]
Add Nuno Cavalho’s other e-mail address
smash [Mon, 16 May 2011 14:08:59 +0000 (15:08 +0100)]
add given when to perfunc
David Mitchell [Wed, 18 May 2011 23:01:22 +0000 (00:01 +0100)]
buildtoc: make dying clearer
print a big "ABORTED" if it dies.
David Mitchell [Wed, 18 May 2011 22:44:14 +0000 (23:44 +0100)]
buildtoc: make a warning clearer
make it clear that the cannot find '=head1 NAME' warning isn't fatal,
and split it over two lines ofr clarity with long filenames
Father Chrysostomos [Fri, 13 May 2011 15:37:48 +0000 (08:37 -0700)]
[perl #78074] Make it explicit that symtab manipulation is not supported
Father Chrysostomos [Sat, 14 May 2011 01:12:30 +0000 (18:12 -0700)]
Restore a croak I deleted by mistake
Todd Rinaldo [Fri, 13 May 2011 05:39:22 +0000 (22:39 -0700)]
RT72688 - Benchmark.t test 24 bug when the testing system is under load.
David Mitchell [Wed, 18 May 2011 22:24:57 +0000 (23:24 +0100)]
release_managers_guide: replace =item with =head3
The main body of the Release Manager's Guide is currently just a long list
of steps, each with a '=item *'. Replace these with
=head3 some description
so that its easier to navigate around.
Also do a few minor structural fixups along the way (eg splitting or
merging individual =item sections).
Also a few typos and bits fixed as I noticed them.
David Mitchell [Wed, 18 May 2011 21:22:25 +0000 (22:22 +0100)]
release_managers_guide: add BLEAD-POINT/-FINAL
the Release Manager's Guide talks about three different release types,
RC, BLEAD and MAINT. This is a bit ambiguous for a major release
(e.g. 5.14.0): is it the first MAINT or the last BLEAD?
So, split BLEAD into two:
BLEAD-FINAL - a final release on a blead branch (e.g. 5.14.0)
BLEAD-POINT - a point release on a blead branch (e.g. 5.15.0, 5.15.1)
Then update the whole document to use these tags consistently.
David Mitchell [Wed, 18 May 2011 20:15:23 +0000 (21:15 +0100)]
release_managers_guide: remove SNAPSHOT
Now that we make regular blead releases, we no longer need to make
snapshot releases. So remove the instructions for SNAPSHOT that
litter release_managers_guide.pod.
Eric Brine [Mon, 21 Feb 2011 10:37:27 +0000 (02:37 -0800)]
given wasn't calling set magic [RT#84526]
Eric Brine [Mon, 21 Feb 2011 10:35:24 +0000 (02:35 -0800)]
TODO tests for RT#84526 - given needs to handle magical TARG
Father Chrysostomos [Fri, 13 May 2011 05:16:57 +0000 (22:16 -0700)]
Revert "Partially revert
4155e4fe"
This reverts commit
7f586e41ad4ecd904c7d8dbe1ddb0f9410484bac.
Father Chrysostomos [Fri, 13 May 2011 05:33:37 +0000 (22:33 -0700)]
Revert "silence do_curse() compiler warning"
This reverts commit
82336099d393c4ac04507e58e4402ba9c413f791.
Michael Witten [Wed, 18 May 2011 21:48:41 +0000 (14:48 -0700)]
Ignore pod/*.{html,man}
Signed-off-by: Michael Witten <mfwitten@gmail.com>
Bo Lindbergh [Fri, 13 May 2011 04:42:03 +0000 (21:42 -0700)]
waitpid doesn't work with WIFSTOPPED
> Quoth Emmanuel Rodriguez:
>> I'm see a strange behavior in the fonction WIFSTOPPED($?) when
>> waitpid($pid, WUNTRACED) is invoked and that the child process
>> receives a stop signal. Under this conditions one would expect that
>> WIFSTOPPED($?) would return a true value, but that's not what is
>> happening. A similar program written in C will have the same macro
>> return true instead of false under the same conditions.
>>
>> I can reproduce this with the default perl provided by Ubuntu 9.10 and
>> OS X 10.6. Which lets me guess that this is not a distro related bug.
>
> This is a documentation error. POSIX.pod incorrectly claims that
> you can pass the value of $? to WIFEXITED and its relatives.
> You must use the raw status value from ${^CHILD_ERROR_NATIVE} instead.
And here's the patch. Note that perlvar.pod gets it right already.
/Bo Lindbergh
Father Chrysostomos [Wed, 18 May 2011 21:38:48 +0000 (14:38 -0700)]
[perl #90898] B::Deparse failure on glob()
Change d1bea3d changed the way that glob() is converted into
a CORE::GLOBAL::glob call, by preserving the OP_GLOB node, so
that it could still do overloading.
But B::Deparse was never updated to account for the change to
the op tree.
Father Chrysostomos [Wed, 18 May 2011 21:35:47 +0000 (14:35 -0700)]
[perl #90160] U* gives ‘U0 mode on an empty string’
This is a regression in 5.10 caused by change 23966/
08ca2aa38a29,
which added a bit of faulty logic. It was treating U* in the middle of
a pack template as equivalent to U0, if the input string was empty.
Zefram [Wed, 18 May 2011 20:54:55 +0000 (21:54 +0100)]
update Math-Complex to CPAN version 1.57
* 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.
Zefram [Wed, 18 May 2011 20:49:45 +0000 (21:49 +0100)]
update Time-HiRes to CPAN version 1.9722
- 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.
Justin Case [Wed, 18 May 2011 20:43:24 +0000 (13:43 -0700)]
[perl #89896] Locale::Maketext test failure
when environment has variable containing unbalanced brackets
Patch is attached to escape brackets in the value of the environment
variable being used in the test.
Nicholas Clark [Tue, 29 Mar 2011 15:37:10 +0000 (16:37 +0100)]
In Perl_regdupe_internal() eliminate npar, which is assigned to but never used.
It has been unused since
28d8d7f41ab202dd restructured the regexp dup code.
Nicholas Clark [Tue, 29 Mar 2011 14:36:40 +0000 (15:36 +0100)]
In S_regpiece(), only declare parse_start if conditional code needs it.
gcc 4.6.0 warns about variables that are set but never read, and unless
RE_TRACK_PATTERN_OFFSETS is defined, parse_start is never read. So avoid
declaring or setting it if it's not actually going to be used later.
Nicholas Clark [Tue, 29 Mar 2011 14:06:50 +0000 (15:06 +0100)]
In Perl_safesyscalloc(), only declare total_size if conditional code needs it.
gcc 4.6.0 warns about variables that are set but never read, and for most
combinations of conditional compilation options, total_size is never read.
So avoid declaring or setting it if it's not actually going to be used later.
Nicholas Clark [Tue, 29 Mar 2011 13:15:59 +0000 (14:15 +0100)]
In pp_warn and pp_die, eliminate pv, which is assigned to but never read.
Nicholas Clark [Tue, 29 Mar 2011 12:38:13 +0000 (13:38 +0100)]
Eliminate C variables unused since
4d0fbddde6c5dcb9 refactored HvFILL()
3 functions had C variables previously used to track whether the number of
hash chains have any entries.
4d0fbddde6c5dcb9 refactored the hash
implementation to calculated this on demand, instead of tracking changes to
it on hash updates. That change missed eliminating those variables, as
gcc prior to 4.6.0 didn't actually warn that they weren't used, because
(technically) they aren't unused - they are assigned to, but never read.
gcc (at least 4.3.2 and 4.6.0) generates identical object code with/without
this change, implying that its optimiser correctly eliminates the code.
Other optimisers may be similar, in which case there's no runtime saving from
this change.
Karl Williamson [Wed, 18 May 2011 18:44:44 +0000 (12:44 -0600)]
mktables: Put off removing the \N{BELL} conflict
Unicode 6.0 re-used the name BELL for a character other than what it
was traditionally for. There is code in mktables to change the
treatment for 5.15, so that it wouldn't be forgotten. But I'm thinking
that we might want to wait til 5.18 to change, and so I just changed it
to 5.17 instead.
Tom Christiansen [Mon, 2 May 2011 13:28:53 +0000 (09:28 -0400)]
[perl #89662] PATCH to perlfunc.pod: select fix
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
Tom Christiansen [Mon, 2 May 2011 13:28:11 +0000 (09:28 -0400)]
[perl #89660] PATCH to perlfunc.pod: three forgotten prototypes, unforgotten
Tom Christiansen [Mon, 2 May 2011 13:27:18 +0000 (09:27 -0400)]
Improved perlpodstyle docs from tchrist
Tom Christiansen [Mon, 2 May 2011 13:25:55 +0000 (09:25 -0400)]
An editing pass on perlop.pod from tchrist
Subject: [perl #89490] PATCH: perlop.pod
Tom Christiansen [Mon, 2 May 2011 13:24:49 +0000 (09:24 -0400)]
perllol doc updates from tchrist.
Tom Christiansen [Mon, 2 May 2011 13:23:11 +0000 (09:23 -0400)]
This patch is aagainst the "blead du moment". It fixes various
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