Re: Smoke [5.8.7] 25589 FAIL(m) MSWin32 WinXP/.Net SP2 (x86/2 cpu)
On Fri, Sep 23, 2005 at 09:14:09PM +0100, Nicholas Clark wrote:
And between last time and this one I didn't think that there were any
dangerous changes. Given that, and the lack of any helpful log on this
smoke report, I'm stuck as to what I messed up that needs fixing.
I think I failed to spot a change that I needed to integrate. Hopefully
25592 fixes it. I think that Steve Hay's 5.8.7 smoker only works weekdays,
so if someone else is able to test build maint on Windows I'd be most
grateful.
Nicholas Clark
Change 25592 by [EMAIL PROTECTED] on 2005/09/24 09:56:14
Integrate:
[ 25110]
no code before declarations!
Affected files ...
... //depot/maint-5.8/perl/doio.c#52 integrate
Differences ...
//depot/maint-5.8/perl/doio.c#52 (text)
@@ -1461,9 +1461,10 @@
Perl_croak(aTHX_ exec? I'm not *that* kind of operating system);
#else
if (sp mark) {
+ char **a;
+ const char *tmps = Nullch;
Newx(PL_Argv, sp - mark + 1, char*);
- char **a = PL_Argv;
- const char *tmps = Nullch;
+ a = PL_Argv;
while (++mark = sp) {
if (*mark)
[EMAIL PROTECTED] [perl]$
kill mv-if-diff?
The distribution contains a shell script mv-if-diff, which does what it says. The Makefile uses it to avoid touching the timestamps on automatically generated files, if they've not actually changed. For example, lib/Config.pm I notice that on my local checkout of maint, when I do a clean rebuild, lib/unicore/mktables is being run 7 times. I also observe that sometimes when I edit files and rebuild, later files needlessly get rebuilt, probably because make thinks something is out of date, something that never gets updated, probably because it's not being touched, due to mv-if-diff, and there are non-file targets in the dependency tree. Parallel makes are also broken. I wonder if all this is related. Should we just get rid of mv-if-diff, and let make be the sole arbiter of what needs updating? And trust that if make wants to rebuild something, it should. I think that doing this would make our rebuilds cleaner, and make it easier to work out the correct set of dependencies such that we can make parallel makes work. Nicholas Clark
Re: kill mv-if-diff?
On Sat, Sep 24, 2005 at 06:44:57PM +0200, Rafael Garcia-Suarez wrote: On 9/24/05, Nicholas Clark [EMAIL PROTECTED] wrote: I also observe that sometimes when I edit files and rebuild, later files needlessly get rebuilt, probably because make thinks something is out of date, something that never gets updated, probably because it's not being I don't get your reasoning here... Sorry, yes, I failed to explain properly. IIRC the following happens: I edit (say) sv.c I run make make reasons that a lot of things are out of date. Specifically, 1: all the Unicode tables are out of date with respect to lib/Config.pm 2: because that in turn is out of date w.r.t. miniperl 3: because that is out of date w.r.t. sv.o 4: because that is out of date w.r.t. sv.c So the make reruns the build steps for 4,3,2,1 Only mv-if-diff kicks in, and lib/Config.pm isn't changed (make never checks if a step actually changes the timestamp on a file) So if I re-run make, make sees that lib/Config.pm is *still* out of date w.r.t. miniperl, so (correctly) figures that steps 2 and 1 need re-running. I stop the insanity with touch lib/Config.pm; make and make re-runs the Unicode tables generation one last time, and then all is happy. Hence why I think that mv-if-diff is counterproductive. Nicholas Clark
Re: Smoke [5.8.7] 25589 FAIL(m) MSWin32 WinXP/.Net SP2 (x86/2 cpu)
On Fri, Sep 23, 2005 at 06:32:00PM +0100, Steve Hay wrote: 25589 Configuration (common) -DCCTYPE=BORLAND -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 -Duseithreads m m -Duseithreads -Duselargefiles | +- -DDEBUGGING +--- no debugging Locally applied patches: MAINT24637 -- Report by Test::Smoke v1.19_72 build 895 running on perl v5.9.3 (Reporter v0.026 / Smoker v0.026) And between last time and this one I didn't think that there were any dangerous changes. Given that, and the lack of any helpful log on this smoke report, I'm stuck as to what I messed up that needs fixing. Nicholas Clark
Re: Smoke [5.8.7] 25531 FAIL(F) openbsd 3.7 (i386/1 cpu)
On Wed, Sep 21, 2005 at 07:21:53PM -0500, Steve Peters wrote: On Wed, Sep 21, 2005 at 06:52:00PM -0500, [EMAIL PROTECTED] wrote: 25531 Configuration (common) none Both sets of failures should be resolved by patches integrated into maintperl today. 22:30 * p5changes Change 25558(maint-5.8/nicholas): Integrate: http://public.activestate.com/cgi-bin/perlbrowse?patch=25558 22:34 @Steve_p Eeek! My maint smoke is 28 patches behind! Still some more patches to chug through. Nicholas Clark
Re: pod/pod2usage2.t
On Thu, Sep 22, 2005 at 11:43:44AM +0200, H.Merijn Brand wrote: On Thu, 22 Sep 2005 10:27:30 +0200, H.Merijn Brand [EMAIL PROTECTED] wrote: make test_harness succeeds, make test fails. Completely rewritten test attached 1. Move to Test::More and add comments to tests 2. Split the combined ok ()'s to one is (), and one ok () each 3. The printing is all done with leading '#' to not confuse TEST 4. That also makes the returned expected output read better IMHO Feel free to change again Steve complained about the attachment failing, but in my Sent box, it was still there. Retry ... The perl.org list server's resident grue eats all files /\.t$/, at least for the default MIME type that most mailers garnish them with (troff, IIRC) Nicholas Clark
Re: Smoke [5.8.7] 25572 PASS MSWin32 WinXP/.Net SP2 (x86/2 cpu)
On Thu, Sep 22, 2005 at 10:37:00PM +0100, Steve Hay wrote: 25572 Configuration (common) -DINST_TOP=$(INST_DRV)\Smoke\doesntexist --- - O O O O -Dusemymalloc O O -Duselargefiles O O -Duselargefiles -Dusemymalloc O O -Duseithreads -Uuseimpsys O O -Duseithreads -Uuseimpsys -Dusemymalloc O O -Duseithreads -Uuseimpsys -Duselargefiles O O -Duseithreads -Uuseimpsys -Duselargefiles -Dusemymalloc O O -Duseithreads O O -Duseithreads -Duselargefiles | +- -DDEBUGGING +--- no debugging Gosh. What did I do wrong? I even hand merged the win32 config files, and still it seems that I didn't mess up this time. Must try harder. What cause the threads problem test to pass tonight, when it failed last night? Or will we never know? Nicholas Clark
Re: Upgrade MakeMaker in maint
On Mon, Sep 19, 2005 at 05:56:50PM -0700, Michael G Schwern wrote: Maint is still using MakeMaker 6.17 which is now TWO YEARS OLD! Last I checked there was some VMS failure or another possibly tied to File::Find but I don't have details. I really rather 5.8.8 not go out with 6.17 again, 6.30 is good and stable. Can we just take the plunge, put 6.30 into maintperl and work out the glitches? The last thing that I remember was that there was some fun with make distclean on VMS in blead and SDBM_File. Or at least something with SDBM_File I was going to look last week to see if you're most recent version had cured it, but it was the day after testdrive went down for 2 weeks. Is the current version happy on VMS with SDBM_File? Nicholas Clark
Re: [EMAIL PROTECTED] on cygwin looks pretty good
On Mon, Sep 19, 2005 at 12:45:33PM -0700, Yitzchak Scott-Thoennes wrote: I see Nicholas Clark has been hard at work integrating patches into perl5.8.x. Trying a build on cygwin at patch 25494 passes all tests except for op/layers.t, which should be fixed once 24764 is integrated. Ooh. Thanks for testing this. I see from Steve Hay's smoke that I broke Win32. But I've not yet worked out why/how to fix it. It would be nice if the version number could be bumped to 5.8.8 soon; I inadvertently installed over my 5.8.7 :) Until such time as someone figures out how to make maint type releases highly visible in the version number (or at least the -v output) I intend to continue refraining from bumping the version number until the first release candidate. It's something I've had no inspiration for. It's the first task mentioned in the TODO for the category Tasks that need a little C knowledge http://public.activestate.com/cgi-bin/perlbrowse?file=pod%2Fperltodo.podrev= (been moderately hard at work reordering the TODO to put the easier things earlier) Nicholas Clark
Re: Perl5 Bug Summary
On Mon, Sep 19, 2005 at 01:16:34PM -0700, Robert Spier wrote: Nick takes the lead! Anyone would think that I programmed in Perl. (instead of on perl) Nicholas Clark
oddity in op.c
Merijn notices this line in 5.8.x in S_new_logop
if ((type == OP_AND) == (SvTRUE(((SVOP*)first)-op_sv))) {
It's wonky. It seems to be wrong. But it's been that way since 5.8.0 started.
The corresponding point in blead is
if ((type == OP_AND SvTRUE(((SVOP*)first)-op_sv)) ||
(type == OP_OR !SvTRUE(((SVOP*)first)-op_sv)) ||
(type == OP_DOR !SvOK(((SVOP*)first)-op_sv))) {
This was patched by Marcus Holland-Moritz, changing that == to in the
process:
http://public.activestate.com/cgi-bin/perlbrowse?patch=22625
Presumably '==' is wrong. But if this is a bug, how can it be detected
with a perl level regression test?
Nicholas Clark
Re: Lots of warnings building [EMAIL PROTECTED]
On Sat, Sep 17, 2005 at 02:28:30PM +0100, Paul Marquess wrote: This is with gcc 3.4.3 They're mostly the same errors as blead had around patch 24079 (etc) when Andy started adding const to blead. I'm hoping that as I work through them most of the warnings will go away because I bring in the patches that fix the warnings. Then I'll only be left with the warnings that are due to me keeping all the non-static functions identical to 5.8.7 (ie no const there) I might have broken VMS or Windows, but as testdrive is down I can't check on VMS. Sorry. Nicholas Clark
Re: Lots of warnings building [EMAIL PROTECTED]
On Sat, Sep 17, 2005 at 10:02:19AM -0500, Andy Lester wrote: They're mostly the same errors as blead had around patch 24079 (etc) when Andy started adding const to blead. I'm hoping that as I work through them most of the warnings will go away because I bring in the patches that fix the warnings. Is there anything I can do to help this effort? Not yet - I've not got all your changes merged in. I know that you fixed warnings in later changes. Once they're all merged in, then it would be useful to work out what remains to be done to get maint warning free once more. One thing I did notice on blead was that if I Configure with -Accflags='-ansi -pedantic -DPERL_GCC_PEDANTIC' then I'm getting warnings about function pointer to data pointer conversions in (at least) toke.c and sv.c, and a lot from intrpvar.h, perlvars.h and thrdvar.h ISO C forbids conversion of function pointer to object pointer type Oh, and this: op.c: In function `Perl_newXS': op.c:4628: warning: assignment discards qualifiers from pointer target type I don't think that glibc has clean enough headers to allow perl to compile with -ansi -pedantic on Linux - I was doing it on FreeBSD, which does. So now I want valgrind dtrace gdb that works with threads *and* clean system headers all on the same platform. Is this too much to ask? (What are the system headers like on Solaris x86? Is anyone porting valgrind to it? This seems like the path of least resistance) Nicholas Clark
Parallel testing
The core regression test suite is getting ever more comprehensive. This is seen as good. Consequentially it's getting larger. Getting larger is making it take longer to run. This isn't so good. apt-get has this nice feature where it can download packages from several sites in parallel, to exploit the fact that the download bottleneck for a single site may be beyond where the routes diverge. Multi-CPU machines are becoming more common. I was wondering - would it be feasible to give the harness script the *option* of running sets of tests in parallel. I'm assuming that this would be useful for things like t/op/*.t and t/uni/*.t, and maybe lib/.../*.t I can see 3 initial questions 1: how does screen layout work when you're running more than one test? 2: how does the caller of test specify how many tests to run in parallel? 3: how do setup/teardown tests identify themselves? Is this feasible? If we can get parallel makes working reliably (now in perltodo: http://public.activestate.com/cgi-bin/perlbrowse?patch=25431 ) then I suspect that the time for make test will become the biggest bottleneck. Also, I've re-ordered perltodo to put the easiest tasks first: http://public.activestate.com/cgi-bin/perlbrowse?file=pod%2Fperltodo.podrev= I'm hoping that more people might read it (and find something interesting to challenge themselves with) now that it no longer starts with scary brain- melting things like re-writing the regexp engine and copy on write for ithreads. Nicholas Clark
Re: better assertion support
On Wed, Sep 07, 2005 at 04:15:58PM +0100, Salvador Fandiño wrote:
Hi,
Nicholas Clark wrote:
Now that the assertion code is (I believe) fully feature complete, I'm
wondering if it can be refactored into a minimal set of core hooks, and an
XS module in ext. Having more hooks increases what is possible for future
authors to achieve as independent modules released to CPAN.
There were two mayor reasons why assertions could not be
implemented outside the core:
1) assertion magic happens at compile time changing the way
assertion calls are compiled inside their callers.
Extending perl to allow customizing how subroutine calls are
compiled, well, that makes me thing about macros, but adding
support for macros to perl5 seems a bit crazy to me :-)
...though some kind of low level macros able to work with OPs
could be used, for instance:
sub sqr : macro {
return B::OPBIN-new(mul, $_[0], $_[0]-clone);
}
Yes, there's no fundamental reason not to add hooks this deep into the
compile time to allow this. If you found you needed this level of flexibility
for assertions, and the core were improved to provide it, who knows what
else CPAN authors (or at least Dr Evil) would be able to come up with.
2) subs and attributes:
currently, subs attributes are very poorly handled, there are
very few things one can do with them, specially because there is
no information about the GLOBs where the subs are going to be stored.
Attribute::Handlers tries to work around that, but it is far from
perfect, mostly because it runs at INIT or CHECK time, and so too
late for attributes that want to influence compile time!
I think this could be done better, maybe adding support for a new
MODIFY_CODEGLOB_ATTRIBUTES hook. Or maybe two, one called before
the sub is defined and another after
(MODIFY_PRECODEGLOB_ATTRIBUTES, MODIFY_POSTCODEGLOB_ATTRIBUTES),
but well, it's a complex matter and all the different possible
cases should be considered.
I don't know enough about how the compile phase works to be able to comment
on the right way to do this.
Nicholas Clark
Re: Storable 2.15 on OSX 10.4 with maintperl fails make test
On Fri, Sep 16, 2005 at 10:44:27AM -0700, Randal L. Schwartz wrote: Yeah, so that's the problem. I install a new Perl, it installs the non-XS version of Scalar::Util. Then I can't install Storable (or many other things) because they say weak isn't supported. Sure, installing Scalar::Util from the CPAN fixes it, but that's not listed as a prereq so it doesn't happen automatically. Thus, Storable's test needs to ignore the weak isn't supported error (right now, that's fatal to the test). This would be the bugreport for P5P. And the bug report for the distributor of the perl you installed would be why isn't it installing the XS version of a core module? ? Nicholas Clark
Re: Storable 2.15 on OSX 10.4 with maintperl fails make test
On Fri, Sep 16, 2005 at 02:28:20PM -0700, Randal L. Schwartz wrote: Nicholas == Nicholas Clark [EMAIL PROTECTED] writes: Nicholas And the bug report for the distributor of the perl you Nicholas installed would be why isn't it installing the XS version Nicholas of a core module? ? What do you mean distributor of the perl you installed? Joking, right? I've said maintperl a few times already. No, I'm not, in as much as I don't understand why the perl you installed only had a pure perl List::Utils I agree with the Storable failure being a bug. But I also want to understand the List::Utils part Did I miss the reason for this in an earlier message? Nicholas Clark
Re: [perl #37162] Perl -- Make test errors..
On Wed, Sep 14, 2005 at 09:11:37AM +0200, H.Merijn Brand wrote: On Tue, 13 Sep 2005 11:56:12 -0700, Sharma, Rahul (via RT) [EMAIL PROTECTED] wrote: # New Ticket Created by Sharma, Rahul # Please include the string: [perl #37162] # in the subject line of all future correspondence about this issue. # URL: https://rt.perl.org/rt3/Ticket/Display.html?id=37162 Hello, Can you please let m know if there is any known resolution for the below. I am using HP -UX supplied C compiler cc to compile perl. Make test gives t he below errors When I build the source, I get failures on Constant.t and Recurs.t lib/ExtUtils/t/Constant...Can't exec gmake: No such file or di rectory at ../lib/ExtUtils/t/Constant.t line 130. FAILED at test 3 Just to check if I'm right, is 'gmake' in your $PATH? If I look in the output below, I see make='make', and this test refers to gmake. On HP that makes quite a lot of difference. That is what I don't understand. The config.sh shows that a gmake was found (on the build machine) but that the make program is make Yet the test script is trying to use gmake. That test script doesn't hard code 'gmake', so what's forcing that change? Nicholas Clark
Perl 5 Porters list summariser
At various times a regular summary of the Perl 5 Porters mailing list has been published, providing informal reports on Perl 5 development activity to an audience far wider than the readership of this list. We've not had a regular summary for some time, because the various volunteers who used to write them no longer have time to donate to this task. So Rafael and I are asking if anyone would like to volunteer to perform this useful service. It would involve writing a summary of the important discussions and announcements on perl5-porters, and publishing it a regular basis, probably weekly or fortnightly. Historically the summary has been sent to the summary list http://lists.cpan.org/showlist.cgi?name=perl5-summary and published on a prominent Perl website, most recently use.perl.org. Given the fairly light traffic on the list these days I don't feel that the task is that onerous for someone already reading the list regularly. If anyone is interested in taking this on, could you reply to me privately, or join the channel #p5p on irc.perl.org and express your interest there. If more than one person is interested, we could run with alternating summarisers, as happens on the Perl 6 lists. Nicholas Clark
Re: Questions regarding Perl instrumentation
On Tue, Sep 13, 2005 at 10:02:38AM +0200, Rafael Garcia-Suarez wrote: Alan Burlison wrote: Rafael Garcia-Suarez wrote: Maybe are you aware of http://blogs.sun.com/roller/page/alanbur?entry=dtrace_and_perl already ? As Rafael says, I've already done some work on this, documented at the link above. My intention is to put some generic macros into perl at the appropriate places. By default they woud be empty, in the case of Solaris you will be able to instantiate them as DTrace probes, on other platforms they could be whatever tracing system the platform supports. I think it's worth investigating doing it in a module, providing an alternate runloop or only changing the pp functions for entersub and leavesub. From what I remember Alan telling me about what Dave had said, there are were a few more points other than entersub and leavesub that would need instrumentation. goto sub; was the most obscure, but I think that require was another. I see nothing wrong with doing it as a module, if that brings the benefit to older, installed, perls, but if the code changes are clean and compile time enabled, I think that once working and stable it would actually be appropriate for 5.8.x. (Given that the whole point of dtrace is to provide a way of instrumenting already running code, and it is already shipped in some very stable mission critical code, such as the Solaris kernel) Alan demonstrated dtrace to me with his perl prototype. It's impressive. ONE interface to instrument calls in perl space, the perl C code, the C runtime library, and the kernel. It's trivial to instrument particular kernel calls made only while you're in a particular perl subroutine. I want that, working threads debugging and valgrind on the same platform. Please. The pony can wait. Nicholas Clark
Re: how to deal with static c++ object
On Tue, Sep 13, 2005 at 03:08:51PM +0800, Dongxu Ma wrote: Hi all, Another question, is there any better way to port a class method which returns an object. Like this: foo foo::bar2() since the returned object is local, which is usually allocated on stack, I have to new an object on heap and copy the content from the local one in my perlxs code. Is there a better way to handle this case? Well, aside from always allocate it on the heap in the first place, I believe not. Nicholas Clark
Re: [perl #36448] configuring ranlib for perl on osx with xcode 2.1
On Fri, Jul 01, 2005 at 09:56:31PM -, Luke Closs wrote: # New Ticket Created by Luke Closs # Please include the string: [perl #36448] # in the subject line of all future correspondence about this issue. # URL: https://rt.perl.org/rt3/Ticket/Display.html?id=36448 Hello, It looks like Apple has changed how ar works in xcode 2.1. As a result, Configure thinks that ar can generate random libraries. This breaks linking libperl.a, for instance when building PerlApp. Configure doesn't currently allow overriding ranlib when Configure detects that ranlib isn't necessary. My patch fixes this, and sets ranlib for darwin. Note that this patch is for ActivePerl 5.6.1 (it doesn't appear to be fixed in 5.9.2), so it probably needs to be manually applied... Indeed it did. Thanks, applied (25402) Sorry about the delay on this one. Nicholas Clark
Re: 5.8.8
On Mon, Sep 12, 2005 at 12:28:52PM -0500, Steve Peters wrote: The only other exception would be changes to re-entrant functions through reentr.pl, where the generated code is quite different than that in bleadperl. Until and unless one of us figures out how to merge the code. Nicholas Clark
Re: [perl #36075] Adding malloc_size/malloc_good_size to Configure
On Mon, Sep 12, 2005 at 08:37:27AM +0200, H.Merijn Brand wrote: On Sat, 10 Sep 2005 17:59:00 -0700, Steve Peters via RT [EMAIL PROTECTED] wrote: [nicholas - Wed Jun 01 08:09:31 2005]: It's not clear if any other malloc implementations provide these functions, or the same functionality with another name, apart from Perl's own malloc's malloced_size Adding the detection for these function is pretty simple, and Configure doesn't need to do anything more that standard libc scanning. I'm guessing it would be easy to add to Metaconfig to check. The following patches can do it for playing with, but don't apply to p4. --- config_h.SH.old Tue Jun 21 14:56:18 2005 +++ config_h.SH Sat Sep 10 19:22:05 2005 @@ -3889,6 +3889,18 @@ */ #$d_libm_lib_version LIBM_LIB_VERSION /**/ +/* HAS_MALLOC_SIZE + * This symbol, if defined, indicates that the malloc_size + * routine is available for use. + */ +#$d_malloc_size HAS_MALLOC_SIZE /**/ + +/* HAS_MALLOC_GOOD_SIZE + * This symbol, if defined, indicates that the malloc_good_size + * routine is available for use. + */ +#$d_malloc_good_size HAS_MALLOC_GOOD_SIZE /**/ + /* HAS_NL_LANGINFO: * This symbol, if defined, indicates that the nl_langinfo routine is * available to return local data. You will also need langinfo.h I'll see. Looks complete. I'll also have to add this to handy.h, unless you have a real location where these new `things' are referenced. Whilst I realise that we can only probe for names we know, as is this doesn't suggest a framework for how to cope with the functions having a different name. Do we define 2 names for them that are actually macros in handy.h, that use malloc_size()/malloced_size() and malloc_good_size()/undef ? Nicholas Clark
Re: [perl #37133] perl crash related to threads and lock()
mode I can create is: (gdb) p thread-prev $3 = (struct ithread_s *) 0x0 which unsurprisingly causes this to SEGV: thread-next-prev = thread-prev; So, also, somehow it's looking like a thread can get freed up without correctly tidying up the linked list. Thoughts? Nicholas Clark
5.8.8
If there's a plan for 5.8.8, it goes roughly like this 0: All changes that apply to maint are integrated from blead 1: Changes should be in blead by midnight (GMT) on the 16th October 2005 2: RC1 will probably appear within a week I'll be out of the country for the first week in October, and probably mostly incommunicado. I'll be in the country for the second week, but again mostly incommunicado. This definitely isn't a problem, as a: how patches get into blead *isn't* my direct concern b: stable stuff isn't done as a last minute rush job [You may read this as if not being able to get patches into maint at the last minute worries you, then those patches will by definition worry me] Clearly if anyone wants to fix bugs in pseudohashes or 5005 threads, then those patches have to go direct to maint. But I believe that little else does. Nicholas Clark
odd corruption seen previously with hashes on VMS
With respect to the odd corruption seen previously on VMS, but now no longer
visible, might this patch have had something to do with it? I believe that
the change I made was correct. If so, then because it removed a large over-
allocation, it will show up any other code that failed to allocate sufficient
space, hence revealing latent bugs elsewhere.
Nicholas Clark
- Forwarded message from Nicholas Clark [EMAIL PROTECTED] -
Mailing-List: contact [EMAIL PROTECTED]; run by ezmlm
Precedence: bulk
List-Post: mailto:perl5-changes@perl.org
List-Help: mailto:[EMAIL PROTECTED]
List-Unsubscribe: mailto:[EMAIL PROTECTED]
List-Subscribe: mailto:[EMAIL PROTECTED]
List-Id: perl5-changes.perl.org
Delivered-To: mailing list perl5-changes@perl.org
Delivered-To: perl5-changes@perl.org
X-Spam-Status: No, hits=-2.6 required=8.0
tests=BAYES_00,UPPERCASE_25_50
X-Spam-Check-By: la.mx.develooper.com
Date: Wed, 1 Jun 2005 08:43:38 -0700
From: Nicholas Clark [EMAIL PROTECTED]
To: Anybody And Everybody perl5-changes@perl.org
Subject: Change 24661: As PERL_HV_ARRAY_ALLOC_BYTES is bytes, not items, the
type should be
Change 24661 by [EMAIL PROTECTED] on 2005/06/01 15:08:02
As PERL_HV_ARRAY_ALLOC_BYTES is bytes, not items, the type should be
char rather than HE *. Bug was harmless, overallocating by a factor
of sizeof(HE *)
Affected files ...
... //depot/perl/hv.c#221 edit
Differences ...
//depot/perl/hv.c#221 (text)
Index: perl/hv.c
--- perl/hv.c#220~24660~Wed Jun 1 07:33:14 2005
+++ perl/hv.c Wed Jun 1 08:08:02 2005
@@ -603,10 +603,13 @@
#ifdef DYNAMIC_ENV_FETCH /* if it's an %ENV lookup, we may get it on the fly
*/
|| (SvRMAGICAL((SV*)hv) mg_find((SV*)hv, PERL_MAGIC_env))
#endif
- )
- Newz(503, HvARRAY(hv),
+ ) {
+ char *array;
+ Newz(503, array,
PERL_HV_ARRAY_ALLOC_BYTES(xhv-xhv_max+1 /* HvMAX(hv)+1 */),
-HE*);
+char);
+ HvARRAY(hv) = (HE**)array;
+ }
#ifdef DYNAMIC_ENV_FETCH
else if (action HV_FETCH_ISEXISTS) {
/* for an %ENV exists, if we do an insert it's by a recursive
@@ -773,9 +776,11 @@
/* Not sure if we can get here. I think the only case of oentry being
NULL is for %ENV with dynamic env fetch. But that should disappear
with magic in the previous code. */
- Newz(503, HvARRAY(hv),
+ char *array;
+ Newz(503, array,
PERL_HV_ARRAY_ALLOC_BYTES(xhv-xhv_max+1 /* HvMAX(hv)+1 */),
-HE*);
+char);
+ HvARRAY(hv) = (HE**)array;
}
oentry = (HvARRAY(hv))[hash (I32) xhv-xhv_max];
End of Patch.
- End forwarded message -
Re: RFC - eliminate discrete arenaroots, mentoring
On Thu, Sep 08, 2005 at 08:54:12AM -0600, Jim Cromie wrote: extracting the lesson; you either blamelogged sprintf.t to find the failing test, then found 25171 as last touch, or you last-50'd sv.c, found the sprintf.t change, then maybe noted the the date and touched-file overlap, then the rogue chunk in my patch. thanks for stepping in where my brain turned off. No, simpler than that. I read my way through your patch, wondering what each hunk did. That was the first non-innocent hunk, and I've read enough of the sprintf code in sv.c to realise it was there without needing to check the line numbers. Thus far, Im unable to smoke current with this patch - Im having issues getting 'make regen' to run after the pfile is applied, and consequently teh compile fails with stuff like: sv.c:8451: error: `PL_body_roots' undeclared (first use in this function) sv.c: In function `Perl_sv_dup': sv.c:10500: error: `PL_body_roots' undeclared (first use in this function) sv.c:10501: error: `PL_body_arenaroots' undeclared (first use in this function) sv.c: In function `perl_clone': sv.c:11355: error: `PL_body_arenaroots' undeclared (first use in this function) sv.c:11356: error: `PL_body_roots' undeclared (first use in this function) make: *** [sv.o] Error 1 Unable to make anything but miniperl in this configuration Any tips welcome. I didn't have a problem with doing perl regen.pl after applying your patch, then re-running make. So I don't know what to suggest. Nicholas Clark
Re: better assertion support
On Tue, Jun 14, 2005 at 11:25:08AM +0200, Rafael Garcia-Suarez wrote: I'm sure you'd welcome feedback from the porters on this feature, too. Is there a list of the patches to blead, from which one can create a cumulative patch representing the changes needed to add assertions. Now that the assertion code is (I believe) fully feature complete, I'm wondering if it can be refactored into a minimal set of core hooks, and an XS module in ext. Having more hooks increases what is possible for future authors to achieve as independent modules released to CPAN. Nicholas Clark
Re: [perl #37094] Internal warning from exception inside a grep
On Tue, Sep 06, 2005 at 07:01:06PM -0700, Chris Heath wrote:
Throwing an exception inside a grep sometimes causes Perl
to emit an internal warning.
$ perl -e 'for (foo) { grep(die, bar) }'
Died at -e line 1.
Attempt to free unreferenced scalar: SV 0x96c61dc, Perl interpreter:
0x96ae008.
The unreferenced scalar seems to be bar as this will still generate an error
$ perl -e 'grep {die} bar for undef'
Died at -e line 1.
Attempt to free unreferenced scalar: SV 0x800dd0.
(undef has special reference counting semantics)
Replacing grep with map produces the same error.
Does this warning indicate possible internal corruption? I have seen
some Perl corruption in a production system at my work recently, as well
as this warning, so I wondered if they could be related.
Well, it's a double free, in as much as one part of the interpreter has a
pointer to a block of memory that will be recycled as a new scalar at some
point. I'm not sure quite what route, or what manipulation of $@ could create
actual corruption though.
Nicholas Clark
Re: RFC - eliminate discrete arenaroots, mentoring
On Tue, Sep 06, 2005 at 11:40:12AM -0600, Jim Cromie wrote: t/op/sprintf..FAILED at test 239 This makes little sense to me. The output is not ok 239 %*2$1d [12, 3] %*2$1d INVALID 12 Translated, that seems to mean that given the template %*2$1d and the data [12, 3] we were expecting to see %*2$1d INVALID (where INVALID means that an /^Invalid conversion/ warning was issued) but actually we got the result 12 But your patch goes nowhere near the printf code. Nicholas Clark
Re: RFC - eliminate discrete arenaroots, mentoring
Scrub my previous message. It was incorrect.
On Tue, Sep 06, 2005 at 11:40:12AM -0600, Jim Cromie wrote:
t/op/sprintf..FAILED at test 239
@@ -9101,11 +9166,9 @@
}
if (!asterisk)
- {
if( *q == '0' )
fill = *q++;
EXPECT_NUMBER(q, width);
- }
if (vectorize) {
if (vectorarg) {
You didn't want to do that. :-)
Nicholas Clark
Re: [CRACK] build a better runloop
On Tue, Sep 06, 2005 at 12:43:48PM +0200, Rafael Garcia-Suarez wrote:
Nicholas Clark wrote:
On Fri, Sep 02, 2005 at 12:07:21PM +0200, Rafael Garcia-Suarez wrote:
OK, Runops::Switch 0.01 just uploaded to CPAN.
From my very first tests, it's slower.
To make it faster, would it need to inline the hot ops?
OK, 0.02 uploaded to play with :
0.02 - 06 Sep 2005
Inline some small hot ops, taking code from current bleadperl :
null, stub, scalar, pushmark, const, gv, pushre, stringify, and, or,
cond_expr, nextstate, unstack, setstate
Compiles with 5.8.7.
Of course, this raises portability problems among different versions of
perl, and I didn't took time to put a ppport.h in there.
Surely one just makes Makefile.PL parse the C source of the various pp*.c
files, and grabs the code direct from there?
It's not like parsing perl. :-)
Here's an arguably contrived example :
$ time perl -e '$i=0;while(++$i1000){$i=~/00/ and $y = 0}'
4.20user 0.00system 0:04.21elapsed 99%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (0major+413minor)pagefaults 0swaps
$ time perl -Mblib -MRunops::Switch -e '$i=0;while(++$i1000){$i=~/00/
and $y = 0}'
4.07user 0.00system 0:04.08elapsed 99%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (0major+640minor)pagefaults 0swaps
Ooh, it's faster. I don't expect it to be always faster, though.
about 3% faster. Hmm.
Nicholas Clark
Re: [perl #37038] Global regular matches generate invalid pointers
On Wed, Aug 31, 2005 at 05:32:25AM -0700, Thilo Girmann wrote: The statement $s = $1 causes Perl to re-use the string abcd for storing the first half (ab) and add a terminating zero. $2 still points to the original second half but the character c got overwritten neanwhile. So if the bug is present you will get c or just c printed out instead of the expected cd. I've added a TODO regression test for this in t/op/pat.t, but I'm not sure how to fix this, without creating a speed hit by copying the matched string every time. Nicholas Clark
Re: [perl #37038] Global regular matches generate invalid pointers
On Tue, Sep 06, 2005 at 07:14:27PM +0100, Nicholas Clark wrote: On Wed, Aug 31, 2005 at 05:32:25AM -0700, Thilo Girmann wrote: The statement $s = $1 causes Perl to re-use the string abcd for storing the first half (ab) and add a terminating zero. $2 still points to the original second half but the character c got overwritten neanwhile. So if the bug is present you will get c or just c printed out instead of the expected cd. I've added a TODO regression test for this in t/op/pat.t, but I'm not sure how to fix this, without creating a speed hit by copying the matched string every time. Specifically I don't think that we can spot the pattern of assigning to the match variable via static analysis (consider references), so whatever we do would have to be runtime. Therefore if we aren't copying, we need to fake it as if we were, which means some sort of copy on write solution. Albeit special case, as we can probably hide sufficient data inside the regexp rather than the SV. But I can't work out a good way to trigger the on write part, suitable for maint. Nicholas Clark
Re: [perl #37036] perl segfault at 'compile'-time
On Wed, Aug 31, 2005 at 03:00:31PM +0200, Dominic Dunlop wrote: Does consting stuff like this get rolled into the various maints as a matter of course? It will get into 5.8.x if it doesn't seem to break anything else. Nicholas Clark
Re: [perl #37076] threads + 'require IO' causes segmentation fault
0xb7407de0 in Perl_ithread_run () from lib/auto/threads/threads.so #9 0xb756adec in start_thread () from /lib/tls/libpthread.so.0 #10 0xb750aa2a in clone () from /lib/tls/libc.so.6 (gdb) where #0 0xb749fa8e in _int_malloc () from /lib/tls/libc.so.6 #1 0xb749ee9d in malloc () from /lib/tls/libc.so.6 #2 0x080ac90f in Perl_safesysmalloc () #3 0x080cac1e in Perl_sv_grow () #4 0x080cafe6 in Perl_sv_setpv () #5 0x0808d6fa in Perl_newCONSTSUB () #6 0xb5dfd3df in boot_IO () from lib/auto/IO/IO.so #7 0x080c5b6d in Perl_pp_entersub () #8 0x080be7e9 in Perl_runops_standard () #9 0x080641ba in Perl_call_sv () #10 0xb7407de0 in Perl_ithread_run () from lib/auto/threads/threads.so #11 0xb756adec in start_thread () from /lib/tls/libpthread.so.0 #12 0xb750aa2a in clone () from /lib/tls/libc.so.6 So I assume that all this in-malloc() corruption comes from scribbling over memory at some other point in some other thread. Reasonable? Nicholas Clark
Re: [CRACK] build a better runloop
On Fri, Sep 02, 2005 at 12:07:21PM +0200, Rafael Garcia-Suarez wrote: OK, Runops::Switch 0.01 just uploaded to CPAN. From my very first tests, it's slower. To make it faster, would it need to inline the hot ops? For that matter, are the ops in pp_hot still the hot ops? Heck, could a switch oploop inline all the ops, but clustered as currently laid out in source files? Nicholas Clark
Re: no 6;
On Thu, Sep 01, 2005 at 12:07:59PM -0500, David Nicol wrote: Does this mean that we have to implement perl4 compatability? perl5 -e 'no 5; print [EMAIL PROTECTED]' It's not valid perl 4: $ perl4 -e 'no 5; print [EMAIL PROTECTED]' syntax error in file /tmp/perl-em47tij at line 1, next 2 tokens no 5 Execution of /tmp/perl-em47tij aborted due to compilation errors. So I think not. (if anyone wants to compile perl4 on FreeBSD, tell Configure that libc is /usr/lib/libc.a, rather than .so After that you'll need to edit a couple of things, but they'll be obvious) Nicholas Clark
sort {$b cmp $a} and the peephole optimiser
Where does the op for cmp go in this?
$ perl -MO=Concise -e '@a = sort {$b cmp $a} @b'
I see:
c @ leave[1 ref] vKP/REFC -(end)
1 0 enter -2
2 ; nextstate(main 2 -e:1) v -3
b 2 aassign[t2] vKS -c
-1 ex-list lK -8
3 0 pushmark s -4
7 @ sort lK/DESC -8
4 0 pushmark s -5
6 1 rv2av[t3] lK/1 -7
5 $ gv(*b) s -6
-1 ex-list lK -b
8 0 pushmark s -9
a 1 rv2av[t1] lKRM*/1 -b
9 $ gv(*a) s -a
I expected to see an ex-scmp in there. Is the cmp ever compiled to ops?
Nicholas Clark
'
Re: sort {$b cmp $a} and the peephole optimiser
On Thu, Sep 01, 2005 at 10:59:52AM +0200, Rafael Garcia-Suarez wrote: Nicholas Clark wrote: I expected to see an ex-scmp in there. Is the cmp ever compiled to ops? yes, but it's freed in S_simplify_sort, called by ck_sort during optree construction, i.e. before the peephole optimizer is called. Aha. This was what I was wondering, and also why the departure from perl's usual policy of not free-ing ops during optimisation. Concise shows the DESC flag on the sort op that indicates this is a reverse sort. and there are also NUM and now REVERSE (IIRC) Nicholas Clark
mentoring new perl 5 porters
One of the good ideas of the Google Summer of Code was to insist that every project has a mentor; an experienced person to advise and guide the grantee. I'm wondering whether we could embrace this idea for perl5-porters. We often feel rather thin on the ground, and there are many people who might start to help, but the general feeling I get is that most find the first step daunting. Coupled with this I'm currently sitting at YAPC::EU, where there are lots of lightning talk slots free tomorrow. So I was wondering whether I should do a lightning talk about some of the approachable pure-perl tasks in the perltoto, in the hope of gaining some interest. But it would be more likely to succeed in its aim if there are actually some people who would volunteer to consider the task. I wasn't going to name anyone in a talk. People don't actually have to mentor anything - there's no shame in saying you'd consider it and then realising that you can't do it (and no need to say why) You don't need to know C. Let alone the perl source. Just have some confidence about how to go about tasks, and create well formed patches. Does this seem like a good idea? Nicholas Clark
[CRACK] build a better runloop
The perl 5 runloop is simple: http://public.activestate.com/cgi-bin/perlbrowse?file=run.cblame=1 It's a tight loop, of about 8 instructions. It's also analogous to the simplest runloop in parrot Leo has just done a talk on parrot, where he showed a graph showing the relative speeds of runloops. The switch runloop is about 3-4 times faster Correct me if I'm wrong, but the whole runloop is pluggable, and can be replaced by any CPAN module. So I'm wondering if anyone wants to take this idea and see if they can create a replacement runloop module that makes existing perl faster. Nicholas Clark
Re: Need help debugging blead on VMS - keys(%ENV)
On Mon, Aug 22, 2005 at 10:35:54PM -0400, John E. Malmberg wrote: On every blead perl I have seen, the following bug is present on VMS and is causing the script t/op/magic.t to fail at test 7. In the Perl debugger, before running any script if you issue the command 'x keys(%ENV), the entry for index 0, also shows up as index 1. DB1 x keys(%ENV) 0 'SYS$TIMEZONE_DAYLIGHT_SAVING' 1 'SYS$TIMEZONE_DAYLIGHT_SAVING' 2 'CDE$DETACHED_LOGICALS' 3 'MOP$NAMED_LOAD' 4 'BUILD_ROOT' On all subsequent calls, you get the expected results: DB2 x keys(%ENV) 0 'SYS$TIMEZONE_DAYLIGHT_SAVING' 1 'CDE$DETACHED_LOGICALS' 2 'MOP$NAMED_LOAD' 3 'BUILD_ROOT' 4 'SMBSRVSHR_TV' IIRC %ENV on VMS is special, in that it's the only platform and only hash that uses the DYNAMIC_ENV_FETCH code. It's quite possible that there's a strange, unnoticed bug in that. Nicholas Clark
Re: [perl #36977] perl 5.8.7 Solaris Sparc compile error: no _ptr member in __FILE
This is all we got: On Mon, Aug 22, 2005 at 07:06:10AM -0700, Vahik Manookian wrote: # New Ticket Created by Vahik Manookian # Please include the string: [perl #36977] # in the subject line of all future correspondence about this issue. # URL: https://rt.perl.org/rt3/Ticket/Display.html?id=36977 This transaction appears to have no content Did the body of a bug report go missing? The subject line suggests that perl failed to compile, with some sort of error about no _ptr member in __FILE How did you run perl's Configure script? Did you pass it any command line arguments to change the behaviour from the default? If running it interactively did you accept the default answers when prompted? Nicholas Clark
Re: 25309 does not compile
On Sat, Aug 20, 2005 at 10:14:28PM +0200, Andreas J. Koenig wrote: 25308 was compiling OK, but 509 says: `sh cflags optimize='-g' pp_sort.o` pp_sort.c CCCMD = cc -DPERL_CORE -c -DDEBUGGING -fno-strict-aliasing -pipe -Wdeclaration-after-statement -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -g -Wall rm -f libperl.a /usr/bin/ar rcu libperl.a perl.o gv.o toke.o perly.o op.o pad.o regcomp.o dump.o util.o mg.o reentr.o hv.o av.o run.o pp_hot.o sv.o pp.o scope.o pp_ctl.o pp_sys.o doop.o doio.o regexec.o utf8.o taint.o deb.o universal.o xsutils.o globals.o perlio.o perlapi.o numeric.o locale.o pp_pack.o pp_sort.o `sh cflags optimize='-g' opmini.o` -DPERL_EXTERNAL_GLOB opmini.c CCCMD = cc -DPERL_CORE -c -DDEBUGGING -fno-strict-aliasing -pipe -Wdeclaration-after-statement -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -g -Wall opmini.c: In function 'Perl_newCONSTSUB': opmini.c:4611: warning: null argument where non-null required (argument 1) cc -L/usr/local/lib -o miniperl \ miniperlmain.o opmini.o libperl.a -lnsl -ldl -lm -lcrypt -lutil -lc libperl.a(sv.o): In function `Perl_sv_2pv_flags': /home/src/perl/repoperls/[EMAIL PROTECTED]/sv.c:3277: undefined reference to `svWupgrade' collect2: ld returned 1 exit status make: *** [miniperl] Error 1 I don't see this when I try a clean build of blead from rsync. Moreover, I'm not sure how sv.c got changed, given that patch 25309 is solely whitespace and solely in POSIX.xs: Change 25309 by [EMAIL PROTECTED] on 2005/08/19 21:19:37 Subject: [PATCH ext/POSIX/POSIX.xs] Whitespace From: Abigail [EMAIL PROTECTED] Message-ID: [EMAIL PROTECTED] Date: Sat, 23 Jul 2005 02:32:35 +0200 Affected files ... ... //depot/perl/ext/POSIX/POSIX.xs#139 edit Differences ... //depot/perl/ext/POSIX/POSIX.xs#139 (text) @@ -1408,8 +1408,8 @@ * essentially meaningless anyway. */ RETVAL = sigaction(sig, act, (struct sigaction *)0); - if(RETVAL == -1) - XSRETURN_UNDEF; + if(RETVAL == -1) + XSRETURN_UNDEF; } LEAVE; I'm confused. Nicholas Clark
Re: [EMAIL PROTECTED] lib/ExtUtils/t/Constant.t VMS fixes
On Sun, Aug 21, 2005 at 12:31:17AM -0400, John E. Malmberg wrote: Fix for correct names for the descrip.mms file used with MMS/MMK on VMS. Per review of Andy Lester, also fixed the error message from failed renames. Also preparation for use of other make programs on VMS with the assumption that no there will be no port of MMK to other platforms even though it is open source. Seems a reasonable assumption. Thanks, applied (25310) Nicholas Clark
Re: [EMAIL PROTECTED] t/op/arith.t fix for VMS with IEEE float
On Sat, Aug 20, 2005 at 11:21:44PM -0400, John E. Malmberg wrote: If VMS is configured to use IEEE float, test 145 was not run. Thanks, applied (25311) Nicholas Clark
Re: Data corruption - [EMAIL PROTECTED] - PERL_HV_ARRAY_ALLOC_BYTES?
On Sat, Aug 20, 2005 at 01:08:07AM -0400, John E. Malmberg wrote: Nicholas Clark wrote: I can only reproduce this on one instance of one test, but on that test it can be reproduced every time. In your previous messages I couldn't spot whether you said which test. Is there some quick way that I can turn on the DEBUG_m function once I start reproducing the problem? It would be interesting to see if that gave any more clues. Yes, good idea. You can do this by setting the bit values in $^D at runtime. So setting $^D to 128 just for the section you're interested in would be the same as -Dm on the command line, only locally. There's a table of letters and values in perlrun.pod. Nicholas Clark
Re: RFC - eliminate discrete arenaroots
On Sat, Aug 20, 2005 at 10:03:50AM -0600, Jim Cromie wrote:
ah, umm, off-by-one err? no wait - its padding - yeah, thats it.
Ive added a new value to the svtype enum: SVt_LAST,
and used it in place of 17.
I couldn't spot a need for padding.
SVt_LAST seems a useful thing to have
BTW- anyone know how to do this (such that it compiles) ?
#define SIZE_SVTYPES sizeof(sizeof_body_by_svtype)
#define SIZE_OFFSETS sizeof(sizeof_body_by_svtype)
/* they better stay synchronized, but this doesnt do it.
#if SIZE_SVTYPES != SIZE_OFFSETS
#error declaration problem: sizeof_body_by_svtype !=
sizeof(offset_by_svtype)
#endif
*/
I don't think it's possible at compile time. The simplest way would seem
to be to compile a small program that #includes sufficient perl headers,
run it (possibly to generate an output file via a Makefile rule) and have
that file, or the successful running of the program as a prerequisite of
compiling the rest of miniperl
ALSO (near the top, so everyone reads it)
please note the comment below. I think Im missing something, perhaps an old
bug / suboptimality.
static int sizeof_body_by_svtype[] = {
0,/* SVt_NULLs, SVt_IVs, SVt_NVs, SVt_RVs have no body */
0,
sizeof(XPVNV), /* 20: seems wrong, but matches old code */
0,
...
Is wrong. NVs (with IVs) were the original allocation hack, where only
sizeof(NV) [or sizeof(IV)] got allocated, but the pointer to the allocated
bit of memory was manipulated downwards, so that it pointed into somewhere
else, but (pointer + structure offset of NV slot) pointed to the allocated
NV-sized piece of memory.
And this is probably invasive enough as it is.
Needs a good smoking.
I'd go with that - smoke this first, then see what's next.
FWIW, Id thought a bit about chosing the arena by body-size, not svtype
(XPVNV, xpvav_allocated, xpvhv_allocated all appear to be 20 bytes)
and that seems like it would fold into the link-list traversal nicely,
possibly as a compile-time option. (or runtime even, since
arena-creation isnt
particularly hot code, except for pathological tests)
I'm not sure if it's worth it. Currently your code finds the correct
arena head by indexing on the SV type. With this you'd need a double index,
from SV type to SV size, and then from SV size to arena.
It might be - would probably need benchmarking.
Then theres HE and pte arenas, which might fold into the array
( in the unused slots) and possibly even SV-heads themselves (at idx=0,
naturally).
That's interesting. SV heads are different, in that their arena is documented
as carrying allocation flags. Specifically SvFAKE is used to signal that this
arena isn't to be free()d. I 've no idea what uses this - none of the core
seems to.
And IIRC, someone said something about Socket data being allocated in
very large (mostly wasted) chunks. These could probly be handled as 1
more arena
(one of the unused ones)
I was unaware of this.
YAGNI ? also possible is tuning arena-size by svtype, possibly w
adjustments
for memory growth during runtime (limited geometric growth). Starting
with small arenas would make them more palatable for the big/rare types.
Not sure if these 'gains' are real/measurable.
I don't know.
Even currently it should be possible to write a module for CPAN that traverses
the SV heads and compacts the allocations of SV bodies.
(Assuming that nothing is evil enough to store a direct pointer to the body)
I'm not sure if we'd benefit from getting much more complex in the arena
allocation code.
Nicholas Clark
Re: Data corruption - [EMAIL PROTECTED] - PERL_HV_ARRAY_ALLOC_BYTES?
On Sat, Aug 20, 2005 at 05:25:02PM -0400, John E. Malmberg wrote: Nicholas Clark wrote: On Sat, Aug 20, 2005 at 01:08:07AM -0400, John E. Malmberg wrote: Nicholas Clark wrote: I can only reproduce this on one instance of one test, but on that test it can be reproduced every time. As of [EMAIL PROTECTED], I can not reproduce the corruption anymore. Bah. If you still have the build tree for the version that reliably shows it, what happens if you apply just patch 25297 to it, and recompile: http://public.activestate.com/cgi-bin/perlbrowse?patch=25297 (I assume that the MMS template is similar to the Unix Makefile and can build the target perl, rather than all, which would save waiting for all the dynamic extensions to rebuild) I'm wondering if it was something about the screwy amount of casting as was in HvARRAY() that was the cause of the problem. Nicholas Clark
Re: Encoding iso-8859-16
On Fri, Aug 19, 2005 at 05:01:04PM +0530, Sastry wrote: Hi Nicholas With reference to my previous mail on encoding module use Encode; $string = a; $enc_string = encode(iso-8859-16, $string); print \n String: $string\n; print \n enc_string: $enc_string\n; a)How different are those ext/Encode/def_t.c and ext/Encode/Byte/byte_t.c files in EBCDIC and ASCII platforms? I don't know. I have no experience of EBCDIC. The files describe converting from perl's internal representation to a fixed external representation. So I assume that they have to differ because the internal representation differs. b) Why is it when I copied the above .c files from ASCII platform to EBCDIC worked for any codepage except IBM-1047 codepage on EBCDCI platform? I don't know. How thorough are the tests? Do the tests check for the conversion of characters with Unicode code points 127? You're asking questions beyond my knowledge. Nicholas Clark
Re: Encoding iso-8859-16
On Fri, Aug 19, 2005 at 05:51:10PM +0530, Sastry wrote: Hi The test case uses the invariant character that is below 127 on ISO-8859-16 codepage. Since character 'a' has a codepoint of 129 on EBCDIC, is there a place in the code where it should apply NATIVE_TO_ASCII macro on the input character? I don't know. And if the test is only checking for invariant characters below 127, it doesn't strike me as a very thorough test. Nicholas Clark
Re: Data corruption - [EMAIL PROTECTED] - PERL_HV_ARRAY_ALLOC_BYTES?
Sorry about the delay in replying. I've had a lot on, and wanted to find
the time to confirm my suspicions.
On Sat, Jul 30, 2005 at 09:50:40PM -0400, John E. Malmberg wrote:
What I have found is that in this case is that the allocation size for
the sv_u.svu_array member appears to be too small.
I don't believe this conclusion to be correct.
I refactored the hash code about 2 months ago and introduced the xpvhv_aux
structure. Prior to this, the malloc()ed region pointed to by the
sv_u.svu_array member was only used for the HE*s. For the case of no the
xpvhv_aux structure, the part of the code that calculates the size to allocate
has not changed.
The size of the allocated or reallocated array is controlled by the
xhv_max member.
DBG exam hv-sv_any-xhv_max
HV\Perl_hv_iternext_flags\hv-sv_any-xhv_max: 7
The actual calculation is for the array size =
PERL_HV_ARRAY_ALLOC_BYTES(HvMAX(hv) + 1) + sizeof(struct xpvfhv_aux)
HvMAX(hv) = 7 from above.
So PERL_HV_ARRAY_ALLOC_BYTES results in:
(8 * sizeof(HE*) + sizeof(struct xpvfhv_aux)
The size of a Pointer type on VMS is 4 bytes. And the size of the
struct xpvfhv is 12 bytes. This results in (8 * 4) + 12 or 48 bytes.
A pointer to the xpvfhv is then stored in hv-sv_u.svu_array[8].
The size of the svu_array type is 12, so the offset is 12 * (8-1) is 84
which is a bit beyond the 48 bytes that was allocated.
It appears to me that macro PERL_HV_ARRAY_ALLOC_BYTES should be using
the size of the HE structure instead of the size of a pointer to that
structure.
The memory that is allocated is used to store an array of HE * pointers.
Not HE structures. The code isn't clear, and when I started trying to
investigate I realised that I could add another member to the sv_u
union, of type HE **, to make things much clearer.
Had the calculation been wrong in the past, we would also have been allocating
4*n bytes on many systems, yet using 12*n bytes, for every hash, which should
have shown up with memory checking tools (and random corruption) left right
and centre.
So I'm assuming that the problem is in or related to the changes I made to
tag a xpvhv_aux structure on the end, but not all the time. Hence I suspect
that it's my fault and been trying to confirm where, and nail the cause, if
not find the solution. But I admit that I have to give up. I don't know
where. Even if I try this change to make the xpvhv_aux structure rather
larger:
//depot/perl/hv.h#76 - /home/nick/p4perl/perl/hv.h
--- /tmp/tmp.89859.0Fri Aug 19 21:38:03 2005
+++ /home/nick/p4perl/perl/hv.h Wed Aug 17 13:54:08 2005
@@ -37,10 +37,14 @@ struct shared_he {
Don't access this directly.
*/
struct xpvhv_aux {
+char splat1[1];
HEK*xhv_name; /* name, if a symbol table */
HE *xhv_eiter; /* current entry of iterator */
I32xhv_riter; /* current root of iterator */
+char splat2[1];
};
+
+#define SPLAT(hv) memset(HvAUX(hv)-splat1, 0xFE, 1);
memset(HvAUX(hv)-splat2, 0xFE, 1);
/* hash structure: */
/* This structure must match the beginning of struct xpvmg in sv.h. */
and put calls to SPLAT everywhere that the members of xpvhv_aux are written
to, I can't trigger the corruption on x86 Linux.
The xpvhv_aux structure is placed in memory directly after the array of
pointers to HE*s. However, memory to hold it is not always allocated.
My assumption is that either
1: There's a code path that starts writing to the location it should be in,
without first calling realloc() to allocate memory for it.
2: There's an error in the code that works out the offset of the xpvhv_aux
structure given the pointer accessed via the macro HvARRAY()
but I can't find it by inspection, and I can't reproduce it, even by tweaking
the code to try to provoke the problem. Running regression tests under
valgrind doesn't find anything amiss either. I'm stuck. But I'm confident
that it's not a three-fold error in the calculation for the size of memory to
allocate for the array of HE **s.
Nicholas Clark
Re: RFC - eliminate discrete arenaroots
On Fri, Aug 19, 2005 at 11:26:46AM +0200, Tels wrote:
-BEGIN PGP SIGNED MESSAGE-
Moin,
Anyway, this work sounds good. Just one small detail:
+
+for (i=0; i17; i++) {
+ S_free_arena(aTHX_ (void**) PL_body_arenaroots[i]);
+ PL_body_arenaroots[i] = 0;
+ PL_body_roots[i] = 0;
+}
The 17 should be defined somewhere. It might change someday :)
I wasn't sure why the 17 was 17 and not 16.
Anyway, nice. This seems a good way to go.
It wasn't directly what I had been thinking about, and it had never occurred
to me to put the arena heads into an array. That's going to reduce the size
of the switch statements nicely.
What I had been wondering was whether the arena roots (or at least all bar
sv_arenaroot) can all be replaced by a single pointer, given that all that
the PL_*_arenaroot pointers point to are structurally identical linked lists
of things to free.
But if that change works, it can be made after the change you're working on
here goes in.
Nicholas Clark
Re: [PATCH ext/POSIX/POSIX.xs] Whitespace
On Sat, Jul 23, 2005 at 02:32:35AM +0200, Abigail wrote: Some lines were outdented by one space. This patch fixes it. Thanks, applied (25309)(by hand, because it turned out to be faster) I don't understand how those 2 lines managed to get to outdented, as the change that created them looks consistent across all 3 hunks, and the other 2 hunks were never outdented. http://public.activestate.com/cgi-bin/perlbrowse?patch=10816 Nicholas Clark
Re: resolving methods at compile time
On Thu, Aug 18, 2005 at 04:10:50PM -0500, David Nicol wrote: Executive vote: more trouble than its worth (but D looks interesting) This is the conclusion I'm coming to for just about all speed optimisations, where the intent is to buy more speed by increasing complexity. I feel that we'd be much better served by attempting to simplify the current code base (without losing functionality) and see whether that opens up any new insights. (As well as fixing bugs and generally increasing maintainability and accessibility) Nicholas Clark
Re: segfault while DELETE THIS
On Thu, Aug 11, 2005 at 11:55:49AM +0800, Dongxu Ma wrote:
According to typemap in ExtUtils and perl.h, casting IV to pointer
should be safe in this case, since on my machine(32bit, kernel
2.6.12), sizeof(int) == 4, which is the same as a pointer. Does
anyone have any idea about this issue?
I think that there's a bug in the typemap you're using:
-typemap---
TYPEMAP
Test *T_OBJECT
INPUT
T_OBJECT
if(sv_isa($arg, \Test\) sv_isobject($arg)) {
$var = INT2PTR($type, SvIV($arg));
SvIV(SvRV($arg))
} else {
warn(\$arg is not a blessed object\);
XSRETURN_UNDEF;
}
If I make the above change to use SvRV then I can avoid getting a segfault.
Nicholas Clark
Re: Smoke [5.8.7] 24695 FAIL(m) MSWin32 WinXP/.Net SP2 (x86/2 cpu)
On Fri, Aug 12, 2005 at 06:39:00PM +0100, Steve Hay wrote: Automated smoke report for 5.8.7 patch 24695 Mugwump.uk.radan.com: Intel(R) Pentium(R) 4 CPU 3.40GHz(~3391 MHz) (x86/2 cpu) onMSWin32 - WinXP/.Net SP2 using ? unknown cc version smoketime 4 minutes 26 seconds (average 13.300 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 24695 Configuration (common) -DCCTYPE=BORLAND -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 -Duseithreads m m -Duseithreads -Duselargefiles | +- -DDEBUGGING +--- no debugging That wasn't me. I didn't do anything. la la la. What changed? Nicholas Clark
Re: [perl #36848] Sys::Syslog::syslog kills program if syslogd not running
On Wed, Aug 10, 2005 at 12:21:49PM -0400, Ed Ravin wrote: I submit that this is a design bug - no other syslog() library behaves this way, especially not the C library that Syslog.pm is based on. Sys::Syslog::syslog() should return an error and let the user deal with it (which would be an improvement over the C version, which has no defined return values). One way of implementing in error return in perl is throwing an exception. We may not agree whether this is the most appropriate design paradigm in this case, but it's definitely a perlish way of doing things, even if it's not a syslogish way. Nicholas Clark
Re: startperl insanity
On Wed, Aug 10, 2005 at 09:56:37PM -0500, Graham Barr wrote:
On Aug 10, 2005, at 4:43 PM, Nicholas Clark wrote:
which somewhat makes sense, as the #! for dprofpp, h2ph and h2xs is
#!/Users/nick/Sandpit/frob/spong
eval 'exec /Users/nick/Sandpit/blead25277/bin/perl5.9.3 -S $0
${1+$@}'
if $running_under_some_shell;
Thats a bug in the .PL script that generates them. perlrun describes
this
#!/bin/sh -- # -*- perl -*- -p
eval 'exec /usr/bin/perl $0 -S ${1+$@}'
if $running_under_some_shell;
So those .PL scripts should probably have
print OUT !GROK!THIS!;
$Config{startperl} -- # -*- perl -*-
eval 'exec $Config{perlpath} -S \$0 \${1+\$@}'
if \$running_under_some_shell;
!GROK!THIS!
Or the exec should have -x and the line #!perl added after the if
By the time there's the -*- perl -*- in place, the #! redispatcher code is
happy, in that it doesn't attempt to re-exec. Adding another #!perl and an
-x earlier doesn't seem to make a difference.
Taking out the -*- perl -*- causes an infinite loop
10 /usr/bin/sh gets to the eval exec, and does that, exec'ing perl
20 perl gets to the first #! line
30 that doesn't say perl, so it re-execs whatever was on the #! line
(/usr/bin/sh)
40 goto 10
So I think that adding -*- perl -*- (and the preceding gubbins) would solve
it, but I don't have access to enough Unix variants to be confident that
that would work everywhere. For now, I've removed the redispatch code from
ponie.
Nicholas Clark
perl's #! redispatch
Perl can act as a /bin/sh replacement, re-dispatching based on the #! line.
The code to do this fires if #! doesn't contain perl, and a few other
conditions. Specifically, s is a pointer to the #! line:
if (!d
*s == '#'
ipathend ipath
!PL_minus_c
!instr(s,indir)
instr(PL_origargv[0],perl))
{
What is that instr(s,indir) about?
It's been in perforce since change #1
There's no comment as to why the #! re-dispatch should be disabled if the
#! line contains the string indir.
Does anyone know?
Nicholas Clark
Re: [perl #36848] Sys::Syslog::syslog kills program if syslogd not running
On Tue, Aug 09, 2005 at 04:30:32PM -0700, eravin @ panix. com wrote: connect: No such file or directory (SOCK_DGRAM after trying SOCK_STREAM) at perlprog line NNN Where the offending line is something like: syslog(notice, SHUTDOWN: $sig); The offending line is in a signal handler. If I edit out the syslog() call n the signal handler, it gets even worse - the program dies with no error message. Here's what happens when I step through with the debugger: main::(/usr/local/sbin/servicemon:160): 160:syslog(notice, STARTUP: services= . join(/, @services) . , startwait=$startwait, cyclewait=$cyclewait); DB1 Debugged program terminated. Use q to quit or R to restart, use O inhibit_exit to avoid stopping after program termination, h q, h R or h O to get additional info. Any suggestions? I've checked the source for Syslog.pm in 5.6.1 and it's calling croak() If you wrap the call to syslog() in an eval, you will catch the error. As to what happens if you remove the call to syslog - given that your source line says SHUTDOWN, is your program shutting down normally in this case? Otherwise I have no idea. [Please do not change anything below this line] - --- Flags: category=core severity=medium --- Site configuration information for perl v5.8.0: Configured by fn at Mon Jul 29 16:55:09 EDT 2002. Summary of my perl5 (revision 5.0 version 8 subversion 0) configuration: Platform: osname=netbsd, osvers=1.5.2, archname=i386-netbsd I don't know how NetBSD versions work. Is this an older NetBSD with a newer version of perl? (One that happens to have reasonable internet connectivity, hence why you used it for bug reporting) Nicholas Clark
Re: Encoding iso-8859-16
On Wed, Aug 10, 2005 at 02:11:45PM +0530, Sastry wrote: On 8/9/05, Nicholas Clark [EMAIL PROTECTED] wrote: On Tue, Aug 09, 2005 at 10:58:48AM +0530, Sastry wrote: $enc_string = encode(iso-8859-16, $string); So $enc_string should be a single byte, 97, everywhere. Can you suggest some pointers in the code to fix this? No, not really. I think that the perl level sub encode() is implemented by Encode::XS::encode. I'd start by putting a gdb breakpoint on that (XS_Encode__XS_encode) and simply single stepping at a C level in from there to see where the code goes, and check that each step does what I'd expect. Nicholas Clark
Re: [perl #36645] INSTALLATION OF PERL 5.8.7
Gah. The quoting is all getting mangled. Policy on this list, and most public lists online isn't top quoting. So, response after the trimmed quoted text On Tue, Aug 09, 2005 at 05:07:40PM -0700, Brezovec, Dick wrote: So do you have any idea of my the script recommended me to abort because I took all the default settings?? Dick Brezovec Staff Computer Security Analyst Southwest Region VAR/P3/ISM POC Cell: 408-205-9033 Currently working at our San Jose site -Original Message- From: Rafael Garcia-Suarez via RT [mailto:[EMAIL PROTECTED] Sent: Monday, July 25, 2005 2:09 AM To: Brezovec, Dick Subject: Re: [perl #36645] INSTALLATION OF PERL 5.8.7 Brezovec, Dick wrote: You may give one or more space-separated answers, or none if appropriate. A well-behaved OS will have no hints, so answering none or just Policy is a good thing. DO NOT give a wrong version or a wrong OS. Which of these apply, if any? [solaris_2] solaris_8 solaris_8.sh does not exist hint to use instead? [solaris_8] none I think you should try with solaris_2 here. The shell script says : # For consistency with gcc, we do not adopt Sun Marketing's # removal of the '2.' prefix from the Solaris version number. # (Configure tries to detect an old fixincludes and needs # this information.) Usually Configure runs just fine when you accept the defaults. For the original report, you didn't accept the default settings. You forced none where the default for the platform was solaris_2. From the output from Configure you quoted in the original bug report, the last few lines were reporting about a C compiler failure. However, the last line doesn't say that specifically: You have a BIG problem. Shall I abort Configure [y] Probably we should add the text I cannot compile programs with your C compiler to that. Nicholas Clark
Re: [PATCH] Re: [perl ######] perl + gcc-4.0.0 + solaris + gnu binutils
On Wed, Aug 10, 2005 at 09:05:38AM -0400, Andrew Dougherty wrote: On Tue, 9 Aug 2005, Niki Waibel wrote: patch is fine and works ok. although i'd really love to see: a) std configure produced by autoconf b) std makefiles produces by automake c) std handling of libraries (libperl.a/libperl.so.1.0.0) by libtool but maybe that is anyway on the roadmap... I'm not aware of any plans in that direction. Replacing perl's mostly-working build system would be a lot of work, and no one has felt a compelling need. It's on the list somewhere after the regexp engine rewrite, Perl 6 and Parrot. ducks Nicholas Clark PS My real opinion is that it should never be on the to do list, given what people have said about autoconf's failure mode when it guesses wrongly. Also we find at work that once you check entire source trees into a version control system that does not preserve timestamps on checkout, then autotools get very confused.
startperl insanity
This I do not understand. If I change config.sh so that 'startperl' is
something odd that does not m!/perl$! *then*
ext/Devel/DProf/t/DProf.t
lib/h2ph.t
lib/h2xs.t
fail, because they report errors such as:
not ok 3 - running ./perl -I../lib -I../../lib ../utils/h2xs -f -n h2xst
21
# Failed test (lib/h2xs.t at line 168)
# got: 512
# expected: 0
not ok 4 - running ./perl -I../lib -I../../lib ../utils/h2xs -f -n h2xst
21
# Failed test (lib/h2xs.t at line 179)
# got: 'Can't exec /Users/nick/Sandpit/frob/spong at ../utils/h2xs
line 1.
# '
# expected: 'Defaulting to backwards compatibility with perl 5.9.3
which somewhat makes sense, as the #! for dprofpp, h2ph and h2xs is
#!/Users/nick/Sandpit/frob/spong
eval 'exec /Users/nick/Sandpit/blead25277/bin/perl5.9.3 -S $0 ${1+$@}'
if $running_under_some_shell;
If I install /Users/nick/Sandpit/frob/spong then all is happy.
If I change the #! line to a /Users/nick/Sandpit/frob/perl then all is happy.
Is this something to do with:
If the #! line does not contain the word perl, the program named after
the #! is executed instead of the Perl interpreter. This is slightly
bizarre, but it helps people on machines that don't do #!, because they
can tell a program that their SHELL is F/usr/bin/perl, and Perl will then
dispatch the program to the correct interpreter for them.
Is it possible to disable it with a flag?
Or should I just try cutting the code out of ponie.
Nicholas Clark
Re: Encoding iso-8859-16
On Tue, Aug 09, 2005 at 10:58:48AM +0530, Sastry wrote: Hi I get 73 printed on EBCDIC platform. I think it is supposed to print 129 as it is the numeric equivalent of 'a'. -Sastry On 8/8/05, Nicholas Clark [EMAIL PROTECTED] wrote: On your EBCDIC platform, what does this give? It prints 73 use Encode; $string = a; $enc_string = encode(iso-8859-16, $string); print ord ($enc_string), \n; 73. Odd. It should print 97 on all platforms. Because: $string contains 1 byte, the byte that represents 'a' in the platform's default character encoding. The encode call should convert from the default encoding to iso-8859-16 And 'a' in iso-8859-16 is 97. Everywhere. So $enc_string should be a single byte, 97, everywhere. Nicholas Clark
Re: [perl #36839] \xA0 (non-breaking space) does and doesn't match \s
On Mon, Aug 08, 2005 at 04:01:05PM -0700, Christopher J. Madsen wrote: # New Ticket Created by Christopher J. Madsen # Please include the string: [perl #36839] # in the subject line of all future correspondence about this issue. # URL: https://rt.perl.org/rt3/Ticket/Display.html?id=36839 This is a bug report for perl from [EMAIL PROTECTED], generated with the help of perlbug 1.35 running under perl v5.8.6. - [Please enter your report here] I'm not clear on whether the non-breaking space character (\xA0) is supposed to match \s or not, but it certainly shouldn't depend on what other characters are in the string. So this test case: No, I agree that it should not. However, this is *the* unfixable UTF-8 bug in Perl 5 - the fact that 1 bit is used as a flag that both signals buffer is encoded as UTF-8 and string should use Unicode rather than bytes semantics (bytes being ASCII or EBCDIC) It all comes down to the internal representation that the scalar happens to have: $ ./perl -Ilib $_ = \xA0; print Bytes\n if /\s/; utf8::upgrade $_; print UTF-8\n if /\s/; __END__ UTF-8 [well, it might be fixable long term, but an incomplete list of requirements would be: 1: finding another flag bit in every SV 2: a deprecation cycle in 5.10 so it wouldn't be done until 5.12] I think that the best work around would be to normalise all the data you process to UTF-8 representation internally. This will make \s consistent. Nicholas Clark
Re: 5.8.8?
On Tue, Aug 09, 2005 at 11:45:16PM +0200, Rafael Garcia-Suarez wrote: On 8/9/05, Alexey Tourbin [EMAIL PROTECTED] wrote: Okay. My concern is that bugfix changes are not tagged as bufixes (at least as they come through perl5-changes), so there's a chance you can miss the one when there's a lot of them. I should get more verbose in my application logs... (Being more specific, I'm concerned about change #24367 (and also changes #24703 and #24709) that fixes getppid() cache; the change was made before 5.8.7 release and did not find its way into 5.8.7; there's a chance it's not in again if you simply review the changes made after 5.8.7 release.) 5.8.7 slipped quite a bit. I decided that it was better to get it out than try to keep going through the backlog I had already. I will go through the backlog, and it's actually easer to do so, because I don't have a direct record of where 5.8.7's release came - the change messages all sit in a mailbox and get deleted once I've concluded whether they are to be integrated or aren't suitable. Yes, IMO this one should go in maint. Yes, it looks like it should. (But there's looking quickly, and thinking slowly and committing. And I don't think that 11pm is a good time to start the latter) Nicholas Clark
Re: Untested builtins
On Mon, Aug 08, 2005 at 11:46:47AM +0200, Dominic Dunlop wrote: In a trawl through all the .t files in bleadperl for uses (rather than just mentions) of Perl builtins, I find the following are not used: endhostent endnetent endprotoent endservent gethostent getnetbyaddr getnetent getprotobynumber getprotoent getservbyport getservent getsockname getsockopt readpipe seekdir sethostent setnetent setprotoent setservent setsockopt Does anybody know a reason besides nobody got around to it yet for this? For example, if we can't rely on stuff like For some of them (readpipe, seekdir) I'd suspect it's round tuits. (TPF have some, if you need them. Not sure what they'd cost to post) The others might start being fun. Although it might be viable to write tests that start with something simple (eg trying to get 'localhost', if that fails, skip all the tests, else start trying more advanced things) Nicholas Clark
Re: is $[ really deprecated?
On Wed, Aug 03, 2005 at 06:04:44PM -0700, Michael G Schwern wrote: On Thu, Aug 04, 2005 at 12:26:32AM +0200, Abigail wrote: What would the gain be if you remove $[? The ponie guys might find it useful not having to implement it. Nick? Er, mmm. It's probably easier leaving it in. Taking it out would simplify the PMC(s) that replace AVs Taking it out would increase the amount of fork between ponie and 5.9 Nicholas Clark
Re: Encoding iso-8859-16
On Thu, Aug 04, 2005 at 11:51:44AM +0530, Sastry wrote: Hi I am running the following script on EBCDIC use Encode; $string = a; $enc_string = encode(iso-8859-16, $string); print \n String: $string\n; print \n enc_string: $enc_string\n; The output: String: a enc_string: ñ (This is the character for codepoint \xF1 on iso-8859-16) What is the expected output in enc_string? You're doing way too many steps here at once to work out what's going on. On your EBCDIC platform, what does this give? use Encode; $string = a; $enc_string = encode(iso-8859-16, $string); print ord ($enc_string), \n; __END__ Nicholas Clark
Re: Transliteration operator(tr//)on EBCDIC platform
On Thu, Aug 04, 2005 at 11:42:54AM +0530, Sastry wrote:
Hi
I am trying to run this script on an EBCDIC platform using perl-5.8.6
($a = \x89\x8a\x8b\x8c\x8d\x8f\x90\x91) =~ tr/\x89-\x91/X/;
is($a, );
The result I get is
'X«»ðý±°X'
a) Is this happening since \x8a\x8b\x8c\x8d\x8f\x90 are the gapped
characters in EBCDIC ?
I think so. In that \x89 is 'i' and \x91 is 'j'.
b) Should all the bytes in $a change to X?
I don't know. It seems to be some special case code in regexec.c:
#ifdef EBCDIC
/* In EBCDIC [\x89-\x91] should include
* the \x8e but [i-j] should not. */
if (literal_endpoint == 2
((isLOWER(prevvalue) isLOWER(ceilvalue)) ||
(isUPPER(prevvalue) isUPPER(ceilvalue
{
if (isLOWER(prevvalue)) {
for (i = prevvalue; i = ceilvalue; i++)
if (isLOWER(i))
ANYOF_BITMAP_SET(ret, i);
} else {
for (i = prevvalue; i = ceilvalue; i++)
if (isUPPER(i))
ANYOF_BITMAP_SET(ret, i);
}
}
else
#endif
which I assume is making [i-j] in a regexp leave a gap, but [\x89-\x91] not.
I don't know where ranges in tr/// are parsed, but given that I grepped
for EBCDIC and didn't find any analogous code, it looks like tr/\x89-\x91//
is treated as tr/i-j// and in turn i-j is treated as letters and always
special cased
I don't know if tr/i-j// and tr/\x89-\x91// should behave differently
(ie whether we currently have a bug)
Nicholas Clark
Re: 5.8.8?
On Tue, Aug 09, 2005 at 01:02:36AM +0400, Alexey Tourbin wrote: Hello, Does someone integrate bugfixes into 5.8 branch? Me. (except that I've not done anything for about a month. I don't find this worrying, as it's not time for a new maintenance release yet) What if I'm interested in taking partial responsibility for this? Whoever does maintenance tends to be drawn from someone who has already been committing to the development branch. I think that this would be more help would be useful. Actually merging across patches is relatively simple, once the decision is taken about what to merge. I also think that there is considerable potential for confusion with more than one person doing it. Nicholas Clark
Re: 5.8.8?
On Mon, Aug 08, 2005 at 02:38:38PM -0700, Yitzchak Scott-Thoennes wrote: On Mon, Aug 08, 2005 at 10:22:59PM +0100, Nicholas Clark wrote: Whoever does maintenance tends to be drawn from someone who has already been committing to the development branch. I think that this would be more help would be useful. Actually merging across patches is relatively ^than ?? er, oops. I think that this would be *where* more help would be useful (ie the general development track stuff. Particularly actually figuring out the causes of bugs and attempting fixes) simple, once the decision is taken about what to merge. and I notice that about 1 month is actually 2. So it seems that I can't count either. Oops again. Nicholas Clark
Re: Data corruption - [EMAIL PROTECTED] on VMS.
On Sat, Jul 30, 2005 at 12:27:43AM -0400, John E. Malmberg wrote: The address 10439704 was already a part of the structure that Perl_hv_iternext_flags() had pointed a variable named iter at. DBG exam *iter *HV\Perl_hv_iternext_flags\iter xhv_name: 1162633044 xhv_eiter: 4998486 xhv_riter: -256 DBG eval/addr iter-xhv_riter 10439704 It appears to me that one of these structures was not allocated large enough for the data that is being put in it. As the xpvhv_aux structure is a fixed size structure, my suspicion is that the problem is the above code somewhere since this is where the HEK struct is allocated just before *iter got corrupted. However the xpvhv_aux structure is allocated by extending the HV's array of linked list heads, and using space after it. So there is the possibility that there is a code path where the extending realloc() didn't take place, and the memory is being used out-of-bounds. What is the value of sv_flags in the hash? (struct hv, defined in sv.h, typdef'd to HV) Specifically is bit 0x0020 set? It should be, where xpvhv_aux is in use (See the comment near SVf_OOK in sv.h) I'm about to set off to the US for OSCON, so I'm unlikely to be in a position to read mail, let alone respond to it, for over 24 hours. (travel + sleep) Nicholas Clark
Re: [PATCH] Re: [perl #36676] -0.0 printed as 0 on Windows
On Thu, Jul 28, 2005 at 11:07:37AM +0200, H.Merijn Brand wrote: And, knowing that it fails on those platforms, what do you want to do with it? Skip or TODO? I can assure you that no changes will be made for libc in HP-UX 11.00 or below, so the 10.20 failure will stay there till the end of times (unless we work around it in the perl source, which is not worth the trouble if you want my opinion) I think the best we can do is document it as this isn't portable and leave it at that. The behaviour of negative floating point zero is platform specific. For starters, it assumes that your platform's floating point can represent it. Heck, there was a thread a year or two back on perl6-internals where it turned out that the precise choice of CPU instructions by the compiler on one platform affected whether a particular C construction produced positive or negative floating point zero. This was the vendor compiler, not gcc. Nicholas Clark
Re: gmake (perl-5.8.6) fails on z/OS
On Thu, Jul 28, 2005 at 02:37:36AM -0700, rajarshi das wrote:
However, if I change the first instance to :
--- utf8.c 2004-11-17 18:22:09.0 +0530
+++ utf8.c.22005-07-28 13:48:24.0 +0530
@@ -363,6 +363,11 @@ Perl_utf8n_to_uvuni(pTHX_ U8 *s,
STRLEN
warning = UTF8_WARN_EMPTY;
goto malformed;
}
+#ifdef EBCDIC
+if (uv == 0xBA) {
+ uv = NATIVE_TO_UTF(uv);
+}
+#endif
if (UTF8_IS_INVARIANT(uv)) {
if (retlen)
This allows gmake to complete.
Thanks for all your help on this.
Do you have any idea *why* this change makes things work?
Nicholas Clark
Re: [PATCH] perlfunc.pod grammar fixes
On Thu, Jul 28, 2005 at 08:55:17AM +0200, Piotr Fusik wrote: I have doubts about the following changes: Note that a block by itself is semantically identical to a loop -that executes once. Thus Clast can be used to effect an early +that executes once. Thus Clast can be used to affect an early exit out of such a block. -You can effect a sleep of 250 milliseconds this way: +You can affect a sleep of 250 milliseconds this way: On Thu, Jul 28, 2005 at 03:50:57AM -0400, Randy W. Sims wrote: chromatic wrote: On Thu, 2005-07-28 at 00:37 -0700, Michael G Schwern wrote: Note that a block by itself is semantically identical to a loop -that executes once. Thus Clast can be used to effect an early +that executes once. Thus Clast can be used to affect an early exit out of such a block. effect is a noun. affect is a verb so I think this change is correct. It's also a transitive verb, so to effect (some direct object) is valid English, if potentially unclear. Yes, they can both be used as tr verbs, but see usage from http://dictionary.reference.com/search?q=affect Usage Note: Affect and effect have no senses in common. As a verb affect is most commonly used in the sense of to influence (how smoking affects health). Effect means to bring about or execute: layoffs designed to effect savings. Thus the sentence These measures may affect savings could imply that the measures may reduce savings that have already been realized, whereas These measures may effect savings implies that the measures will cause new savings to come about. Which would mean that both proposed changes are indeed incorrect, as they're both obout causing things. Could we change both verbs to cause or create to avoid all confusion? Nicholas Clark
Re: [PATCH] perlfunc.pod grammar fixes
On Thu, Jul 28, 2005 at 11:23:45AM +0100, Steve Hay wrote: I didn't think it was confusing, but that be a minority opinion. Well, it's erudite, eloquent English written by someone with good vocabulary. (Did tchrist write it?) However it seems that 1: If you aren't native speaker, or don't notice these sort of differences, you won't see anything wrong 2: If you notice these differences but don't know the real nitty gritty subtleties, you think that there is something wrong. (I certainly did at first) 3: Only if you already know the subtly do you think it's fine. (but you might need to double take) Hence my suggestion to avoid the problem by not using the verb effect, even when it's correct. Nicholas Clark
Re: RFC: index core pods with X
On Wed, Jul 27, 2005 at 10:07:57AM -0500, Andy Lester wrote: On Tue, Jul 26, 2005 at 06:38:00PM -0700, Michael G Schwern ([EMAIL PROTECTED]) wrote: More importantly, make your source data as exact as possible so the maximum amount of information is available to the user. Case is information. My only concern was false information, such as XOperators instead of Xoperators. This is valid concern. I'd see it as: Proper nouns and terms where cApItAlIsaTiOn is significant really should be put into X as is. Everything else should be lower case. Likewise singular unless the plural is specifically needed. No abbreviations. (Or always be consistent with everything using exactly 1 abbreviation) This lets the search tool decide whether it wants to do case insensitive matching. Rather than giving it no choice. However, I suspect that with a small amount of interactive search and replace we can correct anything needed by a later change of policy on normalisation. So this is a bit of a bikeshed issue. Nicholas Clark
Re: [PATCH] Squish warnings in POSIX.xs
On Wed, Jul 27, 2005 at 11:01:00AM -0500, Steve Peters wrote: POSIX.xs has recently been giving the following warnings: POSIX.xs: In function `XS_POSIX_sigaction': POSIX.xs:1348: warning: comparison of distinct pointer types lacks a cast POSIX.xs:1357: warning: assignment from incompatible pointer type The problem comes with assigning Perl's Sigaction_t to sigaction.sa_handler. It seems to like Cvoid *, so that's what we can give it. It's paassing its tests from what I can see, but we'll see how the smokes do on platforms other than Linux and OpenBSD. Casting pointers to functions to pointers to data isn't conformant ANSI C. Offhand I can't remember which platform(s) dislike this. Nicholas Clark
Re: RFC: index core pods with X
On Wed, Jul 27, 2005 at 03:55:45PM -0400, Ivan Tubert-Brohman wrote: Nicholas Clark wrote: The proposal seems very well thought through, and I'd be very happy to see you start on this soon. I'd hope that you'd soon attract volunteers to help, but as you rightly say, only time will tell. I've been contacted by a couple of willing volunteers. I just have a silly question before we start: which version of the pods should we patch? bleadperl? perl-5.8.7? bleadperl please. I merge the documentation changes across. (Just like anything else) Nicholas Clark
Re: bareword test on ebcdic.
On Tue, Jul 26, 2005 at 08:48:10AM -0700, rajarshi das wrote:
For the code points being tested
(\x{0442}\x{0435}\x{0441}\x{0442})
does the perl source file contain the correct byte
sequence in UTF-EBCDIC?
Yes it does, since I ran the test,
if (($hash{\x{0442}\x{0435}\x{0441}\x{0442}}) eq
($hash{eval '\x{0442}\x{0435}\x{0441}\x{0442}'}))
print ok\n;
and the test ran fine, if that is what you mean by the
source file containing the correct byte sequence. Or
am I mistaken ?
You are mistaken, I'm afraid. bareword means no quotes.
In ASCII UTF-8 land, the 1 liner
$ perl -le 'use utf8; $a{ඬ}++; print map {ord} keys %a'
gives
3500
The 3 bytes in the source code between '{' and '}' are 224, 182 and 172
which are the UTF-8 encoding for the code point 3500.
My question is, what are the bytes in UTF-EBCDIC that encode code point 3500?
If you put those 3 bytes directly between the '{' and '}' characters in
the EBCDIC version of that 1 liner, does it also print 3500?
If so, *that* would explain the failures, and be the
thing that needs
correcting. The test file would need if/else with a
different test on EBCDIC.
what would you suggest be put in the if/ else ?
I think that the regression tests tended to do something like
if (ord 'A' == 65) {
# Do the ASCII/UTF-8 version
} else {
# Assume EBCDIC
}
Nicholas Clark
Re: gmake (perl-5.8.6) fails on z/OS
On Tue, Jul 26, 2005 at 07:22:55AM -0700, rajarshi das wrote: Hi, I made the following modifications to utf8.c : #ifdef EBCDIC uv = NATIVE_TO_UTF(uv); #endif Where in utf8.c? Your description of what you changed is inadequate for anyone else to understand the context of your change. I tried redoing it with a clean build, but it still fails. Why does configpm generate errors ? I don't know. I don't fully understand the workings of how perl's UTF-8 implementation is supposed to work on EBCDIC platforms. 1: Is that the only change you've made to the source code? 2: Without that change, how does your build fail? How do the errors differ? Nicholas Clark
Re: bareword test on ebcdic.
On Tue, Jul 19, 2005 at 12:06:55AM -0700, rajarshi das wrote:
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 ?
Well, no, because then it won't be a bareword.
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 ?
You might be better just skipping the test if you can't make it work.
Although it would be better if you could figure out why.
The whole point of the test is to verify that barewords work correctly,
and changing it to a non-bareword defeats the purpose of the test.
Nicholas Clark
Re: bareword test on ebcdic.
On Tue, Jul 26, 2005 at 08:12:16AM -0700, rajarshi das wrote:
I basically want to know if there are alternate ways
of representing barewords (as I mentioned in question
2) above) ?
No. By definition there can not be.
You're failing to grasp what is meant by bareword.
There is only one representation.
Also, any pointers that you have regarding where to
look to fix this ?
Not much better than in toke.c or utf8.c
However, based on a comment I've spotted at the top of utfebcdic.h *think*
that the internal encoding of perl on an EBCDIC system is UTF-EBCDIC rather
than UTF-8. The byte sequence in the source file for the bareword will need
to be valid UTF-EBCDIC.
For the code points being tested (\x{0442}\x{0435}\x{0441}\x{0442})
does the perl source file contain the correct byte sequence in UTF-EBCDIC?
Does the byte sequence in UTF-EBCDIC for those 4 code points differ from the
byte sequence in UTF-8?
Does the source file happen to have the UTF-8 byte sequence?
If so, *that* would explain the failures, and be the thing that needs
correcting. The test file would need if/else with a different test on EBCDIC.
Nicholas Clark
Re: gmake (perl-5.8.6) fails on z/OS
On Tue, Jul 26, 2005 at 07:55:21AM -0700, rajarshi das wrote:
The change is in the fn Perl_utf8n_to_uvuni :
---
.
#define UTF8_WARN_LONG 8
#define UTF8_WARN_ 9 /*
Also FFFE. */
if (curlen == 0
!(flags UTF8_ALLOW_EMPTY)) {
warning = UTF8_WARN_EMPTY;
goto malformed;
}
#ifdef EBCDIC /* the change */
uv = NATIVE_TO_UTF(uv);
#endif /* the change ends here */
if (UTF8_IS_INVARIANT(uv)) {
if (retlen)
*retlen = 1;
return (UV) (NATIVE_TO_UTF(*s));
}
...
A context or unified diff with the original source would have been clearer,
at least in part because most people on the list are used to it.
I don't understand this code, so I don't know why. I think that part of the
reason that you're getting few to no responses to your questions is because
few people understand this code in the first place, and none of them
understand how it interacts with EBCDIC.
The only thing I can think of is that I notice that further down that function
there is:
#ifdef EBCDIC
uv = NATIVE_TO_UTF(uv);
#else
if ((uv == 0xfe || uv == 0xff)
!(flags UTF8_ALLOW_FE_FF)) {
warning = UTF8_WARN_FE_FF;
goto malformed;
}
#endif
Is that second call to NATIVE_TO_UTF still present in your modified code?
Nicholas Clark
Re: wantarray() description in perlfunc as of v5.8.7
On Tue, Jul 26, 2005 at 06:29:57PM +0200, Flavio Poletti wrote:
The obscure passage is the following:
wantarray()'s result is unspecified in the top level of a file,
in a BEGIN , CHECK , INIT or END block, or in a DESTROY method.
All make sense to me except top level of a file, which is obscure IMHO.
Could it be explained more in depth? My very issue regards the use of do
on a file: it currently seems to support wantarray correctly even in the
top level of a file (example at
http://www.perlmonks.org/?node_id=477801), but I'd like to know if this
still falls in the unspecified behaviour warning and, if yes, why.
Unfortunately, my Perl Powers are too weak for me to propose something
100% correct and clear. But I want to be proactive and try to propose to
change file into program:
wantarray()'s result is unspecified in the top level of a program,
in a BEGIN , CHECK , INIT or END block, or in a DESTROY method.
I find that more ambiguous. To me, programs can span more than one file,
so the top level to me would mean just the perl file passed as an argument
to the interpreter.
Would a clarification work?
In effect, wantarray is only specified within subroutines/methods defined
using the Csub keyword, with the exception of implicit calls to DESTROY.
I was going to say places you can call and get a value returned from, but
IIRC you can return a value from a file, which Cdo will return you.
So is wantarray's value is only specified within a subroutine or method
which was called directly by other perl code true?
(And then list the exceptions as the interpreter's implicit calls to
BEGIN ... blocks, DESTROY methods, and any other file loaded by
do/require/use)
Is the current documentation actually *wrong*. In that the unspecified-ness
propagates? ie the documentation says that this wantarray is specified:
$ perl -lwe 'sub a {print =, wantarray}; BEGIN {a}'
=
But I think that actually it's not.
Note that you can still get a context in the top level of a file
when you use Cdo 'file.pl';. In this case, in fact, the code inside
Ifile.pl is provided a context according to the call to Cdo:
my @a = do 'file.pl'; # array context provided
my $s = do 'file.pl'; # scalar context provided
do 'file.pl'; # void or external context provided
Dealing with context, these calls to Cdo 'file.pl' are equivalent
to sub calls; the last line, for example, could inherit the context
when called as the final statement of a sub or of a file.
I think that the documentation was attempting to say that we specifically
don't guarantee that this context will remain the same in future perl
versions. So don't rely on it.
Nicholas Clark
Re: RFC: index core pods with X
I've re-ordered bits of your message to group parts On Tue, Jul 26, 2005 at 02:52:47PM -0400, Ivan Tubert-Brohman wrote: First, a definition. By scope, I mean the part of the document that is deemed relevant to an index entry, and that may be extracted and shown in isolation by a processing or display tool. For example, perldoc -f considers the scope of a function to end at the beginning of the next =item, or at the end of the enclosing =over. * There's no limitation as to the number of times that a given entry can appear in a document or collection of documents. That is, it is not an error to have Xwhatever appear twice in the same file. This means that if two or more adjacent paragraphs are needed to make sense, it's no problem under the scope rules - just mark both. Currently it is used in only *one* place in the perl documentation: pod/perlfunc.pod uses it for the -X filetest operators. * It should be considered case-insensitive. This would lead to some ambiguities: -b File is a block special file. -B File is a binary file (opposite of -T). -c File is a character special file. -C Same for inode change time (Unix, may differ for other platforms) -s File has nonzero size (returns size in bytes). -S File is a socket. -t Filehandle is opened to a tty. -T File is an ASCII text file (heuristic guess). I'm not sure if this is really a problem Perl comes with over 100 files in the pod/ directory, totaling over 100,000 lines of POD. Obviously, indexing all of it by hand is a very large task, so the question arises as to who will do it. If people agree that this is a good idea and are willing to apply the patches, I could lead the project, and hope to attracting volunteers. In the worst case (no one else is willing to help), I believe that even if I can't index *all* of the pods, a partial index is better than no index at all. I would start with the documents that I consider more important, such as perlop, perlsub, perlre, perlobj, etc. Documents such as perldelta* and the faqs probably don't need indexing that much. Potentially the faqs do. The deltas might benefit from it, particularly if searching for a topic on a recent set of documentation brings up an important bug fix in a specific version of perl, and the user realises that there perl is older than this. The proposal seems very well thought through, and I'd be very happy to see you start on this soon. I'd hope that you'd soon attract volunteers to help, but as you rightly say, only time will tell. Nicholas Clark
Re: gmake (perl-5.8.6) fails on z/OS
On Tue, Jul 26, 2005 at 08:34:02AM -0700, rajarshi das wrote: Yes, the second call to NATIVE_TO_UTF is still present in the modified code. Typically, one wouldnt want to do a NATIVE_TO_UTF(NATIVE_TO_UTF(uv)) which is what I am doing due to the second call. But does that make a difference to miniperl ? Well, the code is linked into miniperl, so I can only assume that it's getting called. If so, does removing the second instance of NATIVE_TO_UTF() improve things? Nicholas Clark
Re: wantarray() description in perlfunc as of v5.8.7
On Tue, Jul 26, 2005 at 11:27:05PM +0100, Dave Mitchell wrote: A quick look at the src shows that it scans back through the current context stack for an eval, sub or format. From this perspective, a require or do file is an eval. If it it fails to find one, it returns undef. It doesn't scan previous context stacks, so it wont backtrack through magic, tie, overload etc. Oh. Interesting. I had a chat with Robin Houston (author of Want) about this. Robin says that Want can't scan back past a tie, because the information it would need is in a local variable in a C function. (He was telling me this. I think he told me which function, but it wasn't all sinking in, as things have been a bit http://www.flickr.com/photos/twoshortplanks/28698637/ recently *) Would the core not being able to scan back past tie/overloading/magic/etc be a bug that needs addressing? Nicholas Clark * to avoid confusion I should clarify that that photo was from the meeting on Monday. I was talking with Robin at the meeting on Thursday. ** to avoid distress I should clarify further that neither copenhagen.pm nor the state of the glass have anything to do with the aargh. Nor does any open source code. We know where the code in question lives, and its days are numbered. :-)
Re: perlfunc sez crypt() encrypts... but it doesn't.
On Sun, Jul 24, 2005 at 11:17:10PM -0400, Garry Williams wrote: On Sun, 2005-07-24 at 21:59 -0500, David Nicol wrote: How about using the word obfuscate? It's a nice word Eschew obfuscation. perl -MCPAN -einstall B::Deobfuscate Nicholas Clark
Re: Smoke [5.9.3] 25217 FAIL(F) hp-ux 10.20 (PA-2.0/32/1 cpu)
On Mon, Jul 25, 2005 at 02:42:25PM +0200, H.Merijn Brand wrote: On Mon, 25 Jul 2005 08:44 +0200, H.Merijn Brand [EMAIL PROTECTED] wrote: Failures: (common-args) none [stdio/perlio/univ.utf8] [stdio/perlio/univ.utf8] -DDEBUGGING [stdio/perlio/univ.utf8] -Duseithreads [stdio/perlio/univ.utf8] -DDEBUGGING -Duseithreads ../ext/POSIX/t/sigaction.t..FAILED 26-30 Change 25223 by [EMAIL PROTECTED] on 2005/07/25 11:47:03 use POSIX might not throw an error. Check for useful values also Why doesn't it? Is this a different bug? eval 'use POSIX qw(%SIGRT SIGRTMIN SIGRTMAX); SIGRTMIN + SIGRTMAX'; skip(no SIGRT signals, 4) if $@; ok(SIGRTMAX SIGRTMIN, SIGRTMAX SIGRTMIN); --- eval 'use POSIX qw(%SIGRT SIGRTMIN SIGRTMAX); SIGRTMIN() + SIGRTMAX()'; skip(no SIGRT signals, 4) if $@ || SIGRTMIN() 0 || SIGRTMAX() 0; ok(SIGRTMAX() SIGRTMIN(), SIGRTMAX SIGRTMIN); Or is it successfully exporting SIGRTMIN and SIGRTMAX, and the constants both have the value -1? Nicholas Clark
Re: [EMAIL PROTECTED] on OpenVMS (not good)
On Sat, Jul 23, 2005 at 03:36:39PM -0400, John E. Malmberg wrote: How do I reproduce this? I pulled down perl-5.9.2 and started a build and it fails with: CC/DECC/NOANSI_ALIAS /Include=[]/Standard=Relaxed_ANSI/Prefix=All/Obj=.obj/List #$d_sitecustomize USE_SITECUSTOMIZE /**/ .^ %CC-W-BADDIRECTIVE, $d_sitecustomize is an invalid preprocessor directive, an at line number 3462 in file PERL_BUILD_ROOT:[00]config.h;1 %MMK-F-ERRUPD, error status %X10B91260 occurred when updating target MINIPERLMA 23-JUL-2005 15:28:53 The perl 5.9.2 release is now somewhat out of date. That bug has been fixed. And new ones introduced instead :-( The best way to get the current source is with rsync. The master source repository is in perforce, and there isn't anonymous access to that. We don't tend to make snapshots, I think partly because everyone actively developing is very happy with rsync, and partly because snapshots seem to generate near zero feedback, suggesting the time is better spent elsewhere. (I suspect that the widespread use of rsync helps explain the lack of interest in specific snapshots. In effect every commit gets treated like a snapshot) There are a few paragraphs on what can be got with rsync in perlhack.pod: http://search.cpan.org/~rgarcia/perl-5.9.2/pod/perlhack.pod#Keeping_in_sync but most simply if you run rsync -avz rsync://ftp.linux.activestate.com/perl-current/ perl/ you will get a local directory perl/ containing the current development sources. If you build that you should see the same problems as Abe is reporting. Nicholas Clark
Re: [PATCH] blead help for VMS
On Sun, Jul 24, 2005 at 03:31:55PM -0500, Craig A. Berry wrote: The attached patch (plus one additional step) gets bleadperl building on VMS again. The additional step is renaming the directory ext/Compress/Zlib/zlib-src-1.2.3 to ext/Compress/Zlib/zlib-src which I assume needs to be done in Perforce. The related changes to $ p4 help rename rename -- How to rename files p4 integrate from to p4 delete from p4 submit Perforce does not support a single 'rename' command, but files can be renamed by branching one file into another and then deleting the original file. The 'from' and 'to' file arguments may include wildcards as long as they are matched. Integrating from files require read access to the files, but deleting them requires write access. For further information, see the help for the individual commands. And what it doesn't state explicitly is that you're renaming files, not directories, so you then have to use perforce wildcards, ie: $ cd ext/Compress/Zlib/ $ p4 integrate zlib-src-1.2.3/... zlib-src/... $ p4 delete zlib-src-1.2.3/... Thanks, applied (25217) Nicholas Clark
Re: [PATCH] Re: [EMAIL PROTECTED] on OpenVMS (not good)
On Sun, Jul 24, 2005 at 05:47:26PM -0500, Craig A. Berry wrote: And this should take care of it. Accidentally left out of my patch of two hours ago. Thanks applied (25218) Nicholas Clark
Re: What's holding up mainperl from upgrading MakeMaker?
On Sat, Jul 23, 2005 at 05:23:33AM -0700, Michael G Schwern wrote: I see maintperl is still using MakeMaker 6.17. What's keeping it from using 6.30? I think that the problem was that MakeMaker 6.30 can't build SDBM_File on VMS. However, VMS is currently failing to build even miniperl, due to its C compiler being more stringent about const consistency than anything else on the planet. Nicholas Clark
Re: [perl #36634] Taking last element of an empty slice by putting it in scalar context. 5.8.2
On Fri, Jul 22, 2005 at 07:04:52PM -0400, Joshua Juran wrote: in v5.8.1-RC3 built for darwin-thread-multi-2level (with 1 registered patch), and a=7 b=UNDEFINED b=UNDEFINED b=UNDEFINED b=UNDEFINED in v5.8.7 built for i386-linux-thread-multi. In other words, it appears to have been fixed. It seems to have been fixed between 5.8.5 and 5.8.6. Which I guess is fortunate, because it would mean that upgrading to OS X 10.4 will solve the problem with /usr/bin/perl, if you're not in a position to install your own perl in /usr/local Nicholas Clark
