07/08/14, 09:11 AM | #1 |
|
LibConstantMapper
While trying to figure out wich unambigious Chat Category Constant name relates to wich category I ran into the issue that the Constant Names are the keys in the global table. They can be identified via Pattern Matching, but they are not a subtable that you can easily itterate over.
Doing excessive pattern matching is bad for performance. Also there are other similary organised groups of values (like the Chat_Channels or all the Event ID's) you might want to find an easy match for. So I started development on this library. It consists of two files: mappings.lua Lua Code:
If I also want the chat channels using this library, I just have to modify it like this: Lua Code:
main.lua Lua Code:
That way I get a easy to itterate over table containing wich ConstantName matches wich Category. Going over the whoel global table is a lot faster then I anticipated so maybe I switch to a "retreive on demand, but cache" approach instead. Of course the whole thing will use libStub to avoid multiple execution in the final version. I just wanted to ask if there are any mistakes in this code I have to look out for. |
07/08/14, 10:37 AM | #2 |
|
Some suggestions.
a) either allow more exludes (make it a table) to make things like this work (because Lua's regular expressions are so weak they can't accomplish this in one go): Lua Code:
Lua Code:
Lua Code:
Also it would be nice to have direct [value] => "key" mapping in addition to the table of pairs (I'm aware there might be collisions and the library would have to deal somehow, that's why wrote in addition to ) Last edited by merlight : 07/08/14 at 10:40 AM. |
07/08/14, 12:15 PM | #3 |
Some more suggestions:
Lua Code:
1) Mapping can be part of the name and pattern is defined only in special cases 2) Do not create a new global table ConstantMapperMappings, just make it accessible using the library reference 3) As merlight said, it would be nice to have direct [value] => "key" mapping, so I changed it that way |
|
07/09/14, 04:25 AM | #4 | ||
|
The final structure for mappings might looks something like this: 1 Mapping (the mapping name) -> with 1...N patterns to match -> each pattern with 0...M exclusions But that is pretty far in the future. First things first.
2) The global table was only a temporary solution for my first trials. Currently I actually tend towards mappings being registered at runtime the same way you register media with LibMedia or libaries with LibStub. And only being processed on demand. if so the mappings.lua file will propably run after the actuall library and just call the register function in a loop. 3) My original idea was a [value] => "key" mapping. But that would cause issues if I ever end up with the same value more then once (the whole Chat Cat header issues pointed me at that). The output tables are designed to be itterable via # operator, no use of "pairs" needed. But taht is only personal preference of int indexes over string indexes. Not using the value as key also means I can accomodate non-key worthy values. For example, afaik "" is a valid value. But not a valid index. BugEaters inability to deal with nil and "" values pointed me towards that issue. A simple int indexed array of key&value allows a lot more ways to process the data. Edit (too 3): The more I think about it, the better my idea sounds. The global table is full of values that would never make a valid index for a table: empty stings, functions, other tables - non of that could ever make a proper index. Plus sometimes the same function/table might be used as value multiple keys (so I had the same index used multiple times). Clear index-worthy int and string values seem to be a odd thing in the global table, rather then a common one. Last edited by zgrssd : 07/09/14 at 04:38 AM. |
||
07/09/14, 08:31 AM | #5 | ||||
|
Skip down to *CONSTRUCTIVE* if you only want something constructive, this below is just rant
Lua Code:
Someone else might instead do it this way: Lua Code:
nameIt1 returns the first key with matching value, nameIt2 returns the last. Not to mention that the order of values in mapping depends on the order in which you get them from zo_insecurePairs! Which may be different every time you /reloadui, so addons using any nameIt function might behave strangely sometimes. I know it's hard do deal with conflicts properly, but if it's done in a library, at least it can be done consistently. *CONSTRUCTIVE* You could: 1) Add type requirement to your mapping spec. For example, "only int values allowed", everything else thrown away. 2) Sort your data={{value=5,key="foo"}, {value=5,key="bar"}} pairs table on value and key (sorting elements with equal values on key is important if you want consistent search results). Or zo_binaryinsert right away, instead of table.insert's and table.sort afterwards. 3) Provide a lookup function which would zo_binarysearch for given value in the sorted data. Last edited by merlight : 07/09/14 at 08:34 AM. |
||||
07/09/14, 11:21 AM | #6 | |
|
My experience tells me that a int-indexed, properly formed array consisting of key/value tables offers the best overall usage while still having acceptable looping performance. Looping over the array with # and comparing a string to "something" is going to have the same performance as asking the system for the value to key "something". Because all those tables are "under the hood" are one List without allowed duplicates and one with allowed duplicates. Also I cannot guarantee that any value will be there only once. That is simply a matter of how the data looks and the patterns/exclusiong are set. Better ending up with the same key twice in the array (easy to diagnose) then having sometimes the one key in use, sometimes the other (hard to diagnose). |
|
07/09/14, 04:01 PM | #7 |
|
After another set of pondering I reduced it to the following KISS case and even added some sanity checks on the input data:
Lua Code:
Last edited by zgrssd : 07/09/14 at 04:03 PM. Reason: Had forgotten to throw out some debug messages |
07/09/14, 06:13 PM | #8 | ||
|
I'm not sure how tables with non-contiguous integer-only keys are implemented in Lua; I guess they're simply ordered binary-searched arrays.
|
||
07/10/14, 04:58 AM | #9 |
|
Uploaded a first version:
http://www.esoui.com/downloads/info6...antMapper.html I am propably going to make this a dual-Library: One with the :getMappedData function and others that go over the global table One to store all the maps. That way I could do proper versioning on the maps too. Maybe later. Without caching it would cost resources everytime the value is requested. But it would only be usefull in a rare amount of cases (debugging). Personally I can work with a simple for loop and the data it gives me. Once I get a function with chaching up and running I will propably include it. |
07/11/14, 06:20 AM | #10 |
|
I ultimatively decided against making the mapping and the actuall working library seperate.
I added a function that allows you to get the data based on the name of a map. This function will also be expanded to include caching later. List Maps only gives the names of maps, not the entire map table I have also expanded the mappings a bit so it now includes all events, as well as several event subgroups. But that part is still WIP. I was not able to run this on my client yet and it is not an actuall release, so there are propably still some errors in there: Lua Code:
|
07/12/14, 04:36 AM | #11 |
|
The above code (after adding some missing = in the table assignment at the botom) has been uploaded as version 0.2.
I also started work on a function that gives you a value indexed array of the keys. This is my code so far (not done any testruns): Lua Code:
Last edited by zgrssd : 07/12/14 at 04:38 AM. |
07/13/14, 05:57 AM | #12 |
|
Just uploaded version 0.3
Aside from some changes to the description, this also include the new function: getValIndexedKeyList() Wich gives you a array of the keys, indexed by their values. By default it will throw an assertion exception if it runs into the same value a second time. But this behavior can be disabeled via an optional bool switch (but I highly advise against it. Duplicate values is something you really have to look at. Wich is why I made this case an exception in the first place). |
07/18/14, 02:22 AM | #13 |
|
And now I uploaded v0.4
I added some basic sorting to "getDataByMapping". Not added buffering yet, so it might be slightly slower then before. Embedded the new version fo LibStub. I added a new default mapping for the "BIND_TYPE" enumeration that is currently on the PTS server. The 1.3 patchnoites also gives me a better name for the next major release: "Enumeration Harvester" Apparently those "groups of Cosntants named by a pattern" are thier way of exposing enumerations to our LUA code. It would have been a bit better if they put them into subtables (one per Enum) instead of adding a prefix (so we can quickly itterate over each enum group). But this way I get to programm something for it. |
ESOUI » AddOns » Released AddOns » LibConstantMapper |
«
Previous Thread
|
Next Thread
»
|
Display Modes |
Linear Mode |
Switch to Hybrid Mode |
Switch to Threaded Mode |
|
|