SPUG: Strange code effect

Joseph Werner telcodev at gmail.com
Wed Dec 23 15:27:42 PST 2009 

On Wed, Dec 23, 2009 at 2:52 PM, Skylos <skylos at gmail.com> wrote:
> ...
> Which makes me think "something about that value when a shift is done uses
> the value in a boolean context"
> ...

Thanks for the feedback Skylos, This is exactly the same conclusion
that we have come too; but I STILL cannot place a boolean context in
the a simple shift assignment. The powers that be crack the whip and
say "Problem solved, move on".   Code that does not behave the way I
expect it to bothers me...

Saltbreez

On Wed, Dec 23, 2009 at 2:52 PM, Skylos <skylos at gmail.com> wrote:
> Thats interesting.
>
> So something I had considered when you described the problem initially -
>
> Hm, he's using overrides - that has peril because you are inserting yourself
> inside of system operations on your data type.  If he was crashing in his
> override... or didn't define a needed one a null pointer might do that...
> but naw, the default behavior should be intact if you don't custom define an
> override... so that couldn't be the problem
>
> - was wrong, because the boolean override changed it.
>
> Which makes me think "something about that value when a shift is done uses
> the value in a boolean context"
>
> Exactly what it is about a shift that initiates a boolean context - and why
> failure to define an override bypassed the normal behavior - isn't clear to
> me.  But it makes perfect sense to me.  Context is an unintuitive matter at
> times - sometimes you use values in a context without realizing because the
> context is implicit - for instance, anything in the final position of a
> block has the context of the block itself.  I've gone so far as to do
> <operation that returns an object>; return (); } at the end of a block
> explicitly to keep the returning operation in a void context, thus keeping
> the value to myself.  I wouldn't normally, but in this case it is an object
> that absolutely must be destroyed at the exit of this block.  To have it be
> intercepted would lead to undefined operation within my system.  Kind of
> like resurrecting a destroyed object with funky DESTROY subs.
>
> It may be that the boolean expression evaluation within the shift routine is
> purposeful - or it may merely be a side effect of some sequence that put the
> object value into a boolean context somewhere.
>
> Skylos
>
> "If only I could get rid of hunger by rubbing my belly" - Diogenes
>
>
> On Wed, Dec 23, 2009 at 2:21 PM, Joseph Werner <telcodev at gmail.com> wrote:
>>
>> Hey Ben,
>>
>> Thanks for the feedback!
>>
>> First, let me bring you up to current status. I attempted to
>> construct, by building up to, the problem. This attempt failed to
>> reproduce the central first issue: why was I unable to shift the
>> object off of the array? However, it did answer the second question:
>> The object failed to respond in a boolean context because one
>> overloaded operator had been declared, but neither bool nor stringify
>> had been declared. STRANGER still,  fixing the second problem [bool
>> overload] made the first [shift from array]  problem disappear. I
>> STILL cannot connect the two. Anyhow, problem solved, but the central
>> question remains unanswered.
>>
>> No, we are not using Apache. Wish we were. I tread a tightrope of my
>> nondisclosure commitments, but I can say: we use thin servers, what I
>> have com to call 'campstove' servers [all the expectations of Apache
>> in 2,000 lines of code or less] and due to the environment in which
>> the server runs, either the crashes produce output to a log file, or
>> we never see it.
>>
>> See additional comments below.
>>
>> On Wed, Dec 23, 2009 at 12:36 PM, BenRifkah Bergsten-Buret
>> <mail.spammagnet at gmail.com> wrote:
>> > See comments below.
>> >
>> > On Tue, Dec 22, 2009 at 8:49 PM, Joseph Werner <telcodev at gmail.com>
>> > wrote:
>> >>
>> >> Hey guys [and gals],
>> >>
>> >> I encountered a strange Perl code phenomenon dealing with some object
>> >> references, and and array of object references. Specifically, I could
>> >> not shift a reference to an object off of an array of object
>> >> references. More troubling, I also was unable to use the object
>> >> references in a boolean context. I have written code very similar to
>> >> this dozens if not hundreds of times and never encountered this type
>> >> of problem...
>> >>
>> >> The code is all proprietary,  and the powers that be frown on release
>> >> of any sort, so I will pseudo code what I am talking about. We are
>> >> running Active State Perl 5.10 on a Win32 platform, if that matters
>> >>
>> >> my $some_parms = shift;
>> >> my $objhref = get_objects($some_parms);
>> >> # $objhref = {
>> >> #           '01' => bless( {}, 'ASpecialObject' ),
>> >> #           '03' => bless( {}, 'ASpecialObject' ),
>> >> #           '02' => bless( {}, 'ASpecialObject' )
>> >> #         };
>> >>
>> >
>> > Have you tried assigning anything from $objhref directly at this point?
>> >  For
>> > example, do you get an error if you try to do $myobj = $objhref->{01}?
>>
>> Yes, the hash ref is fully loaded and performs these type of operations.
>>
>> >
>> >>
>> >> # ASpecialObject class does have the <=> overloaded
>> >> # But I cannot see the making a difference...
>> >>
>> >> # Sorting works fine:
>> >>
>> >> my @arrayoforefs;
>> >> eval {
>> >>   @arrayoforefs = sort { $a <=> $b } values %{$objhref};
>> >> }
>> >> # Error checks ignored
>> >
>> > Since you've wrapped this in an eval it seems like you're expecting
>> > exceptions to be thrown.  Why ignore them?  See if there is an exception
>> > that might lead you in the right direction.
>>
>> My BAD. Ignoring exceptions was only pseudocode. In production, we do
>> trap the exceptions. But it is a sunny day scenario [from the point of
>> view of the evaled statement] that is producing the problem, so I
>> omitted any checking to keep the waters clear.
>>
>> >
>> > Also, are you able to access anything within @arrayoforefs without using
>> > an
>> > assignment?  For example what happens when you do warn "arrayofrefs[0]:
>> > @arrayofrefs[0]"?  Do the server crash?
>>
>> Not certian if what @arrayofrefs[0] is what you mean? A slice of one
>> element? I will try and get back to you.
>>
>> >
>> >>
>> >> # Server dies silently at the following statement:
>> >>
>> >> my $chosenO = shift @arrayoforefs;
>> >>
>> >> # If I do this instead:
>> >>
>> >> my $chosenO = $arrayoforefs[0];
>> >>
>> >> # Then this causes the server to silently crash:
>> >>
>> >> return unless $chosenO;
>> >
>> > You've said "server dies silently" and "silently crash" but I'm not
>> > clear
>> > what you mean.  Is this two different things or the same?  By "crash" do
>> > you
>> > mean that the server process exits with a core dump?  Is this an Apache
>> > server?  Mod_perl?  When perl "dies" it generates a message.  Also, in
>> > my
>> > experience when Apache dumps core it puts a message in the log but
>> > you've
>> > said "silently" so perhaps something else is going on.
>>
>> Yes, silently. No core. Frustrating, nothing prints to the log at all,
>> just the server is no longer running.
>>
>> >
>> > My suggestion is to code up the simplest case you can where the problem
>> > is
>> > encountered.  Strip out as much code as possible that doesn't directly
>> > relate to what you're doing.  For example, the following script can be
>> > run
>> > outside of your web server and outside of your Mason environment:
>>
>> Unfortunately my attempts to reproduce the array shift issue outside
>> of the server have failed.
>>
>> Hey Thanks again for the feedback
>>
>> >
>> > #!/usr/bin/perl
>> >
>> > use strict;
>> > use warnings;
>> > use lib "/my/code/path";
>> > use ASpecialObject;
>> >
>> > my $objects = {
>> >  01 => ASpecialObject->new(),
>> >  02 => ASpecialObject->new(),
>> > };
>> >
>> > my @sorted = sort {$a <=> $b} values %{$objects};
>> >
>> > #Does this result in the same problems you're having?
>> > my $chosen0 = shift @sorted;
>> > print "If you see this then the script is done\n";
>> > __END__
>> >
>> > You'll probably have to include some object initialization code but if
>> > you
>> > still have problems with this then you know the problem is somewhere in
>> > ASpecialObject.pm.  Then you can start stripping out the code from there
>> > to
>> > find the minimum amount of code that causes the problem.
>> >
>> > --
>> > Ben
>> >
>> _____________________________________________________________
>> Seattle Perl Users Group Mailing List
>>     POST TO: spug-list at pm.org
>> SUBSCRIPTION: http://mail.pm.org/mailman/listinfo/spug-list
>>    MEETINGS: 3rd Tuesdays
>>    WEB PAGE: http://seattleperl.org/
>
>



-- 
I require any third parties to obtain my permission to submit my
information to any other party for each such submission. I further
require any third party to follow up on any submittal of my
information by sending detailed information regarding each such
submission to telcodev at gmail.com
Joseph Werner

More information about the spug-list mailing list