Re: [PATCH] Final (hopefully) fix for fchdir
On Mon, 18 Jul 2005 22:59:19 -0500, Steve Peters [EMAIL PROTECTED]
wrote:
I noticed the blead's were still failing for HP-UX and AIX and ran a
few tests on HP testdrive systems to see what was happening. There is
a syntax error in code that did not previously compile. Below is the
patch that will compile on HP-UX.
Thanks, applied as change #25178
Enjoy,
Steve Peters
[EMAIL PROTECTED]
--- pp_sys.c.old2005-07-18 12:03:27.0 -0500
+++ pp_sys.c2005-07-18 22:55:54.0 -0500
@@ -3592,7 +3592,7 @@
#ifdef HAS_DIRFD
PUSHi(fchdir(dirfd(IoDIRP(io))) = 0);
#else
- DIE(aTHX PL_no_func, dirfd);
+ DIE(aTHX_ PL_no_func, dirfd);
#endif
}
else {
--
H.Merijn BrandAmsterdam Perl Mongers (http://amsterdam.pm.org/)
using Perl 5.6.2, 5.8.0, 5.8.5, 5.9.2 on HP-UX 10.20, 11.00 11.11,
AIX 4.3 5.2, SuSE 9.2 9.3, and Cygwin. http://www.cmve.net/~merijn
Smoking perl: http://www.test-smoke.org,perl QA: http://qa.perl.org
reports to: [EMAIL PROTECTED],perl-qa@perl.org
Re: [perl #36569] chop fails on decoded string with trailing nul
On Mon, 18 Jul 2005 20:33:28 -0700, Yitzchak Scott-Thoennes [EMAIL PROTECTED] wrote: On Sat, Jul 16, 2005 at 03:48:10PM +0200, H.Merijn Brand wrote: On Sat, 16 Jul 2005 22:05:13 +0900, SADAHIRO Tomoyuki [EMAIL PROTECTED] utf8_to_uvchr((U8*)s, 0) used in do_chop() returns 0, not only if the octet sequence from *s is malformed, but also if *s == '\0'. The return value 0 should be for U+ (NUL) rather than malformedness. Oops :- P.S. by the way, when the string in utf8 ends with malformed octet(s), how should chop() do? It has returned undef without modification of the string. Seems reasonable, though just cutting off one byte of the string would maybe more of an expected behaviour. Maybe Was there more to that sentence? No, I stopped after maybe. Because the more I thought about it, the less certain I was about *any* opinion I might have. I decided to leave that to the utf8 experts I'd vote for removing and returning a malformed char, from the last non continuation byte on (or just the unexpected continuation bytes, if the problem was too many of them). That way, the data error is propagated onto the return value (as IMO it should be), and a full-buffer problem will result in at most one bad char. In fact, I could see being able to rely on this being advantageous to buffering code (both XS and perl): fill buffer with bytes chop char and set aside process buffer move choped char to start of buffer repeat -- H.Merijn BrandAmsterdam Perl Mongers (http://amsterdam.pm.org/) using Perl 5.6.2, 5.8.0, 5.8.5, 5.9.2 on HP-UX 10.20, 11.00 11.11, AIX 4.3 5.2, SuSE 9.2 9.3, and Cygwin. http://www.cmve.net/~merijn Smoking perl: http://www.test-smoke.org,perl QA: http://qa.perl.org reports to: [EMAIL PROTECTED],perl-qa@perl.org
bareword test on ebcdic.
a bareword test :
use utf8;
my %hash = ( = 123);
if (($hash{}) eq ($hash{''})) print ok\n;
The above are the chars corresponding to
\x{0442},\x{0435},\x{0441}, and \x{0442} respectively.
1) On ebcdic, can we represent the barewords as
my %hash = (\x{0442}\x{0435}\x{0441}\x{0442} =
123)
since the actual chars cannot be printed ?
2) Or is there a different way to represent barewords
on ebcdic ?
3) The if condition above becomes,
if (($hash{\x{0442}\x{0435}\x{0441}\x{0442}}) eq
($hash{'\x{0442}\x{0435}\x{0441}\x{0442}'}))
Can I rewrite the above as :
if (($hash{\x{0442}\x{0435}\x{0441}\x{0442}}) eq
($hash{eval '\x{0442}\x{0435}\x{0441}\x{0442}'}))
and still be doing a bareword test ?
Thanks in advance,
Rajarshi.
Start your day with Yahoo! - make it your home page
http://www.yahoo.com/r/hs
Re: your malloc patches
Joshua Hoblitt wrote: On Sun, Jun 15, 2003 at 09:14:16PM +0300, Jarkko Hietaniemi wrote: This just isn't cricket for non-GCC compilers (Solaris, AIX, and Tru64 claim a syntax error, IRIX seems to tolerate it). That a function call (Perl_doing_taint in this case) gets expanded to func(a,b,) just isn't going to work. (What does leaving out an argument like that _mean_, anyway? An implicit 0?) It is a *macro*, not a function call! Macros operate on strings. An empty string is a perfectly valid string (though I do not know what When the macro gets expanded at the very beginning of main() we get this: if (Perl_doing_taint(*argc, *argv, )) which makes many C compilers to choke, but apparently not gcc. the C standard says on this). Anyway, this slot is not used, so put there NOTUSED. I have no idea what you mean by NOTUSED. If you mean the trick you said: #define NOTUSED #define MALLOC_CHECK_TAINT2(argc,argv) MALLOC_CHECK_TAINT(argc,argv,NOTUSED) That doesn't work since that gets expanded to exactly the same as above. A possible solution would be to use __VA_ARGS__. I'm not sure how portable this is between cpp implementations... it supposedly has worked with gcc since at least 2.95 (I haven't tried it with anything older than gcc 3.3) and it is part of C99. Perl sources are C89 compliant and generally try to stay so (i.e. not introduce C99-isms, at least not unconditionally so). But thanks for the information, that may turn out to be useful for something else. #define MALLOC_CHECK_TAINT2(argc,...) MALLOC_CHECK_TAINT(argc,__VA_ARGS__) It was two years ago :-) but I think, based on the current perl.h, that we just opted for assuming that the third argument to main while non-standard is at least tolerated widely enough: #define MALLOC_CHECK_TAINT2(argc,argv) MALLOC_CHECK_TAINT(argc,argv,NULL) --
Re: [PATCH] perlfunc.pod
Offer Kaye wrote: On 7/12/05, Michael G Schwern wrote: Patch Pod::Html? Sorry, I have to.. umm.. I have to rearrange my sock drawer. On Pluto. As an alternative to taking long interplanetary trips, consider using Pod::Xhtml instead of Pod::Html. It's better. Really. Cheers, There's only one real problem with that, however. Sending XHTML as text/html means the browser is expecting tag-soup. NOT XHTML.. sending it properly as application/xhtml+xml means MSIE can't understand it *at all*. (MSIE 6 doesn't grok xml, period) FAR better would be to use HTML 4.01 Strict instead of XHTML unless you (because of MathML or some other such) know WHY you need it. further detailed exposition: http://hixie.ch/advocacy/xhtml
overcoming limitations of embedded perl
All, I noticed that an embedded perl does not allow for dynamic loading - eg. when I try to use Data::Dumper, I get - Can't load module Data::Dumper, dynamic loading not available in this perl. (You may need to build a new perl which supports dynamic loading or has the Data::Dumper module statically linked into it. Now, this is a particularly bad thing for using modules that use Inline - so I was wondering if LD_LIBRARY_PATH could somehow be tweaked to override this message, ie: adding /usr/local/lib/perl5/5.8.6/i686-linux-64int/auto/Data/Dumper so that use statement picks up Dumper.so directly rather than using any DynaLoader magic. Either that, or somehow turn on dynamic loading for embedded perls. Is there an easy way to do this? Digging through Dynaloader, I see that there's a lot more going on than simply loading a '.so' file - that through dl_install_xsub the '.so' files get mapped to perl subs and registered with perl. Or is this issue addressed in perl-5.9.2? What would people suggest as an avenue of approach for implementing this? Ed
Re: [perl #27052] File::Spec-canonpath(a\\..\\..\\b) returns wrong value for Win 32
On 7/12/05, Michael G Schwern via RT [EMAIL PROTECTED] wrote: Ok, enough dithering. Let's kill this bug. File::Spec::Win32-canonpath() currently contains code to collapse .. so whether or not it should continue to do so in the future is outside the scope of this bug. That code is also busted and is the source of this bug. Attached is a patch to fix this bug. It replaces the collapsing code in canonpath() with a more reliable method. It also moves the code into its own method to simplify canonpath(). _collapse() goes into File::Spec::Unix because it is not platform specific. Tests have been added for this bug in both Win32 and Unix. What's the status of this patch ? applied to File::Spec ? rejected ? updated ? (catching up over there...)
Porting perl to (traditional) Mac OS via Genie
Greetings, I'm porting perl to a platform called Genie, which is a Unix-like subsystem that runs in Mac OS. The purpose of this exercise is to have a command-line perl tool available for Mac OS, in a stdio environment with polymorphic file descriptors, without the limitations of MPW. (E.g. MPW tools cannot call other programs; only MPW Shell scripts can do this. Genie could be used to run CGI scripts from a Web server.) Also, I understand that perl 5 is a build requirement for parrot. Another goal of this project is to support parrot development on Mac OS. In most ways, Genie-ish perl will resemble unix perl more than MacPerl -- e.g. open() takes Unix pathnames, and in general everything works like a unix, even if it isn't. The only thing that's absolutely out of the question is fork(), since Mac OS has a universal flat address space, and well-behaved apps like Genie don't muck about in the address translation tables. But with the right misbehavior even that's a possibility, though one for another time. In the meantime, Genie provides something vaguely resembling vfork(). Tonight I produced a minimally functioning miniperl. I owe many thanks to Matthias Neeracher and Chris Nandor for their efforts on MacPerl, and especially Matthias for GUSI, from which I've heavily borrowed for Genie. Genie is actually part of a project I unfortunately named LAMP (LAMP Ain't Mac POSIX) before I was aware of the more common expansion. I've since renamed it 'Lamp' in the hope that that will stem at least a little confusion. Josh -- Joshua Juran Metamage Software Creations - Mac Software and Consulting http://www.metamage.com/ * Creation at the highest state of the art *
[PATCH] allow POSIX SIGRTMIN...SIGRTMAX signals (and plug a core dump)
The attached patch introduces %POSIX::SIGRT which gives access to the POSIX real time signals SIGRTMIN...SIGRTMAX, with the right POSIXly moves. It also plugs a hole the size of a coredump I accidentally run into while fooling around with the patch, try perl -MPOSIX -e 'sigaction(123,0)' Merijn, note that Configure is changed (and some bits of its logic copied over to handy.h) SIGRT.pat.v4.gz Description: GNU Zip compressed data
Re: [perl #17650] [PATCH] DESTROY can prevent propagation of die
On Tue, Jul 19, 2005 at 01:19:19AM +0100, Dave Mitchell wrote: On Mon, Jul 18, 2005 at 01:14:43AM -0400, Alex Vandiver wrote: On Sun, 2005-07-10 at 14:29 +0100, Dave Mitchell wrote: I don't think this fix is robust. You save the current PV value of ERRSV, and then later set it back; in the meantime, ERRSV's PV may have been realloced, and message now points to free or realloced garbage. Point. The attached patch uses save_item(ERRSV) to fully localize [EMAIL PROTECTED] Also added more tests that the previous patch didn't pass on. Thoughts? - Alex I like the idea of localising $@ before calling DESTROY, but unfortunately it breaks this test: Which means that it wasn't tested before being sent to the list. make test exists for a reason. Nicholas Clark
more [PATCH] (Re: [PATCH] allow POSIX SIGRTMIN...SIGRTMAX signals (and plug a core dump))
Jarkko Hietaniemi wrote: The attached patch introduces %POSIX::SIGRT which gives access to the POSIX real time signals SIGRTMIN...SIGRTMAX, with the right POSIXly moves. It also plugs a hole the size of a coredump I accidentally run into while fooling around with the patch, try perl -MPOSIX -e 'sigaction(123,0)' Merijn, note that Configure is changed (and some bits of its logic copied over to handy.h) Forgot the sigaction.t chunk which adds some tests for this new feature and Test::More-fies the test. SIGRT.pat.v4b.gz Description: GNU Zip compressed data
Re: Porting perl to (traditional) Mac OS via Genie
On 19/07/2005, at 10:27 AM, Joshua Juran wrote: I'm porting perl to a platform called Genie, which is a Unix-like subsystem that runs in Mac OS. The purpose of this exercise is to have a command-line perl tool available for Mac OS, in a stdio environment with polymorphic file descriptors, without the limitations of MPW. Good to hear. You don't say whether this is PPC or 68k Mac OS. I guess the former, though the FAQs on your site make me wonder. Back in the day, I worked on keeping Perl running on PPC MachTen, a commercial UNIX-under-Mac OS product from Tenon Intersystems (http:// www.tenon.com). The product, though still apparently available, is, as far as I know, unsupported, and suffers from a number of long- standing bugs and security issues. Vague requests from some users that the code be open-sourced after support ended were rebuffed. MachTen was delivered with gcc, so I didn't use MPW or CodeWarrior in porting perl. If you search in old perl5-porters archives, you'll find mail about various issues I tripped over, including malloc() (once tweaked to work, Perl's own malloc was much faster than Mac OS' own); and fork() (MachTen, thanks to deep and probably dark magic, has both fork() and vfork(), but the latter is MUCH faster, as Mac OS does not support Copy on Write). You'll also find clues in hints/ machten.sh. Or contact me. -- Dominic Dunlop
Re: [perl #2915] Inconsistent warnings with our
On 7/15/05, Michael G Schwern [EMAIL PROTECTED] wrote: our $x; our $x; # no Its not a mask but its useless and probably an oversight on the part of the programmer. Maybe a Useless use of our? Or Repeated use of our? I'm fine with dealing with that separately. There's already the warning our variable %s redeclared that can be re-used for this.
Re: [perl #36588] Problem with semctl() on Perl 5.8.6, 64-bit build, HP-UX 11i
On Mon, Jul 18, 2005 at 07:04:03AM -0700, novotny. petr @ volny. cz wrote: Output from 5.6.1 (32-bit): Created new semaphore 1 Output from 5.8.6 (64-bit): Created new semaphore 0 (Of course, I called ipcrm between the two tests to delete the semaphore. I'm saying this just in case :-)) That's useful, as it's the sort of thing that people forget. (Well, I would) Are you able to build 5.8.5 32-bit on your machine? This would make it clear whether it's a 5.6 - 5.8 issue, or a 32 bit / 64 bit issue. My hunch is that it's something to do with big endian 64 bit builds (and pack templates or maybe structure alignment) but it would be good to test this. Nicholas Clark
Re: [PATCH bleadperl] Re: [perl #2915] my $x; our $x; does not give masked warning
On 7/13/05, Rick Delaney [EMAIL PROTECTED] wrote: I agree too. The following patch will make the first case warn too. Note that it also changes this current behaviour: % perl -wle 'our $p; package X; our $p;' % perl -wle 'our $p; package X; my $p;' my variable $p masks earlier declaration in same scope at -e line 1. I've applied a slightly modified version of your patch to bleadperl, to match the semantics defined earlier : Change 25179 on 2005/07/19 by [EMAIL PROTECTED] Overhaul the semantics of the warning %s variable %s masks earlier declaration, based on a patch by Rick Delaney. Now we have : my $x; my $x; # warns my $x; our $x; # warns our $x; my $x; # warns our $x; our $x; # silent http://public.activestate.com/cgi-bin/perlbrowse?patch=25179 The presence of a package declaration between the two lexical variable delacarations doesn't change the warning case. I think the our variable redeclared warning can be extended to the case our $x; our $x; but specifically not to the case our $x; package X; our $x; since in this latest case the 2nd $x is bound to $X::x and not $main::x. Agreed ?
Re: [perl #36526] Incorrect (X)HTML generated by Pod::Html
Earl Hood (via RT) wrote: What follows is a patch for Pod::Html based upon the version provided in Perl 5.8.6 that appears to fix the problem and generate more proper XHTML. Looking at the Pod::Html for 5.8.7, the patch should be applicable to both. Thanks, applied to bleadperl as change 25181. I've deleted, rather than commented out, the old code, as Michael Schwern suggested. A further note to bear in mind for any future patches is that the patch is easier to apply if the paths are more complete than --- Html.pm.5.8.6Wed Jul 13 01:28:13 2005 +++ Html.pmWed Jul 13 01:20:05 2005 A path of at least lib/Pod/Html.pm would have been more convenient. Radan Computational Ltd. The information contained in this message and any files transmitted with it are confidential and intended for the addressee(s) only. If you have received this message in error or there are any problems, please notify the sender immediately. The unauthorized use, disclosure, copying or alteration of this message is strictly forbidden. Note that any views or opinions presented in this email are solely those of the author and do not necessarily represent those of Radan Computational Ltd. The recipient(s) of this message should check it and any attached files for viruses: Radan Computational will accept no liability for any damage caused by any virus transmitted by this email.
Re: [PATCH] Faster **
On Tue, Jul 19, 2005 at 02:42:34AM +0100, Dave Mitchell wrote: On Fri, Jun 24, 2005 at 12:47:40PM +0200, Piotr Fusik wrote: Due to recent codes changes (cleanup, variable declaration moved) in this part, your patch doesn't apply cleanly. Can you resubmit one against a more recent bleadperl ? No problem. Thanks, applied as change #25177 And now we get to see what Irix long doubles make of this... Nicholas Clark
Smoke [5.9.3] 25178 FAIL(F) bsd/os 4.1 (i386/1 cpu)
Automated smoke report for 5.9.3 patch 25178 fixit.xs4all.nl: Pentium II (i386/1 cpu) onbsd/os - 4.1 using cc version egcs-2.91.66 19990314 (egcs-1.1.2 release) smoketime 3 hours 53 minutes (average 1 hour 56 minutes) Summary: FAIL(F) O = OK F = Failure(s), extended report at the bottom X = Failure(s) under TEST but not under harness ? = still running or test results not (yet) available Build failures during: - = unknown or N/A c = Configure, m = make, M = make (after miniperl), t = make test-prep 25178 Configuration (common) none --- - F F - - -Duse64bitint O O - - | | | +- PERLIO = perlio -DDEBUGGING | | +--- PERLIO = stdio -DDEBUGGING | +- PERLIO = perlio +--- PERLIO = stdio Failures: (common-args) none [stdio/perlio] -Duse64bitint ../t/op/int.t...FAILED 11 -- Report by Test::Smoke v1.19_67 build 842 running on perl 5.00503 (Reporter v0.019 / Smoker v0.023)
Re: overcoming limitations of embedded perl
On Mon, Jul 18, 2005 at 01:35:48PM -0700, Ed Peschko wrote: All, I noticed that an embedded perl does not allow for dynamic loading - eg. when I try to use Data::Dumper, I get - Can't load module Data::Dumper, dynamic loading not available in this perl. (You may need to build a new perl which supports dynamic loading or has the Data::Dumper module statically linked into it. perlembed.pod discusses this in the Using Perl modules, which themselves use C libraries, from your C program. The solution is simply that you need to statically link DynaLoader to your perl, and install its bootstrap in your xs_init. The ExtUtils::Embed module can be used automate writing a xs_init. -- Benjamin Smith [EMAIL PROTECTED], [EMAIL PROTECTED]
Re: [PATCH bleadperl] Re: [perl #2915] my $x; our $x; does not give masked warning
On Tue, Jul 19, 2005 at 12:17:43PM +0200, Rafael Garcia-Suarez wrote: I think the our variable redeclared warning can be extended to the case our $x; our $x; but specifically not to the case our $x; package X; our $x; since in this latest case the 2nd $x is bound to $X::x and not $main::x. Agreed ? Agreed. Thanks, -- Rick Delaney [EMAIL PROTECTED]
Re: [perl #2915] Inconsistent warnings with our
On Tue, Jul 19, 2005 at 12:00:00PM +0200, Rafael Garcia-Suarez wrote: On 7/15/05, Michael G Schwern [EMAIL PROTECTED] wrote: our $x; our $x; # no Its not a mask but its useless and probably an oversight on the part of the programmer. Maybe a Useless use of our? Or Repeated use of our? I'm fine with dealing with that separately. There's already the warning our variable %s redeclared that can be re-used for this. Right. Do we want the \t(Did you mean \local\ instead of \our\?)\n part for this? It is unlikely that the programmer meant local in this case. -- Rick Delaney [EMAIL PROTECTED]
Re: [perl #2915] Inconsistent warnings with our
Rick Delaney wrote: On Tue, Jul 19, 2005 at 12:00:00PM +0200, Rafael Garcia-Suarez wrote: On 7/15/05, Michael G Schwern [EMAIL PROTECTED] wrote: our $x; our $x; # no Its not a mask but its useless and probably an oversight on the part of the programmer. Maybe a Useless use of our? Or Repeated use of our? I'm fine with dealing with that separately. There's already the warning our variable %s redeclared that can be re-used for this. Right. Do we want the \t(Did you mean \local\ instead of \our\?)\n part for this? It is unlikely that the programmer meant local in this case. Good suggestion. I'll have a patch ready soon.
Re: [PATCH] allow POSIX SIGRTMIN...SIGRTMAX signals (and plug a core dump)
On Tue, 19 Jul 2005 12:06:00 +0300, Jarkko Hietaniemi [EMAIL PROTECTED]
wrote:
The attached patch introduces %POSIX::SIGRT which gives access
to the POSIX real time signals SIGRTMIN...SIGRTMAX, with the
right POSIXly moves. It also plugs a hole the size of a coredump
I accidentally run into while fooling around with the patch, try
perl -MPOSIX -e 'sigaction(123,0)'
Merijn, note that Configure is changed (and some bits of its logic
copied over to handy.h)
Configure re-generated
part 2 failed hunk 8. Applied by hand
All together now in as change #25185
Running a complete Configure/make/test_harness left me with three unexplained
failures that *might* have to do with this patch. Anyone having a bright
torch handy to shine a light on it?
===
Failed Test Stat Wstat Total Fail Failed List of Failed
---
../ext/POSIX/t/posix.t 255 65280?? ?? % ??
../ext/POSIX/t/taint.t 255 65280 7 14 200.00% 1-7
../lib/Pod/t/htmlview.t1 256 11 100.00% 1
run/fresh_perl.t 941 1.06% 67
55 tests and 241 subtests skipped.
Failed 4/1021 test scripts, 99.61% okay. 9/109750 subtests failed, 99.99% okay.
run/fresh_perl..ok 52/94# PROG:
# This test is here instead of lib/locale.t because
# the bug depends on in the internal state of the locale
# settings and pragma/locale messes up that state pretty badly.
# We need a fresh run.
# BEGIN {
# eval { require POSIX };
# if ($@) {
# exit(0); # running minitest?
# }
# }
# use Config;
# my $have_setlocale = $Config{d_setlocale} eq 'define';
# $have_setlocale = 0 if $@;
# Visual C's CRT goes silly on strings of the form en_US.ISO8859-1
# and mingw32 uses said silly CRT
# $have_setlocale = 0 if (($^O eq 'MSWin32' || $^O eq 'NetWare') $Config{cc}
=~ /^(cl|gcc)/i);
# exit(0) unless $have_setlocale;
# my @locales;
# if (-x /usr/bin/locale open(LOCALES, /usr/bin/locale -a 2/dev/null|))
{
# while(LOCALES) {
# chomp;
# push(@locales, $_);
# }
# close(LOCALES);
# }
# exit(0) unless @locales;
# for (@locales) {
# use POSIX qw(locale_h);
# use locale;
# setlocale(LC_NUMERIC, $_) or next;
# my $s = sprintf %g %g, 3.1, 3.1;
# next if $s eq '3.1 3.1' || $s =~ /^(3.+1) \1$/;
# print $_ $s\n;
# }
# EXPECTED:
# GOT:
# locale_h is not defined in %POSIX::EXPORT_TAGS at - line 28
# Can't continue after import errors at ../lib/POSIX.pm line 19
# BEGIN failed--compilation aborted at - line 28.
# STATUS: 65280
# Failed at run/fresh_perl.t line 53
run/fresh_perl..FAILED test 67
Failed 1/94 tests, 98.94% okay
../ext/POSIX/t/posixfcntl_h is not defined in
%POSIX::EXPORT_TAGS at ../ext/POSIX/t/posix.t line 17
signal_h is not defined in %POSIX::EXPORT_TAGS at ../ext/POSIX/t/posix.t line
17
limits_h is not defined in %POSIX::EXPORT_TAGS at ../ext/POSIX/t/posix.t line
17
Can't continue after import errors at ../lib/POSIX.pm line 19
BEGIN failed--compilation aborted at ../ext/POSIX/t/posix.t line 17.
../ext/POSIX/t/posixdubious
Test returned status 255 (wstat 65280, 0xff00)
../ext/POSIX/t/sigactionok
../ext/POSIX/t/taintfcntl_h is not defined in
%POSIX::EXPORT_TAGS at ../ext/POSIX/t/taint.t line 17
Can't continue after import errors at ../lib/POSIX.pm line 19
BEGIN failed--compilation aborted at ../ext/POSIX/t/taint.t line 17.
# Looks like your test died before it could output anything.
../ext/POSIX/t/taintdubious
Test returned status 255 (wstat 65280, 0xff00)
DIED. FAILED tests 1-7
Failed 7/7 tests, 0.00% okay
../ext/POSIX/t/waitpid..sys_wait_h is not defined in
%POSIX::EXPORT_TAGS at (eval 1) line 2
skipped
all skipped: no POSIX sys_wait_h
../lib/locale...locale_h is not defined in
%POSIX::EXPORT_TAGS at ../lib/locale.t line 40
../lib/locale...ok
../lib/Pod/t/htmlview...
# Failed test (../lib/Pod/t/pod2html-lib.pl at line 40)
../lib/Pod/t/htmlview...NOK 1# Looks like you failed 1 test
of 1.
../lib/Pod/t/htmlview...dubious
Test returned status 1 (wstat 256, 0x100)
DIED. FAILED test 1
Failed 1/1 tests, 0.00% okay
=
--
H.Merijn BrandAmsterdam Perl Mongers (http://amsterdam.pm.org/)
using Perl 5.6.2, 5.8.0, 5.8.5, 5.9.2 on HP-UX 10.20, 11.00 11.11,
AIX 4.3 5.2, SuSE 9.2 9.3, and Cygwin. http://www.cmve.net/~merijn
Smoking perl: http://www.test-smoke.org,perl QA: http://qa.perl.org
reports to: [EMAIL PROTECTED],
Re: [PATCH] allow POSIX SIGRTMIN...SIGRTMAX signals (and plug a core dump)
H.Merijn Brand wrote: On Tue, 19 Jul 2005 12:06:00 +0300, Jarkko Hietaniemi [EMAIL PROTECTED] wrote: The attached patch introduces %POSIX::SIGRT which gives access to the POSIX real time signals SIGRTMIN...SIGRTMAX, with the right POSIXly moves. It also plugs a hole the size of a coredump I accidentally run into while fooling around with the patch, try perl -MPOSIX -e 'sigaction(123,0)' Merijn, note that Configure is changed (and some bits of its logic copied over to handy.h) Configure re-generated part 2 failed hunk 8. Applied by hand All together now in as change #25185 Running a complete Configure/make/test_harness left me with three unexplained failures that *might* have to do with this patch. Anyone having a bright torch handy to shine a light on it? === Failed Test Stat Wstat Total Fail Failed List of Failed --- ../ext/POSIX/t/posix.t 255 65280?? ?? % ?? ../ext/POSIX/t/taint.t 255 65280 7 14 200.00% 1-7 ../lib/Pod/t/htmlview.t1 256 11 100.00% 1 htmlview.t failure is my mistake, following change 25181. Now fixed in change 25186. Sorry. Radan Computational Ltd. The information contained in this message and any files transmitted with it are confidential and intended for the addressee(s) only. If you have received this message in error or there are any problems, please notify the sender immediately. The unauthorized use, disclosure, copying or alteration of this message is strictly forbidden. Note that any views or opinions presented in this email are solely those of the author and do not necessarily represent those of Radan Computational Ltd. The recipient(s) of this message should check it and any attached files for viruses: Radan Computational will accept no liability for any damage caused by any virus transmitted by this email.
Re: [perl #2915] Inconsistent warnings with our
Rafael Garcia-Suarez wrote:
There's already the warning our variable %s redeclared that can be
re-used for this.
Right. Do we want the
\t(Did you mean \local\ instead of \our\?)\n
part for this? It is unlikely that the programmer meant local in this
case.
Good suggestion.
Implemented by :
Change 25187 by [EMAIL PROTECTED] on 2005/07/19 14:12:38
Extend the the our variable redeclared warning to the case:
our $x; our $x;
and add more tests
Affected files ...
... //depot/perl/pad.c#68 edit
... //depot/perl/t/lib/strict/vars#7 edit
... //depot/perl/t/lib/warnings/pad#8 edit
Differences ...
//depot/perl/pad.c#68 (text)
@@ -515,9 +515,10 @@
sv != PL_sv_undef
!SvFAKE(sv)
(SvIVX(sv) == PAD_MAX || SvIVX(sv) == 0)
-!(is_our (SvFLAGS(sv) SVpad_OUR))
strEQ(name, SvPVX_const(sv)))
{
+ if (is_our (SvFLAGS(sv) SVpad_OUR))
+ break; /* our masking our */
Perl_warner(aTHX_ packWARN(WARN_MISC),
\%s\ variable %s masks earlier declaration in same %s,
(is_our ? our : my),
@@ -540,8 +541,9 @@
{
Perl_warner(aTHX_ packWARN(WARN_MISC),
\our\ variable %s redeclared, name);
- Perl_warner(aTHX_ packWARN(WARN_MISC),
- \t(Did you mean \local\ instead of \our\?)\n);
+ if (off = PL_comppad_name_floor)
+ Perl_warner(aTHX_ packWARN(WARN_MISC),
+ \t(Did you mean \local\ instead of \our\?)\n);
break;
}
} while ( off-- 0 );
//depot/perl/t/lib/strict/vars#7 (text)
[... rest trimmed, cf APC for full text ...]
Re: [PATCH] perlop: why \c\ cannot be placed just before the terminating delimiter
On Mon, 18 Jul 2005 20:28:58 -0700, Yitzchak Scott-Thoennes wrote: On Sun, Jul 17, 2005 at 11:38:05AM +0900, SADAHIRO Tomoyuki wrote: \c\ is an only case (afaik) of escape sequence ending with backslash. Though perlop explains how to find the end of quoted constructs in detail, it may be a trap. I've long considered this a bug. I'd rather not document it, or document it explicitly as a bug. IMO finding the end is inconsistent with later processing, and \c\ should be treated as a complete character. Certainly this may be something like a bug or a limitation. However \c\ is invalid in single-quoted constructs, and a fix that will make qq/\c\/ valid should not make q/\c\/ valid. According to the gory details, interpretation of metacharacters and variables seems to be delayed till the step of interpolation. Though I don't know why the interpretation is performed after the extraction of delimiter-independent texts (by finding the end and removal of backslashes before delimiters), I suppose that, if someone will try to make qq/\c\/ valid, not only interpretation of \c\ but also any kind of interpolation may need to be performed at the step of finding the end. When finding the end and interpolation are performed at the same time, what is wrong? It's difficult, and I don't know the answer. An answer may be the case that backslashs are used as delimiters: if any combinations of a backslash followed by any character would be valid metacharacters, qq\. couldn't be terminated. Regards, SADAHIRO Tomoyuki
Re: [PATCH] perlfunc.pod
On Mon, Jul 18, 2005 at 02:41:30PM -0400, Scott R. Godin wrote: FAR better would be to use HTML 4.01 Strict instead of XHTML unless you (because of MathML or some other such) know WHY you need it. Ok, is there a decent POD - HTML 4.01 Strict module out there? -- Michael G Schwern [EMAIL PROTECTED] http://www.pobox.com/~schwern Ahh email, my old friend. Do you know that revenge is a dish that is best served cold? And it is very cold on the Internet!
Re: [PATCH bleadperl] Re: [perl #2915] my $x; our $x; does not give masked warning
On Tue, Jul 19, 2005 at 12:17:43PM +0200, Rafael Garcia-Suarez wrote: I think the our variable redeclared warning can be extended to the case our $x; our $x; but specifically not to the case our $x; package X; our $x; since in this latest case the 2nd $x is bound to $X::x and not $main::x. Agreed ? Yep. -- Michael G Schwern [EMAIL PROTECTED] http://www.pobox.com/~schwern Don't try the paranormal until you know what's normal. -- Lords and Ladies by Terry Prachett
Re: Porting perl to (traditional) Mac OS via Genie
On Jul 19, 2005, at 5:43 AM, Dominic Dunlop wrote:
On 19/07/2005, at 10:27 AM, Joshua Juran wrote:
I'm porting perl to a platform called Genie, which is a Unix-like
subsystem that runs in Mac OS. The purpose of this exercise is to
have a command-line perl tool available for Mac OS, in a stdio
environment with polymorphic file descriptors, without the
limitations of MPW.
Good to hear. You don't say whether this is PPC or 68k Mac OS. I guess
the former, though the FAQs on your site make me wonder.
I wonder too. I haven't looked at them in years. :-)
Genie requires CFM -- Genie programs are built as CFM drop-ins, or
plugins. CFM-68K Runtime Enabler 4.0 requires System 7.6.1, which
requires a 32-bit clean ROM (and perhaps a 68020 or better). This
leaves out the Mac II, IIx, IIcx, SE/30, and 68000-based machines
(unless an earlier version of the CFM-68K Runtime Enabler with an
earlier system works, which I don't plan to test any time soon). While
it might be possible to use code resources (with Genie fiddling the A4
register for plugin globals) I don't see the value, since much faster
Macs are readily available on the cheap. Genie does actually build and
run on 68K, although you have to patch a bug in Threads.h if you want
to use Thread Manager callbacks without crashing.
Genie's sockets support requires Open Transport -- MacTCP is not
supported. I don't think this will upset anyone.
One caveat is that Open Transport only supports CFM-68K as of version
1.3, which requires Mac OS 8.1, which in addition to ruling out
anything less than a 68040 nails you to a specific OS version.
Fortunately, the OTCFM68KGlue library hacks around this by calling OT
from a 68K code resource and should make it possible to support System
7.5.5 and 7.6.1. I haven't tried this yet.
Back in the day, I worked on keeping Perl running on PPC MachTen, a
commercial UNIX-under-Mac OS product from Tenon Intersystems
(http://www.tenon.com). The product, though still apparently
available, is, as far as I know, unsupported, and suffers from a
number of long-standing bugs and security issues. Vague requests from
some users that the code be open-sourced after support ended were
rebuffed.
Apple phrased it this way: Open source is not a dumping ground for
dead products.[1]
Most unfortunate, since I'm sure I could have found *something* useful
in the source code. ;-) Other closed Unix-on-Mac products include
Mac06 and (though this is a stretch) Apple's own MPW. Open-source
projects include MacMiNT and PATMOS.
MachTen was delivered with gcc, so I didn't use MPW or CodeWarrior in
porting perl. If you search in old perl5-
Genie requires a real C++ compiler to build, which rules out MrC/SC.
Plugins shouldn't require C++ at all, but I haven't investigated using
anything other than MW C. Perhaps I should -- I ran into some curious
MW linker issues that prevent me from linking Genie plugins against my
own shared libraries, and had to link in the standard library
statically.
porters archives, you'll find mail about various issues I tripped
over, including malloc() (once tweaked to work, Perl's own malloc was
much faster than Mac OS' own); and fork() (MachTen, thanks to deep and
probably dark magic, has both fork() and vfork(), but the latter is
MUCH faster, as Mac OS does not support Copy on Write). You'll also
find clues in hints/machten.sh.
One of the problems is returning twice. Matthias got the idea to
provide vfork() as a macro that calls setjmp(), which he implemented in
his Natty project.[2] I opted against this for now, since what you'd
have to do with the return value of setjmp() to implement proper
vfork() semantics and what the standard says you're allowed to do with
it are not compatible. AFAICT you're not even allowed to assign the
return value to a variable. It might work anyway, but I didn't wish to
go there.
My interim solution requires as a compromise that code be written thus:
#ifndef macintosh
#define is_child_pid( pid ) ((pid) == 0)
#endif
pid_t pid;
while ( (pid = vfork()) == -1 ) sleep(5);
if ( is_child_pid( pid ) )
{
/* We're the child */
/* setenv, dup2, etc. */
execve( ... );
_exit( EXIT_FOO );
}
/* We're the parent */
waitpid( ... );
The trick here is that for a Genie plugin, vfork() saves the caller's
process context and returns the child pid (once), is_child_pid() is the
identity function (always true for a pid), and either execve() (unless
it fails) or _exit() restores the original process context AND RETURNS.
(Unless you call without forking, in which case it terminates the
caller's thread.)
Hey -- it works, doesn't it?
The third way is to decide you're not just an application but really
part of the
Re: [perl-5.8.7] Perl regression tests fail when lib directory is present
Try the same Test::Harness with an older perl. See if its a perl bug. -- Michael G Schwern [EMAIL PROTECTED] http://www.pobox.com/~schwern Insulting our readers is part of our business model. http://somethingpositive.net/sp07122005.shtml
RE: Circular dependency prevents installation of Scalar-List-Utils on 5.004
From: Michael G Schwern [mailto:[EMAIL PROTECTED] On Mon, Jul 18, 2005 at 02:30:27PM +0100, Paul Marquess wrote: Is there any way out of this maze of twisty little passages? Install File::Spec by hand? Use 5.004_05 which comes with File::Spec? I think the assumption that Perl will come with File::Spec and Cwd is a fairly safe one these days except for pathologically old versions of Perl. In common with most of the people on this list, I've no doubt that I can easily find a workaround to this problem for my development box -- either installing by hand or by using older versions of the modules. The point is, though, I want to make use of Scalar-List-Utils in Compress::Zlib - which currently works with all Perl's = 5.004. If I do end up using it, and the issues I've encountered are not fixed, then the average user who, for whatever reason, is stuck with a very old version of Perl is going to have a difficult/impossible time building my module. This raises the question (which I think you yourself brought up a couple of weeks ago) about support for ancient-perl. Should module authors continue to support 5.004* at all? The problems I'm encountering with Scalar-Util/Cwd/File-Spec seem to imply a drift towards a de-facto deprecation of support for new modules in ancient-perl (that was a bit of a mouthful!). This may be caused by updates to modules that either explicitly drop support for a given ancient-perl version or inadvertently drop support because they aren't tested on all versions of Perl. I guess another way to look at this is to ask why has nobody else noticed the problem with these modules? Scalar-Util/Cwd/File-Spec are all fairly common modules. Could the lack of problem reports imply that nobody actually uses 5.004* anymore? Paul ___ Yahoo! Messenger - NEW crystal clear PC to PC calling worldwide with voicemail http://uk.messenger.yahoo.com
Re: [PATCH] allow POSIX SIGRTMIN...SIGRTMAX signals (and plug a core dump)
On Tue, 19 Jul 2005, Jarkko Hietaniemi wrote: The attached patch introduces %POSIX::SIGRT which gives access to the POSIX real time signals SIGRTMIN...SIGRTMAX, with the right POSIXly moves. It also plugs a hole the size of a coredump I accidentally run into while fooling around with the patch, try perl -MPOSIX -e 'sigaction(123,0)' One portability nit: The #define NSIG logic has to come *after* #include unixish.h in perl.h, because that's where signal.h gets included. It's good to see you leaving behind such messy topics as cross-compilation and locales, and doing something clean and portable, like signals :-). Cheers, Andy Dougherty [EMAIL PROTECTED]
Re: [PATCH] perlop: why \c\ cannot be placed just before the terminating delimiter
On Mon, 18 Jul 2005 20:28:58 -0700, Yitzchak Scott-Thoennes wrote: I've long considered this a bug. I'd rather not document it, or document it explicitly as a bug. IMO finding the end is inconsistent with later processing, and \c\ should be treated as a complete character. Well, I've thought it over a little longer after the prev reply. If \c\ will be treated as a metacharacter and skipped during finding the end, as well as \\, then \c\ will work as \x1c. But ambiguity may occur when c's are used as delimiter, i.e. qq c...c for Doesn't it see whether \c is an escaped delimiter or a part of \c\ ? How should (qq c\c\c) and (qq c\c\cc) be parsed? qq c\c\c : \c\ (\x1c), or cc (not terminated, error) ? qq c\c\cc : cc, or \c\c (superfluous c, error) ? Regards, SADAHIRO Tomoyuki
Re: [PATCH] perlfunc.pod
Scott R Godin [EMAIL PROTECTED] writes: There's only one real problem with that, however. Sending XHTML as text/html means the browser is expecting tag-soup. NOT XHTML.. This is not true if you use XHTML 1.0. Try it in Firefox. You'll see that the browser reports that it's in standards compliance mode. That being said, there really isn't much of a reason to use XHTML rather than HTML 4.0 unless one just wants to for personal reasons. I use it for my own reasons, but it's primarily as a science experiment, and it's probably not the right mode to run general software in. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/
Smoke [5.9.3] 25185 FAIL(F) linux 2.6.12-3-686 [debian] (i686/1 cpu)
Automated smoke report for 5.9.3 patch 25185 kirk: Intel(R) Celeron(R) CPU 2.00GHz (GenuineIntel 1994MHz) (i686/1 cpu) onlinux - 2.6.12-3-686 [debian] using cc version 4.0.1 (Debian 4.0.1-1ubuntu1) smoketime 5 hours 46 minutes (average 43 minutes 21 seconds) Summary: FAIL(F) O = OK F = Failure(s), extended report at the bottom X = Failure(s) under TEST but not under harness ? = still running or test results not (yet) available Build failures during: - = unknown or N/A c = Configure, m = make, M = make (after miniperl), t = make test-prep 25185 Configuration (common) none --- - F F F F F F F F F F F F -Duseithreads F F F F F F -DPERL_DEBUG_COW F F F F F F -DPERL_DEBUG_COW -Duseithreads | | | | | +- LC_ALL = en_US.utf8 -DDEBUGGING | | | | +--- PERLIO = perlio -DDEBUGGING | | | +- PERLIO = stdio -DDEBUGGING | | +--- LC_ALL = en_US.utf8 | +- PERLIO = perlio +--- PERLIO = stdio Failures: [stdio/perlio/en_US.utf8] [stdio/perlio/en_US.utf8] -DDEBUGGING ../ext/POSIX/t/posix.t..FAILED ?? ../ext/POSIX/t/taint.t..FAILED 1-7 ../lib/Pod/t/htmlview.t.FAILED 1 ../t/run/fresh_perl.t...FAILED 67 [stdio/perlio/en_US.utf8] -Duseithreads [stdio/perlio/en_US.utf8] -DDEBUGGING -Duseithreads [stdio/perlio/en_US.utf8] -DPERL_DEBUG_COW [stdio/perlio/en_US.utf8] -DDEBUGGING -DPERL_DEBUG_COW [stdio/perlio/en_US.utf8] -DPERL_DEBUG_COW -Duseithreads [stdio/perlio/en_US.utf8] -DDEBUGGING -DPERL_DEBUG_COW -Duseithreads ../ext/POSIX/t/sigaction.t..FAILED 1-29 ../lib/Pod/t/htmlview.t.FAILED 1 -- Report by Test::Smoke v1.19#716 running on perl 5.8.7 (Reporter v0.016 / Smoker v0.015)
Re: [perl-5.8.7] Perl regression tests fail when lib directory is present
On Mon, 18 Jul 2005 01:50:33 -0700, Michael G Schwern wrote:
MakeMaker is not involved, just Test::Harness. All the action is in or
called from Test::Harness::Straps-analyze_file.
I agree. TH is resetting INC and the directories passed
into test_harness() are lost after the first invocation.
The simple test script below, when tested twice, fails on
the second call. As you'll see, blib/lib is not in INC.
_ t/foo.t
/ #!/usr/bin/perl -w
| use strict;
| use Test::More qw(no_plan);
|
| use_ok('Device::Profile::Document');
| printf(INC:\t%s\n, join(\n\t, @INC));
If you prepend the perl or (make test) command with
(env PERL5LIB=blib/lib) the tests will work.
% perl -MExtUtils::Command::MM -e 'test_harness(1, blib/lib)' t/foo.t t/foo.t
t/foook 1 - use Device::Profile::Document;
INC: /home/scott/Projects/MDS2/Device-Profile/blib/lib
/usr/lib/perl5/5.8/cygwin
/usr/lib/perl5/5.8
/usr/lib/perl5/site_perl/5.8/cygwin
/usr/lib/perl5/site_perl/5.8
/usr/lib/perl5/site_perl/5.8
/usr/lib/perl5/vendor_perl/5.8/cygwin
/usr/lib/perl5/vendor_perl/5.8
/usr/lib/perl5/vendor_perl/5.8
.
1..1
ok
t/foo
# Failed test (t/foo.t at line 5)
# Tried to use 'Device::Profile::Document'.
# Error: Can't locate Device/Profile/Document.pm in @INC (@INC contains:
/usr/lib/perl5/5.8/cygwin /usr/lib/perl5/5.8
/usr/lib/perl5/site_perl/5.8/cygwin /usr/lib/perl5/site_perl/5.8
/usr/lib/perl5/site_perl/5.8 /usr/lib/perl5/vendor_perl/5.8/cygwin
/usr/lib/perl5/vendor_perl/5.8 /usr/lib/perl5/vendor_perl/5.8 .) at (eval 3)
line 2.
# BEGIN failed--compilation aborted at t/foo.t line 5.
# Looks like you failed 1 test of 1.
not ok 1 - use Device::Profile::Document;
INC: /usr/lib/perl5/5.8/cygwin
/usr/lib/perl5/5.8
/usr/lib/perl5/site_perl/5.8/cygwin
/usr/lib/perl5/site_perl/5.8
/usr/lib/perl5/site_perl/5.8
/usr/lib/perl5/vendor_perl/5.8/cygwin
/usr/lib/perl5/vendor_perl/5.8
/usr/lib/perl5/vendor_perl/5.8
.
1..1
dubious
Test returned status 1 (wstat 256, 0x100)
DIED. FAILED test 1
Failed 1/1 tests, 0.00% okay
Failed Test Stat Wstat Total Fail Failed List of Failed
---
t/foo.t1 256 11 100.00% 1
Failed 1/2 test scripts, 50.00% okay. 1/2 subtests failed, 50.00% okay.
Re: [PATCH] perlfunc.pod
Michael G Schwern wrote: On Mon, Jul 18, 2005 at 02:41:30PM -0400, Scott R. Godin wrote: FAR better would be to use HTML 4.01 Strict instead of XHTML unless you (because of MathML or some other such) know WHY you need it. Ok, is there a decent POD - HTML 4.01 Strict module out there? If the XHTML produced currently would pass a validation test, then it's highly likely that as HTML 4.01 Strict, it would also pass (provided one removes the ' /' style tag-endings from things like 'br', etc. However, I know that CGI.pm (which IIRC is part of the core) is perfectly capable of producing clean well-formed html, (though the default !DOCTYPE used by it is HTML 4.01 Transitional) through its function-oriented interface. (which in a quite nifty fashion, has the added benefit of *looking* almost like html, making it far easier to debug, too.) I've had this itch to rip Pod::Html to shreds for a while now, and refactor it to do the job more cleanly. Would anyone object to my taking a whack at it?
Re: [perl #36588] Problem with semctl() on Perl 5.8.6, 64-bit build, HP-UX 11i
Hi, your guess matches my guess. Generally speaking, I can compile small snippets of C code without problem, but I'm going to run into resource limits if I try to build something as big as Perl. (If you know of a 32-bit 5.8.x Perl build in an HP-UX depot, I will ask our admin to install it, though.) What I thought I'd try is to take a look at the Perl code handling the sem*() calls. Haven't do that yet... I'll keep you updated. - PŮVODNÍ ZPRÁVA - Od: Nicholas Clark via RT [EMAIL PROTECTED] Komu: [EMAIL PROTECTED] Předmět: Re: [perl #36588] Problem with semctl() on Perl 5.8.6, Datum: 19.7.2005 - 12:09:18 On Mon, Jul 18, 2005 at 07:04:03AM -0700, novotny. petr @ volny. cz wrote: Output from 5.6.1 (32-bit): Created new semaphore 1 Output from 5.8.6 (64-bit): Created new semaphore 0 (Of course, I called ipcrm between the two tests to delete the semaphore. I'm saying this just in case :-)) That's useful, as it's the sort of thing that people forget. (Well, I would) Are you able to build 5.8.5 32-bit on your machine? This would make it clear whether it's a 5.6 - 5.8 issue, or a 32 bit / 64 bit issue. My hunch is that it's something to do with big endian 64 bit builds (and pack templates or maybe structure alignment) but it would be good to test this. Nicholas Clark
Re: [PATCH] perlfunc.pod
On Tue, Jul 19, 2005 at 11:31:01AM -0400, Scott R. Godin wrote: I've had this itch to rip Pod::Html to shreds for a while now, and refactor it to do the job more cleanly. Would anyone object to my taking a whack at it? It would probably be better to evaluate the existing POD - HTML converters and wrap POD::Html around them, or just leave POD::Html alone and convert installhtml to use the better module, than to write Yet Another POD - HTML Module. -- Michael G Schwern [EMAIL PROTECTED] http://www.pobox.com/~schwern Reality is that which, when you stop believing in it, doesn't go away. -- Phillip K. Dick
Re: Circular dependency prevents installation of Scalar-List-Utils on 5.004
On Tue, Jul 19, 2005 at 05:32:30PM +0100, Paul Marquess wrote: I guess another way to look at this is to ask why has nobody else noticed the problem with these modules? Scalar-Util/Cwd/File-Spec are all fairly common modules. Could the lack of problem reports imply that nobody actually uses 5.004* anymore? If by use you mean develops against and upgrades modules for then I think it likely. As far as I know one large perl-using bank still has some things running on 5.004, but I don't know if they tweak those scripts much. Nicholas Clark
Re: [PATCH] perlfunc.pod
On 7/19/05, Michael G Schwern [EMAIL PROTECTED] wrote: On Tue, Jul 19, 2005 at 11:31:01AM -0400, Scott R. Godin wrote: I've had this itch to rip Pod::Html to shreds for a while now, and refactor it to do the job more cleanly. Would anyone object to my taking a whack at it? It would probably be better to evaluate the existing POD - HTML converters and wrap POD::Html around them, or just leave POD::Html alone and convert installhtml to use the better module, than to write Yet Another POD - HTML Module. I can think about a couple of points : * state of the art of html documentation has greatly improved since the perl 5.000 days. Pod::Html generates obsolete html (old syntax, no CSS support, etc.) * Pod::Html is barely usable, making a good pod-html translator now would mean designing a more complete and probably incompatible interface. * People have hacked around the limitations of Pod::Html that were the most annoying, and probably post-process its output. It's html, they want eye-candy and stuff that looks like search.cpan.org. OK, that's a weird backwards-compatibility argument. In short, my opinion would be to leave Pod::Html alone, fixing the most obvious bugs, and slowly deprecating it in favor of the next big thing. PS. /me discovers that Pod::Xhtml is a module brought to you by the BBC :)
Re: Circular dependency prevents installation of Scalar-List-Utils on 5.004
On Tue, Jul 19, 2005 at 05:32:30PM +0100, Paul Marquess wrote: This raises the question (which I think you yourself brought up a couple of weeks ago) about support for ancient-perl. Should module authors continue to support 5.004* at all? There's supporting the 5.4.x tree and then there's supporting old versions of that tree. There's only so far I'd expect module authors to bend over for old versions. Supporting the latest version of an old 5.x tree should be far enough. If nothing else, some of the older versions won't even compile with modern build tools. I had to do some fiddling to even get 5.4.5 compiled on OS X. Dealing with old versions is bad enough. Dealing with old releases of old versions is going well beyond the call of duty. I guess another way to look at this is to ask why has nobody else noticed the problem with these modules? Scalar-Util/Cwd/File-Spec are all fairly common modules. Could the lack of problem reports imply that nobody actually uses 5.004* anymore? That's been my conclusion, unless there's some vast Silent Majority of 5.4 users out there and in that case its their fault for keeping quiet. I think one machine at the job I just started here still runs 5.4 and its an old Dynix box that's being phased out. I few other people have mentioned machines they know of that are still running 5.4. There's really no good reason anyone should still be actively developing with 5.4, though they might be keeping it around to run old code, and I'm really not that interested in doing extra work to support sloppy sysadmins that can't be bothered to install two versions of Perl: one for active development and one for old, unsupported code. I haven't even heard from a 5.5.x user in a while. That said, here's how far back the CPAN versions of the critical modules can go which effectively sets a backwards compatibility limit for any module author not wanting to completely reinvent the wheel. Module Ships With Latest Version Installs On ExtUtils::MakeMaker 5.0 5.5.3 (with Pod::Man) Test::More 5.8.0 5.4.5 (maybe further) Test::Harness 5.0 5.5.3 (5.4.5 with a pending patch) File::Spec 5.5.0/5.4.5 5.4.5 (I think) Cwd 5.0 5.4.5 (I think) Module::Build 5.5.3 (I think) Test5.5.0/5.4.5 5.4.5 (I think) NOTE: 5.4.4 is probably equivalent to 5.4.5 in the above list but I don't have a copy to check and Module::CoreList doesn't list 5.4.4. So I'd say for most modules supporting 5.6.2 == good. Supporting 5.5.4 == excellent. Supporting 5.4.5 == if you really want to. Don't bother with intermediate versions (ie. 5.4.0, 5.5.3, etc...). If somebody really wants a module to work on an old Perl they can pay the author to backport it. Why should they do work they don't want to do, is of no benefit to them, and deals with a self-inflicted pathological mess, for Free? -- Michael G Schwern [EMAIL PROTECTED] http://www.pobox.com/~schwern 'All anyone gets in a mirror is themselves,' she said. 'But what you gets in a good gumbo is everything.' -- Witches Abroad by Terry Prachett
Re: [PATCH] perlfunc.pod
Michael G Schwern wrote: On Mon, Jul 18, 2005 at 02:41:30PM -0400, Scott R. Godin wrote: FAR better would be to use HTML 4.01 Strict instead of XHTML unless you (because of MathML or some other such) know WHY you need it. Ok, is there a decent POD - HTML 4.01 Strict module out there? oh, one additional thought.. the current Pod::Html might be better renamed as Pod::XHtml.. no? :)
Re: [PATCH] perlfunc.pod
On Tue, Jul 19, 2005 at 08:59:33PM +0200, Rafael Garcia-Suarez wrote: On 7/19/05, Michael G Schwern [EMAIL PROTECTED] wrote: On Tue, Jul 19, 2005 at 11:31:01AM -0400, Scott R. Godin wrote: I've had this itch to rip Pod::Html to shreds for a while now, and refactor it to do the job more cleanly. Would anyone object to my taking a whack at it? It would probably be better to evaluate the existing POD - HTML converters and wrap POD::Html around them, or just leave POD::Html alone and convert installhtml to use the better module, than to write Yet Another POD - HTML Module. I can think about a couple of points : * state of the art of html documentation has greatly improved since the perl 5.000 days. Pod::Html generates obsolete html (old syntax, no CSS support, etc.) * Pod::Html is barely usable, making a good pod-html translator now would mean designing a more complete and probably incompatible interface. But that doesn't rule out creating a minimal wrapper to provide Pod::Html's interface. * People have hacked around the limitations of Pod::Html that were the most annoying, and probably post-process its output. It's html, they want eye-candy and stuff that looks like search.cpan.org. OK, that's a weird backwards-compatibility argument. On the other hand, I'm quite happy to ignore anyone who gets too upset by their post-processing going awry. Pod::Html is documented as returning HTML. Not the specific current output it creates. In short, my opinion would be to leave Pod::Html alone, fixing the most obvious bugs, and slowly deprecating it in favor of the next big thing. I prefer Schwern's suggestion. Then again, I'm not proposing to volunteer. my own labour here, so ultimately the choice is someone else's. But I don't think that refactoring the existing Pod::Html to create yet another convertor is the way to go. Nicholas Clark
Re: [PATCH] perlfunc.pod
On 7/19/05, Nicholas Clark [EMAIL PROTECTED] wrote: But that doesn't rule out creating a minimal wrapper to provide Pod::Html's interface. But that would imply that wrapped modules should enter the Perl distribution, because Pod::Html is core. Right? Adriano.
Re: [PATCH] perlfunc.pod
On 7/19/05, Adriano Ferreira [EMAIL PROTECTED] wrote: On 7/19/05, Nicholas Clark [EMAIL PROTECTED] wrote: But that doesn't rule out creating a minimal wrapper to provide Pod::Html's interface. But that would imply that wrapped modules should enter the Perl distribution, because Pod::Html is core. Right? Moreover, installhtml is core :)
Re: [perl #36588] Problem with semctl() on Perl 5.8.6, 64-bit build, HP-UX 11i
On Tue, Jul 19, 2005 at 04:55:25PM +0200, [EMAIL PROTECTED] wrote: Hi, your guess matches my guess. Generally speaking, I can compile small snippets of C code without problem, but I'm going to run into resource limits if I try to build something as big as Perl. (If you know of a 32-bit 5.8.x Perl build in an HP-UX depot, I will ask our admin to install it, though.) I can only find gcc built perls for HP-UX What I thought I'd try is to take a look at the Perl code handling the sem*() calls. Haven't do that yet... I can't replicate the problem with 5.8.6 built with 64 bit ints on OS X (So it's not a general big endian problem) Nicholas Clark
Re: [PATCH] perlfunc.pod
On Jul 19, 2005, at 1:35 PM, Russ Allbery wrote: Scott R Godin [EMAIL PROTECTED] writes: Sending XHTML as text/html means the browser is expecting tag-soup. NOT XHTML.. This is not true if you use XHTML 1.0. Try it in Firefox. You'll see that the browser reports that it's in standards compliance mode. I recommend Appendix C of the XHTML spec: HTML Compatibility Guidelines http://www.w3.org/TR/xhtml1/#guidelines That being said, there really isn't much of a reason to use XHTML rather than HTML 4.0 unless one just wants to for personal reasons. I use it for my own reasons, but it's primarily as a science experiment, and it's probably not the right mode to run general software in. I've been developing an HTML output library that I use with mod_perl for my work. Its usage rather resembles the functional interface of CGI, but the output is a hierarchical structure of Perl 5 objects. Calling the root's (or any node's) Print method pretty-prints the entire document (or just that node). Currently it generates XHTML, but it would be trivial to adjust it to produce HTML 4 instead. This decision could be made at runtime through a parameter to Print. This would be a way to separate the production of an HTML document structure from the actual markup generation. If somebody's interested, I'll post it. Josh -- Joshua Juran Metamage Software Creations - Mac Software and Consulting http://www.metamage.com/ * Creation at the highest state of the art *
[perl #36594] ActivePerl splits arguments passed to exec() on whitespace
# New Ticket Created by Piotr Fusik
# Please include the string: [perl #36594]
# in the subject line of all future correspondence about this issue.
# URL: https://rt.perl.org/rt3/Ticket/Display.html?id=36594
This is a bug report for perl from [EMAIL PROTECTED],
generated with the help of perlbug 1.34 running under perl v5.8.0.
-
The problem is that the arguments passed to exec() are not passed
as they are to the called program, but instead are split on whitespace.
Example:
perl -e exec$^X,'-e','print+join+q{,},@ARGV','foo boo bar'
prints:
foo,boo,bar
system() works fine:
perl -e system$^X,'-e','print+join+q{,},@ARGV','foo boo bar'
prints:
foo boo bar
-
---
Flags:
category=core
severity=low
---
Site configuration information for perl v5.8.0:
Configured by ActiveState at Mon Mar 31 00:45:28 2003.
Summary of my perl5 (revision 5 version 8 subversion 0) configuration:
Platform:
osname=MSWin32, osvers=4.0, archname=MSWin32-x86-multi-thread
uname=''
config_args='undef'
hint=recommended, useposix=true, d_sigaction=undef
usethreads=undef use5005threads=undef useithreads=define
usemultiplicity=define
useperlio=define d_sfio=undef uselargefiles=define usesocks=undef
use64bitint=undef use64bitall=undef uselongdouble=undef
usemymalloc=n, bincompat5005=undef
Compiler:
cc='cl', ccflags
='-nologo -Gf -W3 -MD -Zi -DNDEBUG -O1 -DWIN32 -D_CONSOLE -DNO_STRICT -D
HAVE_DES_FCRYPT -DPERL_IMPLICIT_CONTEXT -DPERL_IMPLICIT_SYS -DUSE_PERLI
O -DPERL_MSVCRT_READFIX',
optimize='-MD -Zi -DNDEBUG -O1',
cppflags='-DWIN32'
ccversion='', gccversion='', gccosandvers=''
intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=1234
d_longlong=undef, longlongsize=8, d_longdbl=define, longdblsize=10
ivtype='long', ivsize=4, nvtype='double', nvsize=8, Off_t='__int64',
lseeksize=8
alignbytes=8, prototype=define
Linker and Libraries:
ld='link', ldflags
'-nologo -nodefaultlib -debug -opt:ref,icf -libpath:C:\j\Perl\lib\CORE
-machine:x86'
libpth=D:\Program Files\Microsoft.NET\FrameworkSDK\Lib\
D:\Program Files\Microsoft.Net\Odbc.Net\ C:\j\Perl\lib\CORE
libs= oldnames.lib kernel32.lib user32.lib gdi32.lib winspool.lib
comdlg32.lib advapi32.lib shell32.lib ole32.lib oleaut32.lib
netapi32.lib uuid.lib wsock32.lib mpr.lib winmm.lib version.lib
odbc32.lib odbccp32.lib msvcrt.lib
perllibs= oldnames.lib kernel32.lib user32.lib gdi32.lib
winspool.lib comdlg32.lib advapi32.lib shell32.lib ole32.lib
oleaut32.lib netapi32.lib uuid.lib wsock32.lib mpr.lib winmm.lib
version.lib odbc32.lib odbccp32.lib msvcrt.lib
libc=msvcrt.lib, so=dll, useshrplib=yes, libperl=perl58.lib
gnulibc_version='undef'
Dynamic Linking:
dlsrc=dl_win32.xs, dlext=dll, d_dlsymun=undef, ccdlflags=' '
cccdlflags=' ',
lddlflags='-dll -nologo -nodefaultlib -debug -opt:ref,icf -libpath:C:\
j\Perl\lib\CORE -machine:x86'
Locally applied patches:
ACTIVEPERL_LOCAL_PATCHES_ENTRY
---
@INC for perl v5.8.0:
C:/j/Perl/lib
C:/j/Perl/site/lib
.
---
Environment for perl v5.8.0:
HOME (unset)
LANG (unset)
LANGUAGE (unset)
LD_LIBRARY_PATH (unset)
LOGDIR (unset)
PATH=C:\WINDOWS;C:\WINDOWS\COMMAND;C:\U;C:\JAVA\JDK\BIN;C:\C\DJGPP\BIN;C
:\J\PERL\BIN;C:\J\MYSQL\BIN;C:\U\TEXMF\MAIN\MIKTEX\BIN;C:\U\GS\GS8.11\BI
N;C:\C\CYGWIN\BIN;C:\WINDOWS;C:\WINDOWS\COMMAND;C:\U\ANT\BIN
PERL_BADLANG (unset)
SHELL (unset)
Re: [PATCH] perlfunc.pod
Russ Allbery wrote: Scott R Godin [EMAIL PROTECTED] writes: There's only one real problem with that, however. Sending XHTML as text/html means the browser is expecting tag-soup. NOT XHTML.. This is not true if you use XHTML 1.0. Try it in Firefox. You'll see that the browser reports that it's in standards compliance mode. Firefox is merely being kind to all the silly web-authors out there who think it's a good idea to send XHTML as text/html instead of application/xhtml+xml because the latter breaks in nearly every browser due to the fact that they aren't prepared to handle XHTML as it was meant to be delivered. EVERYONE jumped on this way too early. That being said, there really isn't much of a reason to use XHTML rather than HTML 4.0 unless one just wants to for personal reasons. I use it for my own reasons, but it's primarily as a science experiment, and it's probably not the right mode to run general software in. can't disagree with you there... :)
Re: overcoming limitations of embedded perl
On Tue, Jul 19, 2005 at 01:32:27PM +0100, Benjamin Smith wrote: On Mon, Jul 18, 2005 at 01:35:48PM -0700, Ed Peschko wrote: All, I noticed that an embedded perl does not allow for dynamic loading - eg. when I try to use Data::Dumper, I get - Can't load module Data::Dumper, dynamic loading not available in this perl. (You may need to build a new perl which supports dynamic loading or has the Data::Dumper module statically linked into it. perlembed.pod discusses this in the Using Perl modules, which themselves use C libraries, from your C program. The solution is simply that you need to statically link DynaLoader to your perl, and install its bootstrap in your xs_init. hmm... should have read further in perlembed.. thanks for the pointer.. Ed
Re: [perl #36594] ActivePerl splits arguments passed to exec() on whitespace
On Tue, Jul 19, 2005 at 10:45:34AM -0700, Piotr Fusik wrote:
The problem is that the arguments passed to exec() are not passed
as they are to the called program, but instead are split on whitespace.
Example:
perl -e exec$^X,'-e','print+join+q{,},@ARGV','foo boo bar'
prints:
foo,boo,bar
system() works fine:
perl -e system$^X,'-e','print+join+q{,},@ARGV','foo boo bar'
prints:
foo boo bar
snip
Configured by ActiveState at Mon Mar 31 00:45:28 2003.
Summary of my perl5 (revision 5 version 8 subversion 0) configuration:
Thank you for your report.
That's an old version of Perl. Try upgrading and see if the bug is still
present.
--
Michael G Schwern [EMAIL PROTECTED] http://www.pobox.com/~schwern
Insulting our readers is part of our business model.
http://somethingpositive.net/sp07122005.shtml
Smoke [5.9.3] 25189 FAIL(M) MSWin32 WinXP/.Net SP1 (x86/1 cpu)
Automated smoke report for 5.9.3 patch 25189 TANGAROA.uk.radan.com: Intel(R) Pentium(R) 4 CPU 2.00GHz(~1992 MHz) (x86/1 cpu) onMSWin32 - WinXP/.Net SP1 using cl version 12.00.8804 smoketime 2 hours 15 minutes (average 4 minutes 14.750 seconds) Summary: FAIL(M) O = OK F = Failure(s), extended report at the bottom X = Failure(s) under TEST but not under harness ? = still running or test results not (yet) available Build failures during: - = unknown or N/A c = Configure, m = make, M = make (after miniperl), t = make test-prep 25189 Configuration (common) -DINST_TOP=$(INST_DRV)\Smoke\doesntexist --- - M M M M -Dusemymalloc M M -Duselargefiles M M -Duselargefiles -Dusemymalloc M M -Duseithreads -Uuseimpsys M M -Duseithreads -Uuseimpsys -Dusemymalloc M M -Duseithreads -Uuseimpsys -Duselargefiles M M -Duseithreads -Uuseimpsys -Duselargefiles -Dusemymalloc M M -Accflags='-DPERL_COPY_ON_WRITE' M M -Accflags='-DPERL_COPY_ON_WRITE' -Dusemymalloc M M -Accflags='-DPERL_COPY_ON_WRITE' -Duselargefiles M M -Accflags='-DPERL_COPY_ON_WRITE' -Duselargefiles -Dusemymalloc M M -Accflags='-DPERL_COPY_ON_WRITE' -Duseithreads -Uuseimpsys M M -Accflags='-DPERL_COPY_ON_WRITE' -Duseithreads -Uuseimpsys -Dusemymalloc M M -Accflags='-DPERL_COPY_ON_WRITE' -Duseithreads -Uuseimpsys -Duselargefiles M M -Accflags='-DPERL_COPY_ON_WRITE' -Duseithreads -Uuseimpsys -Duselargefiles -Dusemymalloc | +- -DDEBUGGING +--- no debugging Failures: (common-args) -DINST_TOP=$(INST_DRV)\Smoke\doesntexist [minitest] [minitest] -DDEBUGGING [minitest] -Dusemymalloc [minitest] -DDEBUGGING -Dusemymalloc [minitest] -Duselargefiles [minitest] -DDEBUGGING -Duselargefiles [minitest] -Duselargefiles -Dusemymalloc [minitest] -DDEBUGGING -Duselargefiles -Dusemymalloc [minitest] -Accflags='-DPERL_COPY_ON_WRITE' [minitest] -DDEBUGGING -Accflags='-DPERL_COPY_ON_WRITE' [minitest] -Accflags='-DPERL_COPY_ON_WRITE' -Dusemymalloc [minitest] -DDEBUGGING -Accflags='-DPERL_COPY_ON_WRITE' -Dusemymalloc [minitest] -Accflags='-DPERL_COPY_ON_WRITE' -Duselargefiles [minitest] -DDEBUGGING -Accflags='-DPERL_COPY_ON_WRITE' -Duselargefiles [minitest] -Accflags='-DPERL_COPY_ON_WRITE' -Duselargefiles -Dusemymalloc [minitest] -DDEBUGGING -Accflags='-DPERL_COPY_ON_WRITE' -Duselargefiles -Dusemymalloc comp/utf..dubious DIED. FAILED tests 1-15 io/crlf...dubious DIED. FAILED tests 7-16 io/layers.FAILED tests 5, 7-8, 10, 12, 14, 17-21, 28-32 io/print..dubious io/read...dubious op/crypt..dubious DIED. FAILED tests 1-4 op/magic..dubious DIED. FAILED tests 43-58 op/utftaint...dubious 12 tests skipped. [minitest] -Duseithreads -Uuseimpsys [minitest] -DDEBUGGING -Duseithreads -Uuseimpsys [minitest] -Duseithreads -Uuseimpsys -Dusemymalloc [minitest] -DDEBUGGING -Duseithreads -Uuseimpsys -Dusemymalloc [minitest] -Duseithreads -Uuseimpsys -Duselargefiles [minitest] -DDEBUGGING -Duseithreads -Uuseimpsys -Duselargefiles [minitest] -Duseithreads -Uuseimpsys -Duselargefiles -Dusemymalloc [minitest] -DDEBUGGING -Duseithreads -Uuseimpsys -Duselargefiles -Dusemymalloc [minitest] -Accflags='-DPERL_COPY_ON_WRITE' -Duseithreads -Uuseimpsys [minitest] -DDEBUGGING -Accflags='-DPERL_COPY_ON_WRITE' -Duseithreads -Uuseimpsys [minitest] -Accflags='-DPERL_COPY_ON_WRITE' -Duseithreads -Uuseimpsys -Dusemymalloc [minitest] -DDEBUGGING -Accflags='-DPERL_COPY_ON_WRITE' -Duseithreads -Uuseimpsys -Dusemymalloc [minitest] -Accflags='-DPERL_COPY_ON_WRITE' -Duseithreads -Uuseimpsys -Duselargefiles [minitest] -DDEBUGGING -Accflags='-DPERL_COPY_ON_WRITE' -Duseithreads -Uuseimpsys -Duselargefiles [minitest] -Accflags='-DPERL_COPY_ON_WRITE' -Duseithreads -Uuseimpsys -Duselargefiles -Dusemymalloc [minitest] -DDEBUGGING -Accflags='-DPERL_COPY_ON_WRITE' -Duseithreads -Uuseimpsys -Duselargefiles -Dusemymalloc comp/utf..dubious DIED. FAILED tests 1-15 io/crlf...dubious DIED. FAILED tests 7-16 io/layers.FAILED tests 5, 7-8, 10, 12, 14, 17-21, 28-32 io/print..dubious io/read...dubious op/crypt..dubious DIED. FAILED tests 1-4 op/magic..dubious DIED. FAILED tests 43-58 op/threadsdubious DIED. FAILED tests 1-3 op/utftaint...dubious 11 tests skipped. -- Report by Test::Smoke v1.19_70 build 861 running on perl 5.8.7 (Reporter v0.021 / Smoker v0.024) Radan Computational Ltd. The information contained in this message and any files transmitted with it are confidential and intended for the addressee(s) only. If you have
Re: [perl #34524] sv_rvweaken (Scalar::Util::weaken) is inneffective on tied variables
On Mon, Mar 21, 2005 at 08:42:11PM -, philippe. cote @ usherbrooke. ca
wrote:
sv_rvweaken doesn't handle tied variables
Proof :
+-+
Sample code
+-+
#!/usr/bin/perl
use strict;
use warnings;
use Util::Monitor;
use Scalar::Util qw(weaken);
use Devel::Peek;
{
my (@a);
$a[0] = [EMAIL PROTECTED];
#tie @a, 'TestArray';
Dump($a[0],1);
weaken($a[0]);
Dump($a[0],1);
print Leaving scope\n;
}
print Scope left\n;
package TestArray;
use Tie::Array;
use base 'Tie::StdArray';
sub DESTROY { print Monitor::TestArray::DESTROY : $_[0]\n; }
I'm not really sure what you expect the effect of weakening a tied array
element should be. I suspect that in the general case doing this makes no
sense.
1;
+-+
Output without tie @a, 'TestArray'
(Just to show you that weaken works without the tie)
+-+
SV = RV(0x81829c0) at 0x814127c
REFCNT = 1
FLAGS = (ROK)
RV = 0x814e740
SV = PVAV(0x81426cc) at 0x814e740
REFCNT = 2
FLAGS = (PADBUSY,PADMY)
IV = 0
NV = 0
ARRAY = 0x814
FILL = 0
MAX = 3
ARYLEN = 0x0
FLAGS = (REAL)
SV = RV(0x81829c0) at 0x814127c
REFCNT = 1
FLAGS = (ROK,WEAKREF,IsUV)
RV = 0x814e740
SV = PVAV(0x81426cc) at 0x814e740
REFCNT = 1
FLAGS = (PADBUSY,PADMY,RMG)
IV = 0
NV = 0
MAGIC = 0x8266f08
MG_VIRTUAL = PL_vtbl_backref
MG_TYPE = PERL_MAGIC_backref()
MG_FLAGS = 0x02
REFCOUNTED
MG_OBJ = 0x81411c8
SV = PVAV(0x8263704) at 0x81411c8
REFCNT = 2
FLAGS = ()
IV = 0
NV = 0
ARRAY = 0x82677e8
FILL = 0
MAX = 3
ARYLEN = 0x0
FLAGS = (REAL)
ARRAY = 0x814
FILL = 0
MAX = 3
ARYLEN = 0x0
FLAGS = (REAL)
Leaving scope
Scope left
+-+
Output with tie @a, 'TestArray';
+-+
SV = PVLV(0x817c568) at 0x81413f0
REFCNT = 1
FLAGS = (TEMP,GMG,SMG,RMG)
IV = 0
NV = 0
PV = 0
MAGIC = 0x81505b8
MG_VIRTUAL = PL_vtbl_packelem
MG_TYPE = PERL_MAGIC_tiedelem(p)
MG_FLAGS = 0x02
REFCOUNTED
MG_OBJ = 0x814139c
SV = RV(0x81829ac) at 0x814139c
REFCNT = 2
FLAGS = (ROK)
RV = 0x8141354
TYPE = t
TARGOFF = 0
TARGLEN = 0
TARG = 0x81413f0
SV = PVLV(0x817c568) at 0x81413f0
REFCNT = 1
FLAGS = (TEMP,GMG,SMG,RMG)
IV = 0
NV = 0
PV = 0
MAGIC = 0x81505b8
MG_VIRTUAL = PL_vtbl_packelem
MG_TYPE = PERL_MAGIC_tiedelem(p)
MG_FLAGS = 0x02
REFCOUNTED
MG_OBJ = 0x814139c
SV = RV(0x81829ac) at 0x814139c
REFCNT = 2
FLAGS = (ROK)
RV = 0x8141354
TYPE = t
TARGOFF = 0
TARGLEN = 0
TARG = 0x81413f0
Leaving scope
Scope left
Monitor::TestArray::DESTROY : TestArray=ARRAY(0x8141354)
+-+
Explanations
+-+
We see that weaken is not applied on a tied variable. I've been
searching in source code and calls goes like this :
Scalar::Util::weaken - sv_rvweaken - Perl_sv_rvweaken
+-+
Scalar::Util::weaken source code
+-+
void
weaken(sv)
SV *sv
PROTOTYPE: $
CODE:
#ifdef SvWEAKREF
sv_rvweaken(sv);
#else
croak(weak references are not implemented in this release of perl);
#endif
We see clearly that it only calls sv_rvweaken from the perl source code.
So this method doesn't contain bugs.
We also finds that sv_rvweaken is associated to Perl_sv_rvweaken as
defined by embed.h
Let's look at this code
+-+
Perl_sv_rvweaken source code from sv.c
+-+
/*
=for apidoc sv_rvweaken
Weaken a reference: set the CSvWEAKREF flag on this RV; give the
referred-to SV CPERL_MAGIC_backref magic if it hasn't already; and
push a back-reference to this RV onto the array of backreferences
associated with that magic.
=cut
*/
SV *
Perl_sv_rvweaken(pTHX_ SV *sv)
{
SV *tsv;
if (!SvOK(sv)) /* let undefs pass */
return sv;
if (!SvROK(sv))
Perl_croak(aTHX_ Can't weaken a nonreference);
else if (SvWEAKREF(sv)) {
Re: [PATCH] perlfunc.pod
Rafael Garcia-Suarez wrote: On 7/19/05, Michael G Schwern [EMAIL PROTECTED] wrote: It would probably be better to evaluate the existing POD - HTML converters and wrap POD::Html around them, or just leave POD::Html alone and convert installhtml to use the better module, than to write Yet Another POD - HTML Module. I can think about a couple of points : * state of the art of html documentation has greatly improved since the perl 5.000 days. Pod::Html generates obsolete html (old syntax, no CSS support, etc.) * Pod::Html is barely usable, making a good pod-html translator now would mean designing a more complete and probably incompatible interface. * People have hacked around the limitations of Pod::Html that were the most annoying, and probably post-process its output. It's html, they want eye-candy and stuff that looks like search.cpan.org. OK, that's a weird backwards-compatibility argument. In short, my opinion would be to leave Pod::Html alone, fixing the most obvious bugs, and slowly deprecating it in favor of the next big thing. Pod::Html4 anyone? :) PS. /me discovers that Pod::Xhtml is a module brought to you by the BBC :) heehee :D
Re: ithreads: CLONE is not invoked on returned values from join
On Sun, Mar 27, 2005 at 06:31:59PM -0500, Stas Bekman wrote:
So we have CLONE that allows us to properly clone objects when a new
thread is started. The current invocation approach really sucks, since
trying to figure out what things need to be cloned is a pain-in-a-back.
But it's doable [1]. Previously we have started discussing of passing the
objects to be cloned as an argument(s) to CLONE, but it didn't get anywhere.
Now I've discovered a new problem. If intentially or accidently you have
to return an object from a thread callback:
threads-new(\read_test)-join;
sub read_test {
my $obj = Foo-new;
#1;
}
You're screwed since now you have a dangling temp object which you didn't
really want to in first place (but can be figured out by reading the
manpage), but the real problem is that even if you did want it:
my $ret_obj = threads-new(\read_test)-join;
this object is not properly cloned. If you had a C pointer stashed in
SvIVX and you have a DESTROY method that frees that pointer, it's a sure
segfault, since both the parent thread and the child thread will point to
the same C struct.
So I'd love to see at least perl 5.10 dealing with this properly (of
course 5.8.x would be lovely too). The wishlist:
1) have CLONE get the SVs to clone as arguments to it, which will
tremendously simplify the life of developers.
2) fix the explained above bug and run the objects through CLONE when they
are returned from join().
How does this interact with the new CLONE_SKIP thinggy?
--
Spock (or Data) is fired from his high-ranking position for not being able
to understand the most basic nuances of about one in three sentences that
anyone says to him.
-- Things That Never Happen in Star Trek #19
Re: [perl #36588] Problem with semctl() on Perl 5.8.6, 64-bit build, HP-UX 11i
Hi, I'd hate to be wrong, but I think I can see the error in doio.c: The code performs INT2PTR on a, enlarging it to a 64-bit char*. Since we're on a big-Endian machine, it means it is padded with zeroes on the left side. Then it moves a into union semun.buf. However, SETVAL works in the val member of union semun. Since this val is 32-bit and since we are on big-Endian, this val is always going to be zero. Quod erad demonstrandum :-) I wouldn't go so far as to suggest you a fix, but I think that you'll need a special branch for SETVAL (the only semctl() case that actually works on union semun.val. Please comment. Regards, Petr Novotny [EMAIL PROTECTED] - PŮVODNÍ ZPRÁVA - Od: Nicholas Clark via RT [EMAIL PROTECTED] Komu: [EMAIL PROTECTED] Předmět: Re: [perl #36588] Problem with semctl() on Perl 5.8.6, Datum: 19.7.2005 - 12:09:18 On Mon, Jul 18, 2005 at 07:04:03AM -0700, novotny. petr @ volny. cz wrote: Output from 5.6.1 (32-bit): Created new semaphore 1 Output from 5.8.6 (64-bit): Created new semaphore 0 (Of course, I called ipcrm between the two tests to delete the semaphore. I'm saying this just in case :-)) That's useful, as it's the sort of thing that people forget. (Well, I would) Are you able to build 5.8.5 32-bit on your machine? This would make it clear whether it's a 5.6 - 5.8 issue, or a 32 bit / 64 bit issue. My hunch is that it's something to do with big endian 64 bit builds (and pack templates or maybe structure alignment) but it would be good to test this. Nicholas Clark
Re: [PATCH] perlfunc.pod
Scott R Godin [EMAIL PROTECTED] writes: Firefox is merely being kind to all the silly web-authors out there who think it's a good idea to send XHTML as text/html instead of application/xhtml+xml because the latter breaks in nearly every browser due to the fact that they aren't prepared to handle XHTML as it was meant to be delivered. EVERYONE jumped on this way too early. My opinion is at http://www.eyrie.org/~eagle/notes/xhtml.html for anyone who cares. In general, I mostly agree with you, but the software I write for my own purposes all generates XHTML and will continue to do so. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/
Re: [perl #34524] sv_rvweaken (Scalar::Util::weaken) is inneffective on tied variables
On Wed, Jul 20, 2005 at 01:27:51AM +0100, Dave Mitchell wrote:
On Mon, Mar 21, 2005 at 08:42:11PM -, philippe. cote @ usherbrooke. ca
wrote:
sv_rvweaken doesn't handle tied variables
Proof :
+-+
Sample code
+-+
#!/usr/bin/perl
use strict;
use warnings;
use Util::Monitor;
use Scalar::Util qw(weaken);
use Devel::Peek;
{
my (@a);
$a[0] = [EMAIL PROTECTED];
#tie @a, 'TestArray';
Dump($a[0],1);
weaken($a[0]);
Dump($a[0],1);
print Leaving scope\n;
}
print Scope left\n;
package TestArray;
use Tie::Array;
use base 'Tie::StdArray';
sub DESTROY { print Monitor::TestArray::DESTROY : $_[0]\n; }
I'm not really sure what you expect the effect of weakening a tied array
element should be. I suspect that in the general case doing this makes no
sense.
To put it another way, the tied element $a[0] acts like a black box around
whatever the tying object does; you can put things in the box or take them
out, but you can't modify the contents of the box the way weaken does.
Unless someone implements support for a WEAKEN method...
