| 00:29.21 | seebs | Is there an easy API call to check whether a given string is a valid point name for a SetPoint()? |
| 00:29.28 | seebs | Or a list of valid names that's accessible from code? |
| 01:24.38 | ZorbaTHut | I don't think there's an easy API call. as I recall, it's (LEFT|CENTER|RIGHT)(TOP|CENTER|BOTTOM), or any of those tokens individually |
| 01:24.46 | ZorbaTHut | actually I think I support them in the opposite order as well |
| 01:25.28 | Noshei | "TOPLEFT", "TOPCENTER", "TOPRIGHT", "CENTERLEFT", "CENTER", "CENTERRIGHT", "BOTTOMLEFT", "BOTTOMCENTER", "BOTTOMRIGHT". You may also use a string identifier that refers to a single axis - "TOP", "BOTTOM", "LEFT", "RIGHT", "CENTERX", "CENTERY". If you want more direct numeric control you can use number pairs. 0,0 is equivalent to "TOPLEFT", 1,1 is equivalent to "BOTTOMRIGHT", 0.5,nil is equivalent to "CENTERX". |
| 01:25.38 | Noshei | thats what's in the codumentation |
| 01:27.02 | ZorbaTHut | oh yeah, CENTERX and CENTERY also |
| 01:27.14 | ZorbaTHut | I think I support XCENTER/YCENTER/LEFTTOP and such as well, even though they're not documented |
| 03:11.30 | seebs | In this case, I want the names that are a complete specifier only, so I just went with the list-of-9. |
| 04:17.31 | *** join/#riftuidev Solsis00 (~Solsis00@ip98-186-89-123.fv.ks.cox.net) |
| 04:17.40 | Solsis00 | Evening all |
| 04:21.28 | Solsis00 | I'm about to embark on a new journey and a better method of tracking remaining time on buffs. I was thinking of doing that in a coroutine. Would that be the best way? |
| 04:29.44 | Baanano | what can a coroutine do in that situation you can't do without it? |
| 04:30.36 | Solsis00 | well coroutines are still a puzzle to me.. my understanding is they allow something to execute while the "core" of the addon continues to do whatever it does. |
| 04:31.13 | Solsis00 | So what I'm looking for is an efficient way to apply a buff indicator to a frame and have a timer on it that counts down how long is left. |
| 04:32.18 | Solsis00 | if using system.update is the best way then I'll just restructure it to try and reduce it's work cause it is a little sloppy right now. But if i'm going to be recoding was just wondering what other options (possibly better) I had. |
| 04:32.39 | Solsis00 | before I wasted the time |
| 04:33.42 | Baanano | a coroutine is a collection of instructions that can "pause" at specific points, so you can "resume" them later from that point |
| 04:33.58 | Solsis00 | so it wouldn't really benefit me in this case |
| 04:34.18 | Baanano | they won't resume automatically, you'll still need to tell them to resume from system.update or something |
| 04:34.32 | Solsis00 | I'd be better off just setting an individual function up on a 1 sec timer and kick it with system.update |
| 04:36.05 | Solsis00 | K. That answers my question. I'm going back through and recoding each piece of my addon from scratch to optimize it.to kind of merge all the addition/bandaids I've put in. |
| 07:59.04 | *** join/#riftuidev Kheldar (~Kheldar@217.108.40.234) |
| 08:27.21 | seebs | Solsis00: Note that "run this every second" is exactly what LibCron is supposed to do. |
| 08:27.37 | seebs | So that not every addon needs to have the System.Update check that sums frame times to see when it's been a second. |
| 08:27.51 | seebs | zzz |
| 09:50.24 | Solsis00 | Thanks seebs. I will keep that in mind. Right now though with the major changes coming in 2.4.. using other peoples libraries make me very nervous. Worst case I might wait til after 2.4 to pick it up. |
| 09:50.55 | Solsis00 | I already have a timer and system.update function setup so it isn't a big deal. Just looking for an efficient low cpu solution. |
| 09:51.19 | Solsis00 | Goal right now is optimizing my mess that has accumulated over the last year and a half. |
| 10:01.29 | Thorarin | Never let technical dept accumulate for such extended periods of time :P |
| 10:02.16 | Solsis00 | well.. as I was told back then.. worry about functionality and making it work then optimize for performance |
| 10:02.50 | Solsis00 | I've added so many features and changes that were just kind of squeezed in the code to make them work. |
| 10:03.17 | Solsis00 | I've learned a lot since then and am not going back and applying it to make it better. |
| 10:03.24 | Ivnedar | which 2.4 changes? |
| 10:03.44 | Solsis00 | Event changes |
| 10:04.20 | Solsis00 | any addons that don't conform to the new event system (which is presently in place) will break when they remove the old system completely. which is rumored to be in 2.4 |
| 10:04.34 | Ivnedar | deprecated 2.4, removed 2.5 I though |
| 10:04.35 | Ivnedar | t |
| 10:04.58 | Solsis00 | nice.. they moved it up.. gives people more time but my point is still valid |
| 10:05.03 | Ivnedar | yeah |
| 10:05.18 | Ivnedar | pretty sure mine are all sorted |
| 10:05.41 | Solsis00 | I've done the core of mine. I need to comb back through it to make sure I didn't miss anything |
| 10:05.52 | Ivnedar | It's easy when there's 2-3 lines to change :D |
| 10:06.00 | Thorarin | Creating events is still not implemented... |
| 10:06.11 | Ivnedar | maybe in 2.4 :D |
| 10:06.11 | Thorarin | For frames at least |
| 10:06.24 | Solsis00 | oh for like custom events you mean? |
| 10:06.27 | Thorarin | (and publishing them ofc) |
| 10:06.31 | Thorarin | Yeah |
| 10:06.45 | Solsis00 | yea.. I'm not that advanced :( |
| 10:06.48 | Thorarin | I have some custom controls :) |
| 10:10.33 | Ivnedar | I really hope the next patron thing they add is crafting stations :D |
| 10:10.53 | Solsis00 | lol |
| 10:10.55 | Solsis00 | that would be nice |
| 10:11.06 | Ivnedar | it's the only thing that's missing now I think |
| 10:11.12 | Solsis00 | yea |
| 10:11.27 | Solsis00 | pull a labratory out of your pocket. |
| 10:32.06 | *** join/#riftuidev Imhothar (miranda@ppp-188-174-138-132.dynamic.mnet-online.de) |
| 10:33.49 | *** join/#riftuidev Imhothar (miranda@ppp-188-174-138-132.dynamic.mnet-online.de) |
| 12:34.00 | *** join/#riftuidev Imhothar_ (miranda@ppp-188-174-144-205.dynamic.mnet-online.de) |
| 13:00.16 | *** join/#riftuidev Noshei (~quassel@c-24-9-171-99.hsd1.co.comcast.net) |
| 15:07.52 | *** join/#riftuidev zz_Cidan (~cidan@c-69-143-9-116.hsd1.va.comcast.net) |
| 15:41.15 | *** join/#riftuidev seebs (~seebs@home.seebs.net) |
| 15:41.15 | *** mode/#riftuidev [+o seebs] by ChanServ |
| 16:02.35 | *** join/#riftuidev dryness (~012345678@216.40.38.234) |
| 16:06.15 | *** join/#riftuidev Solsis00 (~Solsis00@ip98-186-89-123.fv.ks.cox.net) |
| 17:02.12 | *** join/#riftuidev Imhothar (miranda@ppp-188-174-144-205.dynamic.mnet-online.de) |
| 17:08.58 | Imhothar | huh did they rename the forum url again? |
| 17:11.45 | LeadGuitar | *shrug |
| 17:24.06 | Imhothar | hmm for some reason the Curse client keeps thinking my copies of BananAH and Gadgets is modified even though I just did a clean download |
| 17:24.27 | Imhothar | mysteries |
| 17:30.22 | Noshei | curse client, blah |
| 18:15.12 | Imhothar | "Invalid Forum specified. If you followed a valid link, please notify the administrator" |
| 18:15.23 | Imhothar | http://forums.riftgame.com/rift-general-discussions/addon-api-development/ |
| 18:15.27 | Imhothar | anyone else getting this? |
| 18:16.33 | *** join/#riftuidev Kaelten (~Kaelten@WoWUIDev/WoWAce/WoWIFA/CurseStaff/kaelten) |
| 18:16.33 | *** mode/#riftuidev [+o Kaelten] by ChanServ |
| 18:18.27 | LeadGuitar | that's odd |
| 18:19.12 | LeadGuitar | http://forums.riftgame.com/technical-discussions/addon-api-development/ |
| 18:20.16 | Imhothar | ah the index page is updated now |
| 18:28.56 | Noshei | yeah Imhothar I've gotten that a couple times today with different forums |
| 18:33.16 | seebs | All those forum URL things are a side-effect of a bad fix for a security hole, I think. |
| 18:33.29 | seebs | See, by default, vB uses numbers for everything. The 13th forum is ../f13 |
| 18:33.40 | seebs | And the user page for a user is .../u### |
| 18:33.59 | seebs | But the Trion people who set the forum up cleverly just used your Trion Worlds account ID as your forum user ID. |
| 18:34.18 | seebs | Meaning that the "welcome to our newest user, …" message was a pretty reliable measure of the rate at which new accounts got created. |
| 18:34.48 | seebs | So they adopted a vB "hack" (the vB nomenclature for mods) which does fancy forum/thread title things, with lovely side effects. |
| 18:35.06 | seebs | For instance, at least for quite a while, a thread in which the last word was "print" (not considering punctuation, which is ignored) couldn't be displayed normally. |
| 19:13.21 | Imhothar | ZorbaTHut: going through the docs, many events still lack the "handle" event argument |
| 19:14.00 | seebs | That reminds me, there is an ambiguity of sorts. |
| 19:14.23 | seebs | Which is that I think either Doomsprout's guide is wrong, or the docs are wrong, or I'm just sort of confused, about how frame events have their arguments shuffled. |
| 19:14.32 | seebs | frame:EventAttach(event, handler) |
| 19:14.36 | Imhothar | they don't |
| 19:14.38 | seebs | Will this call handler(frame, event, ...) |
| 19:14.43 | seebs | or handler(event, frame, ...) |
| 19:15.04 | seebs | Or possibly just handler(event, …) and if you wanted a frame argument passed in you should have used a closure. |
| 19:15.06 | Imhothar | since they are object methods self is first |
| 19:15.27 | Imhothar | hence "self" is not mentioned in the docs |
| 19:16.38 | Imhothar | ZorbaTHut: there is also a bug in your tools regarding the summary for bubble/dive events. they all are "EventName@summary" |
| 19:16.50 | seebs | Well, are they object methods, though? |
| 19:17.18 | seebs | Because the frame object doesn't necessarily have a member named that, so it's not that we're always seeing a call of the form frame:handler(event, …) |
| 19:18.03 | Imhothar | whether it has a member or not doesn't matter. the Event.UI. events have a self argument |
| 19:18.29 | Imhothar | though that doesn't really shine through well in the docs |
| 19:27.09 | seebs | The reason I ask is, I *thought* -- I'd have to go look now -- that I was getting them in a different order. But I may have screwed something else up. |
| 19:27.33 | Imhothar | it's always f(self, ...) where ... are the event args as shown in the docs |
| 19:28.12 | seebs | frame:EventAttach(Event.UI.Layout.Size, function(event) stt.size_change(frametable, event) end, "handle size changes") |
| 19:28.45 | seebs | The reason I did this was that the *first* argument to the function provided was being the event. I think. I don't have the version that I was having trouble with handy. |
| 19:29.08 | seebs | But it seemed to me that the first argument reaching the function was the event, not its containing frame. |
| 19:29.17 | seebs | … As it happens, I want the thing the frame is associated with anyway. |
| 19:29.48 | seebs | BTW, I uploaded LibScrollyTextThing, which is a library which provides the thing where you have a text object, and a scrollbar, and want the text object to be scrolled by the scrollbar. |
| 19:30.48 | seebs | Basically, create a blank Frame, use LibScrollyTextThing.create(frame, various config flags), and you get a thing which handles the Mask and the scrollbar and all that stuff. |
| 19:31.34 | seebs | As of the version I uploaded, it handles the case where the frame you told it to use changes height (I don't think it handles height changes, though, whoops). Also it supports a glow={table} option to use SetEffectGlow. |
| 19:31.56 | seebs | I've found that SetEffectGlow{strength=2,blurX=5,blurY=5} is a HUGE improvement in legibility for text most of the time. |
| 19:39.14 | Noshei | from my understanding the current Documentation lacks the handle paramater for all Events |
| 19:39.33 | Noshei | it should be Event(handle, shit that is documented here) |
| 19:40.01 | Imhothar | aye |
| 19:40.16 | Noshei | the doc's just haven't been updated to reflect that |
| 19:41.07 | Noshei | it also holds the same for all frame events |
| 19:42.36 | *** join/#riftuidev Solsis00 (~Solsis00@ip98-186-89-123.fv.ks.cox.net) |
| 22:20.01 | seebs | Not really addon-related, but: I haven't looked at the state of Rift's dungeon-type content in basically forever. Do tanks need special gear outside of experts, or is the toughness thing really specific to experts/raids? |
| 22:27.36 | Noshei | with the exception of the open world raid bosses, no they don't seebs |
| 22:30.02 | seebs | Cool. Thinking of riftstalking some. |
| 22:35.49 | *** join/#riftuidev dolby (~dolby-wow@MMOI/Administrator/pdpc.silver.dolby) |
| 22:35.49 | *** mode/#riftuidev [+o dolby] by ChanServ |
| 22:38.02 | Baanano | anyone with experience in indexing a MVCC keyvalue store? I'm switching BananAH to MVCC to improve concurrency, but also want to add "repost" detection. The issue is that without an index that new feature reduces scan throughput by 2 orders of magnitude, and I dunno how to index MVCC properly :( |
| 22:45.51 | Imhothar | since we don't have "real" concurrency you always know the state the DB is in, shouldn't you? |
| 22:49.04 | seebs | MVCC? |
| 22:50.23 | Baanano | right now, some operations can take a few frames (as a full scan), and while that's being done all read operations (for example searching) block, and viceversa (any long read operation blocks writes), the motivation to use MVCC is to allow read operations to use the last committed snapshot of the data so they don't block write operations |
| 22:50.34 | seebs | I don't know what MVCC is. |
| 22:50.41 | Baanano | mvcc = multi version concurrency control |
| 22:51.11 | seebs | Is this a new software package, or a difference in how you are using the existing Lua tables, or what? |
| 22:51.35 | Imhothar | It's his new idea to outsmart the watchdog I guess |
| 22:52.23 | Baanano | http://en.wikipedia.org/wiki/Multiversion_concurrency_control |
| 22:52.48 | Imhothar | why not make sure every frame leaves the DB in a readable state? |
| 22:54.27 | seebs | I think the issue is, if a read also needs more than one frame, you can't necessarily resume a read of the database in a future frame. |
| 22:54.49 | Imhothar | it may be imperfect, but at least it doesn't block |
| 22:54.50 | Baanano | what seebs said |
| 22:54.59 | seebs | For the sake of argument, imagine that instead of some really fancy thing, we just have a table, and the table is large enough that you need to iterate over it with a coroutine. |
| 22:55.06 | seebs | So you're doing something like |
| 22:55.19 | seebs | for k, v in pairs(hugetable) yield(k, v) end |
| 22:55.20 | Imhothar | then use a copy-and-swap approach |
| 22:55.41 | Imhothar | your writing operation works on a copy of the datasection it needs and when done swaps out the tables |
| 22:55.59 | Imhothar | pending read operations still use the old version |
| 22:56.18 | seebs | A copy of an auction history database seems like it would be pretty huge. Depending on the structure, though. Hmm. |
| 22:56.32 | Imhothar | you don't need to make a full copy |
| 22:56.48 | seebs | Like, if the top level keys are item ids, and you copy that, and you're also modifying each of the subtables… Hmm. |
| 22:57.03 | Baanano | that's what mvcc would do, but how to keep both indexes, one for the old snapshot and one for the new snapshot? |
| 22:57.03 | seebs | Well, that's a thing. You could in principle do copy-and-replace at both levels. |
| 22:57.23 | Imhothar | but in the end that is how MVCC works |
| 22:57.31 | seebs | Okay, say we have a table such that history[itemid][N] = Nth scan result for itemid. |
| 22:57.35 | Imhothar | if a read operation is pending the new data is saved somewhere else |
| 22:58.08 | seebs | Iterating is: for item, details in pairs(history) do for i = 1, #details do something_with(details[i]) end end |
| 22:59.05 | seebs | Now, when you want to modify things, first you shallow-copy the top-level history table. Then whenever you want to modify a specific history entry, you shallow-copy that, and do new_history[itemid] = new_details |
| 22:59.22 | seebs | The old tables are there until no one refers to them, and the tables they refer to are never modified by the writer. |
| 22:59.43 | seebs | But when the writer's done, it has a new history table which contains old-or-new tables for each item, depending on whether there were changes. |
| 22:59.54 | Imhothar | First, you're not allowed to modify a table which is currently iterated with pairs() by adding new values, otherwise you get undefined behavior. Second, if you want your read to be consistent you must not apply "concurrent" writes |
| 22:59.58 | seebs | But a reader that started with the old history table and iterated over it will never see an inconsistent table. |
| 23:00.34 | Imhothar | the only option you have is to do the modifications on a off-copy and apply it one nothing is reading the relevant section |
| 23:00.46 | Imhothar | *once |
| 23:00.53 | seebs | Right. In this design, so far as I know, you will never modify one of the previously-referenced tables by adding values. Any time you might add values, you copy the table you might add values to, then use the new table to replace the old one. |
| 23:01.07 | seebs | So you are never actually modifying the old tables at all. |
| 23:01.32 | Imhothar | you should certainly make sure your modifying operations are queued |
| 23:01.51 | Imhothar | something like a single-writer-multiple-reader lock |
| 23:01.53 | seebs | So instead of history[itemid][N+1] = new_detail, you would do copy = shallow_copy(history[item_id]); copy[#copy + 1] = new_detail; history[itemid] = copy |
| 23:01.58 | Imhothar | though not a lock |
| 23:02.06 | seebs | And if you wanted to add a new item id, you'd do the same thing to the history table itself. |
| 23:03.14 | Baanano | i'm not queueing modifying operations, but making wait those that try to modify uncommitted data, or rolling back them if waiting would result in a deadlock |
| 23:04.55 | Imhothar | you could get crazy with metatables, adding an implicit history to every value |
| 23:04.58 | Imhothar | if you feel crazy |
| 23:05.10 | Imhothar | really crazy |
| 23:08.40 | Imhothar | or at least to those section which can have sich a commit history |
| 23:15.13 | Baanano | in case you're bored: http://pastebin.com/KLqVSgNv |
| 23:22.40 | Imhothar | -- Increase command ID |
| 23:22.40 | Imhothar | transaction.cid = transaction.cid + 1 |
| 23:22.50 | Imhothar | if you were my collegue I'd have to slap you for that comment |
| 23:25.35 | Baanano | :P |
| 23:25.59 | seebs | So apparently, there is a fascinating bug in the Rift store. |
| 23:26.09 | seebs | The recipes section of the store can crash. |
| 23:26.19 | seebs | But! What gets me is: It doesn't crash because too many recipes are *available*. |
| 23:26.25 | seebs | It crashes because too many recipes are *known*. |
| 23:27.04 | Imhothar | argh I have a grasshopper hiding somewhere in my appartment and it's making damn loud noises |
| 23:28.02 | Noshei | lol |
| 23:35.51 | *** join/#riftuidev seebs (~seebs@home.seebs.net) |
| 23:35.51 | *** mode/#riftuidev [+o seebs] by ChanServ |