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