Authors CurseForge

Personnally I do it like this :

local function pairsByKey (t, f)
	local a = {}
	for n in pairs(t) do table.insert(a, n) end
	table.sort(a, f)
	local i = 0      -- iterator variable
	local iter = function ()   -- iterator function
		i = i + 1
		if a[i] == nil then return nil
		else return a[i], t[a[i]]
		end
	end
	return iter
end

...

function foo()
	local bar = {
		["key1"]="value1",
		["key2"]="value2",
		["key3"]="value3",
	}
	for k, v in pairsByKey(bar) do
		dostuffwith(k, v)
	end
end

I have no idea if what I do leads to a lot of garbage or not, it does a nice job of hiding the complexity in the iterator so that the code itself looks simple...It has the added advantage of allowing for a sorter to be passed as a second argument.

Similarly I use the same principle to iterate over a raid/party :

local function RaidIterator()
	local i = 0
	return function ()
		i = i + 1
		local unit
		if UnitInRaid("player") and i<=GetNumRaidMembers() then
			return "raid"..i
		else
			numPartyMembers = GetNumPartyMembers()
			if i<= numPartyMembers then
				return "party"..i
			elseif i==numPartyMembers+1 then
				return "player"
			end
		end
	end
end

I have released a new version correcting the heals appearing as crit since a few patches. Additionally I have released Acheron_Graph which gives a graphical vision of what happened to the unit and when.

It is indeed, as I said in your ticket that's what you get when you are trying an experimental addon :p

On a side note Skada_FriendlyFire is now correctly packaged and should work flawlessly... Should it work less than flawlessly you are authorized to blame drugs, as a second step you may open a ticket on the project page...

I'm under the impression the problem occurs when the children of a container are almost filling the container or actually filling a bit more than the container... What was weird with my bug was that if I actually clicked on the scrollbar the freezing stopped...
I solved it the same way you did : by adding an empty filler element...

It looks exactly like what I reported in this ticket : http://www.wowace.com/addons/ace3/tickets/122-game-framerate-loss-when-opening-blizz-config-panel/

I have written a module that adds a friendly fire damage mode (Skada_FriendlyFire), it is still in experimental status but as soon as I can test it properly I will release it. It will add some data into the set / player objects, as I understand it it is the way to go about such things (for player object data is friendly fire damage done amount, as well as amount for each raid member targetted / spell used).
First question : is it all right with you if I do that ?
Second question : if you could go over my code and tell me if it's up to par with your standards I would be grateful. Specifically I could not find a way to use the existing framework and say that I was interested in the events that had dst AND src as raid members so I have to parse more events than I should, I do it in such a way that should not be more demanding on resources than if it was coded in the framework but I may have missed something.

There are different ways to access Acheron, the most used ones are :
- Open Acheron through the Launcher, a /command => Acheron opens without any character being filtered
- Right click on any unitframe and select Show Death report => Acheron opens with a filter on the character defined by the unitframe

If you are using the Ace3 framework, take a look at the tutorial here : http://old.wowace.com/wiki/WelcomeHome_-_Your_first_Ace3_Addon

Edit : scratch that, I'm a moron...

Still no updates about us, poor frenchmen who only get the 500$ Paypal item ?

I swear this is another anglo plot to wrong us, cheese-eating surrendering monkeys :p

I wanted to know the precise rules governing CHAT_MSG_LOOT in a raid environment and specifically : is the event always generated when someone in the raid loots something ? Is there a distance limit ? What if you are not in the same zone ?

I am in the process of writing a simple DKP addon for my guild, I will just record automatically attendance and loots with a way to edit both.
I thought at the beginning to just have one of the people in the raid to use the addon. The problem I am running into is if that guy disconnects, I am at risk of losing all the info for the night.

Any idea of a simple solution to work around that ? I toyed with two ideas :
- Is there a way I could manually force the commit on file of my AceDB ? Not sure if possible.
- A client / server solution where the server is re-negociated periodically, if server crashes one of the client takes over... Strikes me as quite complicated...

I do not like any of those solutions, help meee !

As a general rule you should only use the public API for a widget, no using of widget.frame or at least only in the purpose of reading things, it is the only guarantee you are not screwing things up for the next user.
Hint : instead of doing frame.frame:SetPoint, do frame:SetPoint()

As for your problem, test it but chances are that logging out will not fire OnClose script.
The solution to use the OnUpdate script is NOT a good one if I understand correctly the intricacies of wow...

I think you could open a ticket for Nev to add a OnMovementStart / Stop callback on the frame

Being a bg healer myself I am strongly against any such addon !