Alright, I've been hard at work making Parser-3.0 have feature-parity with Parser-1.1, and it's finally at that point. I've also added a compatibility layer to Parser-3.0 so that any addons which are coded to the Parser-1.1 API don't have to change, but instead can load Parser-3.0 and have it all work.
[2007/05/27 21:11:45-62-x1]: Parser-3.0\Parser-3.0.lua:3694: bad argument #1 to 'rawget' (table expected, got nil)
Parser-3.0\Parser-3.0.lua:3694: in main chunk
Infos:
Running embeds. PaserLib-1.1 in Eavesdrop, Parser-3.0 in Pitbull, and ParserLib in sct.
Found a minor bug with this and spell school values. Its returning the lower case SPELL_SCHOOL0_NAME value instead of the correct SPELL_SCHOOL0_CAP value.
Looking at the code regarding my previous post, I think this line
if info.damageType == DAMAGETYPE_PHYSICAL or info.damageType == DAMAGETYPE_UNKNOWN then
result.element = nil
else
result.element = info.damageType:lower()
end
Can be:
if info.damageType == DAMAGETYPE_UNKNOWN then
result.element = nil
else
result.element = info.damageTypeLocal
end
So this is like an attempt to deprecate and eventually obsolete Parser-1.1?
Or what's the future of Parser-1.x? (which as I understand is maintained and suffers no outstanding issues at the moment)
So this is like an attempt to deprecate and eventually obsolete Parser-1.1?
Or what's the future of Parser-1.x? (which as I understand is maintained and suffers no outstanding issues at the moment)
Another mod to come close to ckks goal, to rule the Interface World! :p
So this is like an attempt to deprecate and eventually obsolete Parser-1.1?
Or what's the future of Parser-1.x? (which as I understand is maintained and suffers no outstanding issues at the moment)
You're right, it works fine.
The only "problem" is that the API is a bit hard to work with, but that doesn't justify spending hours and hours of work to get Parser-3.0 in a working condition.
So this is like an attempt to deprecate and eventually obsolete Parser-1.1?
Or what's the future of Parser-1.x? (which as I understand is maintained and suffers no outstanding issues at the moment)
You're right, it works fine.
The only "problem" is that the API is a bit hard to work with, but that doesn't justify spending hours and hours of work to get Parser-3.0 in a working condition.
I have to state that, while the filters in 3.0 is nice, it requires raid unitid info - without unitid you can't really have much input for the filters except 'player', and you dont get unitid from combat log, so 3.0 embedded a RosterLib, which I personally don't think is a good idea - why should a parser try to guess the unitid from names?
Since the core algorithm is the same, I personally see Parser-3.0 as Parser-1.1 + RosterLib, and adding a filter layer API after having unitid info. While these two libraries work as a great combo, one can easily make a filter layer on top of 1.1 easily by reusing RosterLib and Parser-1.1, instead of rewriting one with 2 combined, the result is only 1 parser in your UI, which was one of the main objective for me to make a generic parser.
A generic parser IMO shouldn't try to do things which it shouldn't, stealing the job of RosterLib being one big example. So while 3.0 is nice, it doesn't fit my personal definition of a generic combat log parser, and so I'll still maintain 1.1.
I do not discourage anyone to use 3.0 though. It's good and well written, it also tries to do some common and useful tasks which Parser-1.1, with the goal of being a low level generic parser, will never support, overheals and raid unitid being some examples.
Because it doesn't. Ambiguity is a small problem for enUS, but is a HUGE issue with frFR. Parser-3.0 broke ParserLib-based addons for me.
Edit: the latest release does not seem to have this problem anymore, provided that I add the following line in Parser-3.0.toc :
OptionalDeps: SW_Stats
I used the same trick with ParserLib, because SW_FixLogStrings, part of SW_Stats package, transforms patterns and remove ambiguous cases.
Maybe it would be a good idea to add SW_FixLogStrings's logic to Parser-3.0 or as another Library that Parser-3.0 and ParserLib would use, because without it, frFR parsing is severely broken.
Because it doesn't. Ambiguity is a small problem for enUS, but is a HUGE issue with frFR. Parser-3.0 broke ParserLib-based addons for me.
Edit: the latest release does not seem to have this problem anymore, provided that I add the following line in Parser-3.0.toc :
OptionalDeps: SW_Stats
I used the same trick with ParserLib, because SW_FixLogStrings, part of SW_Stats package, transforms patterns and remove ambiguous cases.
Maybe it would be a good idea to add SW_FixLogStrings's logic to Parser-3.0 or as another Library that Parser-3.0 and ParserLib would use, because without it, frFR parsing is severely broken.
SW_FixLogStrings provides a function to modify the combat log patterns to fix the ambiguous patterns, which SW_Stats uses if it exists.
Instead of adding such logic (modifying combat logs) to parser, I think SW_FixLogStrings should be changed in the way it modifies combat log. Currently it merely provides a function, the function modifies the global combat log pattern when SW_Stats calls it.
Instead of requiring addon to explicitly call the function, SW_FixLogStrings should actively fixes the combat logs patterns known to cause problems.
This way all other parsers have to do is to add SW_FixLogStrings as the OptDeps, if you have SW_FixLogStrings, then you got fixed combat logs. If an addon is known to break by SW_FixLogStrings, all you have to do is to add SW_FixLogStrings as OptDeps, and not SW_Stats.
May be suggest that to the author of SWStats? Having 2 addons trying to modify combat logs will cause even bigger problems, so duplicating SW_FixLogStrings should be avoided whenever possible, ask the author of SW_FixLogStrings to make it works nicer with other addons.
btw Parser-1.1 works without adding SWStats as OptDeps, as a side effect of the load-on-demand patterns. If you have SWStats loaded, the patterns from ParserLib are loaded after SW_FixLogStrings fixes them.
Correct me if I am wrong, but the way 3.0 works now is it basically overrides 1.1 completely. So if you have 3.0 and 1.1 installed, 3.0 will be used for everything. I understand the usefulness of this in that 1.1 written mods don't have to change anything, but I still think the mod authors should have the ability to choose which to use if both are installed.
I agree it sucks having two Parsers running at the same time doing mostly the same thing, but I'm not sure the best way to move forward.
Instead of requiring addon to explicitly call the function, SW_FixLogStrings should actively fixes the combat logs patterns known to cause problems.
Which means keep a database of patterns in SW_FixLogStrings, which is what I think the current design was trying to avoid.
Quote from rophy »
Having 2 addons trying to modify combat logs will cause even bigger problems, so duplicating SW_FixLogStrings should be avoided whenever possible, ask the author of SW_FixLogStrings to make it works nicer with other addons.
As SW_FixLogString corrects metapattern known to be problematic, and not a known list of patterns, you can safely replicate it's logic so that SW_FixLogString has no effect if called after our library has modified the patterns and so that our library has no effect if loaded after SW_FixLogString has been called.
An other option is to directly add the simple :
local get_pattern
do
local SW_FixLogStrings
function get_pattern (str)
if SW_FixLogStrings == nil then
SW_FixLogStrings = _G.SW_FixLogStrings or false
end
local s = _G[str]
if SW_FixLogStrings then
local n = SW_FixLogStrings(s)
if s ~= n then
_G[str] = n
s = n
end
end
return s
end
end
Instead of requiring addon to explicitly call the function, SW_FixLogStrings should actively fixes the combat logs patterns known to cause problems.
Which means keep a database of patterns in SW_FixLogStrings, which is what I think the current design was trying to avoid.
Quote from rophy »
Having 2 addons trying to modify combat logs will cause even bigger problems, so duplicating SW_FixLogStrings should be avoided whenever possible, ask the author of SW_FixLogStrings to make it works nicer with other addons.
As SW_FixLogString corrects metapattern known to be problematic, and not a known list of patterns, you can safely replicate it's logic so that SW_FixLogString has no effect if called after our library has modified the patterns and so that our library has no effect if loaded after SW_FixLogString has been called.
An other option is to directly add the simple :
local get_pattern
do
local SW_FixLogStrings
function get_pattern (str)
if SW_FixLogStrings == nil then
SW_FixLogStrings = _G.SW_FixLogStrings or false
end
local s = _G[str]
if SW_FixLogStrings then
local n = SW_FixLogStrings(s)
if s ~= n then
_G[str] = n
s = n
end
end
return s
end
end
to Parser-3.0 and Parser-1.1
While I understand the design of the current SW_FixLogStrings,
in my opinion, since SW_FixLogStrings is a stand-alone library, which job is to fix the problematic combat logs, then maintaining a list of problematic patterns, and actively fixes them probably can belong to its job too.
This way the big bonus is you require no change to any addon/library which is known to incompatible with SW_FixLogStrings, the only requirement is to add SW_FixLogStrings as an OptDeps.
Of course... explicitly supports SW_FixLogStrings in all parsers work too, but making SW_FixLogStrings more functional will be more friendly to other addons which have some tiny inline parsers.
Correct me if I am wrong, but the way 3.0 works now is it basically overrides 1.1 completely. So if you have 3.0 and 1.1 installed, 3.0 will be used for everything. I understand the usefulness of this in that 1.1 written mods don't have to change anything, but I still think the mod authors should have the ability to choose which to use if both are installed.
I agree it sucks having two Parsers running at the same time doing mostly the same thing, but I'm not sure the best way to move forward.
I didn't write the compatible layer, but if it works correctly then I think we don't have to care.
AFAIK, as the current way it works, if an addon is using 1.1, it doesn't have to change to 3.0. The compatible layer is for those who already use 3.0 and wants to only have 1 parser in memory, in that case, 1.1 mod authors don't have to care about 3.0.
So unless you want to use 3.0 and its API, or you can just keep on using 1.1. Of course all those are under the assumption that the compatible layer works correctly, in case it has any bug, users will direct the complains to the 1.1 mod author, and it'll be hard as hell to find out the cause unless the user turn 3.0 off.
So unless you want to use 3.0 and its API, or you can just keep on using 1.1. Of course all those are under the assumption that the compatible layer works correctly, in case it has any bug, users will direct the complains to the 1.1 mod author, and it'll be hard as hell to find out the cause unless the user turn 3.0 off.
Maybe adding some kind of warning when 3.0 overrides 1.1 could help ?
Rollback Post to RevisionRollBack
To post a comment, please login or register a new account.
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumGetting an error, just updated.
[2007/05/27 21:11:45-62-x1]: Parser-3.0\Parser-3.0.lua:3694: bad argument #1 to 'rawget' (table expected, got nil)
Parser-3.0\Parser-3.0.lua:3694: in main chunk
Infos:
Running embeds. PaserLib-1.1 in Eavesdrop, Parser-3.0 in Pitbull, and ParserLib in sct.
-
View User Profile
-
View Posts
-
Send Message
Curse Premium-
View User Profile
-
View Posts
-
Send Message
Curse Premium-
View User Profile
-
View Posts
-
Send Message
Curse PremiumCan be:
I'm running Parser-3 v37503 & Sct 36393 & sctd v36395
all my librairies are disembeded and runing on frFR client.
Or what's the future of Parser-1.x? (which as I understand is maintained and suffers no outstanding issues at the moment)
Another mod to come close to ckks goal, to rule the Interface World! :p
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumYou're right, it works fine.
The only "problem" is that the API is a bit hard to work with, but that doesn't justify spending hours and hours of work to get Parser-3.0 in a working condition.
I have to state that, while the filters in 3.0 is nice, it requires raid unitid info - without unitid you can't really have much input for the filters except 'player', and you dont get unitid from combat log, so 3.0 embedded a RosterLib, which I personally don't think is a good idea - why should a parser try to guess the unitid from names?
Since the core algorithm is the same, I personally see Parser-3.0 as Parser-1.1 + RosterLib, and adding a filter layer API after having unitid info. While these two libraries work as a great combo, one can easily make a filter layer on top of 1.1 easily by reusing RosterLib and Parser-1.1, instead of rewriting one with 2 combined, the result is only 1 parser in your UI, which was one of the main objective for me to make a generic parser.
A generic parser IMO shouldn't try to do things which it shouldn't, stealing the job of RosterLib being one big example. So while 3.0 is nice, it doesn't fit my personal definition of a generic combat log parser, and so I'll still maintain 1.1.
I do not discourage anyone to use 3.0 though. It's good and well written, it also tries to do some common and useful tasks which Parser-1.1, with the goal of being a low level generic parser, will never support, overheals and raid unitid being some examples.
/script Parser30Frame:OnEvent("CHAT_MSG_SPELL_BREAK_AURA", AURADISPELOTHER3:format( "Roger's Pet", "Roger's Buff", "Mob's Pet", "Pet's Spell")Because it doesn't. Ambiguity is a small problem for enUS, but is a HUGE issue with frFR. Parser-3.0 broke ParserLib-based addons for me.
Edit: the latest release does not seem to have this problem anymore, provided that I add the following line in Parser-3.0.toc :
I used the same trick with ParserLib, because SW_FixLogStrings, part of SW_Stats package, transforms patterns and remove ambiguous cases.
Maybe it would be a good idea to add SW_FixLogStrings's logic to Parser-3.0 or as another Library that Parser-3.0 and ParserLib would use, because without it, frFR parsing is severely broken.
SW_FixLogStrings provides a function to modify the combat log patterns to fix the ambiguous patterns, which SW_Stats uses if it exists.
Instead of adding such logic (modifying combat logs) to parser, I think SW_FixLogStrings should be changed in the way it modifies combat log. Currently it merely provides a function, the function modifies the global combat log pattern when SW_Stats calls it.
Instead of requiring addon to explicitly call the function, SW_FixLogStrings should actively fixes the combat logs patterns known to cause problems.
This way all other parsers have to do is to add SW_FixLogStrings as the OptDeps, if you have SW_FixLogStrings, then you got fixed combat logs. If an addon is known to break by SW_FixLogStrings, all you have to do is to add SW_FixLogStrings as OptDeps, and not SW_Stats.
May be suggest that to the author of SWStats? Having 2 addons trying to modify combat logs will cause even bigger problems, so duplicating SW_FixLogStrings should be avoided whenever possible, ask the author of SW_FixLogStrings to make it works nicer with other addons.
btw Parser-1.1 works without adding SWStats as OptDeps, as a side effect of the load-on-demand patterns. If you have SWStats loaded, the patterns from ParserLib are loaded after SW_FixLogStrings fixes them.
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumI agree it sucks having two Parsers running at the same time doing mostly the same thing, but I'm not sure the best way to move forward.
Which means keep a database of patterns in SW_FixLogStrings, which is what I think the current design was trying to avoid.
As SW_FixLogString corrects metapattern known to be problematic, and not a known list of patterns, you can safely replicate it's logic so that SW_FixLogString has no effect if called after our library has modified the patterns and so that our library has no effect if loaded after SW_FixLogString has been called.
An other option is to directly add the simple :
local get_pattern do local SW_FixLogStrings function get_pattern (str) if SW_FixLogStrings == nil then SW_FixLogStrings = _G.SW_FixLogStrings or false end local s = _G[str] if SW_FixLogStrings then local n = SW_FixLogStrings(s) if s ~= n then _G[str] = n s = n end end return s end endto Parser-3.0 and Parser-1.1
While I understand the design of the current SW_FixLogStrings,
in my opinion, since SW_FixLogStrings is a stand-alone library, which job is to fix the problematic combat logs, then maintaining a list of problematic patterns, and actively fixes them probably can belong to its job too.
This way the big bonus is you require no change to any addon/library which is known to incompatible with SW_FixLogStrings, the only requirement is to add SW_FixLogStrings as an OptDeps.
Of course... explicitly supports SW_FixLogStrings in all parsers work too, but making SW_FixLogStrings more functional will be more friendly to other addons which have some tiny inline parsers.
I didn't write the compatible layer, but if it works correctly then I think we don't have to care.
AFAIK, as the current way it works, if an addon is using 1.1, it doesn't have to change to 3.0. The compatible layer is for those who already use 3.0 and wants to only have 1 parser in memory, in that case, 1.1 mod authors don't have to care about 3.0.
So unless you want to use 3.0 and its API, or you can just keep on using 1.1. Of course all those are under the assumption that the compatible layer works correctly, in case it has any bug, users will direct the complains to the 1.1 mod author, and it'll be hard as hell to find out the cause unless the user turn 3.0 off.
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumMaybe adding some kind of warning when 3.0 overrides 1.1 could help ?