00:01:04 is it possible to set the seed of catch2? 00:01:38 i can set srand of cstdlib, but catch2 use srand to set seed from a config 00:03:57 catch2 contain a SimplePcg32 00:04:12 with the default initial state of 0xed743cc4U 00:04:58 and a github issue says Catch2 would re-initialize the rng with the same seed in each test. 00:05:21 oh. it can. 00:05:29 SimplePcg32 has a seed method 00:06:27 ugh. it has two SimplePcg32, called s_rng and m_rng 00:06:54 reading the source to figure this out is stupid 00:07:04 but google doesn't give me the answer. 00:09:39 If it has a fixed seed then that's already enough 00:11:11 usually i just throw lots of random numbers at a test if it is fast without setting a constant seed 00:11:40 that and plus a few hand-picked values 00:50:24 -!- Yermak_ is now known as Yermak 00:57:19 dgn.create_monster(5, 5, "random") seems to always give 00:58:12 env.mons[0].name(DESC_PLAIN, true) 00:58:36 I mean env... always say the "random" monster is a "DEAD MONSTER" 00:58:56 env.mons[0].type is always 1000 01:05:58 nope. not deterministic. 01:06:22 dgn.create_monster(5, 5, "orc / bat") 01:07:16 doesn't always give orc 01:16:16 crawl_state.seed = you.game_seed = Options.seed = 729 01:16:54 still stays the same 01:16:54 maybe dLua and cLua also have seeds? 01:16:57 but then dgn.create_monster is actually implemented in c++ 01:21:18 Experimental (bcrawl) branch on underhound.eu updated to: 0.23-a0-3603-ge1cc4b0452 01:34:31 Unstable branch on crawl.develz.org updated to: 0.26-a0-682-g294304f6e8 (34) 01:55:17 Windows builds of master branch on crawl.develz.org updated to: 0.26-a0-682-g294304f6e8 02:53:38 Monster database of master branch on crawl.develz.org updated to: 0.26-a0-682-g294304f6e8 03:31:25 Fork (bcrawl) on crawl.kelbi.org updated to: 0.23-a0-3603-ge1cc4b0452 03:31:59 Fork (bcadrencrawl) on crawl.kelbi.org updated to: 0.22.1-3082-g9265d4071b 03:53:51 -!- amalloy is now known as amalloy_ 07:16:56 Does a webtiles or web console game know what server it's on? If not is there a way to tell it? 08:02:37 I suspect the usual lua tests don't have a fixed random seed. 08:06:54 setup_step() calls _initialize() in startup.cc, which run the lua tests. But calls to rng::reset() is in _setup_generic(...) in ng-setup.cc, which is called in setup_game(), which happens after setup_step() calls _initialize(). 08:07:20 the whole game only has one call to rng::reset(). 08:13:52 maybe one more call to rng::reset() as part of a lua command. 09:13:17 the lua tests have a fixed seed 09:19:59 they call debug.reset_rng 09:20:25 i think that is the case because the game has two calls to rng::reset() 09:20:45 one of them is in l-debug.cc 09:24:16 03CrawlCycle02 07https://github.com/crawl/crawl/pull/1590 * 0.26-a0-702-g6320759: feat: Allow setting seed for crawl's rng 10(12 minutes ago, 3 files, 97+ 8-) 13https://github.com/crawl/crawl/commit/6320759081e7 09:25:44 the tests of the fixture performs many setup and teardown steps 09:26:12 uh 09:26:23 while i think the fixture is fast enough for normal usage, in the test of the fixture, it is a bit slow. 09:26:35 advil? 09:26:41 what is up with that commit 09:26:58 commit to my pull request 09:27:10 there's already code to set the seed 09:27:24 that is setting seed in the fixture 09:27:29 there's already a test for the rng 09:28:37 aidanh want the fixture to set the seed 09:28:53 to make sure any test that use the fixture would always give the same result 09:29:11 so I add that feature 09:30:14 if you call rng::seed with a uint64_t it will set the seed 09:31:37 maybe that will work. i did a cutdown version of crawl's initialization 09:31:47 so i set a fake command line argument that set the seed 09:32:06 the Options, you.game_seed are all the same 09:32:34 and then i use rng::reset(), as in ng-setup.cc 09:32:55 basically, i try to do it the same way as crawl's initialization 09:33:08 because i don't know what would happen otherwise. 09:33:16 all the intricate stuff involving Options and crawl_state is to handle setting seeds from rc files / command line in various ways 09:33:25 and other cases 09:34:11 I think what aidanh's comment was point to is simply changing the indicated line to something like `rng::seed(1)` 09:36:08 i mentioned setting the "-seed xyz" fake commandline argument. 09:36:38 I have no idea why that is a good way to do it? 09:36:48 I think there's something very fundamental I'm missing in terms of "why" questions here 09:36:55 maybe he was a bit tired and didn't realize i was trying to copy the initialization of crawl? 09:37:19 why is copying the initialization of crawl a good idea? 09:37:34 the way the lua tests currently work, they use the actual initialization of crawl, and in doing so, test it 09:38:37 hmm. it is the way that fixture works in catch2. 09:39:10 each test use the fixture once. 09:40:00 and if i do it exactly same as the lua tests, it will crash 09:40:14 some initialization steps in crawl doesn't have corresponding cleanup step 09:40:30 doing those step twice will crash the cath2 tests 09:41:18 why not add the cleanup steps? 09:42:36 if something is missing from _reset_game that is plausibly a bug in any case 09:43:23 (what is it that is missing?) 09:43:28 if someone adds the cleanup step, i would use it. 09:43:51 it is not reset_game 09:44:12 several includes instantiate global variables 09:44:26 without cleaning up function that destroys those global variables 09:44:47 i want to write test, so i don't want to change the main source if possible. 09:45:11 ok, so we have said this before but you are probably going to have to drop that principle :-) 09:45:26 globals can't be destroyed per se, but all the globals should have a way of resetting them 09:45:48 e.g. `you` resets by `you - player()` 09:45:50 er 09:45:59 `you = player()` 09:47:21 please take a look of the fixture that I wrote. the comments explained that. 09:47:32 it is not just the you, env, crawl state globals. 09:47:41 there are more 09:47:46 imo one of the main points of writing tests is to find weaknesses in the code they are testing, it is never a purely observational activity 09:47:53 yes, and they should all have a way of resetting 09:48:02 because that's how returning to the main menu after a game works 09:50:06 i think that tests try to provide an objective and independent view of the software 09:50:37 I mean, maybe in a corporate dev environment with dozens of programmers 09:50:44 but probably not even there 09:51:02 at least in the view point of a maintenance programmer 09:51:14 I would not support merging testing code that works around problems in the main source rather than just fixing them 09:51:21 so test and main source should be independent. 09:51:29 that's not how it works in this project 09:54:51 i might do that after i write enough test and docs to learn enough parts of the code base. 09:55:40 new developers don't know the code base as well as you guys 09:57:22 I can't actually figure out what comments you have in mind, but if you are able to construct something like `_teardown_fixture_lua` you know enough to modify _reset_game 09:58:09 as a concrete reason why I don't think this strategy is a good idea, it leads to code duplication between _teardown_fixture_lua and _reset_game, where the latter is already a notorious source of bugs (exactly because resetting is brittle) 09:59:20 the init and reset are not completely clear to me at this moment. 09:59:43 yes, they are not simple parts of crawl 09:59:44 even the ng-setup.cc can have a function that reset lua's persistent storage 09:59:54 which should happen in the reset game part. 10:00:13 that is why i prefer to follow them as closely as possible in the fixture 10:00:22 even if it is just voodoo 10:19:04 i can't #include main.cc, the reason is test_main.cc in the catch2-test folder. 10:20:33 and fake-main.cc in the main source. 10:31:33 03CrawlCycle02 07https://github.com/crawl/crawl/pull/1590 * 0.26-a0-703-ga275c0d: style: Checkwhite and unbrace 10(4 minutes ago, 1 file, 1+ 3-) 13https://github.com/crawl/crawl/commit/a275c0d1d60d 10:37:23 if the problem is the `main` function there's a couple of solutions to that, since crawl has a ton of stuff in main.cc (not ideal, but it's been that way for a long time) the simplest solution is probably to prevent regular `main` from being defined for catch2 builds using the preprocessor 10:38:21 I'm not much of an expert on our catch2 setup though, aidanh has been the de facto maintainer of it recently 10:38:30 that would be a lot of changes. 10:39:04 i dont disagree about that making the init, reset, and crash steps cleaner is a good idea. 10:39:26 but each comit only should do a small number of things. 10:40:05 if i make a pull request that try to cleanup those steps of crawl, it would be too big 10:40:16 and i don't have the knowledge to do all of that 10:41:41 the way to include the reset function in main.cc is to first 10:41:46 split it away from main.cc 10:41:55 that is certainly another option 10:42:18 changing the test_main.cc or fake-main.cc wouldn't work 10:42:59 because those two files don't have the reset function in the first place 10:42:59 but now, what should the new file do? 10:43:14 collecting all reset functions don't make sense. 10:43:44 I'm not proposing a general cleanup, what I'm suggesting is that afaict your test writing has revealed a potential bug in the reset code, and it does not seem like the right solution to just write testing code that then works around that bug. (With the caveat that without seeing the crashes involved I'm still not sure what the actual issue is, it may just be a simple missing call to some reset code that exists) 10:43:47 and that certainly should be another comit. 10:44:51 with the more general issue being code duplication between reset/init code in the test and in the game 10:45:14 I guess the crashes happened when you exactly copied the reset code? 10:45:38 the reset function in main is fine 10:45:59 it is just that i can't include it along with everything in main.cc into the catch2 tests 10:46:14 because catch2 tests use their own test_main.cc and the fake-main.cc of the main source. 10:46:47 splitting the reset function from main.cc seems the only way to avoid duplication. 10:47:16 #ifdefing main would be simpler 10:47:21 if i change fake-main, that will break the monster utility. 10:47:45 main has too many things that a test don't need. 10:48:35 no need for screen, tile, commands etc 10:48:35 main.cc is already too big 10:48:35 i dont even know why the berserk penalty is in the handling of player's command 10:52:18 but breaking main.cc is a big change, that should be another pull request. 10:53:05 if that's what is necessary to write this lua interface properly, it should not be in a separate PR imo 10:53:25 think about the scope. 10:53:31 moving _reset_game to its own file as non-static is not a big change though 10:54:12 if that's all it would take 10:54:12 there are more things 10:55:16 a seperate pr for each thing that get pulled out of main.cc 10:56:18 you know what? somehow arena includes function from main.cc 10:56:24 instead of the other way around 10:56:56 I'm not sure why those would need to be a separate PR 10:57:13 because things like arena including main.cc can happen 10:58:09 changing main.cc actually can break other things because main.cc is not always the root 10:58:25 i mean the thing just look crazy to me 10:59:48 I don't see what you're seeing for arena 10:59:48 process_command 10:59:48 world_react 10:59:48 somehow arena uses process_command from main.cc 10:59:50 process_command is defined in command.h 11:00:02 but the cmd constants are in main.cc 11:00:17 and implemented in main.cc for (I guess) historical reasons 11:00:22 i mean the numbers of the telephone book is in main.cc 11:00:51 I totally get that crawlcode can be crazy sometimes :-) 11:00:54 main.cc has some function that implement the response to the commands 11:01:06 all of that should get split out. 11:01:16 but you don't have to fix it all at once 11:01:39 it is unknown. so i want one pr for each refactor of main.cc 11:02:07 if you try to look at this and ask, "how should main.cc be", that in and of itself is a crazy project, but I don't think(?) that's what would be needed to write the reset code for this fixture correctly 11:02:57 yes. just unknown risk. may be totally harmless. 11:03:30 plus you guys can decide to merge the refactor of main.cc first 11:03:43 or merge the fixture + the refactor of main.cc together 11:33:46 <12ebering> I don’t have time to read this PR closely and I don’t want to be too negative to a new enthusiastic contributor. However, I’m finding this whole exercise increasingly dubious in that CrawlCycle it seems you have a set of software principles you’ve learned somewhere, and are trying to wedge applying them into crawl, instead of adjusting your contributions to the projects workflow based on 11:33:46 feedback. 11:35:04 <12ebering> I remain unconvinced that a lua set-up fixture for catch2 is worthwhile. The lua integration testing system is imo more appropriate for tests that require the significant complicated global state that is “a player and two monsters, one of which is invisible” 11:39:13 I think something like my moncast.lua test (which sets up some stuff and calls a c++ function in l-debug.cc for the actual test part) might be better done with this kind of fixture 11:40:48 ebering: the full motivation is here: https://github.com/crawl/crawl/pull/1587 11:41:31 the lua binding to c++ function that implement unit test is not generally reusable. 11:44:36 New branch created: pull/1591 (1 commit) 13https://github.com/crawl/crawl/pull/1591 11:44:36 03Midn802 {GitHub} 07https://github.com/crawl/crawl/pull/1591 * 0.26-a0-683-g9095a62: Update mon-spell.h 10(14 minutes ago, 1 file, 8+ 0-) 13https://github.com/crawl/crawl/commit/9095a62b86dc 11:44:49 if i write a new test of a c++ entity, then i need to write a lua binding for the entity. 11:45:07 it would be relative easy for a free function, but difficult for things like an iterator. 11:46:36 as for the pull request issue, if it is ok to mix refactoring main.cc with implementing a new feature together, then i don't mind to do that. 11:46:49 but spliting it into two pull requests mean 11:47:05 you guys get to choose to merge a pull request that improve main.cc without merging the lua fixture. 11:47:46 so, even if the lua fixture is a really bad idea, not all work is wasted. 12:09:17 ebering: i agree with your comment made a few days ago that these are still not true unit tests. 12:09:58 So I tried to see if mocking the global game state is possible. 12:12:53 It is possible, but very time consuming. 12:15:54 so i agree with you that we can't have true unit test until we refactor the code substaintially. 12:17:46 substantially*, i mean. 12:58:37 sorry, completely failed to catch the -seed command line thing earlier 13:03:49 ebering: in fact I think that their software principles are mostly good ones, and would be beneficial if applied, modulo practicality 13:04:17 it's just that crawl code is not in a position to benefit from many of these changes, because they require refactoring 13:31:21 <12ebering> Yes, and the modulo practicality is where my concern lies. It seems like CrawlCycle's idea for contributing has (because of the demons hiding inside that modulo practicality) spiralled in scope from "implement some new tests to learn the codebase" to "a major refactor of main.cc", and I worry that CrawlCycle's devotion to this particular incarnation of their idea is going to go badly because "a majo 13:31:21 refactor of main.cc" is a rather big thing for a first contribution to any longstanding open source project. 14:03:29 <10PleasingFungus> just do a major refactor of directn.cc instead 14:03:32 <10PleasingFungus> ^joke 14:07:21 I do think that implementing a lua testing fixture is not a trivial first project 14:09:12 https://crawl.develz.org/mantis/view.php?id=12373 any ideas on how this should be handled? Mark it dangerous for specific gods? Prevent it from making hell rats if following good gods? Prevent the wrath? 14:09:50 <12ebering> Mark it evil so the good gods hate it 14:10:37 <03wheals> %git :/rats 14:10:37 <04Cerebot> PleasingFungus * 0.26-a0-666-gee0ae89: Mark ratskin as evil (12373) (6 days ago, 1 file, 1+ 1-) https://github.com/crawl/crawl/commit/ee0ae89446c4 14:11:40 ^ the end of dcss as we know it 14:12:03 look at the commit count... 14:13:56 <03wheals> the hell rats all live in that commit 14:34:40 ebering: please see the logs. i don't want to refactor main.cc if possible. 14:35:02 ebering: advil say a small refactoring of main.cc would avoid code duplication of reset_game in main.cc 14:35:27 ebering: i believe of your profession are generally reasonable 14:35:34 especially when they are not short of time. 14:35:51 So, let me distill the situation in my view down to bullet points and table. 14:36:43 claim 1: Test of an entity consists of 3 parts: 1. set up test scenario. 2. call the entity 3. verify assumptions. 14:37:20 now, let's first look at the issue purely in terms of speed of development. 14:37:51 claim 2: Setting up the test scenario is faster with dLua than with c++ 14:37:59 i think we both agree on this claim. 14:38:36 claim 3: Call of the entity is easier in C++ than in Lua. 14:38:43 well. if we call the c++ entity in Lua, we need to write Lua bindings for the c++ code. 14:38:58 If we call the c++ entity directly in C++, we don't need to write the binding. 14:39:42 writing the Lua binding for free function is easy, for class is tedious, and for iterator is time consuming. 14:40:08 claim 4: Verifying assumption is easier in C++ than in Lua. 14:40:21 Lua's api is convenient but not as complete as the C++ api. 14:40:45 That means checking various assumption and peeking at the internal is easier with C++ than with Lua 14:41:01 claim 5: Using a hybrid approach gets the best of both worlds. 14:41:29 The lua fixture allow setting the scenario with dlua, call the entity with c++, and verify the assumptions with c++. 14:41:58 There are other benefits in terms of reducing code bloat in the main source, and making code reusable. 14:42:22 But I think a verification of those claims are sufficient to prove the Lua binding make writing tests faster. 14:42:42 Please tell me your objection to these claims. 14:47:23 <12ebering> CrawlCycle: advil pointing to moncast.lua made a much stronger case for why implementing some lua tools for catch2 is a good for the codebase 14:48:04 ebering: i totally think i have limited understanding of the code base. That is why i don't like to touch the main source if possible 14:48:23 <12ebering> CrawlCycle: my claim is that if your goal is "learn the crawl codebase by implementing some easy to implement tests as a small first project", then "implement major new testing infrastructure that requires touching the main codebase" is not a good way to go about it 14:48:32 ebering: in fact, i didn't include any refactoring of the main source in the pull request. 14:49:08 <12ebering> and that you'll accomplish your goal by putting this on the back burner for a bit and identifying things that you can test without lua 14:49:49 <12ebering> this will give you a broader tour of the codebase and help you build a sense for what parts are crossloaded/heavily rely on globals, and what parts don't 14:49:49 ebering: erh. even the 3 actor scenario needs lots of setup. 14:50:16 <12ebering> which will give you the confidence to start touching the main codebase, in order to do the refactoring needed to add lua to the catch2 system in a non-brittle way 14:51:22 <12ebering> CrawlCycle: our test coverage is abysmal, I am willing to bet there are plenty of things that have less global dependence that could be tested with less setup than a 3 actor scenario 14:52:19 <12ebering> Finding those things is a good way to learn the codebase, and tests for them (because you found the tests that are easier to implement) are good initial projects to get your toes wet with development. The knowledge you gain from these projects will make your Big Goal easier to accomplish. 14:53:04 ebering: i go through the file in alapbetical order and document anything with a usage more than 40. nearly everything i have seen till act-iter.cc uses env, you, or crawl_state in some way. 14:53:37 ebering: i once asked which file has the cleanest code of crawl. no one gave a serious answer. 14:53:41 <10PleasingFungus> ha 14:53:48 ebering: so, where should i start? 14:53:53 <10PleasingFungus> i once wrote a file in crawl that i was proud of 14:53:54 <10PleasingFungus> i should go find it 14:53:59 <10PleasingFungus> it seems like you and ebering are approaching this from very different angles 14:54:08 <10PleasingFungus> ebering is trying to help you maximize your ability to learn the codebase 14:54:14 <10PleasingFungus> you're trying to optimize on utility for the codebase 14:54:32 <10PleasingFungus> but it seems like you won't really be able to do very much for the project until you have a better understanding of it 14:54:46 <10PleasingFungus> so following ebering's suggestion of finding something that might have low utilization but is simpler to test could be right 14:55:26 <08wormsofcan> the file of crawl with the cleanest code will be whichever one is the smallest filesize 14:55:26 <12ebering> either the smallest filesize or the shortest git log history 😛 14:56:03 <10PleasingFungus> i think species.cc is decent 14:56:25 <10PleasingFungus> likewise jobs.cc 14:58:41 <10PleasingFungus> huh, we have some cc files that only have one commit. i didn't expect that 14:58:46 ok. i will try those two files next time. if i can't write the tests with c++ api easily, i will comeback to you guys. 14:58:49 <10PleasingFungus> e.g. ng-init-branches.cc 15:00:00 looks like there's actually a catch2 test for that one? 15:00:08 <12ebering> CrawlCycle: sounds like a good plan. And, in terms of learning the codebase you should keep track (with notes or whatever works for you) of what parts are easy to test with the existing api and what parts are not and why that is the case 15:01:02 ebering: lua binding for everything or lua binding when the guys that edit maps say they want it? 15:01:15 ebering: i will keep that in mind. 15:01:54 <10PleasingFungus> trivia: the most touched files: (apologies in advance to IRC users, I suspect this will look quite bad there) 3583 crawl-ref/source/player.cc 2655 crawl-ref/source/religion.cc 2527 crawl-ref/source/mon-util.cc 2137 crawl-ref/source/beam.cc 2012 crawl-ref/source/describe.cc 1860 crawl-ref/source/dungeon.cc 1833 crawl-ref/source/monster.cc 1737 crawl-ref/source/item_use.cc 1731 15:01:55 crawl-ref/source/tilepick.cc 1628 crawl-ref/source/main.cc 15:01:55 <12ebering> for example, act-iter.cc is difficult to test with the C++ api because despite appearing to provide somewhat lowlevel iterator primatives, these iterators require a level with a dungeon grid and terrain, populated by monsters and a player, which require some items, the player needs skills and a species and so on 15:02:40 ebering: it is also difficult to test with lua because writing the binding is difficult. i don't want to write a binding for monster list or the whole env. 15:03:02 <12ebering> CrawlCycle: dlua bindings are provided for things that mapmakers need or that the test api needs; clua bindings are provided for ui automation and scripting, they tend to be added by bot authors 15:03:08 <10PleasingFungus> recent changes look quite different, though: 219 crawl-ref/source/player.cc 211 crawl-ref/source/describe.cc 160 crawl-ref/source/ui.cc 156 crawl-ref/source/files.cc 154 crawl-ref/source/ability.cc 144 crawl-ref/source/spl-cast.cc 139 crawl-ref/source/tags.cc 136 crawl-ref/source/directn.cc 136 crawl-ref/source/tilepick.cc 128 crawl-ref/source/initfile.cc ui.cc! 15:03:30 <12ebering> (see qw.rc in the source for an example of a bot authored in clua) 15:08:03 pleasingfungus: my eyes! 15:11:12 03PleasingFungus02 07* 0.26-a0-683-g5206c1d: Note aux armour in stash search 10(19 seconds ago, 1 file, 3+ 0-) 13https://github.com/crawl/crawl/commit/5206c1d7acb0 15:11:39 ebring: thanks. i have things to do now and would come back later. 15:12:09 <10PleasingFungus> rip naruni 15:12:09 <04Cerebot> rip 15:17:16 Unstable branch on crawl.kelbi.org updated to: 0.26-a0-683-g5206c1d7ac (34) 17:14:49 New branch created: pull/1592 (2 commits) 13https://github.com/crawl/crawl/pull/1592 17:14:49 03Kieron Dunbar02 07https://github.com/crawl/crawl/pull/1592 * 0.26-a0-671-gbbaf54f: Change the spelling of some words to Australian English. 10(53 minutes ago, 11 files, 21+ 20-) 13https://github.com/crawl/crawl/commit/bbaf54f8656f 17:14:49 03Kieron Dunbar02 07https://github.com/crawl/crawl/pull/1592 * 0.26-a0-672-g809658f: Rename the "center_on_scroll" option as "centre_on_scroll", but let the user use either spelling. 10(40 minutes ago, 4 files, 11+ 7-) 13https://github.com/crawl/crawl/commit/809658f9c3bd 17:21:48 <10PleasingFungus> excellent 17:59:41 03CrawlCycle02 07https://github.com/crawl/crawl/pull/1590 * 0.26-a0-704-gdad21f9: fix: Reorder #include for ccache 10(4 minutes ago, 1 file, 2+ 2-) 13https://github.com/crawl/crawl/commit/dad21f92ef14 18:12:26 sahdkjhfkaj (L1 NaNe) Crash caused by signal #6: Aborted (D (Sprint)) 18:24:34 Would my code get built faster on ci if I sign up for circle ci? 18:24:43 I mean signing up for my fork. 18:24:50 Unstable branch on underhound.eu updated to: 0.26-a0-683-g5206c1d7ac (34) 18:25:16 i have signed up for travis ci for my fork, but it seems a bit slow. 18:28:00 is it possible to make sure my commits passes ci before updating the pull request to crawl/crawl repository? 18:28:15 i mean to check if my commits passes ci of my own fork. 18:32:55 probably I can make a staging branch that gets check by ci 18:33:35 after that, sync that with the pull request branch 18:34:14 wow. travis is so slow when i look at it. 18:52:25 <12ebering> we are (slowly) migrating away from travis 18:52:45 <12ebering> you can see the github actions and run the relevant ones on your platform before pushing 18:53:05 <12ebering> see also the pre-commit hooks in docs/develop/git.txt (I think that's the right file name) 18:53:19 <12ebering> Which will run some of the checks before you even commit! 19:00:33 richardnixon (L17 SpVM) Crash caused by signal #6: Aborted (Shoals:1) 19:49:18 -!- Guest34445 is now known as bh 20:14:23 03CrawlCycle02 07https://github.com/crawl/crawl/pull/1590 * 0.26-a0-706-g6db1ecf: Merge branch 'master' into crawlcycle/test/2_lua_fixture 10(11 minutes ago, 0 files, 0+ 0-) 13https://github.com/crawl/crawl/commit/6db1ecfda73a 20:14:23 03CrawlCycle02 07https://github.com/crawl/crawl/pull/1590 * 0.26-a0-707-g7a8e9ad: fix: Include to appease ccache 10(7 minutes ago, 1 file, 1+ 0-) 13https://github.com/crawl/crawl/commit/7a8e9ad4f4ad 22:11:24 GuyPerson (L20 HOFi) ASSERT(!targets.empty()) in 'mon-cast.cc' at line 2385 failed. (No push space from (74,7)) (Vaults:3) 22:55:59 Whiskey (L22 FoFi) ASSERT(you.can_pass_through_feat(env.grid(p))) in 'player.cc' at line 541 failed. (D (Sprint)) 22:56:05 Whiskey (L22 FoFi) ASSERT(you.can_pass_through_feat(env.grid(p))) in 'player.cc' at line 541 failed. (D (Sprint)) 22:56:14 Whiskey (L22 FoFi) ASSERT(you.can_pass_through_feat(env.grid(p))) in 'player.cc' at line 541 failed. (D (Sprint)) 22:56:30 Whiskey (L22 FoFi) ASSERT(you.can_pass_through_feat(env.grid(p))) in 'player.cc' at line 541 failed. (D (Sprint)) 22:58:25 Whiskey (L22 FoFi) ASSERT(you.can_pass_through_feat(env.grid(p))) in 'player.cc' at line 541 failed. (D (Sprint)) 23:07:59 The auto-generated species-data.h contains a line: 23:08:36 static const map species_data = ... 23:08:50 why is it static? i think we only need one unique species_data 23:09:36 When I #include "species-data.h" into my test, I get a new copy of species_data. 23:56:28 Since branch_iterator in branch.cc is undocumented, I don't know what does ng-init-branches.cc do 23:56:56 and I also don't know the meaning of the tests in test_ng-init-branches.cc 23:57:08 that is not good. 23:57:48 doc without test is not trustworthy 23:58:26 test without doc is a mystery