Re: Speaking of namespace advice...
Curtis Jewell wrote in perl.module-authors : I've got a module that... well, the idea is that it's the Module::CoreList for Strawberry. What should I call it? Module::List::Strawberry and Strawberry::ModuleList both come to mind. Module::CoreList::Strawberry ? Here's the hashes so far: By the way, did you notice that perl comes with a script that helps generating the Module::CoreList data ? http://perl5.git.perl.org/perl.git/blob_plain/HEAD:/Porting/corelist.pl It can be helpful, I suppose. -- Is it any wonder the world's gone insane, with information come to be the only real medium of exchange ? -- Thomas Pynchon, Gravity's Rainbow
Re: lexical warnings question
2009/6/27 Joshua ben Jore twi...@gmail.com:
Uh... yeah, maybe.
Reading warnings.pm's import is revealing. Appears the current
package doesn't matter at all - it just writes to ${^WARNING_BITS}
which is global because it is one of those ${^...} variables.
No, it's not global : it's a magic variable that points at the current
warnings for the statement being compiled (much like %^H and $^H point
at the pragmas currently in effect at compile time).
Re: [ANNOUNCE] ExtUtils::MakeMaker 6.53_02
2009/6/8 Michael G Schwern schw...@pobox.com: http://github.com/schwern/extutils-makemaker/tree/v6.53_02 This is an alpha release of MakeMaker, a release candidate for 6.54. Its mostly fixes to bugs introduced by 6.52 on VMS and Windows while building perl. Thanks, applied to bleadperl as c09562552278eb4945e2fed8b0ba38b1a12597a7 Test boilerplates added to new tests to keep them passing as e39d780342f3e91579069fdc80eda72bfe639ae7 (yes, this is still needed.)
Re: S_IFLNK() Availability on Win32 (and other non-UNIX systems)
2009/1/14 Shlomi Fish shlo...@iglu.org.il:
Hi all,
I recently uploaded File-Find-Object-0.1.6 to CPAN and got this errror report
on MSWin32:
http://www.nntp.perl.org/group/perl.cpan.testers/2009/01/msg3039451.html
Reading from there, we see the following:
{{{
Your vendor has not defined Fcntl macro S_IFLNK, used at C:/Perl/lib/Fcntl.pm
line 214.
# Looks like you planned 3 tests but ran 2.
# Looks like your test exited with 255 just after 2.
Dubious, test returned 255 (wstat 65280, 0xff00)
Failed 1/3 subtests
}}}
This appears multiple times for each test script. The reason it happens is
that instead of doing -l / -d / -f / etc. I just do one stat() and then use
S_IFLNK() from Fcntl on the mode field of stat (the one with index 2). (To
save on system calls).
What's wrong with using _ instead ?
Obviously, it doesn't work on Windows at that report. My questions are:
1. Can I ever expect it to work on Windows?
Dunno. Does Windows 7 implement symbolic links ? I think that's
unlikely.
2. Is it fixed on perl-5.8.9 or perl-5.10.0 there?
What do you mean, fixed ? If the OS doesn't support S_IFLNK, you can't
use it. That's not a bug.
3. The error report seems to come from ActivePerl (or otherwise a Perl that
was built using MS DevStudio). Does S_IFLNK work better on Mingw32-based
Perls?
I bet it doesn't, since the libc won't support it anyway. Maybe on
cygwin there's some kind of compatibility layer ?
4. Why doesn't Perl do the right thing with this macro, like it does using -l.
Because you're using a low level API, comparable to using POSIX.pm for
example : it tries to be close to your libc, to enable you to do
difficult things.
Re: S_IFLNK() Availability on Win32 (and other non-UNIX systems)
2009/1/14 Shlomi Fish shlo...@iglu.org.il: What's wrong with using _ instead ? Well, I'm storing the result of stat somewhere, and then checking for whether it's a link or not only later. I guess I can also store the return code of -l and other things I'm interested in. That's what _ is for : it stores the result of the last stat or lstat. (see perldoc -f stat) By the way, may I point out that to see if something is a symbolic link, you need lstat. stat does not stat symbolic links, but it stats their targets, so your test will always be false.
Re: Package aliases and isa()
Torsten Schoenfeld wrote in perl.module-authors :
Aloha,
over in gtk2-perl land, we'd like to split out the Gtk2::Pango stuff from the
Gtk2 module into its own module with the namespace Pango. We would like to
do
this in a backwards compatible way so that any code that is using the
Gtk2::Pango stuff continues to work just fine when we switch Gtk2 over to use
the new Pango.
So we basically do this in Gtk2.pm:
use Pango;
{
no strict 'refs';
foreach my $key (keys %Pango::) {
*{'Gtk2::Pango::' . $key} = *{'Pango::' . $key};
}
}
For some reason, this has the effect that the following lines both evaluate
to true:
Pango::Layout-isa (Gtk2::Pango::Layout::);
Gtk2::Pango::Layout-isa (Pango::Layout::);
Now, that's really good because we need those to evaluate to true for
backwards
compatibility. The problem is that I don't understand *why* they are true.
I think I understand *why*. At least in 5.10.
I attach a simple standalone program that demonstrates this behavior. perl
5.8.8, 5.10.0, and blead all output two 1s when running this program on my
machine. perl 5.6.2, however, evaluates New-isa(Old::) to false.
So I wonder if it is safe to rely on the behavior exhibited by perl = 5.8.
Or
is it just some implementation-dependent artifact? Is there a better way to
achieve what I want?
I think it's safe.
A quick look shows that bleadperl does not have tests for this behaviour
in t/mro/*.t. I suggest that you turn your example program into a test
and submit it to perl5-porters. The best way to ensure that a behaviour
will not break in a next release is to add a regression test for it :)
Re: [ANNOUNCE] ExtUtils::MakeMaker 6.37_02
On 26/11/2007, Michael G Schwern [EMAIL PROTECTED] wrote: 6.37_01 did a refactoring which broke XS building, this release fixes it. Thanks to Andreas for catching that. I've now upgraded EU::MM to 6.37_02 in bleadperl, including the new xs test and the change to MM.pm that will maybe need to be reverted (if Jan says so).
Re: Incompatible change in blead perl for Safe.pm?
Burak Gürsoy wrote in perl.module-authors : Hi, I have a module named Text::Template::Simple ( http://search.cpan.org/dist/Text-Template-Simple/ ) and one of it's tests (t/05-safe) is dying under 5.9.5: http://www.nntp.perl.org/group/perl.cpan.testers/2007/08/msg576957.html http://www.nntp.perl.org/group/perl.cpan.testers/2007/07/msg546071.html http://www.nntp.perl.org/group/perl.cpan.testers/2007/05/msg499523.html my default permit list is like this: my @permit = qw(:default require); everything is fine under $] 5.9.x but it dies with this error under blead: 'caller' trapped by operation mask I couldn't locate an entry for this change in the 5.9.5 change log. Can someone give me info on this subject? Or shall I just add caller (and anything it requires) to my permit list? I don't think that was a desired change, but a bug introduced with a fix elsewhere. I'll look at it. Probably the bug is in Opcode rather than in Safe (so I'd rather fix it before 5.10.0 is out.) -- The world is independent of my will. -- Wittgenstein, Tractatus Logico-Philosophicus, 6.373
Re: error messages in cpan w/readline in 5.8.7...(?)
On 9/30/05, Linda W [EMAIL PROTECTED] wrote: When I start cpan, it complains about valid entries in my .inputrc -- that are valid for BASH's use/version of readline: ... I can get-around the problem by unsetting my INPUTRC env variable before starting CPAN, but what's changed? Why did I not get similar errors under the suse-built 5.8.6? How'd I manage to screw up my 5.8.7 build, or is it even 'perl' related...? cpan? It's probably related to Term::ReadLine::Gnu (which is not part of the perl core.) I don't know much about your setup, but this is the module which is linked against libreadline. Maybe the SuSE packages miss some dependencies, or something.
Re: more multiple interface support using VERSION
David Manura wrote in perl.module-authors : It could be slightly shortened to this: use Text::Balanced 1.95_1.96; # ok I also propose an important difference in how this is interpreted. So the way to solve the module versioning problem is to fundamentally change the way Perl parses numbers. Mmmhm. opps, as I haven't implemented or compiled this, that should be use Text::Balanced '1.95_1.96'; You could overload VERSION() to do this. (see the UNIVERSAL manpage). You could even write a base class that overloads VERSION and make Text::Balanced inherit from this. Ah, but as Text::Balanced is a core module this means that this base class should go in the core as well... I'm not opposed to this (but this is a subject for the perl 5 porters list.)
