Beefy Boxes and Bandwidth Generously Provided by pair Networks
Clear questions and runnable code
get the best and fastest answer
 
PerlMonks  

"New XP" may report at inappropriate times

by davido (Archbishop)
on Jul 12, 2011 at 03:57 UTC ( #913835=pmdevtopic: print w/replies, xml ) Need Help??

Update: Please see the update at the bottom. I think I was mistaken in assessing my observation.

It's probably been this way for awhile, but I've been wondering why when a person gains XP the notification message in the XP Nodelet sometimes may report the new XP gain several times in a row before the message stops showing up.

Here is the relevant code, I think:

1: my( $shownumbers )= @_; 2: # send FALSE if you want people to see gain/loss w/o exact numbe +rs 3: 4: return "" 5: if getId($USER) eq $HTMLVARS{default_user}; 6: 7: my $curexp= $USER->{experience}; 8: my $oldexp= $VARS->{oldexp}; 9: $oldexp= $curexp 10: if ! defined $oldexp; 11: my $difexp= $curexp - $oldexp; 12: $VARS->{oldexp}= $curexp; 13: return "" 14: if 0 == $difexp; ....... lots more below dealing with quips.

It seems that the desired behavior is to have a new XP gain reported exactly one time, not several. I can't prove that it's not just a matter of being upvoted several times, but my feeling that the upvote clusers don't fit my posting habits. For example, maybe I've gone several days between new posts. When I come back to PerlMonks, I find 6xp added. Then upon hitting, "Newest Nodes" or "Talk", I get the same six-point report. It's unlikely in that event that I really gained 6 over the course of a couple days, and then six in the matter of a few seconds again..

I don't want to put out a theory as to why it's happening in the absence of solid evidence, but it seems that $VARS->{oldexp}= $curexp; is taking several reloads to propagate to all the servers.

I guess I would be looking for confirmation that (1) There is a problem, ie, the behavior is as I describe: That the first two reloads (even via 'talk button') sometimes fail to clear the New XP message by setting $VARS{oldxp}=$curxp, and (2) That it's supposed to work as I expect: The report is supposed to show only once. A third question would be what possibilities exist as to why it's happening.

Update: Now that I finally gather the courage to suggest there might be a problem I find it impossible to duplicate the behavior I thought was happening. So perhaps $VARS->{oldexp}= $curexp; is doing exactly what it ought to, and I've been incorrect in my casual observation of the anecdotal evidence I thought was supporting my hunch. ;)


Dave

Replies are listed 'Best First'.
Re: "New XP" may report at inappropriate times
by choroba (Chancellor) on Jul 12, 2011 at 09:52 UTC
    Sometimes, I also have the feeling that the XP gain is being reported several times: mainly when I open several different links in several tabs at the same time.
Re: "New XP" may report at inappropriate times
by GrandFather (Sage) on Jul 12, 2011 at 11:44 UTC

    I certainly see the behaviour you describe where the XP notification is shown for any number of pages opened within a small (few tens of seconds maybe) period of time, including refreshing a page within a small period of time. When it happens it seems to affect all pages opened within the period. As you suggest the effect does not happen consistently and I can't put any sort of reliable time period on the "window of opportunity" except that it seems to be more than a few seconds and less than a few tens of seconds.

    True laziness is hard work

Log In?
Username:
Password:

What's my password?
Create A New User
Chatterbox?
[Corion]: Of course, the error was in my own code ;)
[marioroy]: Corion, start and start_child in MCE::Hobo::Manager return a MCE::Hobo object, whereas P::FM returns the PID. I can have it return the PID though. I tried Hobo::Manager with several P::FM modules, just changed P::FM to MCE::Hobo::Manager and it works.
[marioroy]: I also have a Hobo driver for Forklift allowing folks to use in multiple classes, no conflicts with one another. That's not possible for P::FM.
[Discipulus]: congrats marioroy!
[marioroy]: CORE::wait works well eventhough multiple instances or classes using Hobo::Manager.
[Corion]: marioroy: I'm not sure what the normal use for the PID is in P:FM, but I guess that most programs just ignore or log it
[Corion]: Oh, yes, programs could call wait $pid, but if your $pid is an object, then you could add a ->wait method to it and wait $pid would call that automatically "thanks" to indirect object notation
[marioroy]: Just documentation edits is all that remains. Hobo::Simple provides foreach and forseq with identifier capability -- all transparently supporting array, hash, file handle, and seq 1 .. N.
[marioroy]: Corion Regarding PID, that's great. So will leave it so compatible with MCE::Hobo. e.g. ->create returns a Hobo object. Folks can get ->pid from it. So, that's not a problem.

How do I use this? | Other CB clients
Other Users?
Others exploiting the Monastery: (7)
As of 2017-05-26 08:42 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?