Philip M. Gollucci wrote:
> Philip M. Gollucci wrote:
>
>> Philippe M. Chiasson wrote:
>> Ah, I did miss it... read right over it. D'oh!
>>
> Here is its again with the return 0 left in as most of the code in
> Build.pm is return 0 though not all.
> Also, using Philippe's cmp_tuples function.
Loo
Philip M. Gollucci wrote:
Philippe M. Chiasson wrote:
Ah, I did miss it... read right over it. D'oh!
Here is its again with the return 0 left in as most of the code in Build.pm is
return 0 though not all.
Also, using Philippe's cmp_tuples function.
Index: Build.pm
===
Philippe M. Chiasson wrote:
That was by design, to keep the behaviour of <=> or cmp
You must have missed this bit:
return cmp_tuples([EMAIL PROTECTED], [EMAIL PROTECTED]) == 1;
Where I specifically check that @tuples is greater than @r_tuples.
Figured this cmp_tuples() migth also be used to
Philip M. Gollucci wrote:
> Philippe M. Chiasson wrote:
>
>> Isn't "return;" the more canonical way of returning false ?
>
> Beats me... I know a lot of the mp2 code particular Apache2::Status as I
> was just digging in there uses return 0. I really have no preference.
Just looked around the ex
[EMAIL PROTECTED] wrote:
>>>Isn't "return;" the more canonical way of returning false ?
>>
>>Beats me... I know a lot of the mp2 code particular Apache2::Status as I
>
>
> was just digging in there uses return 0. I really have no preference.
>
> Just a note, the new "Perl Best Practices" Dam
> > Isn't "return;" the more canonical way of returning false ?
> Beats me... I know a lot of the mp2 code particular Apache2::Status as I
was just digging in there uses return 0. I really have no preference.
Just a note, the new "Perl Best Practices" Damian Conway, suggest a bare
return is be
Philippe M. Chiasson wrote:
Isn't "return;" the more canonical way of returning false ?
Beats me... I know a lot of the mp2 code particular Apache2::Status as I
was just digging in there uses return 0. I really have no preference.
Minor nit, but wouldn't
my @tuples = split /\./, $has_versi
Philip M. Gollucci wrote:
> Philippe M. Chiasson wrote:
>
>> A better patch might be to first check if we already have that option
>> from Perl,
>> otherwise, try and figure out if it's safe to add it ourselves.
>
> Okay, as requested, I've functionalized this and added a check to make sure
> $cc
Philippe M. Chiasson wrote:
A better patch might be to first check if we already have that option from Perl,
otherwise, try and figure out if it's safe to add it ourselves.
Okay, as requested, I've functionalized this and added a check to make sure
$ccopts doesn't already contain this compile fl
Philip M. Gollucci wrote:
>> I am not so surprised ;-) I've seen patches take many more iterations
>> than this one before going thru. It's one way to keep the codebase
>> clean and concise (and hopefully bug-free).
>
> Before I rip more of my hair out, I believe this whole thread is going
> to be
I am not so surprised ;-) I've seen patches take many more iterations
than this one before going thru. It's one way to keep the codebase
clean and concise (and hopefully bug-free).
Before I rip more of my hair out, I believe this whole thread is going
to be moot. *sigh*.
Explanation:
svn co ..
Philip M. Gollucci wrote:
> Third and final take. No objects and I'll commit. I combined all 3 of
> the verions. :) Who would have thought something so small would take so
> long?
I am not so surprised ;-) I've seen patches take many more iterations
than this one before going thru. It's one way
Third and final take. No objects and I'll commit. I combined all 3 of
the verions. :) Who would have thought something so small would take so
long?
===
--- lib/Apache2/Build.pm(revision 230957)
+++ lib/Apache2/Build.pm
13 matches
Mail list logo
