- Error number parsing
- VMS hackery
- The (f)crypt of mystery
- Yet more self-ties
- Rsync vs. FTP'ing the patches
- Changes to README.aix
- The Regex Stack Problem
- Things nobody's fixed
- Craig Berry
You can subscribe to an email version of this summary by sending an empty message to email@example.com.
Please send corrections and additions to
Apologies for the slightly late appearance of this report; I aim to get them out every Monday, but I'm hoping you were all so distracted by the US election that you didn't notice yet. This week was pretty heavy, reaching either 300 or 550 messages depending on whether you count unique mails or duplicates. However, there wasn't much in the way of hugely interesting content.
An innocent-looking patch to
t/lib/io_multihomed.t managed to turn up some problems with
Errno.pm. (Good work Casey Tweten for finally tracking that down, after what
looked like a rather agonizing debugging session...)
If you didn't know, the
Errno module is automatically generated by reading the system's
errno.h file when Perl is being built. However, it looks like some people's
systems and libc implementations use macros that are too difficult for
Perl to parse automatically, and this meant that some error constants (you
ETOOSTUPID and so on.) were not getting picked up. (Tom Hughes noticed this on
RedHat 7.0 as well.) The solution is to use the
-dM flag to gcc; there's not much we can do for non-gcc right now.
There was a lot of work on VMS this week: firstly, in the area of file
locking. Peter Prymmer reported that
t/lib/st-lock.t failed since VMS doesn't really have locking. Peter Farley piped up and
said that this was also the case on DOS and DJGPP, and the work-around
there was to null-op the locking tests. Andy Dougherty mentioned that
a permanent fix would be to define a
d_fcntl_can_lock Configure variable to determine whether or not
fcntl is any use. Craig Berry had suggested this idea before; Andy provided
Peter also noticed that one of Jarkko's patches had broken the
POSIX module; there were also some problems with erronous output confusing
the test harnesses, so that the tests were passing but were still
After all that, Perl on VMS now passes all tests, and there was much rejoicing!
Richard Proctor is trying to compile Perl on RiscOS (and take over the
RiscOS pumpkin) however is having problems in that
fcrypt isn't prototyped on that system. He tried to force the issue with a
couple of casts, but Jarkko wasn't impressed; the Right Way to do it is
to have a separate
riscos/ directory and put the platform-specific things in there. Nicholas Clark
remarked that the
[fcrypt] support was "weird":
There are 4 references to FCRYPT but nothing anywhere (even in a port subdirectory) defines the macro. The macro isn't of the usual HAS_ or I_ forms. Does anyone know where it originates?
Nobody did, which is... well, weird. However, we found out where
UnixLib got its
fcrypt implementation from.
Andy Dougherty suggested that the other right way to do it would be to
define (and test for) a configure symbol
d_fcrypt_proto which then turns into
No patches were forthcoming.
Randy Ray has a module (
Perl-RPM) which uses a self-tie; he found that the reference count of a
self-tied object is two, where you'd expect it to be one. Alan replied
that self-ties are badly broken (hey, don't we know it...) and Jarkko
announced that we could really do with someone who's prepared to tackle
this issue and get it sorted out. Randy promised to try and have a look.
Steffen Bayer suggested that you could just manually set the reference count back to one, which struck Alan as somewhat sick. Steffen responded:
IMO, this is a matter of opinion. :-)
There's nothing fundamentally evil about setting the refcount to a lower value, because this just triggers the DESTROY() event sooner than it would normally.
But Nick noted that you can't ensure that you're not going to create any more references to the object during DESTROYing, so this really is fundamentally evil after all.
Merijn Brand complained of a discrepancy between the patch archive (That's rsync://ftp.linux.activestate.com/perl-current-diffs/ or ftp://ftp.linux.activestate.com/pub/staff/gsar/APC/perl-current-diffs) and the latest source tree. ( rsync://ftp.linux.activestate.com/perl-current/ or ftp://ftp.linux.activestate.com/pub/staff/gsar/APC/perl-current.)
Sarathy explained that
The rsync mirror is automatic and syncs with the repository every five minutes.
Updating the patch area still requires manual intervention (with all the goofiness that implies, which you've noted) and is typically on a daily cycle. Making this process automatic is on my tuit list, but don't ask me when.
The thread went a little off topic into the mechanics of setting up a rsync server, but lead to a contribution to perlhack from Merijn explaining how to keep in sync with the Perl source.
We've recently been telling AIX users that they need to upgrade their compilers in order to compile Perl, so Merijn send in a patch to README.aix to tell them how to do so. Read about it.
Jarkko also decided it was time we had a README.Solaris; volunteers are being sought.
Sam Smith found a regular expression which will crash the engine with a segfault - further investigation showed it was the engine recursing too deeply and exceeding the maximum stack depth. Dominic Dunlop explained that it was difficult to fix this one, as writing stack checking code portably is quite a challenge, and fixing the root of the problem - changing the regex engine from recursion to iteration - is somewhat Herculean.
Dominic further explained that he had a stack checking patch but it
depended on the system having the BSD resource limit functions
setrlimit. He also couldn't find a nice way of making this all play sensibly with
threads. At the time, Ilya had countered that the problem should really
be fixed by rewriting the engine to be iterative; Dominic had tried
this, but it was very tricky and slowed the whole thing down by about
30% - this was due to the extra memory allocation of the structures that
needed to be copied between levels. Jarkko came up with a few ideas,
most promising being the use of a custom stack.
The work-around is to increase the process's stack size using
ulimit; it was suggested that perl should be able to use
setrlimit to extend its own stack size when necessary. This was frowned upon by
Jarkko - limits are imposed for a reason.
Anyone who's got infinite patience and sanity may want to consider hacking at removing the recursion, but so far Dominic and Hugo look like the only people patient and sane enough.
A few bug reports nobody's investigated yet, for those of you with a spare minute: xsubpp truncates files
Craig Berry deserves a special mention for his huge contribution to p5p this week - we saw nearly three hundred messages from him. However, on closer examination, 284 of them turned out to be the same, thanks to a malicious copy of CC Mail belonging to somewhere completely different. (It wasn't Craig's fault at all.)
I leave you with a veritable smorgasbord of misdirected queries, test reports, FAQs, off-topic posts, and people spamming the list about how much spam there was on the list, and until next week I remain, your humble and obedient servant,