I would consider dumping the local functions that build up class tables once it's determined they're not needed. LHC3 had some conditional code that only ran per class in the main body, whereas LHC4 has local functions which live for the duration of your WoW session. Once you have a valid UnitClass("player"), you can nil them and save some space.
13:47] <yoshimo> if i get a c stack overflow while casting, what could an addon have done wrong?
[13:48] <mitch0> infinite recursive call?
[13:49] <mitch0> like hooking stuff twice while calling orig
Apparently I can't tunnel through IRC like I used to, so I'll either take longer to respond on IRC or might miss something that's said. I'll see if I can duplicate it tomorrow or Thursday when I have time, but if it's a bug that only happened on a level 4 then I'll live for the time being.
Can you put the recursive loop bug in a ticket so I don't forget about it? Tagged b2 as well, at this point everything should be good for testing and starting to implement.
Forgot to check the upgrade path, but there was a small bug that will cause errors if a version loads then a newer one loads later that is load on demand, it's fixed in b2.1 which will be up when the repo starts working again.
I've taken the existing oUF_HealComm addon and updated it to use LibHealComm-4.0 and everything seems to work fine, although I have 1 concern.
Currently I am getting the GUIDUnitMapTable on every heal update, which is a kludge, instead of only getting an updated version of the table when it has changed.
Looking at the code the GUIDUnitMapTable updates on initialisation of LibHealComm-4.0 and on the UNIT_PET, PARTY_MEMBERS_CHANGED and RAID_ROSTER_UPDATE events. While I could also listen for these events and update afterwards, I would need some nominal delay to avoid race conditions and ensure the table has been updated before I get it again.
Would it be more elegant for LibHealComm-4.0 to fire another event whenever it makes changes to the GUIDUnitMapTable? Then any addon using LibHealComm-4.0 could listen for that event as the trigger to grab the updated copy.
I'd suggest updating your code to this : http://gist.github.com/183681 :
- apply the heal modifier,
- use GUIDUnitMapTable before updateHealCommBars loop,
- do not update every oUF frames but instead use the oUF.units table (this might cause issues though).
BTW, GUIDUnitMapTable does not return a copy each time. It returns a reference to the same unmodifiable table each time.
Thanks for the suggestions Adirelle, I'll take a closer look when I'm not at work.
The previous oUF_HealComm allowed each oUF frame to specify a .ignoreHealComm flag to disable showing the incoming heal bar. With it being possible to have the same unit shown on player frame, target frame, targetoftarget frame, raid frame, maintank frame and maintanktarget frame I don't necessarily want all of them to show the incoming heal bars.
You don't need to recall HealComm:GetGUIDUnitMapTable() anyway, the table that it returns is just a metatable that redirects all requests to the GUID -> Unit table, but it creates that on file load and it'll always reference the lastest GUID -> Unit table even when the tables released to GC. It's just:
-- Returns the guid to unit table
HealComm.protectedMap = HealComm.protectedMap or setmetatable({}, {
__index = function(tbl, key) return HealComm.guidToUnit[key] end,
__newindex = function() error("This is a read only table and cannot be modified.", 2) end,
__metatable = false
})
function HealComm:GetGuidUnitMapTable()
return HealComm.protectedMap
end
Not in this case, I release the pendingHeals, bucketHeals, guidToUnit, guidToGroup tables to the GC when the player leaves the group and the function wrapper ensures it will call the latest version without me having to reinitialize the metatable which would require another call to :GetGUIDUnitMap().
Rollback Post to RevisionRollBack
To post a comment, please login or register a new account.
On my nightelftestdruid lvl 4 deDE-locale i casted http://www.wowhead.com/?spell=5185 Healing Touch and got:
and from irc
It doesnt happen with a lvl 1 male nightelf on the ptr. but i don't know if that helps ;)
EDIT: the testdruid which had the bug is now lvl 6 and entered dolanaar, and it didnt happen for 2h... no more bug
And I questioned myself if I should repost it here too, but decided against it :rolleyes:
Currently I am getting the GUIDUnitMapTable on every heal update, which is a kludge, instead of only getting an updated version of the table when it has changed.
Looking at the code the GUIDUnitMapTable updates on initialisation of LibHealComm-4.0 and on the UNIT_PET, PARTY_MEMBERS_CHANGED and RAID_ROSTER_UPDATE events. While I could also listen for these events and update afterwards, I would need some nominal delay to avoid race conditions and ensure the table has been updated before I get it again.
Would it be more elegant for LibHealComm-4.0 to fire another event whenever it makes changes to the GUIDUnitMapTable? Then any addon using LibHealComm-4.0 could listen for that event as the trigger to grab the updated copy.
You can see how I have updated oUF_HealComm here: http://github.com/Evilpaul/oUF_HealComm4/tree/master
- apply the heal modifier,
- use GUIDUnitMapTable before updateHealCommBars loop,
- do not update every oUF frames but instead use the oUF.units table (this might cause issues though).
BTW, GUIDUnitMapTable does not return a copy each time. It returns a reference to the same unmodifiable table each time.
The previous oUF_HealComm allowed each oUF frame to specify a .ignoreHealComm flag to disable showing the incoming heal bar. With it being possible to have the same unit shown on player frame, target frame, targetoftarget frame, raid frame, maintank frame and maintanktarget frame I don't necessarily want all of them to show the incoming heal bars.