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:[EMAIL PROTECTED]]
> > > 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
> > > 
> > 
> 

Reply via email to