00:04:41 -!- wvc2 is now known as wvc 00:13:31 Unstable branch on cbro.berotato.org updated to: 0.34-a0-1788-g328cd5380e (34) 00:50:45 Nnyef (L12 TrSh) Crash caused by signal #11: Segmentation fault (Volcano) 00:51:06 Nnyef (L12 TrSh) Crash caused by signal #11: Segmentation fault (Volcano) 00:59:34 03dolorous02 07* 0.34-a0-1789-g376ce8f1ef: Add a few religious arguments to graffiti. 10(21 minutes ago, 1 file, 18+ 0-) 13https://github.com/crawl/crawl/commit/376ce8f1ef5e 00:59:34 03dolorous02 07* 0.34-a0-1790-g9edff1cd0f: Clarify a comment. 10(2 minutes ago, 1 file, 4+ 2-) 13https://github.com/crawl/crawl/commit/9edff1cd0fae 01:30:03 StonerKitturk (L13 KoBr) Crash caused by signal #11: Segmentation fault (Volcano) 01:30:28 StonerKitturk (L13 KoBr) Crash caused by signal #11: Segmentation fault (Volcano) 01:30:46 StonerKitturk (L13 KoBr) Crash caused by signal #11: Segmentation fault (Volcano) 01:39:50 StonerKitturk (L13 KoBr) Crash caused by signal #11: Segmentation fault (Volcano) 01:40:07 StonerKitturk (L13 KoBr) Crash caused by signal #6: Aborted (Volcano) 01:40:33 StonerKitturk (L13 KoBr) Crash caused by signal #6: Aborted (Volcano) 01:40:41 StonerKitturk (L13 KoBr) Crash caused by signal #11: Segmentation fault (Volcano) 01:40:49 StonerKitturk (L13 KoBr) Crash caused by signal #6: Aborted (Volcano) 01:40:57 StonerKitturk (L13 KoBr) Crash caused by signal #11: Segmentation fault (Volcano) 03:17:25 -!- wvc0 is now known as wvc 03:23:09 -!- wvc2 is now known as wvc 03:41:25 -!- wvc5 is now known as wvc 04:33:11 Experimental (bcrawl) branch on underhound.eu updated to: 0.23-a0-5261-gd9800d219b 05:11:15 Unstable branch on crawl.akrasiac.org updated to: 0.34-a0-1790-g9edff1c (34) 07:58:12 03dolorous02 07* 0.34-a0-1791-g9794acd101: Rename a graffiti tag. 10(37 minutes ago, 1 file, 5+ 6-) 13https://github.com/crawl/crawl/commit/9794acd101fb 07:58:12 03dolorous02 07* 0.34-a0-1792-g3e525b69aa: Add more references to hailed gods. 10(26 minutes ago, 1 file, 10+ 3-) 13https://github.com/crawl/crawl/commit/3e525b69aa28 07:58:12 03dolorous02 07* 0.34-a0-1793-ge33a68bbb2: Reweight god references in unreadable graffiti. 10(11 minutes ago, 1 file, 2+ 0-) 13https://github.com/crawl/crawl/commit/e33a68bbb2e3 07:58:12 03dolorous02 07* 0.34-a0-1794-gfd447d0384: Move "a wagon full of pancakes" into hailed gods. 10(7 minutes ago, 1 file, 6+ 6-) 13https://github.com/crawl/crawl/commit/fd447d03848a 08:13:12 03dolorous02 07* 0.34-a0-1795-g13829917ae: Reweight more god references; update a comment. 10(6 minutes ago, 1 file, 9+ 7-) 13https://github.com/crawl/crawl/commit/13829917ae49 08:13:12 03dolorous02 07* 0.34-a0-1796-gf8a9312393: Add another writing adjective to graffiti. 10(4 minutes ago, 1 file, 2+ 0-) 13https://github.com/crawl/crawl/commit/f8a93123932a 08:35:41 03dolorous02 07* 0.34-a0-1797-gbcc3919a4b: Add another unreadable graffiti line. 10(68 seconds ago, 1 file, 2+ 0-) 13https://github.com/crawl/crawl/commit/bcc3919a4b95 08:56:01 03dolorous02 07* 0.34-a0-1798-g7de7c6ff57: Add another writing adjective to graffiti. 10(9 minutes ago, 1 file, 2+ 0-) 13https://github.com/crawl/crawl/commit/7de7c6ff57bf 08:56:01 03dolorous02 07* 0.34-a0-1799-g9247e96862: Move a glowing adjective to a writing adjective. 10(6 minutes ago, 2 files, 2+ 2-) 13https://github.com/crawl/crawl/commit/9247e96862b7 09:20:35 03dolorous02 07* 0.34-a0-1800-gda3c44569b: Add comments about possible name/word overlaps. 10(13 minutes ago, 3 files, 9+ 2-) 13https://github.com/crawl/crawl/commit/da3c44569bf7 10:50:48 <09gammafunk> giving an update on my investigations on this wonderful volcano crash 10:52:36 <09gammafunk> what's happening is that there is a function returned by a single call to Triggerable.synchronized_markers(primary), where here primary is the collapse_marker variable in the map's main lua chunk 10:53:18 <09gammafunk> This is fine/normal, and the returned function is called repeatedly as each marker is placed, which is also fine/normal 10:54:52 <09gammafunk> What's not fine/normal is that this function is a closure with an upvalue first, that's internal to that first function call to synchoronized_markers, and this first upvalue is somehow not retaining changes from subsequent calls to the returned function/closure 10:55:32 <09gammafunk> so every single call to the closure is seeing first as true and is thus creating a new primary marker instead of creating a replica on subsequent calls (after the first call) 10:55:53 <09gammafunk> this is despite the closure attempting to set first to false each time 10:55:57 <09gammafunk> it is called 10:56:57 <09gammafunk> I've verified that in 0.33 the closure works normally and makes replicas as it should for calls after the first one (because first is properly being updated via the closure) 10:57:48 <09gammafunk> so I'm going to keep investigating as to why this is happening, but if someone has an idea, feel free to speak up 11:10:56 <04dracoomega> Makes me wonder a little if scoping rules for closures have somehow changed between lua versions (though investigating the manual for each version does not seem to suggest this is the case). (I am not very familiar with any of this, but took a brief look after what you said) 11:14:49 <09gammafunk> yes, I should look through the version changes from 5.1->5.4 to that end 11:15:43 <09gammafunk> but it's hard to see how this closure could work differently. It may be some artifact of how these lua marker chunks are being loaded/run after the upgrade to 5.4 11:19:59 <04dracoomega> You did say that - at some point, somehow - things that should be in global tables stop being there. (ie: the 'launch second game crashes' bug), which implies some change in how loading is handled. (Might be irrelevantly unrelated, but since I don't think that part is understood yet, either, who knows?) 11:21:05 <09gammafunk> yes, I thought of this as well when realizing what was happening 11:21:33 <09gammafunk> it's just that this first variable is not in the global env; it's an upvalue 11:22:18 <09gammafunk> and it's being seen properly as true each time, it's just that changes to its value are not reflected in subsequent calls to the closure 11:58:39 <07wizardike> Does anyone know how often CPO is meant to update? It doesn't seem to have updated in about a week if I'm reading the version in my morgue correctly https://crawl.project357.org/morgue/Wizard1ke/morgue-Wizard1ke-20251213-181949.txt 12:06:18 <04dracoomega> The learndb rebuild entry claimed it was every 15 minutes. Even if that is no longer true, going that long sounds like some other issue. 13:00:03 StonerKitturk (L13 KoBr) Crash caused by signal #11: Segmentation fault (Volcano) 13:09:30 yidoboi (L11 MiFi) Crash caused by signal #11: Segmentation fault (Volcano) 13:09:56 StonerKitturk (L13 KoBr) Crash caused by signal #11: Segmentation fault (Volcano) 13:10:06 StonerKitturk (L13 KoBr) Crash caused by signal #11: Segmentation fault (Volcano) 13:10:13 StonerKitturk (L13 KoBr) Crash caused by signal #6: Aborted (Volcano) 13:10:24 StonerKitturk (L13 KoBr) Crash caused by signal #6: Aborted (Volcano) 13:10:45 StonerKitturk (L13 KoBr) Crash caused by signal #11: Segmentation fault (Volcano) 13:10:53 StonerKitturk (L13 KoBr) Crash caused by signal #11: Segmentation fault (Volcano) 13:11:00 StonerKitturk (L13 KoBr) Crash caused by signal #11: Segmentation fault (Volcano) 13:11:36 StonerKitturk (L13 KoBr) Crash caused by signal #11: Segmentation fault (Volcano) 13:14:06 <09gammafunk> I have a fix to prevent this crash for new instances of the map, but I need to make a fix to deal with existing instances 13:15:02 <09gammafunk> I'm leaning towards making our C++ listener code more robust to lua shenanigens where markers get removed, thereby deconstructing the marker and a potential listener 13:15:21 <09gammafunk> which is how our errant lua code is causing the crash 13:35:42 StonerKitturk (L13 KoBr) Crash caused by signal #11: Segmentation fault (Volcano) 15:41:27 StonerKitturk (L13 KoBr) Crash caused by signal #6: Aborted (Volcano) 15:55:31 03gammafunk02 07* 0.34-a0-1801-g53a2113884: Add dlua errors to crash dumps 10(2 days ago, 1 file, 8+ 0-) 13https://github.com/crawl/crawl/commit/53a2113884ec 15:55:31 03gammafunk02 07* 0.34-a0-1802-ga9a8b13fb6: Fix crashing volcano triggers 10(40 minutes ago, 3 files, 23+ 6-) 13https://github.com/crawl/crawl/commit/a9a8b13fb635 15:57:46 <09gammafunk> just gonna wait for CI to finish until I rebuild servers 16:01:22 <04dracoomega> So, no luck on figuring out what is going on with that upvalue, it looks like? 16:02:04 <04dracoomega> (I mean, fingers crossed that isn't necessary with this other infrastructure in place, but it certainly doesn't leave one feeling altogether comfortable) 16:02:30 <09gammafunk> no, I'm not sure if you read my commit message, but the behaviour is quite odd 16:02:37 <04dracoomega> I did read it, yes 16:03:42 <09gammafunk> if it's not clear, if you add above that test of the first upvalue a call to e.g. crawl.mpr() (or some IO function e.g. in the lua io library...I think it just has to exit the lua "context"), then the upvalue sees changes 16:05:02 <09gammafunk> I discovered this when using (inside the closure itself) lua's bundled debug library in as debug2 (we override debug in dlua with our own stuff) and using it to grab basic info about upvalues 16:05:35 <09gammafunk> it showed that it had e.g. 4 upvalues, it showed that the second was first and then...the closures just started working as they should 16:05:51 <09gammafunk> just by adding this debugging code above what was previously the first line 16:07:09 <09gammafunk> one thing that changed in 5.2 was that C functions and user data no longer have environments and have their own facilities for upvalue-like data, but neither case is relevant here; this is just a normal lua function 16:08:08 <09gammafunk> I will keep fixing lua bugs (we have issues with cloud gen and I think at least one wizlab) but the lua-side behaviour is strange and concerning 16:11:47 <04dracoomega> Yeah, that's... it feels like there something fundamentally off somewhere along the line (but I certainly have no insight about what that might be) 16:42:22 Unstable branch on underhound.eu updated to: 0.34-a0-1802-ga9a8b13fb6 (34) 16:50:10 Unstable branch on crawl.akrasiac.org updated to: 0.34-a0-1802-ga9a8b13fb6 (34) 17:39:48 <09gammafunk> ...wow...I just got totally bamboozed by a cloud marker bug that (apparently) isn't a bug at all.. 17:39:54 <09gammafunk> something about clouds has changed so that 17:40:03 <09gammafunk> cpp static bool _cloudable(coord_def loc, cloud_type ctype) { const cloud_struct *cloud = cloud_at(loc); return in_bounds(loc) && !cell_is_solid(loc) && (!cloud || cloud_is_stronger(ctype, *cloud)) && (!is_sanctuary(loc) || is_harmless_cloud(ctype)) && cell_see_cell(you.pos(), loc, LOS_NO_TRANS); } 17:40:24 <09gammafunk> the basic test that the cloud targeter uses when trying the place clouds has changed 17:41:02 <09gammafunk> this disallows cloud generators from placing multiple clouds if the player doesn't currently have los_no_trans with the potential location 17:41:18 <09gammafunk> which is pretty misleading for cloud generators behind glass 17:42:38 <09gammafunk> apparently this has been since 17:42:41 <09gammafunk> %git 2322c75162bbdf8f462a95944074f8b621df7580 17:42:42 <04Cerebot> PleasingFungus * 0.28-a0-487-g2322c75162: Fix cloud targeters (CarefulOdds) (4 years, 3 months ago, 1 file, 2+ 1-) https://github.com/crawl/crawl/commit/2322c75162bb 17:43:46 <09gammafunk> it seems undesirable for cloud generators (i.e. ones operating through markers) to care about the player's los when placing clouds 17:44:06 <09gammafunk> so we should probably have an override for the targeter to ignore that condition when it's used for the purpose of cloud generators 17:44:16 <09gammafunk> so I guess the last hour hasn't been totally wasted... 19:29:06 <04dracoomega> I have definitely noticed some very weird player-centric behavior regarding cloud generators in past 19:29:54 <04dracoomega> (Like, it felt like the places some things would place would 'move' with the player in some fashion - possibly due to LoS change? 19:30:53 <09gammafunk> yeah, that sounds plausible 19:32:08 <09gammafunk> I'm going to start working on that important "reinitialization" crash now, but I think an easy fix for the cloud application issue is just to have a "dungeon" mode for instantiating the targeter that relaxes the player LOS_NO_TRANS check and then have the dlua cloud function use this 19:32:39 <09gammafunk> well I guess I have to add this mode both to the targeter and to the apply_area_cloud function function, but either way 19:32:39 <04dracoomega> That does make sense to me, yes 19:32:53 <04dracoomega> Seems conceptually straightforward and reasonable 19:33:08 <09gammafunk> it's sort of regrettable how the dungeon cloud function is even using this targeter; feels a bit wrong to me, since targeters are inherently an actor thing? 19:33:22 <09gammafunk> seems a bit like an abuse of the design, but changing that would be a bigger refactor 20:56:55 <09gammafunk> %git 20:56:55 <04Cerebot> gammafunk * 0.34-a0-1802-ga9a8b13fb6: Fix crashing volcano triggers (6 hours ago, 3 files, 23+ 6-) https://github.com/crawl/crawl/commit/a9a8b13fb635 23:34:46 Unstable branch on crawl.develz.org updated to: 0.34-a0-1802-ga9a8b13fb6 (34) 23:55:04 Windows builds of master branch on crawl.develz.org updated to: 0.34-a0-1802-ga9a8b13fb6