gmane.comp.lang.perl.perl5.porters

PATCH [perl #58430] Unicode::UCD::casefold() does not work as documented, nor prob as intended

karl williamson — 2008-12-04T02:51:54

Attached is a patch for this problem. The root of the problem is that casefold() did not realize that there could be multiple lines in the input file for a given character, and so retained only information from whatever happened to be the last line. I solved this by adding fields to the returned hash to return information from the other lines. The existing fields return the exact same information as before, so no existing code should be broken. casefold() was also expecting syntax in the Unicode database that was changed in Version 3.2 (We're at 5.1 now). I changed it so it accepts either syntax, so that it can correctly be run on old and new versions of Unicode. I also took the liberty of significantly upgrading the documentation for this module, correcting wrong statements, broken links, using better pod constructs, etc, and added detail about the interface so that hopefully a reader won't have to experiment or read the code, as I had to do, to find out what really gets returned. --- U

Re: UNIVERSAL::VERSION and version.pm

John Peacock — 2008-12-04T01:50:25

No, I'm saying that if I do as you ask, there will be an even bigger action-at-a-distance bug, where the behavior of version comparisons will depend on whether your code gets loaded before or after some other module loads version.pm. That's a worse problem. I've given you plenty of rope to hang yourself with already, I don't intend to make it worse... John

[patch< at >34995] vms.c - Memory freed from wrong pool

John E. Malmberg — 2008-12-04T01:38:04

In trim_unixpath, the wrong free routine was being used resulting in data corruption. -John wb8tyw< at >qsl.net Personal Opinion Only --- /rsync_root/perl/vms/vms.cSun Nov 23 22:54:17 2008 +++ vms/vms.cWed Dec 3 19:05:18 2008 < at >< at > -9345,10 +9345,10 < at >< at > char def[NAM$C_MAXRSS+1], *st; if (getcwd(def, sizeof def,0) == NULL) { - Safefree(unixified); - Safefree(unixwild); - Safefree(lcres); - Safefree(tpl); + PerlMem_free(unixified); + PerlMem_free(unixwild); + PerlMem_free(lcres); + PerlMem_free(tpl); return 0; } if (!decc_efs_case_preserve) {

Smoke [5.11.0] 34986 FAIL(F) netbsd 4.0 (i386/1 cpu)

Steven Schubiger — 2008-12-04T01:30:02

Automated smoke report for 5.11.0 patch 34986 p5netbsd: AMD Duron (686-class) (i386/1 cpu) on netbsd - 4.0 using cc version 4.1.2 20061021 prerelease (NetBSD nb3 20061125) smoketime 17 hours 20 minutes (average 2 hours 10 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 34986 Configuration (common) none ----------- --------------------------------------------------------- O O O O O O O O -Duse64bitint O O O O -Duseithreads O O F O -Duseithreads -Duse64bitint | | | +----- PERLIO = perlio -DDEBUGGING | | +------- PERLIO = stdio -DDEBUGGING | +--------- PERLIO = perlio +----------- PERLIO = stdio Locally applied patches: DEVEL SMOKE34986 Failures: (common-args) none [stdio] -DDEBUGGING -Duseithreads -Du

Re: Perl_peep (was Re: Perl_linklist)

Ben Morrow — 2008-12-03T23:59:55

Quoth matt-p5p< at >trout.me.uk (Matt S Trout): Please. Or just add CHECKOP in all the places it should be but isn't. Ben

[PATCH] Re: Adding autodie to Perl 5.10.1?

Paul Fenwick — 2008-12-03T23:32:50

Okay, I lied about having a patch ready on Sunday. The first cut is ready now. The attached mega-patch: * Applies autodie 1.996 against core. * Includes all tests that depend solely upon core modules. * Includes documentation changes to perlmodlib.pod * Includes MANIFEST changes. The patch doesn't include IPC::System::Simple (although autodie will use it if it finds it), so you can't `use autodie qw(system)' out of the box. If you want IPC::System::Simple in core, let me know, and I'll prepare a patch for it as well. If everything smokes fine and we merge into maint, then I'd love to bump the version number of autodie to 2.0 before Perl 5.10.1 goes to release. This would be purely so users don't need to remember an awkward version number for the first core release of autodie. Questions, feedback, ideas, counter-patches, and suggestions are all very welcome. All the very best, Paul

Re: [perl #31838] utf8 threading crash

John Gardiner Myers — 2008-12-03T23:27:29

Problem does not reproduce with 5.10.0. It was most likely fixed with the regex engine rewrite.

Re: [perl #31838] utf8 threading crash

John Gardiner Myers — 2008-12-03T23:24:49

Problem is not reproducing on blead.

Re: Adding autodie to Perl 5.10.1?

Paul Fenwick — 2008-12-03T22:40:11

G'day Dave / p5p, Dave Mitchell wrote: Excellent! Autodie is pure perl, and doesn't break either (with lots of test cases to make sure). Yikes! Since I really, really would love autodie in 5.10.1, I guess I know what I'm doing this weekend. ;) You can expect to see a new patch by Sunday. All the best, Paul

Re: Perl_peep (was Re: Perl_linklist)

Rafael Garcia-Suarez — 2008-12-03T21:57:16

2008/12/3 Matt S Trout trout.me.uk>: That's true. An optree constructed by hand is made "runnable" by linklist. Actually it's a good way to describe what linklist does. That would be a good argument to make linklist public.

Re: UNIVERSAL::VERSION and version.pm

Matt S Trout — 2008-12-03T21:56:27

Of course. Please also solve the Halting Problem :) Which is why I think it would be nice to be able to have part of the features of your version comparison library be optional :) In large codebases, I might want the version object information, but follow "if it ain't broke don't fix it" in terms of UNIVERSAL:: things. Projects where you can't just test the damn thing and see if it breaks anything do, sadly, exist :) What you're basically saying is "if you want my version library, you must also let me make an action-at-a-distance change to your interpreter". I am aware that action at a distance -can- be good, but unless I know I need it I'd still prefer to avoid it. Basically, there's more than one way to do it - all I'm asking is that your module allows mine as well, with yours by default, rather than enforcing yours.

Re: Perl_peep (was Re: Perl_linklist)

Matt S Trout — 2008-12-03T21:48:29

I'd like to be able to do much of what the compiler is able to currently. I'm also aware that's a lot of API to maintain. But at the very least I think we should consider current CPAN usages to be a baseline - "some sort of op creation callback" plus "a way to construct your own optree (fragments) and turn them into something runnable" plus "a way to run an optree fragment" - though I wouldn't horribly mind building a proper CV and executing it normally, I worry about the performance for that when trying to do clever things like building macros (also when writing keywords that take an expr ala map/grep, rather than just ones that take a sub).

Re: Perl_linklist (was Re: modules on CPAN defining PERL_CORE)

Matt S Trout — 2008-12-03T21:42:27

linklist() is an interesting question. The basic problem BeginLift has is that it wants to take a half-built optree and finish compiling it, then run it. It sort of seems to me like a "finish up this optree" function might be really useful. Interestingly, B::Generate provides a $op->linklist in perl, complete with comment "# This is where we implement op.c in Perl. Sssh." :) which I think proves that the function is worthwhile. I suspect the remaining XS in there is basic bookkeeping that can happily use the current public API.

Re: Perl_peep (was Re: Perl_linklist)

Matt S Trout — 2008-12-03T21:34:40

I have no idea but PL_check hackery is the basis of all my parser hacks. It's currently the only place we can get a hook into the compilation process usefully often. It's also incredible useful for doing scoped op mangling - autobox uses it for this and I have a number of other plans involving that. I would argue that PL_check mangling is not something we -should- be doing, and I don't have a problem if it breaks -provided- an alternative API is added that lets people get at op construction. Said new API could even hook -all- ops to get round the PADSV problem (which I've been shot in the face by once already :)

Re: on expectations of privacy

Matt S Trout — 2008-12-03T21:26:53

Method::Signatures is schwern's playground for exploring syntax ideas, so arguably it's allowed to be "BROKEN" so long as it proves the concept :) Devel::Declare and Method::Signatures::Simple (which is back to rgs' original proposal for a method keyword so far as I can tell) both build on win32 fine. Data::Alias is generally considered "useful but broken"; I believe as of 5.8.9 it -does- work on win32 though - however I don't know why :)

RE: [perl #59662] [RESOLVED] Cwd::realpath fails on unsearchable directory (AIX)

2008-12-03T04:55:01

Steve, I think you're probably right that this is fixed in at least some situations in later releases. I'm following up because there is a bug in the latest Cwd.pm (version 3.29). Line 546 calls File::Spec->rel2abs(), but File::Spec has not yet been loaded. The fix is similar to line 526: add: require File::Spec; right before calling File::Spec->rel2abs() on line 546. I was able to see this bug in action by copying *only* the Cwd.pm from the latest module release for Cwd (from PathTools-3.29.tar.gz) to the current directory and then adding use lib "." to the perl part of my test script. This caused the following error: Can't locate object method "rel2abs" via package "File::Spec" at Cwd.pm line 546. #!/bin/ksh mkdir testdir chmod 444 testdir echo "from perl:" perl -we ' use strict; use lib "."; use Cwd (); print "<", Cwd::realpath("testdir"), ">\n"; ' echo "from a.out:" ./a.out rmdir testdir (The reason I copied only the Cwd.pm file from the PathTools package is that the late

Re: Change 34979: Add two more flags, PERLDBf_SAVESRC_NOSUBS and PERLDBf_SAVESRC_INVALID,

Nicholas Clark — 2008-12-03T19:13:06

I don't know how trivial it is, but the right place to ask for an opinion on that is perl5-porters. Nicholas Clark

Re: [perl #31838] utf8 threading crash

John Gardiner Myers — 2008-12-03T18:58:37

Reproduces on Perl 5.8.8 on a 2-processor vmware i686 box.

5.10.0 "Configure" improvement for 'userelocatableinc' on Solaris 10

Luc St-Louis — 2008-12-03T01:07:11

The 'userelocatableinc' option works incorrectly on Solaris 10 (and earlier, presumably). The problem is that the path to the executable cannot be obtained like on Linux ('/proc/self/exe') or on BSD ('/proc/curproc/file'). But, as suggested by 'almut' on perlmonks (http://www.perlmonks.org/?node_id=686876). it can be obtained with '/proc/self/path/a.out'. So the solution (tested and working) is to have in Configure (currently, around line 15563) something like the following "if ... fi" snippet added, for Solaris 10: procselfexe='' val="$undef" case "$d_readlink" in "$define") ... if $issymlink /proc/self/path/a.out ; then $ls -l /proc/self/path/a.out > reflect if $contains /`basename $ls` reflect >/dev/null 2>&1; then echo "You have Solaris-like /proc/self/path/a.out." procselfexe='"/proc/self/path/a.out"' val="$define" fi fi ... I think this also makes $^X return a correc

[PATCH - 5.10.x] Revert const'ing in cygwin.c (repost)

Jerry D. Hedden — 2008-12-03T16:47:51

Blead Change 32681 (make miniperl -Wwrite-strings clean) resulted in some build warnings being generated by cygwin.c. In response, I submitted blead Change 32689 (const'ing in cygwin.c) to correct these. Change 33119 to 5.10.x integrates blead Change 32689. However, since blead Change 32681 cannot be integrated into 5.10.x, cygwin.c is now producing the following build warnings: cygwin.c: In function `do_spawn': cygwin.c:125: warning: assignment from incompatible pointer type cygwin.c:127: warning: assignment from incompatible pointer type To correct this, the portion of 5.10.x Change 33119 related to blead Change 32689 needs to be reverted. The attached patch does this. (This is a repost from my original submission back in October.) --- perl/cygwin/cygwin.c +++ perl/cygwin/cygwin.c < at >< at > -83,8 +83,7 < at >< at > do_spawn (char *cmd) { dTHX; - char const **a; - char *s,*metachars = "$&*(){}[]'\";\\?>|<~`\n"; + char **a,*s,*metachars = "$&*(){}[]'\";\\?>|<~`\n"; const char *comm

Re: Adding autodie to Perl 5.10.1?

Dave Mitchell — 2008-12-03T16:40:47

As long as it doesn't break binary or backwards compatibility, then yes. Yes. That change (and any previous ones) will then be integrated into the 5.10.x branch. I want 5.10.x released by the end of the year, and would want any recent changed to be suitably smoked and bedded in before integrating into maint. So there's a short window for it getting into 5.10.1. (Of course, there's always 5.10.2).