• 0

    posted a message on Ace2 ParserLib thoughts
    I'm not sure about the performance of TriggerEvent(), but I can do a AceEvent:IsEventRegistered() check before firing Parser_CHAT_MSG_COMBAT_SELF_HITS and Parser_Message_Hit, the overhead should be minimal when addons only registered to one of the above. I guess I'll just make all the options available to users.

    So, ParserLib defaults to "auto mode" that if anyone registered a "Parser_Message_Hit", ParserLib registers all events containing "hit" message.
    Addons can choose to do the "manual mode" if they want, may be with a call to something like parser:SetAutoRegister("addonID", false). In this case, they'll have to specific what events they want by parser:RegisterEvent("addonID", "event") (leave handler nil).

    In this case, I'll need some way to know who you are, to check that you are in manual mode or not when AceEvent_EventRegistered is fired, so "addonID" should be the reference to self. ( Because when AceEvent_EventRegistered fired, I got your class object reference. )

    So the usage is something like this:

     parser:SetAutoRegister(self, false)
     parser:RegisterEvent(self, "CHAT_MSG_COMBAT_SELF_HITS"); -- don't pass a handler
     self:RegisterEvent("Parser_Message_Hit"); -- ParserLib will not register to any Blizzard event by this call.

    or like this:

     self:RegisterEvent("Parser_Message_Hit"); -- ParserLib will registers to all Blizzard events containing "hit" patterns.

    when CHAT_MSG_COMBAT_SELF_HITS occurs, ParserLib will fire Parser_CHAT_MSG_COMBAT_SELF_HITS AND Parser_Message_Hit if there are addon registered to them.

    hmm......... need wait till I'm not so busy IRL before I can really think about these carefully :X
    Posted in: Libraries
  • 0

    posted a message on Ace2 ParserLib thoughts
    If there is any naming convention suggested in AceEvent I'll be sure to use it, doesn't really matter. (That isn't being mentioned in the AceEvent wiki though, I think you should add it? Or is it already there and I missed it ?)

    When I started developing ParserLib 1 I have thought about the idea of client registering to types insteand of the events. But in the case that the author is only interested in some events, for example "only damages done by me", then the author only has to register to CHAT_MSG_COMBAT_SELF_HITS, CHAT_MSG_SPELL_SELF_DAMAGE and the possible events for DOTs. In the registering-to-types approach ParserLib have to register to all combat-related events even if this is the case. I was mainly concerned about the efficency when not every addon wants to listen to all the events, so to simplify the problem I just let authors take care of what events they want.

    But I can see how that will be convenient to authors, it'll remove the need of info.type checking, and authors no longer have to care about "what patterns are fired from what event". I'll have to think about it.

    If I am to make both approaches available, that is, firing a Parser_CHAT_MSG_COMBAT_SELF_HITS, when CHAT_MSG_COMBAT_SELF_HITS occurs, and also firing a Parser_Hit if the message is a "hit" message, how does that sounds to you? In this case, you'll get duplicate events if you registered to both the Parser_CHAT_MSG event and the Parser_Type event.

    for the BulkEvents do you mean RegisterBucketEvent()? I think you can use that as long as I am firing the events with AceEvent?
    Posted in: Libraries
  • 0

    posted a message on Ace2 ParserLib thoughts
    Since AceEvent now fires a custom event when someone registers an event, I am able to start writing Parser-2.0. The initial code for Parser-2.0 is done (haven't upload to svn yet ), I'll need some more testing first though.

    AceEvent will an optional dependency, if it exists, ParserLib simply fires a custom event PARSER_XXX with AceEvent.

    So you can do either the old:

    parser:RegisterEvent("addonID", "CHAT_MSG_COMBAT_SELF_HITS", OnEvent)

    or with AceEvent:
    self:RegisterEvent("PARSER_COMBAT_SELF_HITS"); -- Replace "CHAT_MSG" with "PARSER"

    I hope this is the best method to implement, this way authors can optionally choose to use the new AceEvent methods, or goes back the old embedded library approach if the addon doesn't need the functionalities of AceEvent at all.

    Posted in: Libraries
  • 0

    posted a message on Ace2 ParserLib thoughts
    I had been thinking on how to make use of the AceEvent for ParserLib

    ParserLib needs to :

    • 1. Maintains a list of client addons, and the event they registered.
    • 2. Only registers those events which there are at least one client addon interested.
    • 3. Parse arg1 for information, save it in a backup info table.
    • 4. Notifies the client with the event and info table when the event occured.
    • 5. Each time ParserLib will restore the info data from the backup table before sending to a client, because client may modify contents of the info table.

    AceEvent can save ParserLib from doing (1), (4), but how can I do (2) (5) ?

    (2) requires that ParserLib know when some addon registers to an event, if an addon registers to AceEvent and not ParserLib, I cannot know it.

    On method to do this is to have AceEvent fires a ADDON_REGISTER_EVENT event when Ace2 addon reigsters to an event (especially custom events).

    Another method is to let addon do a TriggerEvent insteand of RegisterEvent:

    ace2addon:TriggerEvent("PARSER_REGISTER_COMBAT_SELF_HITS", self, "OnCombatEvent")

    and in ParserLib:

    function ParserLib:OnClientRegisteringEvent(event, client, handler)
     1. client:RegisterEvent("PARSER_COMBAT_SELF_HITS", "OnCombatEvent")
     2. parser:RegisterEvent("CHAT_MSG_COMBAT_SELF_HITS");

    But I think this doesn't look very intutive?


    (5) also requires ParserLib to be involved in the notification of clients.

    One method is to have AceEvent do this automatically when they see an arg of type table, since it makes sense that every client addon should receive exactly the same arg.

    For both (2) and (5), I think another possible solution is to make ParserLib as an inherited class of AceEvent, and overwrite related those related functions.

    Posted in: Libraries
  • 0

    posted a message on A Couple Questions
    I'm still noob at lua, but for the term "efficiency" I think the following can be considered:


    - raw addon size (the memory usage before OnLoad() )
    - memory usage after OnLoad()
    - memory usage after OnLoad() and collectgarbage()
    - maxmimum memory usage after loading everything, also after a collectgarbage()
    - the memory required to complete a benchmark function.

    - memory increase rate when the addon isn't busy.
    - memory increase rate when the addon is busy.


    - addon loadup time until end of OnLoad() and may be Initialize()
    - the time used for each part of your main function calls.
    - the time required to complete a benchmark function.

    These are what I always try to optimize for my addons.

    To know if your addon is 'efficient' or not, grab a similar addon and compare both addons for the above attributes.
    Posted in: General Chat
  • 0

    posted a message on Ace SVN
    Sorry if the question is dumb.
    If I import a project into the SVN trunk, does the revision starts at 1 (from the svn manual) ?

    From the svn logs I see most of the 'initial commit' have a revision starts at like 1xxx. Does that mean those projects are added by 'commiting a change to the parent folder' and not 'importing a new project'?

    What I mean was, if I am to upload my ParserLib to SVN, should I:

    - Check out the whole /root/trunk, add ParserLib to /root/trunk/ParserLib, then commit the change of /root/trunk


    - Import ParserLib folder to /root/trunk ?

    Posted in: General Chat
  • To post a comment, please or register a new account.