01:05:53 03PleasingFungus02 07* 0.26-a0-834-g69557b8: Remove skill training restrictions (hellmonk) 10(6 minutes ago, 9 files, 57+ 64-) 13https://github.com/crawl/crawl/commit/69557b85ccba 01:22:09 -!- amalloy is now known as amalloy_ 01:32:33 Unstable branch on crawl.kelbi.org updated to: 0.26-a0-834-g69557b85cc (34) 01:53:12 Windows builds of master branch on crawl.develz.org updated to: 0.26-a0-834-g69557b85cc 02:44:34 Unstable branch on cbro.berotato.org updated to: 0.26-a0-834-g69557b85cc (34) 02:53:04 Monster database of master branch on crawl.develz.org updated to: 0.26-a0-834-g69557b85cc 03:31:08 Fork (bcrawl) on crawl.kelbi.org updated to: 0.23-a0-3681-ga1082b90cb 09:32:40 -!- amalloy_ is now known as amalloy 09:46:09 03advil02 07[targeted-commands] * 0.26-a0-877-ge5cf44a: First-pass implementation for quivering abilities 10(5 minutes ago, 7 files, 309+ 57-) 13https://github.com/crawl/crawl/commit/e5cf44a9de55 09:46:19 Branch pull/1581 updated to be equal with targeted-commands: 13https://github.com/crawl/crawl/pull/1581 09:57:48 04Build failed for 08targeted-commands @ e5cf44a9 06https://github.com/crawl/crawl/actions/runs/366208679 11:11:20 %git a1a73b7a55c 11:11:20 07advil02 * 0.26-a0-713-ga1a73b7: Improve Text wrap recalculation checks 10(2 weeks ago, 2 files, 38+ 4-) 13https://github.com/crawl/crawl/commit/a1a73b7a55c1 11:11:48 ^ that has the unfortunate side effect of causing text widgets to never rewrap when expanding 11:13:21 it's possible that other fixes I did later make that one less necessary 11:13:41 though all that commit does is cache more, so resizing should invalidate the cache 11:26:18 03PleasingFungus02 07* 0.26-a0-835-g8259106: Partially fix skill menu (dinky) 10(66 seconds ago, 1 file, 1+ 1-) 13https://github.com/crawl/crawl/commit/8259106e1431 11:32:24 Unstable branch on crawl.kelbi.org updated to: 0.26-a0-835-g8259106e14 (34) 11:46:31 reverting that commit does fix the issue though 12:01:02 I did actually test that case, is it possible something else is going on? 12:01:19 it should rewrap, if the previous calculation involved a size constraint and the new one is bigger 12:01:44 if the previous calculation imposed no size constraint the assumption is that it's already as wide as it will get 12:02:53 it's possible there's a mistake in the logic 12:07:10 just reading the code I'm not seeing one though (though the logic ended up a bit complicated) 12:08:43 to prevent rewrapping, the last requested size has to be greater than the last calculated size (or 0), and the current requested size has to be less than or equal to the current cached size 12:08:57 or 0 12:09:57 "current cached size" is the same as "last calculated size" in that description 12:10:48 the previous caching thing was mostly broken btw because it didn't handle 0 12:13:56 the logic looks roughly correct to me as well 12:23:35 hm, ok it looks vaguely incorrect after some experimentation 12:25:00 to clarify, the intent is to return early if the input max-width is in the range [prev wrapped width, prev input max-width], right? 12:25:59 and same for height, of course 12:26:17 no...if max-width >= prev wrapped width and prev wrapped width < prev max width 12:26:21 Unstable branch on crawl.akrasiac.org updated to: 0.26-a0-835-g8259106 (34) 12:26:56 the latter condition `prev wrapped width < prev max width` must be true by definition, no? 12:27:35 hm I think I was assuming it does exact truncation, but maybe it doesn't 12:28:37 prev wrapped width <= prev max width is true by definition 12:29:06 but if no linebreaks end up exactly at max_width then yeah < won't work very well 12:30:55 ah, right 12:31:52 apart from that, you still need to compare the current sizereq with the prev one, and recalculate fully if the current sizereq is larger 12:32:17 which the current code doesn't do 12:33:20 if the previous sizereq was bigger than a size that would force any line wrapping, there's no need to recalculate 12:34:15 i mean the opposite: if the previous sizereq is smaller 12:34:29 if the previous sizereq did not force wrapping, and the current sizereq is bigger than the previous one? 12:35:21 not sure what you mean by 'did not force wrapping' 12:35:41 was big enough that no linewrapping was needed to fit 12:36:53 shouldn't make any difference 12:37:32 why would you need to recalculate if you're guaranteed to not need to do any extra linewrapping? 12:38:24 by previous sizereq, I mean m_wrapped_sizereq 12:39:52 if the new sizereq is wider than that, we may very well need to wrap *less* 12:39:52 but if there was no wrapping at all in the first place, you can't wrap less? 12:39:52 I feel like I'm missing something here 12:40:27 I mean, yeah, I do think it isn't calculating correctly whether there was any wrapping in the cached version 12:41:36 an input width request R will wrap the text if it's not already wrapped, and that text will have width W, with W <= R 12:42:11 for subsequent requests, if R' is in [W, R], we can just return the same wrapped text 12:42:38 and we don't need to update the endpoints W and R of this range 12:43:39 if R' < W, we definitely have to rewrap, and if R' > R, we *may* have to rewrap 12:45:27 we can't know if, after rewrapping at R' and getting a wrapped width W', if W' == W without just going ahead and doing the rewrapping 12:49:00 if you know that at width R, there was no linebreaking/truncation imposed, then for R' > R you know you don't have to rewrap 12:49:27 actually this is kind of academic but the relevant case that actually does come up is where R' = 0 12:49:35 er, R = 0 12:51:09 you don't *have* to rewrap for R' greater than R, but that's the bug: R' > R isn't rewrapped, so text widgets never expand again 12:51:39 I think the bug is that I didn't calculate where there was linebreaking in the cache correctly 12:52:07 you shouldn't need to actually care where the linebreaks are in the cached wrapped string 12:52:15 ...i don't think, anyway 12:52:22 if there are none it's kind of useful 12:52:29 (that's the normal case that happens a lot) 12:52:39 well, I didn't widely test Text uses 12:52:50 it doesn't affect this caching behaviour though 12:53:00 oh it most definitely does :-) 12:53:15 what I was trying to optimize is the behavior on &ctrl-l on a debug build with very long levelgen outputs 12:53:37 that's different, that's the caching behaviour affecting this :) other way around 12:54:50 so i don't usually build with fulldebug, but I imagine there's many hard linebreaks? 12:54:57 the normal sequence of calls there was ~ 3 calls of this function, first with width 0, then with some giant number (maybe the entire window width?) and then with the number calculated from one or both of the previous calls 12:55:12 iirc 12:55:14 yes, and very many lines 12:56:00 it's possible that this doesn't need to be optimized at all any more with the other lower level fixes 12:56:42 then i'm surprised this caching works at all for resizing, since if there's much variation in the line content, you'd expect the wrapped width to always be very close to the sizereq width 12:59:39 advil: did you consider setting FS_PREWRAPPED_TEXT on the scroller? 13:01:11 no, what does that do? 13:01:29 you pre-wrap the text once, and it disables line-wrapping 13:02:19 the message window uses it; resizing the text widget is way too slow otherwise 13:02:58 well, useful to know about 13:03:00 %git 10d74db38bc 13:03:00 07advil02 * 0.26-a0-714-g10d74db: Lower a polynomial for linewrapping in local tiles 10(2 weeks ago, 1 file, 5+ 4-) 13https://github.com/crawl/crawl/commit/10d74db38bc1 13:03:29 the slowness was probably not unrelated to that 13:03:45 %git 33af53a8 13:03:45 07advil02 * 0.26-a0-715-g33af53a: Fix another slowdown in wrapping large strings 10(2 weeks ago, 1 file, 1+ 1-) 13https://github.com/crawl/crawl/commit/33af53a816aa 13:03:46 and that 13:04:05 but still, that does explain why the builder log seemed so different from ctrl-p in my testing (I just assumed it was longer) 13:04:21 oh i see what you mean by the presence of linebreaks 13:04:26 fwiw with those fixes they are comparable now 13:05:15 wow, that's pretty incredible 13:05:50 I didn't necessarily mess with resizing a lot 14:21:40 03advil02 07[targeted-commands] * 0.26-a0-878-gf5f79f0: Let staff of olgreb use the static targeter when needed 10(33 seconds ago, 2 files, 5+ 5-) 13https://github.com/crawl/crawl/commit/f5f79f047e38 14:21:50 Branch pull/1581 updated to be equal with targeted-commands: 13https://github.com/crawl/crawl/pull/1581 14:32:39 04Build failed for 08targeted-commands @ f5f79f04 06https://github.com/crawl/crawl/actions/runs/366674672 14:36:01 03advil02 07[targeted-commands] * 0.26-a0-879-gbc12b69: Fix a tag upgrade issue 10(40 seconds ago, 1 file, 0+ 1-) 13https://github.com/crawl/crawl/commit/bc12b6951877 14:36:11 Branch pull/1581 updated to be equal with targeted-commands: 13https://github.com/crawl/crawl/pull/1581 18:22:04 Unstable branch on underhound.eu updated to: 0.26-a0-835-g8259106e14 (34) 19:34:09 is there anyone out there who does not #define CLUA_BINDINGS? 19:34:09 sort of tempted just to remove that flag 19:44:09 03advil02 07[targeted-commands] * 0.26-a0-880-g31f85d6: add CMD_AUTOFIRE to `p` 10(6 minutes ago, 1 file, 4+ 1-) 13https://github.com/crawl/crawl/commit/31f85d6bf7ba 19:44:09 03advil02 07[targeted-commands] * 0.26-a0-881-gab44609: Don't show item letters for actions in quiver 10(72 seconds ago, 1 file, 1+ 8-) 13https://github.com/crawl/crawl/commit/ab44609ca6b7 19:44:19 Branch pull/1581 updated to be equal with targeted-commands: 13https://github.com/crawl/crawl/pull/1581 19:47:33 04Build failed for 08targeted-commands @ ab44609c 06https://github.com/crawl/crawl/actions/runs/367134251 19:51:38 04Build failed for 08targeted-commands @ ab44609c 06https://github.com/crawl/crawl/actions/runs/367134251 19:53:26 hmm looks like that thing they kept threating to disable (add-path) finally got disabled 20:06:11 -!- elliptic__ is now known as elliptic 20:29:27 Blackmore (L16 TrBe) ERROR in 'mon-movetarget.cc' at line 115: ZotDef: monster ice statue failed to pathfind to (39,17) (the Orb) (Zot (ZotDef)) 20:29:36 Blackmore (L17 TrBe) ERROR in 'mon-movetarget.cc' at line 115: ZotDef: monster oklob plant failed to pathfind to (39,17) (the Orb) (Zot (ZotDef))