00:27:14 -!- amalloy_ is now known as amalloy
01:03:02 <Henzell> Corinon (L11 FoFi) ASSERT(isnormal(n)) in 'ray.cc' at line 189 failed. (D (Sprint))
01:21:41 <Lantell> Experimental (bcrawl) branch on underhound.eu updated to: 0.23-a0-3603-ge1cc4b0452
01:51:52 <CrawlCycle> does claw have a default namespace to hide implementation details?
02:06:11 <CrawlCycle> usually we add underscore to functions that are implementation details.
02:06:32 <CrawlCycle> What to do if I want to hide a class?
02:15:54 <amalloy> don't put it in the header
02:17:31 <amalloy> CrawlCycle: that's what really determines what's "hidden" vs exported. a _ prefix is just a convention for readability
02:20:04 <CrawlCycle> i made a class for defining a global guard for running the initialization steps of crawl.
02:20:27 <CrawlCycle> some of those init steps have no corresponding clean up functions.
02:20:59 <CrawlCycle> that means i can only run them once across all the tests
02:21:59 <CrawlCycle> I want to expose the instantiation (the global guard) of that class
02:22:20 <CrawlCycle> but i want to hide the class's definitions as implementation details.
02:22:54 <CrawlCycle> the thing get worse because the guard class uses another class that i also want to hide.
02:23:23 <CrawlCycle> the include file of all these class contains the declaration of the classes and the instantiation of the global guard
02:24:50 <CrawlCycle> if i don't hide the instantiation, can i hide the declaration?
02:25:42 <amalloy> you can put a stub in the header, if you want the type to be known but opaque. foo.h: class foo; foo.cc: class foo {...}
02:26:39 <CrawlCycle> tried that ...
02:27:14 <CrawlCycle> maybe i did something wrong
02:27:22 <CrawlCycle> it is not a templated class
02:28:28 <CrawlCycle> amalloy, but both the instantiation and declaratio are in the header.
02:28:41 <CrawlCycle> foo.h: class foo; foo();
02:28:59 <CrawlCycle> foo.cc: foo::foo() {}
02:30:25 <CrawlCycle> foo.h: class Foo; static Foo foo();
02:30:34 <CrawlCycle> let's see i can compile a cut-down version.
02:32:57 <CrawlCycle> nope
02:33:42 <CrawlCycle> test.h: class A; static A a;
02:34:38 <CrawlCycle> test.cc:
02:34:43 <CrawlCycle> #include "test.h"
02:34:45 <CrawlCycle> class A {
02:34:49 <CrawlCycle> public:
02:34:59 <CrawlCycle> A() {}
02:35:01 <CrawlCycle> };
02:35:09 <CrawlCycle> test.h:
02:35:16 <CrawlCycle> class A;
02:35:20 <CrawlCycle> static A a;
02:35:59 <CrawlCycle> error: aggregate `A a` has incomplete type and cannot be defined.
02:36:36 <CrawlCycle> i don't think this can work. I need a full definition to instantiate a class.
02:36:49 <CrawlCycle> if I instantiate the class within the header
02:37:11 <CrawlCycle> i can't just put a forward declaration in the header
02:41:34 <CrawlCycle> right now, i put the class's declaration in detail namespace in the header
02:42:16 <CrawlCycle> i don't like global variables...
02:45:32 <Gretell> Monster database of master branch on crawl.develz.org updated to: 0.26-a0-667-g92642533e4
02:47:59 <amalloy> i don't think you know what static does in c++. what you wrote would create N distinct A objects if the header is included in N different files
02:49:40 <amalloy> you probably mean extern, if you want it to be visible to clients but defined elsewhere. see how player.hs defines `extern player you;`
02:51:09 <CrawlCycle> should be extern
02:52:46 <CrawlCycle> thanks. i learn c++ on my own.
02:53:03 <CrawlCycle> so probably there are still a lot of things to learn
02:54:02 <CrawlCycle> but one problem though. where to instantiate that global variable?
02:54:27 <CrawlCycle> a bunch of tests will use that fixture
02:54:43 <CrawlCycle> i mean a bunch of test_xyz.cc files will use that fixture
02:55:01 <CrawlCycle> then all those .cc files get linked into a single catch2-test-executable
02:55:24 <CrawlCycle> do i really have to use a singleton?
02:56:06 <CrawlCycle> i don't think instantiating that global within the test_xyz.cc files make sense.
02:56:28 <CrawlCycle> if one developer instantiate it in one test_xyz.cc
02:56:34 <CrawlCycle> another developer does the same thing
02:56:41 <CrawlCycle> then there will be problems
02:56:45 <CrawlCycle> multiple definition
02:58:23 <CrawlCycle> there is only one fixture file. the fixture gets setup and tear down in each test.
02:58:23 <CrawlCycle> if i instantiate the global within the dlua_fixture.cc
02:58:33 <CrawlCycle> it may work.
03:00:11 <amalloy> i don't really understand what you're trying to build. i've just given some pretty general c++ feedback when you say something that doesn't sound right
03:02:10 <CrawlCycle> thanks. i was thinking out loud, after asking the question.
03:05:29 <amalloy> in particular, you've said your thing will be initialized only once globally, but also talked about initializing it in each test
03:07:18 <CrawlCycle> one guard for init steps of crawl
03:07:30 <CrawlCycle> the fixture use the guard
03:07:52 <CrawlCycle> the fixture gets create and destroyed during running of each test
03:08:35 <CrawlCycle> i can't do the instantiation of the guard in the main function
03:09:34 <CrawlCycle> because not all tests use the guard.
03:09:34 <CrawlCycle> the fixture that i am writing enable using dungeon builder lua commands in the unit tests
03:09:41 <CrawlCycle> the old and existing catcher2 tests don't need to run dlua commands.
03:10:43 <CrawlCycle> in the current build process, all the test_xyz.cc files in catch2-test/ directory get linked to test_main.cc, which #include the fake-main.cc in the main source.
03:11:41 <CrawlCycle> if i put the instantiation of my init guard into test_main.cc, then the old tests will have access to my guard too.
03:12:14 <CrawlCycle> maybe that is not too bad.
03:13:50 <CrawlCycle> everything gets compiled into a single catch2-test-executable anyway.
03:19:11 <CrawlCycle> alternatively, just instantiate in the guard's header
03:19:34 <CrawlCycle> then use extern to refer to that global in the fixture's .cc
03:20:05 <CrawlCycle> since the header only gets include once, i only have one instantiation
03:20:46 <CrawlCycle> and the externs would all refer to that single instantiation in the header.
03:20:51 <CrawlCycle> just don't declare the guard's instantiation as static.
03:21:06 <CrawlCycle> that sounds better.
03:30:57 <Kelbell> Fork (bcrawl) on crawl.kelbi.org updated to: 0.23-a0-3603-ge1cc4b0452
03:47:45 <Kelbell> Fork (bcadrencrawl) on crawl.kelbi.org updated to: 0.22.1-3058-g7dd4cf362e
08:53:00 -!- amalloy is now known as amalloy_
09:47:34 <CrawlCycle> what is the difference between dlua and clua?
09:47:55 <CrawlCycle> dlua looks like dungeon builder lua. But what is clua?
09:53:12 <Discord|> <12e​bering> clua is "client lua" and is used for player RC scripting
09:54:10 <Discord|> <12e​bering> CrawlCycle: while on the one hand we do appreciate testing and documentation efforts, on the other hand it seems you're still very new to the codebase relative to the ambition of your project (which, I'm still not completely clear on; it looks like you started out trying to make a "unit test" for actor_near_iterator)
09:55:10 <CrawlCycle> it is a fixture for using dlua commands in catcher2-test
09:55:42 <CrawlCycle> it is nearly done now. i am writing unit tests to test the fixture.
09:56:11 <CrawlCycle> the use case is to use dlua to set up scenario
09:56:17 <CrawlCycle> and use c++ to write the test
09:56:25 <Discord|> <12e​bering> We already have an "integration testing" framework purely in lua
09:56:28 <CrawlCycle> to avoid writing lua binding for everything that i want to test.
09:56:37 <Discord|> <12e​bering> Well yes that's what I'm getting at
09:56:37 <CrawlCycle> for example, the iterator.
09:56:57 <Discord|> <12e​bering> I don't think that iterator is worth this effort to test; it's straightforward, hasn't been touched in years, and hasn't contributed a bug in years.
09:57:37 <Discord|> <12e​bering> Crawl's codebase is highly cross-loaded: something that looks like it should be a "unit" (i.e. actor_near_iterator) depends on tons of global state, which makes it a better candidate for integration/stress testing for coverage
09:58:32 <Discord|> <12e​bering> And, in the long run, a better approach to testing these "units" would be to re-factor them so they can be tested without initializing a large part of crawl's global state
09:59:07 <CrawlCycle> during this refactoring, how to ensure that we haven't broken things?
10:00:28 <Discord|> <12e​bering> code review, hope, and the large scale integration testing that is our live trunk deployment to thousands of beta test players worldwide
10:00:30 <CrawlCycle> i think that temporary doc and test are a step in doing this.
10:00:42 <CrawlCycle> but i am not sure if that is the best way to do it.
10:02:25 <Discord|> <12e​bering> Consider: as the effort and complexity of a temporary test grows, how likely is it to become permanent and a burden
10:03:15 <CrawlCycle> hmm. what are the potential disadvantages?
10:04:08 <CrawlCycle> obviously, i don't see them when i work on the tests.
10:04:08 <CrawlCycle> when a developer come by and work on the refactoring
10:04:08 <CrawlCycle> what would happen?
10:04:30 <CrawlCycle> the developer look at the doc and the test
10:04:37 <Discord|> <12e​bering> Lets focus on the specific case of actor_near_iterator
10:04:37 <CrawlCycle> to see what is the original behavior
10:04:43 <CrawlCycle> oh
10:05:06 <Discord|> <12e​bering> It must
10:08:19 <Discord|> <12e​bering> I guess, what I want to say is: the past week of these chat logs have been you delving into the complexities of this project, providing dlua support for writing unit tests, which is decidedly not a unit test, all for the sake of testing an iterator that as far as I can tell has never generated a bug
10:09:04 <Discord|> <12e​bering> if it's about ensuring that in some hypothetical refactor actor_near_iterator maintains its contract, a short snippet of documentation of the class describing that contract will suffice
10:09:44 <Discord|> <12e​bering> the iterator is not long nor complex
10:09:44 <Discord|> <12e​bering> it's also not totally clear to me what an appropriate refactor would be
10:09:54 <CrawlCycle> yea. i don't think it needs to be changed.
10:09:55 <Discord|> <12e​bering> since actor_near_iterator, by definition, references the global state of the game
10:10:40 <CrawlCycle> i see a lot of things use the monster_near_iterator
10:10:50 <CrawlCycle> which is similar to the actor_near_iterator
10:11:11 <CrawlCycle> so i decided to write doc and test
10:11:35 <advil> well, in fairness, |amethyst and I both suggested the other day that testing some aspects of that iterator would be reasonable
10:11:39 <CrawlCycle> i hope the dlua support make setting up scenarios for writing tests easier.
10:11:58 <advil> I did try to suggest this would be better done via a lua test though
10:12:50 <CrawlCycle> but i don't like changing the source code to add lua binding for writing just a test...
10:13:02 <CrawlCycle> writing test should not change the source code
10:13:37 <Discord|> <12e​bering> I think my skepticism of testing is in part my mathematican's accent: we should just formally verify crawl!
10:14:37 <CrawlCycle> i totally believe in you guys know more and better than me
10:15:27 <CrawlCycle> just that i agree using c++ to set up test scenario is tedious.
10:15:43 <CrawlCycle> and dlua is easier.
10:16:03 <Discord|> <12e​bering> Writing integration tests can definitely require a change to the source. I would argue that while something like "actor_near_iterator" appears to be a low-level unit, because it is an iterator over rather high-level global state, testing it is an integration exercise, not a unit exercise
10:16:18 <Discord|> <12e​bering> So yes, dlua, part of our integration automation, makes it easier
10:16:30 <Discord|> <12e​bering> but in order to test more with lua tests, you must expose more to lua
10:16:43 <Discord|> <12e​bering> which requires writing lua bindings
10:23:49 <CrawlCycle> many things are like that. for example, any function that works on the player (the you object). so, what needs unit testing?
11:53:09 <CrawlCycle> An alternative would be try to do a real mock of crawl's environment.
11:53:32 <CrawlCycle> for example, a mock environment object
11:54:07 <CrawlCycle> that is actually an interface
11:54:20 <CrawlCycle> and we can choose what to implement in each test
11:54:30 <CrawlCycle> and only implement the minimal requirement for each test
11:54:43 <CrawlCycle> all the implementations are organized into a library
11:55:03 <CrawlCycle> that we can select and use sparingly for each test.
11:55:29 <CrawlCycle> The current catch2-tests don't do this. the catch2-test-executable uses fake-main
11:56:40 <CrawlCycle> This is the hardway. mock with dependency inversion.
11:56:59 <CrawlCycle> probably the correct way.
11:59:28 <CrawlCycle> but this way still has some problems.
11:59:38 <CrawlCycle> Each change to the crawl's environment object
11:59:49 <CrawlCycle> would require a corresponding manual change of the mock
12:00:15 <CrawlCycle> i guess this is an acceptable cost.
12:02:23 <CrawlCycle> or maybe not.
12:04:33 <CrawlCycle> the environment object contains the monster array, which contains the monster object
12:04:46 <CrawlCycle> a change to the definition of the monster or actor class
12:04:53 <CrawlCycle> would require a corresponding mock.
12:06:07 <CrawlCycle> the dlua fixture would at least avoid writing new lua bindings when we write new integration tests.
12:08:01 <CrawlCycle> A real mock would surely not change even when the main source change.
12:09:05 <CrawlCycle> A cut-down initialization of crawl would not change *most* of the time when the main source change. That means test scenario needs its own check before we use those scenario to test other things.
12:10:07 <CrawlCycle> which way is better? real mock or scenarios?
13:55:34 <Cheibriados> 03PleasingFungus02 07[bogged-down] * 0.26-a0-668-g206a269: Buff bog bodies 10(8 weeks ago, 1 file, 2+ 2-) 13https://github.com/crawl/crawl/commit/206a2694b21b
13:55:34 <Cheibriados> 03PleasingFungus02 07[bogged-down] * 0.26-a0-669-g60eb314: New monster: bloated husk 10(8 weeks ago, 6 files, 42+ 0-) 13https://github.com/crawl/crawl/commit/60eb3143ebc3
13:55:34 <Cheibriados> 03PleasingFungus02 07[bogged-down] * 0.26-a0-670-g010d1bb: New monster: bunyip 10(8 weeks ago, 7 files, 33+ 0-) 13https://github.com/crawl/crawl/commit/010d1bba03fe
13:55:34 <Cheibriados> 03PleasingFungus02 07[bogged-down] * 0.26-a0-671-gd384799: New monster: devouring swarm 10(8 weeks ago, 30 files, 180+ 5-) 13https://github.com/crawl/crawl/commit/d384799eee78
13:55:34 <Cheibriados> 03PleasingFungus02 07[bogged-down] * 0.26-a0-672-g4d30ca1: Power up insubstantial wisps 10(8 weeks ago, 4 files, 55+ 2-) 13https://github.com/crawl/crawl/commit/4d30ca1ca598
13:55:34 <Cheibriados> 03PleasingFungus02 07[bogged-down] * 0.26-a0-673-ge2766cd: New monster: Kitsune 10(8 weeks ago, 11 files, 63+ 9-) 13https://github.com/crawl/crawl/commit/e2766cd67760
13:55:34 <Cheibriados> 03PleasingFungus02 07[bogged-down] * 0.26-a0-674-g4199943: New monster: goliath frog 10(8 weeks ago, 14 files, 57+ 16-) 13https://github.com/crawl/crawl/commit/4199943f93d8
13:55:34 <Cheibriados> 03PleasingFungus02 07[bogged-down] * 0.26-a0-675-gd8f4298: New monster: eleionoma 10(8 weeks ago, 14 files, 150+ 3-) 13https://github.com/crawl/crawl/commit/d8f4298187a0
13:55:34 <Cheibriados> 03PleasingFungus02 07[bogged-down] * 0.26-a0-676-g15186a6: Remove unused M_HYBRID flag 10(8 weeks ago, 1 file, 1+ 1-) 13https://github.com/crawl/crawl/commit/15186a6d47b5
13:55:34 <Cheibriados> 03PleasingFungus02 07[bogged-down] * 0.26-a0-677-gc08c92f: Sq into el 10(8 weeks ago, 1 file, 2+ 2-) 13https://github.com/crawl/crawl/commit/c08c92f68e64
13:55:34 <Cheibriados> ... and 22 more commits
13:55:53 <Cheibriados> Branch pull/1533 updated to be equal with bogged-down: 13https://github.com/crawl/crawl/pull/1533
14:19:50 <Discord|> <10P​leasingFungus> 8 weeks ago... time flies
14:44:51 <CrawlCycle> can gmock mock global object, like the (player you;) object?
14:46:32 <CrawlCycle> the player class is not even an interface. not sure if gmock can directly work with that.
15:00:36 <CrawlCycle> ok.. but i can make a new main function for the test
15:00:52 <CrawlCycle> and replacing the original game state by an interface
15:00:56 <CrawlCycle> and then use gmock
15:10:46 <CrawlCycle> seems not easy to use gmock with catch2
17:46:15 -!- amalloy_ is now known as amalloy
22:38:05 <CrawlCycle> in l-you.cc the deprecated LUAFN(you_mutation) only takes 1 string argument and returns an int.
22:39:39 <CrawlCycle> nvm. i figure it out. lua "you.mutate" binds to another c++ function.
23:19:35 <Cbrotell> vortex (L7 DEFE) ASSERT(you.equip[slot] == -1) in 'player-equip.cc' at line 58 failed. (D:4)
23:24:18 <CrawlCycle> does dlua allow us to get return value from a lua command?
23:28:56 <CrawlCycle> i think dlua can't do that, after skimming over all calls to dlua.xyz methods.
23:29:29 <wheals> !crashlog
23:29:31 <Sequell> 22621. vortex, XL7 DEFE, T:3347 (milestone): https://cbro.berotato.org/morgue/vortex/crash-vortex-20201018-031933.txt
23:31:16 <CrawlCycle> what does that crashlog tell?
23:31:32 <CrawlCycle> amulet of guardian spirit? or something else?
23:33:28 <CrawlCycle> equip on delay
23:36:50 <wheals> the log suggests that somehow the player started two equip delays
23:37:05 <wheals> no idea how
23:38:06 <Cbrotell> vortex (L8 DEFE) ASSERT(you.equip[slot] == -1) in 'player-equip.cc' at line 58 failed. (D:6)
23:38:54 <CrawlCycle> wow. i can't figure that out even after reading EquipOnDelay
23:39:22 <CrawlCycle> how did you figure that out?
23:41:51 <CrawlCycle> is it possible to get a save game, seed, and replay the player's actions?
23:50:42 <gammafunk> generally only devs can access online saves, and only if you can get player to make one first via console menu
23:53:56 <wheals> !crashlog
23:53:57 <Sequell> 22622. vortex, XL8 DEFE, T:5156 (milestone): https://cbro.berotato.org/morgue/vortex/crash-vortex-20201018-033805.txt
23:54:18 <wheals> &rc vortex
23:54:19 <Sequell> ?rc vortex git
23:54:28 <wheals> %rc vortex git
23:54:29 <Sequell> http://dobrazupa.org/rcfiles/crawl-git/vortex.rc
23:56:56 <wheals> seems that lua is the problem, i'd guess that it.puton doesn't check whether it's already on