| 01:14.01 | *** join/#wowuidev Seerah (~umsin@75-36-111-192.lightspeed.mmphtn.sbcglobal.net) |
| 01:14.01 | *** mode/#wowuidev [+o Seerah] by ChanServ |
| 05:22.50 | *** join/#wowuidev Andols (~yaaic@217-209-12-6-no170.tbcn.telia.com) |
| 05:40.13 | *** join/#wowuidev Seerah (~umsin@75-36-111-192.lightspeed.mmphtn.sbcglobal.net) |
| 05:40.14 | *** mode/#wowuidev [+o Seerah] by ChanServ |
| 05:48.48 | *** join/#wowuidev Andols (~yaaic@217-209-12-6-no170.tbcn.telia.com) |
| 06:00.52 | *** join/#wowuidev Andols2 (~yaaic@2a00:801:42e:992f:17cb:88:a24f:5a46) |
| 07:29.08 | *** join/#wowuidev greedom (~greedom@muedsl-82-207-236-128.citykom.de) |
| 08:26.13 | *** join/#wowuidev AcidWeb1 (~AcidWeb@londe.iosphe.re) |
| 11:19.39 | *** join/#wowuidev stolenlegacy (~stolenleg@unaffiliated/stolenlegacy) |
| 13:23.33 | *** join/#wowuidev Breen (~Breen@80.175.117.105) |
| 13:52.22 | *** join/#wowuidev LexAwayFromHome (~lexlexlex@154.5.197.130) |
| 14:25.53 | *** join/#wowuidev Tentacled (~androirc@2a00:f41:18cb:27fe:0:4c:6f6a:ef01) |
| 14:27.36 | Tentacled | Bah. I need to get myself a shell one of these days. Anyway, what's up with C_AH.ReplicateItems being useless..? |
| 15:27.44 | *** join/#wowuidev Funkeh` (~Funkeh`@WoWUIDev/WoWAce/Ace3/BigWigs/funkeh) |
| 15:57.38 | *** join/#wowuidev Tentacled (~sinus@159-205-234-125.adsl.inetia.pl) |
| 16:37.19 | *** join/#wowuidev harl (~harl@unaffiliated/harl) |
| 16:43.30 | *** join/#wowuidev Andols (~yaaic@217-209-12-6-no170.tbcn.telia.com) |
| 17:06.56 | *** join/#wowuidev Andols (~yaaic@217-209-12-6-no170.tbcn.telia.com) |
| 17:39.32 | *** join/#wowuidev Andols (~yaaic@217.209.12.6) |
| 18:34.51 | *** join/#wowuidev greedom (~greedom@muedsl-82-207-236-128.citykom.de) |
| 18:54.09 | *** join/#wowuidev Sonicbit (~Sonicbit@unaffiliated/sonicbit) |
| 20:06.05 | foxlit | https://www.townlong-yak.com/box/dysqQc << so I wrote this to solve the link copy/paste problem I had earlier. |
| 20:07.49 | foxlit | I say solve, but it's really a half-solution that works for my use case: I essentially substitute the text with an alternate representation that is safe to copy when you press ctrl-c, and do nothing on paste. |
| 20:09.15 | Ennea | foxlit, does line 27 work on mac also? |
| 20:09.22 | foxlit | yes. |
| 20:09.25 | Ennea | interesting |
| 20:10.22 | Ennea | nifty workaround |
| 20:13.28 | foxlit | if I could have nice client API things, I'd appreciate editBox:Insert(text[, highlightInsertion]), editBox:GetHighlightRange() to match the editBox:HighlightText(start, end) setter, and a non-hacky way to schedule code to run before the current frame is rendered (like the old C_Timer.After(0, ...) ). |
| 20:28.21 | *** join/#wowuidev Sonicbit_ (~Sonicbit@unaffiliated/sonicbit) |
| 20:35.11 | *** join/#wowuidev Fisker (~Fisker-@185.109.91.253) |
| 20:45.00 | Ennea | ah, you used to be able to invoke C_Timer.After with 0 to have code run before the next frame? that is p cool |
| 20:45.07 | Ennea | did blizz tell us why they removed that? |
| 21:05.39 | *** join/#wowuidev Sonicbit (~Sonicbit@unaffiliated/sonicbit) |
| 21:06.11 | foxlit | it's an obvious infinite delay footgun that doesn't run out of stack. |
| 21:07.28 | Ennea | heh.. oh well |
| 21:12.31 | foxlit | (but to be fair so is "repeat until nil" and nobody is getting rid of while loops, so maybe just don't shoot yourself in the foot?) |
| 21:13.30 | Ennea | yea, i prefer the "don't shoot yourself in the foot" stance for sure |
| 21:23.17 | *** join/#wowuidev Seerah (~umsin@75-36-111-192.lightspeed.mmphtn.sbcglobal.net) |
| 21:23.17 | *** mode/#wowuidev [+o Seerah] by ChanServ |
| 21:34.07 | *** join/#wowuidev Elmoe (~Elmoe@24.18.143.238) |
| 21:34.28 | *** join/#wowuidev Sonicbit_ (~Sonicbit@unaffiliated/sonicbit) |
| 21:38.43 | *** join/#wowuidev Sonicbit (~Sonicbit@unaffiliated/sonicbit) |
| 22:10.54 | *** join/#wowuidev Sonicbit_ (~Sonicbit@unaffiliated/sonicbit) |
| 23:05.06 | TheDanW | the reason the After(0, ...) was changed was because there was no guarantee it would be invoked this frame vs the next frame, it was somewhat "random" from the callers perspective, depending on its internal state, this meant that during testing it everything seemed great because it was "always" executed the next frame, but with sufficiently complex timer usage it would be executed the same frame causing an infinite loop |
| 23:07.04 | nevcairiel | what does it do now? execute immediately? |
| 23:07.18 | TheDanW | always delays |
| 23:10.28 | foxlit | "sufficiently complex timer usage" sounds like silly code. |
| 23:13.34 | foxlit | You might want to guarantee that C_Timer.After(>0) never runs during the current frame, but if someone is explicitly using a zero duration, the intention is pretty clear. |
| 23:13.41 | TheDanW | or several addons interacting with the system |
| 23:16.14 | nevcairiel | One might think a "complete" timer system may have facilities to control runtime and perhaps not bog down the main loop too much, so that it has allowances for letting a frame render before it runs the next timer, so if too many timers want to run "now", one of them may shift to the next frame |
| 23:57.46 | foxlit | Maybe it could've punted only the timers that were queued after it started executing timers for this frame. |