| 00:11.04 | *** join/#wowuidev Tentacled (~tentacle@2a00:f41:1c63:415d:0:5b:71ef:9f01) |
| 00:13.37 | *** join/#wowuidev modernist (~mke@2a00:23c5:3481:ed00:c024:8ca:9a8b:b4cc) |
| 00:24.31 | *** join/#wowuidev purl (ibot@rikers.org) |
| 00:24.31 | *** topic/#wowuidev is 7.3.x ToC: 70300 || http://pastebin.com || Battletags: http://goo.gl/2bm7n || This channel is logged, via purl |
| 00:37.01 | *** join/#wowuidev modernist (~mke@2a00:23c5:3481:ed00:c024:8ca:9a8b:b4cc) |
| 01:01.20 | *** join/#wowuidev Seerah (~umsin@2601:3c2:80:1380:64f9:56d6:4219:6d7f) |
| 01:01.21 | *** mode/#wowuidev [+o Seerah] by ChanServ |
| 03:39.17 | *** join/#wowuidev Cairenn (~Karen@MMOI/Administratrix/Cairenn) |
| 03:39.17 | *** mode/#wowuidev [+o Cairenn] by ChanServ |
| 04:08.13 | *** join/#wowuidev Hekili (~Hekili@2601:147:c003:1e30:8a9:6b44:9a87:3525) |
| 04:09.42 | *** join/#wowuidev ls- (~ls@180.183.93.111) |
| 04:30.16 | *** join/#wowuidev ShadniX (dagger@p4FEFCAD8.dip0.t-ipconnect.de) |
| 05:53.33 | *** join/#wowuidev ls- (~ls@180.183.93.111) |
| 05:54.36 | *** join/#wowuidev ls-_ (~ls@223.204.250.56) |
| 06:05.48 | *** join/#wowuidev Varyak (~Varyak@host-188-174-235-114.customer.m-online.net) |
| 06:28.03 | *** join/#wowuidev ccox (~ccox@WoWUIDev/Norganna/Developer/CCox) |
| 06:45.18 | *** join/#wowuidev yalb (xsbot@lua/bot/yalb) |
| 06:46.14 | *** join/#wowuidev g0urra (~g0urra@unaffiliated/gourra) |
| 07:02.27 | *** join/#wowuidev VIad (~Vlad@cm-84.213.146.58.getinternet.no) |
| 07:10.34 | *** join/#wowuidev modernist (~mke@host86-152-200-112.range86-152.btcentralplus.com) |
| 07:59.33 | *** join/#wowuidev bluspacecow (~bluspacec@121.99.98.200) |
| 07:59.33 | *** mode/#wowuidev [+v bluspacecow] by ChanServ |
| 08:17.36 | *** join/#wowuidev ls- (~ls@183.89.4.238) |
| 09:40.03 | *** join/#wowuidev stolenlegacy (~stolenleg@unaffiliated/stolenlegacy) |
| 10:16.37 | nevcairiel | man updating HandyNotes for BfA is going to be annoying for a while to come, especially if I try to keep existing plugins working, because other authors are generally absent =p |
| 10:18.37 | nevcairiel | well, mostly working. if you had notes in a micro dungeon you're j ust screwed |
| 10:19.34 | nebula | why would you be screwed, it's just putting those notes on the proper map now, no? |
| 10:19.59 | nebula | or you're not gonna bother mapping levels and such |
| 10:20.03 | nevcairiel | because HN stored shit by mapFile |
| 10:20.08 | nebula | ah. |
| 10:20.17 | nevcairiel | and mapFiles of microdungeons are a pain |
| 10:20.21 | nevcairiel | so i'm not mapping those |
| 10:20.52 | nevcairiel | luckily most plugins just deal with the actual outdoor zones |
| 10:21.00 | nevcairiel | so it'll be mostly fine |
| 10:22.01 | nevcairiel | i already have like 40kb of data table just to map those values, as well |
| 10:23.40 | nevcairiel | ultimately its all going to get better, but the transition will hurt :p |
| 10:26.00 | nevcairiel | It also doesn't help that the worldmap is still in disarray, not sure I trust a frame thats still called "TestWorldMapFrame" |
| 10:35.21 | *** join/#wowuidev NickG365 (~NickG365@cortex.starlabs.theflash.rocks) |
| 11:19.18 | tz | if only I could have GetDistanceToEJEncounter() |
| 11:39.42 | *** join/#wowuidev modernist (~mke@2a00:23c5:3481:ed00:c024:8ca:9a8b:b4cc) |
| 11:55.12 | *** join/#wowuidev modernist (~mke@2a00:23c5:3481:ed00:c024:8ca:9a8b:b4cc) |
| 12:05.09 | *** join/#wowuidev modernist (~mke@2a00:23c5:3481:ed00:c024:8ca:9a8b:b4cc) |
| 12:09.31 | *** join/#wowuidev modernist (~mke@2a00:23c5:3481:ed00:c024:8ca:9a8b:b4cc) |
| 12:39.55 | *** join/#wowuidev modernist (~mke@2a00:23c5:3481:ed00:c024:8ca:9a8b:b4cc) |
| 12:44.09 | *** join/#wowuidev TentacledOne (~tentacle@2a00:f41:18a2:cafa:0:50:7b38:7401) |
| 13:00.10 | *** join/#wowuidev stolenlegacy (~stolenleg@unaffiliated/stolenlegacy) |
| 13:12.13 | *** join/#wowuidev Tercioo (~Tercioo@185.153.176.3) |
| 13:32.16 | nevcairiel | well i sort of did, simple handynotes plugins work on 8.0 without having to manually re-do their data (although they really should) |
| 14:04.29 | Infus | TheDanW: the bug with the automatic size calculation of FontStrings is not fixed in 8.0. Is that still on your list of known issues? |
| 15:01.24 | *** join/#wowuidev Tentacled (~sinus@87-205-240-1.adsl.inetia.pl) |
| 15:02.03 | Tentacled | Whoa. Is it expected that a GetItemInfo causes an item info event on the same execution path..? O_o |
| 15:03.14 | Tentacled | ...pha\Libs\CallbackHandler-1.0\CallbackHandler-1.0.lua:90: in function `Fire' |
| 15:03.14 | Tentacled | <PROTECTED> |
| 15:03.14 | Tentacled | <PROTECTED> |
| 15:04.09 | Tentacled | I'm quite sure something that causes an event to be fired should NOT call event handlers on the same stack... |
| 15:09.31 | *** join/#wowuidev stolenlegacy (~stolenleg@unaffiliated/stolenlegacy) |
| 15:09.48 | foxlit | why? It's not unusual for functions to trigger events immediately if they're able to do so. |
| 15:12.35 | nevcairiel | indeed |
| 15:12.46 | nevcairiel | changing the world map ie. did that always |
| 15:15.16 | Tentacled | In the same event stack..? Isn't the very purpose of events to be queued..? |
| 15:16.42 | nevcairiel | yeah you could e ven cause a loop if you were doing it wrong |
| 15:18.42 | *** join/#wowuidev Wobin (~wobin@www.thewonder.dog) |
| 15:25.32 | Tentacled | That's what I just did, got a nice C stack overflow. |
| 15:25.56 | Tentacled | I was sure events were fired from some internal dispatcher, on a separate call stack. |
| 15:30.51 | *** join/#wowuidev Andols (~yaaic@m83-185-247-70.cust.tele2.se) |
| 15:32.33 | *** join/#wowuidev g0urra (~g0urra@unaffiliated/gourra) |
| 15:40.54 | *** join/#wowuidev Varyak (~Varyak@ppp-82-135-91-148.dynamic.mnet-online.de) |
| 15:43.06 | Tentacled | I mean, it's either sync or async, you don't mix these... |
| 15:44.50 | Chipzz | Tentacled: "on a separate call stack" that makes 0 sense given they said repeatedly WoW is a mostly single-threaded game because of lua |
| 15:46.01 | Tentacled | How else would you describe "being called after all Lua calls are done and we've gone back to the main program loop"? |
| 15:46.26 | Chipzz | Tentacled: also, "17:15 < Tentacled> In the same event stack..? Isn't the very purpose of events to be queued..?" -> I would answer that with a a solid no |
| 15:47.46 | Chipzz | Tentacled: I've been implementing a WoW emulator over the past 1,5 year... Believe me when I say that firing the events directly makes a lot of sense implementation wise |
| 15:48.29 | Chipzz | currently the only async thing in my emulator is C_Timer |
| 15:48.32 | Tentacled | It may be easier, sure, but to me it looks like it violates some principle of asynchronicity. |
| 15:49.15 | Tentacled | I provide callbacks - or register event handlers - precisely with the purpose of having them called LATER, not right now in the same execution path. |
| 15:49.24 | Chipzz | which principke would that be exactl? and where is your so-called "principle of asynchronicity" stated or explained, but because it sure as hell sounds like sth you made up |
| 15:49.58 | Tentacled | That's why I said "some principle". Of course I made that up. But it doesn't make much sense otherwise. |
| 15:50.19 | Chipzz | well handlers being called "later" (after you SetScrript or whatever) makes sense |
| 15:50.46 | Chipzz | I mean, if calling SetScript would immediatly call the function provided, that would be stupid |
| 15:51.00 | Chipzz | but outside of that what you're saying makes very little sense, if at all |
| 15:51.30 | Tentacled | So would something like, GetItemInfo(12345, function(itemdata) print("I'm a callback",itemdata) end -- wouldn't that be silly, too? |
| 15:51.45 | Chipzz | no |
| 15:52.17 | Chipzz | the callback might be there because Item Info may need a round-trip to the server |
| 15:52.17 | Tentacled | I guess I'm a stickler to my made-up rules. :P |
| 15:52.31 | Chipzz | may being the operative word |
| 15:52.43 | Chipzz | but if the item info is in your local cache, why wait with the callback? |
| 15:52.46 | Tentacled | ^ And that's what I'm talking about. The "may" apparently makes it either a sync or an async call. |
| 15:52.56 | Chipzz | yeah and that makes sense |
| 15:53.08 | Chipzz | you're talking about a very specific function here, not general WoW API |
| 15:53.16 | Tentacled | For the sake of avoiding loops, that's why. I'd definitely want to know if I'm getting an async or sync handling. |
| 15:53.32 | Chipzz | you cannot say there is some blablbabla made up princiuple when you can only give one example |
| 15:54.13 | Tentacled | Oh I can make up a lot of principles, I usually make up at least eight before breakfast. |
| 15:54.38 | Chipzz | I need to remind myself to put you on ignore then ;) |
| 15:54.42 | Tentacled | (Kudos if you catch that reference.) |
| 15:54.58 | Chipzz | I guess I didn't :) |
| 15:55.34 | Tentacled | Blah, it was six, not eight. My bad. |
| 15:55.40 | Chipzz | Tentacled: but the function being either async or sync is exactly why the function doesn't just return the data |
| 15:56.56 | foxlit | hey, don't butcher Carroll. |
| 15:57.03 | Tentacled | foxlit++ |
| 15:58.08 | Tentacled | That seems like a half-conceived idea to me, leaving the function's behavious inconsistent. What's wrong about calling the event handler on the same animation frame, just in a new event cycle? At least it'd ALWAYS be properly async. |
| 15:58.33 | foxlit | now your infinite loop killed the renderer. |
| 15:59.37 | Tentacled | Hmm, indeed. Instead of overflowing the stack. I'm not sure which is better, frankly. :> |
| 16:01.04 | Tentacled | So next frame it is. It wasn't guaranteed to return results on the same frame, so why not assume it's always the next frame? Writing code that tries to assume it's all in the same frame is bad. |
| 16:01.05 | Chipzz | Tentacled: because making it async gthe whole time would be stupuid and hrder implementation wise |
| 16:01.16 | Chipzz | that's why |
| 16:01.16 | Tentacled | Hey, it's already half-async. |
| 16:01.30 | Chipzz | not everything is about ease of use, some things are abot ease of implementation |
| 16:02.01 | Tentacled | If there's already async code there, making an extra shunt down the sync route is extra code. |
| 16:02.13 | Chipzz | no it's not |
| 16:02.46 | Tentacled | How not |
| 16:02.49 | Chipzz | I would suggest actually trying to write sth in C++ / liblua before making such statements |
| 16:03.55 | Tentacled | I would suggest actually asking if I did before making such statements as yours, too. I did, and fixed a bug or two in a C# Lua lib while at that. I'm not talking out of my ass. |
| 16:04.15 | Chipzz | the bottom line is, making stuff async in C/C++ is quite a bit of extra work |
| 16:04.27 | Chipzz | it's obvious you want to avoid that when possible |
| 16:04.35 | Tentacled | But it already IS async, if the item data is not in the cache now. |
| 16:05.42 | Tentacled | The code is there. So having an extra "if (data_already_in_cache) call_event(GIIR,data)" is extra code that - if not present - would just leave it to the (already present) async route to handle. |
| 16:05.51 | Chipzz | how much experiece do you have writing C code? |
| 16:07.27 | Tentacled | I wouldn't know, frankly. On and off, 10 years? 20 for a stretch? I'm not strictly coding in C for a living, it's more like on and off projects every now and then. |
| 16:07.47 | Chipzz | have you ever done sth with, lets say Gtk+? |
| 16:07.58 | Tentacled | Negative. No gtk+. |
| 16:08.09 | Chipzz | have you noticed how almost all of the callbacks there have a last arguement "void *userdata" |
| 16:08.23 | Chipzz | which is because C doesn't have tables/hashes whatever |
| 16:08.51 | Chipzz | C++ std::map does exist, but is prohibitively expensive compared to a simple struct |
| 16:09.20 | Chipzz | so you don't want to pass back a std::map in a callback handler (not as the general case anyway) |
| 16:09.30 | Tentacled | So they're for passing arbitrary stuff, which gives the C side a headache. What about that? |
| 16:09.35 | Chipzz | you need to write a struct to contain the data for the callback |
| 16:10.28 | Chipzz | like I said, a headache on the C side is sth you want to avoid. |
| 16:10.31 | Tentacled | Or decide on a data structure, like you just said. Most APIs define structs or struct-like things in their callback routines, yes. |
| 16:11.07 | Tentacled | Sure, but it seems like you're describing the issues with writing callback mechanisms in general. |
| 16:13.35 | Tentacled | In our case, GetItemInfo already _has_ an async mode, used when the item is not in cache. I'm just surprised it's not used as its only mode of functioning, since it's already there, written, tested, live. |
| 16:13.49 | Chipzz | well, on top of that there's also the interaction with the network part of the game. have less clue about that, but I can imagine that being where the actual complexity you want to avoid is |
| 16:16.48 | Tentacled | I'm just theorycrafting as well, but I imagine GetItemInfo to look, on the inside, like "if (!in_cache(itemid)) { request_item_info(itemid); } else { call_GIIR_handlers(itemid); }". If it were to the ol' me, I'd make request_item_info() just put results immediately into the results queue if they're cached. Simpler, more versatile... Maybe. |
| 16:18.04 | Chipzz | you're contradicting yourself with the last bit |
| 16:18.42 | Chipzz | "just put results immediately into the results queue if they're cached." -> but in your pseudo-code request_item_info is only caled in the non-cached branch |
| 16:20.02 | *** join/#wowuidev modernist (~mke@2a00:23c5:3481:ed00:c024:8ca:9a8b:b4cc) |
| 16:21.41 | *** join/#wowuidev Shooter_ (~osmc@dly142.neoplus.adsl.tpnet.pl) |
| 16:23.00 | Tentacled | The way I'd imagine it improved would get rid of "branches" in the code, reducing it to always call request_item_info and rely on it being smart. |
| 16:27.33 | *** join/#wowuidev modernist (~mke@2a00:23c5:3481:ed00:c024:8ca:9a8b:b4cc) |
| 16:28.18 | Tentacled | An item ID gets pushed into an "actually awaiting those" list. The next check cycle looks in the cache for items in this list. Handlers get called no matter if item data needed a server call to arrive, or it was already there in the first place. |
| 16:28.59 | Tentacled | It'd not be squeezing every cycle out of the CPU, but it'd be loop-proof. |
| 16:29.28 | *** join/#wowuidev modernist (~mke@host86-152-200-112.range86-152.btcentralplus.com) |
| 16:47.01 | *** join/#wowuidev modernist (~mke@2a00:23c5:3481:ed00:c024:8ca:9a8b:b4cc) |
| 16:53.03 | *** join/#wowuidev modernist (~mke@2a00:23c5:3481:ed00:c024:8ca:9a8b:b4cc) |
| 17:03.15 | *** join/#wowuidev modernist (~mke@2a00:23c5:3481:ed00:c024:8ca:9a8b:b4cc) |
| 17:09.16 | *** join/#wowuidev schlumpf (~schlumpf@ip5f5ae509.dynamic.kabel-deutschland.de) |
| 17:15.18 | *** join/#wowuidev modernist (~mke@2a00:23c5:3481:ed00:c024:8ca:9a8b:b4cc) |
| 17:15.26 | TheDanW | Infus: it is, but it's a real tricky one |
| 17:18.29 | Infus | TheDanW: okay, thanks |
| 17:31.26 | *** join/#wowuidev modernist (~mke@2a00:23c5:3481:ed00:c024:8ca:9a8b:b4cc) |
| 18:14.21 | *** join/#wowuidev Andols2 (~yaaic@78-70-44-4-no170.tbcn.telia.com) |
| 18:18.10 | Infus | TheDanW: behold our workaround, and a "fix" for it today: https://github.com/WeakAuras/WeakAuras2/commit/471103124c1099a483d72addddde28145de95f57 |
| 18:25.29 | TheDanW | beautiful |
| 18:31.48 | *** join/#wowuidev Varyak (~Varyak@ppp-82-135-91-148.dynamic.mnet-online.de) |
| 18:57.10 | *** join/#wowuidev modernist (~mke@2a00:23c5:3481:ed00:c024:8ca:9a8b:b4cc) |
| 19:35.26 | *** join/#wowuidev Seerah (~umsin@2601:3c2:80:1380:64f9:56d6:4219:6d7f) |
| 19:35.27 | *** mode/#wowuidev [+o Seerah] by ChanServ |
| 19:42.57 | Fisker | Hey Seerah |
| 19:43.04 | Fisker | Hey friends |
| 19:43.14 | Thunder_Child | What friends? |
| 19:43.44 | Fisker | Torhal is super friend |
| 19:44.11 | Thunder_Child | pfft, Torhal is just a cat filled meat puppet. |
| 19:45.20 | Fisker | Cats are the best |
| 19:50.36 | Tentacled | Raccoons>cats. |
| 20:53.57 | *** join/#wowuidev Ketho (~Ketho@2a02:a44e:ac87:1:908f:90c6:76f7:9b1e) |
| 21:07.27 | *** join/#wowuidev Funkeh` (~Funkeh`@WoWUIDev/WoWAce/Ace3/BigWigs/funkeh) |
| 21:16.19 | nevcairiel | did they screw up a build deploy again? servers are still up on the old one, and it seems to have stopped giving the build out |
| 21:18.09 | Stanzilla | they reverted it |
| 21:18.25 | Stanzilla | check for updates, should revert you too |
| 21:30.58 | Alram | it'll be back when they update servers |
| 21:48.53 | *** join/#wowuidev modernist (~mke@2a00:23c5:3481:ed00:c024:8ca:9a8b:b4cc) |
| 22:04.27 | *** join/#wowuidev modernist (~mke@2a00:23c5:3481:ed00:c024:8ca:9a8b:b4cc) |
| 22:04.49 | *** join/#wowuidev rainrider_wow (bc635451@gateway/web/freenode/ip.188.99.84.81) |
| 22:27.11 | *** join/#wowuidev Semlar (~semlar@72.189.128.149) |
| 22:50.56 | *** join/#wowuidev DiscordBot3 (~DiscordBo@schwingendesphoenix.org) |
| 22:51.21 | *** join/#wowuidev schlumpf_ (~schlumpf@ip5f5ae509.dynamic.kabel-deutschland.de) |
| 23:23.19 | foxlit | on the bright side, 8.0 fixed the .minWidth bug. |
| 23:44.02 | Funkeh` | foxlit: what bug was that |
| 23:46.04 | foxlit | the one where a dropdown menu's info.minWidth would promptly be ignored, resulting in some rather silly widget layout. |
| 23:58.49 | zenzelezz | more like weirdget |