00:20:41 <DenialAdams> gripe with the log format: it's entirely seperated by colons, but the place value is represented with two colons (eg. Dungeon 5 is D::5). So you can't just parse by splitting on colon character :(
00:21:57 <gammafunk> DenialAdams: the sequell code does have a parser already written, I'm sure
00:22:13 <gammafunk> I don't know how sequell encodes the number of fields
00:22:27 <gammafunk> perhaps the idea is you know the fields and field orders
00:23:44 <DenialAdams> gammafunk: I was looking at how the new crawl scoreboard does it, and it does it by reading it as JSON - I wasn't thrilled with that, so I was doing it a different way instead. Haven't looked at sequll yet, I'll check now
00:43:53 <gammafunk> DenialAdams: https://github.com/crawl/sequell/blob/master/config/crawl-data.yml#L795
00:44:01 <gammafunk> is where sequell knows about the xlogfile fields
00:48:47 <DenialAdams> thanks gammafunk. The parsing of the xlog itself happens here https://github.com/crawl/go-sequell/blob/master/xlog/xlog.go#L56
00:54:01 <gammafunk> yeah, that looks like it's just the basic string parsing though
00:55:25 <gammafunk> I wonder, are the ':' in field values escaped
00:56:36 <gammafunk> anyhow, can't help you too much, as I don't know Go (nor ruby, which the sequell-proper code for dealing with the DB data seems to be written in)
00:57:07 <gammafunk> you can email darshan if you have some questions, he's pretty busy, but probably will be able to get back to you eventually
00:59:39 <DenialAdams> no worries :) I don't know go either but I'm muddling along. I think the special casing for the `::` happens in FindSeperator. It looks for the next Seperator that is not escaped ('::')
01:30:27 <Eksell> Unstable branch on CRAWL.XTAHUA.COM updated to: 0.21-a0-414-gba8bdf1 (34)
02:01:53 -!- amalloy_ is now known as amalloy
03:20:02 -!- amalloy is now known as amalloy_
03:22:05 -!- amalloy_ is now known as amalloy
03:22:44 <Rotatell> Unstable branch on crawl.beRotato.org updated to: 0.21-a0-414-gba8bdf1 (34)
03:52:11 <Yermak> I want a function to return one of the three outcomes instead of two (it currently returns bool). Is it better to add extra bool& parameter or change its type to int?
03:53:18 <Yermak> Bool is clearer, int is simpler.
03:59:11 <Yermak> I think I'll go with bool&.
04:03:57 <Yermak> Another question. What's better: if (!condition) smth1; else smth2; or if (condition) smth2; else smth1;? Keep in mind condition is very often false. First option is generally better to use for performance purposes (also in this case)
04:04:18 <Yermak> (also in this case performance improvement is practically zero)
04:04:38 <Yermak> Second option has marginally better readability.
04:06:34 <Yermak> Actually, hmm, I think I lied about performance improvement?
04:14:18 -!- amalloy is now known as amalloy_
04:18:18 <geekosaur> generally one goes for the shorter then-case, for readability reasons.
04:18:43 <Yermak> so (!condition)?
04:23:25 <geekosaur> yeh
04:24:05 <geekosaur> basically if (cond) { big lump} else { one-liner } is too easy to lose the else while reading it
04:49:50 <Yermak> It looks like whenever I change branch in my local repo, make starts creting all .o file from scratch, despite Me having ccache.
04:50:16 <Yermak> s/creting all .o file/creating all .o files/
08:02:16 <advil> Yermak: I prefer returning something to using &bool, but int is not the best option. You can create a custom enum/enum class, or see if the enum maybe_bool (which has a false value, a maybe value, and a true value) will do what you need
08:03:10 <Yermak> I guess &bool worked fine in my case, thx.
08:03:40 <advil> well, some of us may be quite opposed to using &bool in an argument list :)
08:04:01 <Yermak> It's a function that is used exactlyy once.
08:04:04 <advil> I will change old &args in crawl when I work on code that has them
08:04:40 <Yermak> Right now I'm totally confused on how many different 'update' functions there are in the code.
08:05:27 <advil> what are you working on?
08:05:37 <Yermak> Golubria UI improvements
08:05:59 <Yermak> I fixed the message. But I'm totally lost an how to clear phantom images.
08:07:20 <advil> ah I see
08:08:03 <advil> not sure how to do that either. stupid question...are you sure that's not on purpose, so you don't forget where you came from? I see how it would be confusing with multiple ones though
08:08:45 <advil> map memory in general is confusing
08:09:16 <Yermak> Well, in tiles minimap should have exactly one white dot - the player, as far as I understand. But these out-of-los jumps mupltiply white dots.
08:09:42 <Yermak> Even if this was on purpose it still has a bug.
08:11:10 <Yermak> Also there is fog created on your square, so you won't forget.
08:12:03 <advil> my usual MO for trying to figure out something like that is to find something in crawlcode that already does it
08:12:10 <advil> !source trap_def::destroy
08:12:10 <Sequell> 1/1. https://github.com/crawl/crawl/blob/master/crawl-ref/source/traps.cc#L75
08:12:15 <Yermak> yeah, I did that
08:12:27 <advil> possibly "env.map_knowledge(pos).set_feature(DNGN_FLOOR);" will do what you need?
08:12:59 <Yermak> Many functions update something only if it's in los.
08:13:04 <Yermak> no, it's not
08:13:09 <Yermak> it's not
08:13:51 <Yermak> there is some universal function viewwindow() that should update everything in theory, but it doesn't work.
08:17:34 <advil> til that golubria is a trap
08:17:59 <Yermak> yep, this is the first thing I learnt when started working on this.
08:27:46 <advil> hm, yeah, it already should be calling trap_def::destroy
08:28:14 <advil> FR rewrite passages as a kind of portal, not a trap
08:28:36 <Yermak> Transporters is also a trap and they've been added recently.
08:28:54 <advil> oh they are?
08:28:58 <advil> didn't realize that
08:29:02 <|amethyst> they aren't
08:29:18 <|amethyst> transporters are DNGN_TRANSPORTER
08:29:21 <Yermak> oops, I'm wrong
08:29:42 <Yermak> They were close to each other in the other file.
08:30:38 <Yermak> Anyway, I think problem is that map is never updated outside of your los.
08:31:42 <Yermak> If I destroy the trap, put fog there, update screen, and only then move player, it should work. Would this be an adequate fix to a problem?
08:32:00 <Yermak> s/a prob/the prob/
08:34:13 <advil> hmm how do I get a passage to lead to an out of los position?
08:34:30 <|amethyst> advil:  cast it multiple times
08:35:14 <advil> oh I see
08:35:26 <Yermak> Also, should two Golubria commits (messaging fix and phantom image fix) be one pull-request?
08:36:17 <Yermak> Maybe it's even fine to do one request for non-related commits?
08:36:31 <advil> that's fine as one pull request
08:38:17 <advil> so when I'm trying to replicate this in console, the passage does get cleared
08:38:34 <advil> sometimes the cloud sticks around, but not the passage
08:38:35 <Yermak> It's interesting
08:38:49 <Yermak> Cloud should stick around.
08:39:19 <advil> was that screencap webtiles or local tiles?
08:39:34 <Yermak> Does it get cleared on 'X' map even when it's out of current map view?
08:39:41 <advil> yeah
08:39:52 <Yermak> It's from both.
08:40:02 <Yermak> Both tiles has this bug.
08:40:34 <Yermak> I think updating the whole map in tiles is costly and that's why only visible area is updated.
08:41:47 <advil> yeah, that could be, at least for webtiles
08:41:52 <Yermak> Sicne it's all ok in console I guess the only place that needs changes is the code related to tiles?
08:42:17 <Yermak> That's why my last idea is wrong, yes?
08:43:03 <advil> if that works (I take it you mean clearing while the player is in los) that still seems like the most straightforward solution for now
08:43:24 <|amethyst> Looks to be purely a painting problem
08:43:29 <|amethyst> at least in webtiles
08:43:32 <Yermak> Btw, you said cloud sticks around *sometimes*, not always?
08:43:45 <|amethyst> if I x over the out-of-sight gone passage, it says [the floor.]
08:43:55 <Yermak> cloud should stick always.
08:44:09 <advil> it might be that the cloud dissipates very quickly sometimes?
08:44:10 <|amethyst> whereas if the passage is still there it says [a passage of Golubria.]
08:44:29 <advil> yeah, the map knowledge will be correct
08:44:54 <advil> but it seems like that doesn't get drawn out of los in tiles
08:45:10 <Yermak> cloud is 1 + 1d3 turns, it can't dissipate immediately?
08:46:01 <Yermak> or does 1 + 0 makes it disappear right after you use the passage?
08:46:19 <advil> yeah, and I bet that also won't get drawn on tiles
08:46:23 <advil> so you'd see different behavior there
08:46:29 <|amethyst> there's also the bit where player-created clouds expire more quickly out of LOS
08:46:35 <advil> ah
08:47:45 <|amethyst> my guess is that the cloud never got drawn in the first place since it was already out of sight, and then expires too
08:47:59 <advil> I do see it sometimes in console
08:48:01 <Yermak> true
08:48:03 <|amethyst> if you wizmode teleport back to the portal's los (so you don't get a turn)
08:48:12 <|amethyst> then you will see the cloud still there
08:48:24 <|amethyst> in webtiles that is
08:48:52 <|amethyst> s/get a turn/take a turn/
08:49:33 <advil> Yermak: did you track down what specifically in viewwindow might be doing this?
08:49:36 <advil> I hate viewwindow
08:49:48 <Yermak> I did try viewvindow, didn't work.
08:49:56 <Yermak> viewwindow*
08:50:23 <Yermak> So, do I implement (destroy trap, put fog, update, move player, update) idea or should it be done in some other way?
08:51:33 <advil> what you might want to try first is just doing the map knowledge thing first, I'm not sure how trap triggering will work if the trap is already destroyed
08:51:59 <Yermak> I tried env.map_knowledge(pos).set_feature(DNGN_FLOOR); too, didn't work.
08:52:49 <advil> hm
08:52:50 <Yermak> And anyway it's called in trap_def::destroy()
08:52:51 <|amethyst> hm
08:52:59 -!- firemonkey is now known as firemonkey\splat
08:53:00 <|amethyst> looking at tileweb.cc: TilesFramework::_send_map
08:53:17 <|amethyst> perhaps it would be enough (for webtiles anyway) to get m_need_full_map set
08:54:11 <advil> if this happens in local tiles too, that won't fix it
08:54:28 <Yermak> it does
08:54:47 <advil> it does seem like there must be a bug here that would affect other out-of-los drawing in tiles
08:55:17 <Yermak> There is not much out-of-los drawing like that.
08:55:33 <advil> yeah, I can replicate in local tiles
08:57:25 <Yermak> Hmm, if you step away from monster that is on the edge of your los, and then it steps into los, it gets cleared. I think it might be possible to find something that clears it out of los.
08:57:27 <advil> it'll also affect cloud drawing out of los, local tiles is definitely not behaving like console (tiles never draws clouds out of los)
08:57:32 <|amethyst> tileidx_out_of_los seems to be what causes the issue in local tiles
08:58:12 <|amethyst> it checks for some kinds of updates to map_knowledge, but not all
08:58:22 <|amethyst> and for the cloud it specifically does not
09:00:35 <|amethyst> In fact it has this comment  // Player memory.   but that refers to the tiles, *not* map_knowledge, which is what actually represents player memory...
09:07:58 <Yermak> advil, do you see cloud on 'X' map right after passaging in console?\
09:08:51 <Yermak> It would be useful to have this cloud in terms of marking the place you came from.
09:09:21 <advil> I think it depends on whether the cloud lasted >1 turns, but sometimes. it sounded like |amethyst tested that with wizmode teleport (which is instantaneous) and it's always there
09:09:41 <|amethyst> it's "there" but it doesn't appear in the map
09:09:41 <advil> could change it to last minimum 2 turns, then it would always be visible (assuming this other stuff is fixed)
09:09:49 <Yermak> No, I get that it is always ther if you do teleport there.
09:10:20 <Yermak> I'm interested if it is marked on the 'X' map.
09:10:33 <|amethyst> meaning it probably isn't being put in map_knowledge
09:10:37 <Yermak> I guess I should yes
09:10:43 <Yermak> yes*
09:10:58 <|amethyst> I don't think making it last longer would help
09:11:54 <advil> I was definitely seeing it sometimes in X
09:12:06 <|amethyst> hm, I never do
09:13:04 <|amethyst> unless I land within LOS of the portal I entered
09:13:31 <advil> ugh this computer doesn't have ccache installed I guess
09:13:51 <advil> in 5-8 minutes I will tell you whether I was hallucinating
09:14:58 <Yermak> Speaking of ccache: it seems that whenever I create a new branch in my local repo, 'make' command start building all .o files from scratch. What could be causing this?
09:15:46 <Yermak> to be exact, I always use 'make TILES=y'
09:15:58 <gammafunk> this new branch doesn't have any file changes?
09:16:12 <gammafunk> if you were to stash changes before switching, for instance
09:16:13 <advil> are you sure that ccache is working?  try "ccache -s" to make sure
09:16:18 <Yermak> Well, I created new branch, then do changes then do make.
09:16:20 <|amethyst> even without ccache
09:16:34 <|amethyst> did you change any header files?
09:16:50 <aidanh> Try setting CXX=g++ when you run make
09:16:50 <Yermak> ccache -s puts out statistics makeing me believe it's working
09:16:58 <gammafunk> yeah, if you changed headers or any other files that are dependencies of a given object file, it must be recompiled
09:17:14 <Yermak> nope, I chaned only .cc files
09:17:58 <Yermak> What does CXX=g++ do?
09:18:00 <advil> hm, can check the stats before and after a build, if you see just the misses increasing then it's at least trying
09:18:26 <advil> it's possible that a package manager is using ccache but it's still not configured right for building other stuff
09:18:56 <nikheizen> yermak: compiles with g++
09:19:58 <aidanh> For me, the makefile was using x86_64-pc-linux-gnu-c++ as the compiler, which wasn't set up with ccache
09:20:39 <Yermak> I'm quite new to this makefile stuff. If I say that "which g++ gcc" outputs "/usr/lib/ccache/g++ /usr/lib/ccache/gcc" will it be enough to clear this question?
09:21:30 <|amethyst> cat .clfags and look at the second word
09:21:34 <|amethyst> er, .cflags
09:21:44 <|amethyst> do which on that
09:22:21 <|amethyst> I had to set up symlinks for that in /usr/lib/ccache
09:22:33 <Yermak> /usr/lib/ccache/x86_64-linux-gnu-g++
09:22:54 <|amethyst> so it should be using ccache
09:22:54 <|amethyst> s/should be/is/
09:23:11 <|amethyst> but even without ccache
09:23:42 <|amethyst> the sequence: build; git checkout -b newbranch; build with same arguments as first tile
09:23:45 <|amethyst> s/tile/time/
09:23:52 <|amethyst> shouldn't need to rebuild anything
09:23:53 <Yermak> I could try creating new branch and issuing 'make' without any flags to see if flags have any influence, but it will take half an hour.
09:23:58 <|amethyst> other than maybe version.o
09:24:21 <|amethyst> if you change from  make TILES=y  to just   make
09:24:23 <aidanh> if you make, make clean, and then make again, is the second build cached?
09:24:26 <|amethyst> that will definitely equire a rebuild
09:25:34 <Yermak> I should've put it clearer: 1) 'make' without flags, 2) create new branch, 3) 'make' without flags.
09:25:36 <aidanh> Is there something like FTFontWrapper::split() for console?
09:26:01 <|amethyst> Yermak:   make TILES=y; create new branch; make TILES=y   should also work and not rebuild the second time
09:27:15 <advil> |amethyst: I think you're right, I was just seeing clouds from having taken a bunch of passages in sequence and seen some of them in los
09:27:17 <|amethyst> aidanh:  wordwrap_line
09:27:34 <|amethyst> aidanh:  which has to be called in a loop
09:28:09 <aidanh> |amethyst: any way to use a formatted_string with that?
09:28:54 <aidanh> alternatively, if there's a function to strip formatting, I can use that, and add console formatting support later
09:30:08 <|amethyst> I'm not aware of anything to word-wrap a formatted_string after it is created
09:30:19 <|amethyst> however, it does have   parse_string_to_multiple
09:30:30 <|amethyst> to do the word-wrapping at creation time
09:30:45 <|amethyst> also, wordwrap_line has an option to handle colour tags
09:31:21 <|amethyst> (that's what parse_string_to_multiple uses)
09:33:23 <aidanh> I don't see an option for colour tags; wrap_col in parse_string_to_multiple means wrap_columns
09:33:41 <|amethyst> wordwrap_line(line, wrap_col, true, true)
09:33:46 <|amethyst> that first 'true'
09:33:51 <aidanh> Or do you mean tags
09:33:52 <|amethyst> string wordwrap_line(string &s, int width, bool tags, bool indent)
09:33:53 <aidanh> Ah
09:33:53 <|amethyst> yeah
09:33:55 <Yermak> Oh, I'm sorry, I guess I tackled 'git pull --rebase' somewhere inbetween branch changes today, and gammafunk commits had changes to header files.
09:34:06 <|amethyst> Yermak: aha
09:34:17 <aidanh> |amethyst: Ok, thanks, this looks like it'll do the trick :)
09:41:14 <gammafunk> it...it was my fault...
09:49:04 <Cheibriados> Main menu: Ogre's magic abilities are not as good as the description in the menu seems to imply. 13https://crawl.develz.org/mantis/view.php?id=11274 by Pereza0
09:54:50 <Yermak> !blame gammafunk
09:54:51 <Sequell> I pronounce gammafunk... Guilty!
10:00:28 <aidanh> Hmm.. is there anything like cprintf that handles colour tags?
10:04:57 <|amethyst> formatted_string::display
10:05:09 <|amethyst> (well, first you parse, then you display)
10:06:00 <aidanh> I saw that; wasn't sure what the start and end parameters do
10:07:11 <|amethyst> they're optional, and let you skip some of the fs_ops
10:07:37 <|amethyst> grep seems to indicate that no one actually passes those arguments
10:08:02 <aidanh> I'll try that; thanks
10:48:53 <aidanh> Ok, that works well enough
10:49:53 <aidanh> Unfortunately curses' text wrapping is jumpy when newlines get wrapped to the start of a new line.. hmm
10:55:14 <aidanh> ... and parse_string_to_multiple() fixes that; perfect
11:08:10 <Yermak> I can't find #define USE_TILE in the source. Does USE_TILE means only local tiles or both local and web?
11:08:21 <Yermak> s/means/mean/
11:09:17 <|amethyst> Yermak:  it's defined in the Makefile, and it's used for both
11:09:22 <Yermak> thank you
11:09:23 <|amethyst> local tiles is  USE_TILE_LOCAL
11:20:53 <Yermak> So, if I comment lines #891, 893 and 894 in tilepick.cc, extra passages gets cleared from the map. Monsters out of los walking into passages don't get them cleared, passages timing out out of los also don't get cleared. Magic mapping seems to work fine. All *seems* work right, but I can't call the bug fixed.
11:21:28 <Yermak> s/work/to work/
11:22:25 <Yermak> Saving-loading the game also don't get out-of-los-passages cleared.
11:23:40 <|amethyst> "Monsters out of los walking into passages don't get them cleared"
11:23:44 <|amethyst> why would it?
11:24:07 <Yermak> I made the chaneg without understnding its consequences. It could happen!
11:24:17 <|amethyst> the player didn't see the monster enter the passage, how would they know it happened?
11:24:36 <|amethyst> likewise for timing out
11:25:34 <|amethyst> the goal isn't to make the map reflect the current state of the dungeon, but to make it reflect consequences of things the player saw happen (I entered this portal, so I know it's closed now)
11:25:53 <Yermak> yes, of course
11:28:29 <Cheibriados> Text bug with losing Wu Jian piety 13https://crawl.develz.org/mantis/view.php?id=11275 by sokol815
11:32:57 <Yermak> In other words: I deleted an if-statement and bug has gone. But wasn't this if-statement there for a reason? I can't see it.
11:41:18 <|amethyst> probably only Enne knows
11:42:07 <|amethyst> it seems like it's intended to be some kind of caching
11:42:29 <aidanh> I see there's tile_gui_info(), tile_player_info(), etc. but there's no generic info() that takes a tile_def?
11:44:46 <|amethyst> TILEG_ and TILE_ have overlapping enumerator values, so no
11:46:10 <|amethyst> though you could probably implement that with a template, assuming you're passing in a literal enumerator and not something that has been saved into an int
11:46:20 <aidanh> Wait.. you can't differentiate based on the texture id?
11:46:35 <aidanh> tile_def has both tileidx and a texture id
11:47:17 <|amethyst> oh, sorry
11:47:22 <|amethyst> I misunderstood
11:49:25 <|amethyst> looks like there is something inside TilesTexture, but that's local tiles only
11:50:03 <|amethyst> hm
11:50:10 <|amethyst> but you have to get the ImageManager to be able to do that
11:50:47 <aidanh> That's ok; this is only for local tiles; image widgets currently don't render at all on console
11:51:07 <aidanh> tilesdl has a method to get the image manager, so that will work great
11:51:29 <|amethyst> once you have the ImageManager, you can do  im->m_textures[tiledef.tex].get_info(tiledef.tile)
11:51:44 <|amethyst> or something along those lines
11:52:00 <|amethyst> probably no one would complain if you made a wrapper method for that :)
11:52:04 <|amethyst> in ImageManager
11:52:40 <|amethyst> (or as a free function that takes an ImageManager *)
11:53:43 <|amethyst> maybe there should be a better way to do that that doesn't involve the ImageManager
11:54:04 <|amethyst> or at least to map from TEX_FLOOR to tile_floor_info
11:54:39 <|amethyst> the mapping is buried in ImageManager::load_textures right now though
11:54:51 <aidanh> I'll stick with a tile_info(tile_def foo) for now, as that's immediately useful
11:55:07 <|amethyst> I'm not sure how this is handled in webtiles
11:55:12 <|amethyst> I guess all on client side
11:56:10 <aidanh> It's a little weird having tile_info as part of the image manager, though
11:57:19 <aidanh> From what I can work out, yeah, client side stuff
11:57:38 <Cheibriados> 03gammafunk02 07* 0.21-a0-415-g9d6f0e4: Give the Vortex monster spell a description 10(17 seconds ago, 1 file, 8+ 0-) 13https://github.com/crawl/crawl/commit/9d6f0e4082e6
12:03:26 <aidanh> Is there any support for rendering repeating tiles?
12:04:38 <aidanh> Was thinking it'd be useful for UI box backgrounds
12:05:16 <aidanh> It's possible to do manually, but it's more efficient if it's done in a shader
12:16:30 <|amethyst> aidanh:  googling seems to indicate that SDL doesn't have a way to do that, so you'd have to either loop, or fall back to opengl
12:17:03 <aidanh> not directly, no, but all the tiles rendering code uses opengl anyway
12:17:33 <aidanh> I'll fall back to a loop to start with
12:17:44 <aidanh> Needs to work first
12:30:19 <Yermak> If I pull a commit deleting aforementioned 'if' will it be accepted? (I doubt it's normal to make changes without full understanding of what you're doing.)
12:53:14 <gammafunk> Yermak: you certainly can, and mention what is your understanding about it
12:53:38 <gammafunk> and one of us can take a closer look and either merge or close the PR if it turns out there's a reason why it must remain
12:54:29 <gammafunk> I might be able to look at it later today, I have a bit of a backlog of mantis issues and PRs I need to get to
12:55:21 <Yermak> I just wanted to see what happens if I delete 'if'. It turned out that bug was fixed and nothing was broken as far as I could see. I have no other understanding.
12:55:57 <gammafunk> well, it's nice to document that work in some way with a bug report or PR, but yeah I can't comment further without looking in detail
12:56:20 <Yermak> ok, thanks
13:09:04 -!- amalloy_ is now known as amalloy
13:22:03 <Henzell> Unstable branch on crawl.akrasiac.org updated to: 0.21-a0-415-g9d6f0e4 (34)
13:23:43 <amalloy> i like to refer to https://en.wikipedia.org/wiki/Wikipedia:Chesterton%27s_fence when i'm thinking about deleting something that's clearly pointless
13:42:23 <Cheibriados> New branch created: pull/645 (1 commit) 13https://github.com/crawl/crawl/pull/645
13:42:23 <Cheibriados> 03Yermak02 07https://github.com/crawl/crawl/pull/645 * 0.21-a0-415-gab1ab6f: Improve messaging for passage of Golubria 10(41 minutes ago, 2 files, 18+ 18-) 13https://github.com/crawl/crawl/commit/ab1ab6f64c71
13:56:48 <geekosaur> [02 17:52:28] <Xiongnu> So every time I get a --more-- prompt, everything on my screen moves up a line including the viewport.  And only new glyphs refresh.
14:00:55 -!- socks__ is now known as socks_
14:03:19 <Cheibriados> New branch created: pull/646 (1 commit) 13https://github.com/crawl/crawl/pull/646
14:03:19 <Cheibriados> 03Yermak02 07https://github.com/crawl/crawl/pull/646 * 0.21-a0-415-g85b3557: Change Ogre's description (Pereza0) 10(8 minutes ago, 1 file, 1+ 1-) 13https://github.com/crawl/crawl/commit/85b35574b78e
14:34:43 <Cheibriados> New branch created: pull/647 (1 commit) 13https://github.com/crawl/crawl/pull/647
14:34:43 <Cheibriados> 03Filip Michałowski02 07https://github.com/crawl/crawl/pull/647 * 0.21-a0-406-g81d50fc: Fixed no ability description on R-click (#11231) 10(22 hours ago, 3 files, 27+ 1-) 13https://github.com/crawl/crawl/commit/81d50fc7ae9b
14:36:15 <Yermak> If I fix a mantis bug, is it better to mention reporter's name in brackets or number of the issue? E.g. "Change Ogre's description (Pereza0)" or "Change Ogre's description (11274)"?
14:37:02 <amalloy> i like to put the reporter's name in the commit title, and then if you want you can also refer to the mantis issue in the longer description
14:37:08 <amalloy> people like to see their name
14:38:23 <geekosaur> why not both? (Pereza0, 11274)
14:45:11 <Cheibriados> New branch created: pull/648 (1 commit) 13https://github.com/crawl/crawl/pull/648
14:45:11 <Cheibriados> 03Yermak02 07https://github.com/crawl/crawl/pull/648 * 0.21-a0-415-g31839ce: Improve WJC messaging (sokol815) 10(7 minutes ago, 1 file, 7+ 5-) 13https://github.com/crawl/crawl/commit/31839ce7fa89
14:46:36 <Yermak> What's better - ASSERT(bool_function()); or bool var = bool_function(); ASSERT(var);?
14:48:12 <gammafunk> I think the former
14:48:57 <amalloy> the second would be important if we disabled ASSERTs in release builds and bool_function() had side effects that we want to perform regardless, but since that's not the case the former is better
14:50:57 <Yermak> bool_function does have side effects. Still the first option?
14:52:02 <gammafunk> don't way have a way to disable ASSERTs in a build?
14:52:11 <gammafunk> I seem to recall that
14:53:37 <Yermak> How do I change my pull request?
14:53:49 <gammafunk> you can force push to the branch
14:54:10 <gammafunk> you could simply make a subsequent commit, but force push is probably the best way, so that your PR can be merged more easilly
14:54:32 <amalloy> eh, i think an ordinary push is usually better
14:54:40 <amalloy> so that reviewers can see the progression
14:54:57 <gammafunk> well it's ultimately a personal preference
14:55:00 <amalloy> yes
14:55:12 <Yermak> Ok, push, but what then? Do I make new pull-request?
14:55:21 <gammafunk> oh, no regardless of which you do
14:55:42 <gammafunk> you simply make/push a commit to the same branch
14:55:42 <gammafunk> the PR is tied to this branch
14:55:42 <Yermak> oh, I got it
14:55:42 <gammafunk> and the PR listing will see any current state of the branch
14:55:50 <amalloy> i guess if it has side effects it's probably not a good idea to do it in an assert
14:56:03 <amalloy> it turns out we do have a way to disable asserts even though i've never seen it used
14:56:22 <gammafunk> yeah that was my intuition
14:57:26 <Yermak> If ASSERTs are disabled, won't compiler grunt at unused bool variable?
14:58:42 <gammafunk> yeah I suppose it might
14:59:34 <Yermak> Also if I make second commit to reflect requested changes and it's accepted which commit's name will be used as the result?
14:59:54 <amalloy> the person merging the PR chooses how to merge it
14:59:58 <Yermak> ok
15:00:29 <gammafunk> for something like that, we'd expect the merge to rebase the commits, although it might depend on the nature of those commits I guess
15:00:40 <gammafunk> s/merge/merger/
15:01:01 <gammafunk> they could squash them, but if they didn't, it wouldn't be a big deal either
15:01:38 <gammafunk> I like to squash commits when possible, particlarly if a commit is a fix to trying to do a thing attempted in a previous commit
15:01:40 <amalloy> look at https://github.com/crawl/crawl/pull/643 for an example
15:01:59 <amalloy> you made a commit, i added a second commit, and then while merging i squashed them together into one commit written by you
15:02:17 <gammafunk> good thing he did too
15:02:29 <gammafunk> "replace commad with and..." he didn't finish his thought!
15:02:34 <gammafunk> *comma
15:03:27 <gammafunk> quite excellent joke ruined by a typo, what a shame
15:12:20 <Yermak> Do all enums have each own .h files?
15:15:03 <gammafunk> no Yermak
15:15:31 <gammafunk> their having a header file is mostly to help avoid recompilation for enums that are non-static
15:16:37 <gammafunk> if they lie in the header file associated with a cc file, cc files that include the first cc file header for the functions define in there (that may not use this enum)
15:16:42 <gammafunk> then changing the enum means all these dependent files need recompilation
15:17:32 <amalloy> Yermak: since the enum i suggested adding is only used internally by a single .cc file, i think it would be reasonable to just add it to the top of that .cc file. |amethyst may disagree
15:17:35 <gammafunk> so if it has a header, cc files can directly include it if they need it
15:18:28 <gammafunk> if an enum is only used in one cc file and doesn't appear as part of any prototype, then generally it just stays in that cc file
15:18:39 <amalloy> specifically i imagine Yermak is thinking about https://github.com/crawl/crawl/pull/645#pullrequestreview-73890171
15:58:25 <Cheibriados> 03Yermak02 07https://github.com/crawl/crawl/pull/645 * 0.21-a0-416-gf726ff4: Improve Golubria messaging version2 10(5 minutes ago, 1 file, 19+ 8-) 13https://github.com/crawl/crawl/commit/f726ff42df8b
16:19:20 <Cheibriados> 03Yermak02 07https://github.com/crawl/crawl/pull/641 * 0.21-a0-416-g728eac4: Remove reference to cleared levels from 'Out of the depths' paragraph. 10(6 minutes ago, 1 file, 3+ 4-) 13https://github.com/crawl/crawl/commit/728eac4579d8
16:20:54 <Yermak> If I comment a bug on mantis, it goes at the top of the list. How are changes tracked in pull requests?
16:30:12 <amalloy> https://github.com/crawl/crawl/pulls
16:30:46 <aidanh> PRs stay in the same order, but people watching the repo or the PR will be notified of new changes/comments
16:30:49 <Yermak> Yes, they stay at the same spot after changes was made.
16:30:59 <Yermak> oh
16:33:11 <amalloy> right, i got an email about your change but i was at lunch. just replied
16:48:44 <Brannock> there are a lot of open pull requests. we should be merging/closing some of these.
16:50:44 <Cheibriados> 03Yermak02 07https://github.com/crawl/crawl/pull/645 * 0.21-a0-417-gb3b7f0b: Improve Golubria messaging version3 10(4 minutes ago, 1 file, 10+ 10-) 13https://github.com/crawl/crawl/commit/b3b7f0b226f0
16:51:04 <Yermak> There are a lot of issues on Mantis that should be closed also.
16:51:31 <Brannock> I'd start working on some of the PRs but I'd need some time to refamiliarize myself with the codebase after being away for so long.
16:56:25 <Cheibriados> 03Mindcrafter02 {amalloy} 07* 0.21-a0-416-g79d0e6c: Improve messaging for passage of Golubria (#645) 10(8 seconds ago, 2 files, 31+ 20-) 13https://github.com/crawl/crawl/commit/79d0e6c15588
17:08:24 <gammafunk> Well PRs should be closed/merged as we have time, but most of them are minor
17:08:34 <gammafunk> I view them the same was as bug reports
17:08:57 <gammafunk> certainly good to merge them if we can, but there is not a timer that necessarily starts ticking when one is made or anything
17:09:15 <gammafunk> Right now I'm going to be focusing on getting a couple important items for the dev plan complete
17:10:07 <gammafunk> probably wu removal+usk merging and wand stacking, hopefully this week
17:10:18 <gammafunk> We should also consider if we want to merge neil's food branch
17:10:58 <gammafunk> I'm still overall mostly interested in a removal of food with something like piety decay or maybe that trap effect idea Lasty and elliptic were discussing (or both)
17:11:06 <gammafunk> but those will take some time to work out the details
17:11:38 <gammafunk> oh and purple chunks, either removal (that seemed to be a concensus, but there was some talk about changing the way some mutations work)
17:11:50 <gammafunk> or just letting them be eaten while engorged, at a minimum
17:12:00 <gammafunk> even if we don't want to merge the food unification branch right now
17:12:40 <gammafunk> but I need to go back and read that discussion about mutation changes for the tiered ones and see if that could be done relatively easilly
17:13:05 <gammafunk> in which case we could maybe remove purple chunks
17:13:22 <gammafunk> oh, and eating while engorged sounds simple, but apparently has some possibly nasty technical issues
17:18:18 <Yermak> So I guess it is a good idea then to comment mantis bugs which have pull-requests?
17:19:39 <Yermak> What would be the wording? "Pull-request has been issued"? "Patch has been bull-requested"?
17:21:42 <gammafunk> "See the pull request here: <link>" is fine
17:22:16 <gammafunk> I suppose you could just mention the pull request number, but a link is nice if you have it
19:03:25 <Cheibriados> 03Mindcrafter02 {amalloy} 07* 0.21-a0-417-g0adc95b: Improve WJC messaging (sokol815) (#648) 10(8 seconds ago, 1 file, 7+ 5-) 13https://github.com/crawl/crawl/commit/0adc95ba8ec2
20:47:07 <espais> !messages
20:47:07 <Sequell> No messages for espais.
21:03:43 <espais> anybody online that knows much about the travis CI process?
21:10:51 <espais> basically, i was hoping to play around with the test suites as the CI process intrigues me (academically), and was curious if it were something i could take and run offline
21:12:08 <|amethyst> espais:  they seem to have source code at   https://github.com/travis-ci/travis-ci
21:12:30 <|amethyst> (mostly in submodules of that repo, it appears)
21:12:41 <espais> crawl-specific though?
21:12:52 <espais> i thought that was just the travis code
21:12:53 <|amethyst> ah, no
21:13:04 <|amethyst> I thought you meant you wanted to run your own copy of Travis-CI
21:13:09 <espais> oh no, that i could probably figure out
21:13:35 <espais> i do a lot of software testing research (am prof.) and was thinking that travis ci was a really interesting development in the testing world
21:13:48 <espais> and i was hoping to apply my addiction of crawl to my academic life
21:14:24 <|amethyst> crawl's travis config is in .travis.yml and .travis/ under our repo
21:15:16 <|amethyst> well, the config is in .travis.yml but it refers to some Perl scripts in .travis/ that set up the apt repos, dependencies, etc
21:16:00 <espais> ah, so that's part of the actual repo then
21:16:20 <espais> gooood gooooood
21:16:20 <espais> http://s2.quickmeme.com/img/73/732b0b61628088b3e0c41ad6fdbad98c04581515e682478399edc9b40adc271e.jpg
21:16:29 <espais> i could probably setup a local instance of git/travis then and run my stuff
21:16:32 <|amethyst> yes.  In fact, if you clone the repo and enable travis without changing anything else, it will report back to ##crawl-dev with results
21:16:36 <|amethyst> which isn't so great, but
21:16:42 <espais> yea...probably will have to redirect that
21:16:50 <espais> otherwise you guys are going to be flooded with results
21:17:02 <espais> (planning on running a genetic algorithm to optimize some test suites)
21:17:10 <|amethyst> if you're using your own copy of travis, you can probably just disable the IRC notifier
21:17:17 <espais> hah
21:17:25 <espais> shouldn't be an issue anyway ... my univ's firewall blocks the irc port
21:17:55 <espais> i'm running a local instance of dgl and had to setup beem to run off of a raspberry pi from my house
21:18:30 <espais> awesome, thanks |amethyst
21:18:42 <espais> quick Q...did you guys drive the yml file or was that auto-generated?
21:18:47 <espais> *derive the yml
21:20:19 <|amethyst> probably was made by hand, though it might have been based on a reference
21:21:54 <espais> kk
21:21:59 <espais> alright, thanks
23:37:20 -!- mikee__ is now known as mikee_
23:42:24 -!- mikee___ is now known as mikee_