Front page | perl.vmsperl |
Postings from October 2002
RE: MMK + 7.3-1 = :-( [was Re: Problem building Perl]
Thread Next
From:
Henderson, Jordan
Date:
October 4, 2002 06:53
Subject:
RE: MMK + 7.3-1 = :-( [was Re: Problem building Perl]
Message ID:
C02C9AA5C528D411A7840060B057CE010641A8F2@DAYNT1
Peter,
Failing at test 2 in t/pod/find, huh?
That's the same place that I had a failure that is discussed in the attached.
Haven't gotten around to putting together a patch yet.
Could you try that code change to the test recommended in the attached email and
see if this corrects it? It was a great puzzle to me that I was the only one
experiencing this behavior from what I believe is an improper use of Perl's
grep.
Jordan Henderson
Defense Automatic Addressing System Center
WPAFB, OH
DSN: 986 3804
Commercial: (937) 656 3804
Instead of getting married again, I think I'll just find a woman I don't like
and give her a house.
-Steven Seagal
> -----Original Message-----
> From: PPrymmer@factset.com [mailto:PPrymmer@factset.com]
> Sent: Thursday, October 03, 2002 10:29 PM
> To: Craig A. Berry
> Cc: steve@wcslnet.co.uk; vmsperl@perl.org
> Subject: Re: MMK + 7.3-1 = :-( [was Re: Problem building Perl]
>
>
>
> Craig Berry wrote:
>
> !Until then, if anyone would like to remind me how this is done or
> !have a crack at it, please do. In the meantime I think the
> !workaround is to use MMS or build on 7.3 or earlier.
>
> I can confirm that with MMS V3.2-01 using a compiler/OS of:
>
> DEC C V6.0-001 on OpenVMS Alpha V7.3-1
>
> that it is possible to build unpatched Perl 5.8.0 on an ODS-2
> volume on a fibre channel SAN.
>
> MMS test reported these failures:
>
> lib/File/Find/t/find.................FAILED at test 1
> lib/File/Find/t/taint................FAILED at test 1
> lib/Net/hostent......................FAILED at test 5
> t/pod/find...........................FAILED at test 2
> Failed 4 test scripts out of 636, 99.37% okay.
>
> The hostent.t failure is due to the Multinet V4.3
> bug h_length bug for which we have not yet
> applied the ECO from Process.
>
> In your message you mentioned what appeared to be an
> old copy of MMK. I should point out to this list that
> Matt Madison was kind enough to fix some directory
> recursion bugs in MMK recently for me (the bugs
> rendered emacs 21.2 unbuildable - it uses recursive
> MMK and is far from releasable yet).
>
> At any rate MMK users may want to upgrade, I have:
>
> $ mmk /ident
> %MMK-I-IDENT, this is the MadGoat Make Utility V3.9-3
> -MMK-I-COPYRIGHT, Copyright (c) 1992-2002, MadGoat Software. All Rights
> Reserved.
>
> But I have not yet attempted to be perl 5.8.0 on
> VMS V7.3-1 with that utility yet. I'll try to report
> back.
>
> Peter Prymmer
>
>
-----
Message-ID: <C02C9AA5C528D411A7840060B057CE010641A7CD@DAYNT1>
From: "Henderson, Jordan" <jhenderson@daas.dla.mil>
To: "Henderson, Jordan" <jhenderson@daas.dla.mil>, "'Craig A. Berry'"
<craigberry@mac.com>
Cc: "'Vmsperl (E-mail)'" <vmsperl@perl.org>
Subject: RE: Building 5.8.0 problem
Date: Wed, 18 Sep 2002 17:04:02 -0400
X-Mailer: Internet Mail Service (5.5.2656.59)
OK, I almost got a clean build and test on this platform. This platform being:
DEC C V6.0-001 on OpenVMS Alpha V7.3
MMS 3.3
I got this one test failure, and I'm not sure what's going on here.
It's a failure in t/pod/find, #2.
I spy what I think is a problem with the test, but maybe I'm confused. Here's
the an extract from t/pod/find.t (lines 41 through 55):
---
if ($^O eq 'VMS') {
$compare = lc($compare);
$result = join(',', sort values %pods);
my $undollared = $Qlib_dir;
$undollared =~ s/\$/\\\$/g;
$undollared =~ s/\-/\\\-/g;
$result =~ s/$undollared/pod::/g;
my $count = 0;
my @result = split(/,/,$result);
my @compare = split(/,/,$compare);
foreach(@compare) {
$count += grep {/$_/} @result;
}
ok($count/($#result+1)-1,$#compare);
}
---
Now, my debuggin shows $count == 0, even though I do show that the string in $_
at line 52 is in @result. Now, grep modifies $_ with the elements found in
@result. Is this potentially undefined behavior? 'perldoc -f grep' says:
grep BLOCK LIST
grep EXPR,LIST
This is similar in spirit to, but not the same as,
grep(1) and its relatives. In particular, it is
not limited to using regular expressions.
Evaluates the BLOCK or EXPR for each element of
LIST (locally setting $_ to each element) and
returns the list value consisting of those ele-
ments for which the expression evaluated to true.
In scalar context, returns the number of times the
expression was true.
@foo = grep(!/^#/, @bar); # weed out comments
or equivalently,
@foo = grep {!/^#/} @bar; # weed out comments
Note that $_ is an alias to the list value, so it
can be used to modify the elements of the LIST.
While this is useful and supported, it can cause
bizarre results if the elements of LIST are not
variables. Similarly, grep returns aliases into
the original list, much as a for loop's index
variable aliases the list elements. That is, mod-
ifying an element of a list returned by grep (for
example, in a "foreach", "map" or another "grep")
actually modifies the element in the original
list. This is usually something to be avoided
when writing clear code.
See also "map" for a list composed of the results
of the BLOCK or EXPR.
So, $_ above is first aliased to an element of @compare and then it gets aliased
to an element of @result. Tricky. If these things aren't done in the "right"
order (what order is right?), then bazaare things could happen.
if I change the foreach loop to:
---
foreach $compare (@compare) {
$count += grep {/$compare/} @result;
}
---
It seems to work. I think the test here is passing, there's no problem with the
pods or their locations, but the test depends on undefined behavior. Or,
perhaps grep is broken in my copy of 5.8.0?
I could put together a real bug report on this, but I thought I'd bounce it off
of vmsperl first.
-Jordan Henderson
If you require contact information, please request it via return email.
If we're not supposed to eat animals, then why are they made out of meat?
-Anonymous
> -----Original Message-----
> From: Henderson, Jordan
> Sent: Wednesday, September 18, 2002 2:50 PM
> To: Henderson, Jordan; 'Craig A. Berry'
> Cc: 'Vmsperl (E-mail)'
> Subject: RE: Building 5.8.0 problem
>
>
> Well, I decided to get back to checking out my build
> problems. More questions, less answers.
>
> I decided that a good way to go about it would be to take out
> all my special logicals and symbols and try again. I was
> sure that this would take care of the problem I found where
> my HOME logical was causing problems and it might knock out
> or help localize some of the others.
>
> I tried a build with a fresh directory hierarchy, both
> '@CONFIGURE "-des"' and running CONFIGURE and answering the
> questions, and I'm getting the same problem I had before with
> the missing ENCODE.C file. I did remember checking account
> quotas, but I'll check again. I bet the problems there are
> related to quotas somehow, as this machine has never been
> used for production, or even much development so the setup
> may not be as checked out as they are elsewhere.
>
> In the meantime, I moved my development/testing efforts over
> to another, much slower, machine that has MMS installed. I'm
> building there now and I'm into the 'MMS test' now, which
> seems to be going well.
>
>
>
>
> -Jordan Henderson
> If you require contact information, please request it via
> return email.
>
> If we're not supposed to eat animals, then why are they made
> out of meat? -Anonymous
>
>
>
>
>
>
>
>
> > -----Original Message-----
> > From: Henderson, Jordan
> > Sent: Tuesday, August 20, 2002 10:34 PM
> > To: 'Craig A. Berry'
> > Cc: Vmsperl (E-mail)
> > Subject: RE: Building 5.8.0 problem
> >
> >
> >
> > I'm going to skip this research as it seems to be building
> > correctly with the new MMK.
> >
> > I did see a test failure fly by a minute ago, but only one I
> > recall seeing. Pretty smooth sailing right now.
> >
> > Thanks for the pointer on the updated MMK. I do have a
> > recent MMS on another machine, but as I said, I'll skip the
> > research on problems I no longer have.
> >
> >
> > Jordan Henderson
> > Policy prohibits the inclusion of contact information in
> > email signature blocks. Please request contact information
> > via return email if you require it.
> >
> > I am fused, just in case I Blow Out. -Thom E. Yorke
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > > -----Original Message-----
> > > From: Craig A. Berry [mailto:craigberry@mac.com]
> > > Sent: Tuesday, August 20, 2002 10:29 PM
> > > To: Henderson, Jordan
> > > Cc: Vmsperl (E-mail)
> > > Subject: Re: Building 5.8.0 problem
> > >
> > >
> > > Henderson, Jordan wrote:
> > > > Hmmm... No line as you describe in the vicinity of the error:
> > >
> > >
> > > > CC/DECC
> > > /Include=[]/Standard=Relaxed_ANSI/Prefix=All/Obj=.obj
> > > /NOANSI_ALIAS/floa
> > > >
> > > t=ieee/ieee=denorm_results/Define=("VERSION=""1.22""","XS_VERS
> > > ION=""1.22""")/Inc
> > > > lude=([---],[-.Encode])/NoList SYMBOL.c
> > > > %MMK-F-NOACTION, actions to build SYMBOL_T.OBJ unknown
> > >
> > > Well, at least we do see errors well upstream from where we
> > > were before.
> > > This is *very* strange, Jordan. It has just compiled a .C
> > > file and then
> > > the next thing it does is complain that it does not know
> > the rule for
> > > converting a .C into a .OBJ! If you have MMS, give it a shot
> > > and see if
> > > anything different happens.
> > >
> > > Do check process quotas and such. I think MMK
> communicates to its
> > > subprocess through a mailbox and it wouldn't be at all hard
> > > to blow your
> > > BYTLM among other things. Here's what I've got:
> > >
> > > $ sh process/quota
> > >
> > > 20-AUG-2002 21:22:32.61 User: CRAIG Process ID:
> > > 00000238
> > > Node: BRIANA Process
> > > name: "_FTA2:"
> > >
> > > Process Quotas:
> > > Account name: CAB
> > > CPU limit: Infinite Direct I/O limit:
> > > 150
> > > Buffered I/O byte count quota: 99808 Buffered I/O
> > > limit: 150
> > > Timer queue entry quota: 10 Open file quota:
> > > 200
> > > Paging file quota: 196352 Subprocess quota:
> > > 10
> > > Default page fault cluster: 64 AST quota:
> > > 248
> > > Enqueue quota: 2000 Shared file
> > > limit: 0
> > > Max detached processes: 0 Max active jobs:
> > > 0
> > >
> > > Soft CPU Affinity: off
> > >
> >
>
Thread Next