01:45:54 -!- amalloy is now known as amalloy_ 03:30:52 Fork (bcrawl) on crawl.kelbi.org updated to: 0.23-a0-2347-g4f414a2140 04:49:10 03Umer Shaikh02 07https://github.com/crawl/crawl/pull/1136 * 0.24-a0-596-g84f6445: Allow putting on jewellery from the floor 10(3 hours ago, 4 files, 64+ 51-) 13https://github.com/crawl/crawl/commit/84f6445daaa5 11:23:55 Stable (0.23) branch on underhound.eu updated to: 0.23.1-89-g277498a001 12:59:55 -!- amalloy_ is now known as amalloy 14:20:48 demonblade (L22 GnSk) ASSERT(!invalid_monster(&mons)) in 'mon-death.cc' at line 1839 failed. (Depths:2) 14:21:58 !crashlog 14:22:16 21176. demonblade, XL22 GnSk, T:54673 (milestone): http://crawl.akrasiac.org/rawdata/demonblade/crash-demonblade-20190910-182046.txt 16:18:39 New branch created: py2019 (1 commit) 13https://github.com/crawl/crawl/tree/py2019 16:18:39 03advil02 07[py2019] * 0.24-a0-614-g17cf758: Preliminary support for Tornado 5+ 10(7 minutes ago, 10 files, 96+ 97-) 13https://github.com/crawl/crawl/commit/17cf7582c9a6 16:20:23 advil: nice branch name :) ; not sure if you pulled any of my attempts at moving webtiles forward from webtiles-changes or if the stuff you got was from Edlothiol 16:20:42 but maybe I can help look over that code if I take a break from fedhas stuff for a day or two 16:20:45 I was looking at the webtiles-changes branch, is there another one? 16:21:05 uh, there is but I think it's just one to update jsx/react contribs etc 16:21:07 well 16:21:13 let me refresh my memory, it's been so long 16:21:35 %git webtiles-changes-bsr 16:21:35 07gammafunk02 * 0.16-a0-3871-g47fc128: Require an http option and set in the default config (mrwooster) 10(4 years, 6 months ago, 3 files, 13+ 9-) 13https://github.com/crawl/crawl/commit/47fc128b3d0c 16:21:40 I did have some trouble finding commits that solved all the issues I ran into, so I may well have missed something 16:22:00 though webtiles-changes just wanted tornado v 4.1 I think, and version 5 removes a bunch of deprecated stuff 16:22:05 my big concern without looking into things was if the new tornado model was all based on futures or whatnot 16:22:13 right 16:22:30 crazy as it sounds, the way I fixed it up seems to still run in tornado 3.2.1?? 16:22:37 yeah 16:22:41 which seems much too good to be true 16:23:03 I think if you're properly using tornado latest you are using something more like the asycio style? 16:23:13 yes, but that's all under the hood 16:23:22 the only thing I needed to do for that was the ioloop restructuring 16:24:08 yeah, but if you look at the 6.x user guide they're giving examples with e.g. async def/ await 16:24:16 though I suspect that trunk webtiles has one ioloop per crawl process? which isn't allowed any more unless the ioloop is actually in a different thread...so that may represent a big under-the-hood change 16:24:23 I do plan on testing with tornado 6 16:25:23 well it's a great project to get going either way, so we can finally move to python 3 and have a python codebase that's remotely close to modern standards 16:25:25 but I'm going to fix up the python so it is forward compatible first 16:25:26 yep 16:25:46 was reminded this morning that python 2 is **dead** in Jan 2020 16:25:58 yeah i just read about that 16:26:01 thought I'd give this part of the upgrade a shot 16:26:29 oof 16:27:10 floraline: one thing I forgot to put in the commit message is that they way the password reset did its timeout doesn't work with asyncio in current Tornado 16:27:23 can you remember if there's some reason we didn't call that in a subprocess? 16:27:44 (in the branch it simply blocks until it returns) 16:29:50 i did it in the most naive way, don't give me the benefit of the doubt there 16:30:09 i only made it work, i surely didn't do it in the smartest way 16:30:15 heh 16:30:19 well I merged it 16:30:30 and I vaguely remembered some kind of discussion about that part 16:30:40 it blocks that client's thread while it works on sending the email iirc 16:30:52 i think i figured that was no big deal so i just moved on 16:55:52 Duplicate antique items for wrong price 13https://crawl.develz.org/mantis/view.php?id=12060 by Le_Nerd 17:13:04 The build passed. (py2019 - 17cf758 #11877 : advil): https://travis-ci.org/crawl/crawl/builds/583342468 17:19:16 floraline: afaik only the crawl process itself is in a different thread, the webserver app is singlethreaded 17:22:13 i thought every request spawns its own thread? 17:23:24 for the crawl propcess 17:23:28 *process 17:30:19 yeah it just uses the tornado event loop for http stuff, right? 17:40:58 yeah 17:41:45 which is nowadays the asyncio loop (which is basically magic I think) 17:42:01 but it will block 17:42:26 there's a debug setting that does some logging if there's a blocking subprocess, but I think it might slow things down 17:44:27 well, maybe I don't understand the question, but can the password reset stuff just not be done using an asynchronous python library? 17:44:31 the blocking issue is specifically for calling the smtp server, and I think it should be doable in a subprocess 17:44:53 right, but there's probably an asynchronous python library for doing smtp 17:45:03 so that wouldn't block the main loop if used correctly 17:45:57 at least I see this: https://github.com/cole/aiosmtplib 17:47:01 most of the commonly used protocols have properly asynchronous libraries at this point 17:50:38 I think even just `os.fork` would work for this use case 17:53:42 well, maybe not 17:54:23 I'm seeing examples of using asyncio with an event loop in a seperate thread too 17:55:10 I'm not really well-versed on what's the best approach for our needs; I can say that just using a properly asynchronous library (like that aiosmtplib) is a nice way to prevent blocking stuff 17:55:43 the websockets library we and everyone else uses is properly asynchronous, for example 17:56:03 in this case I was thinking about something simpler because the sendmail call just needs to be fed some data from the parent process and then terminate 17:56:23 maybe check out https://hackernoon.com/threaded-asynchronous-magic-and-how-to-wield-it-bba9ed602c32 17:56:40 they use sending a smtp message as an example 17:56:51 with a non-asynchronous library for smtp 17:57:24 although good lord their code blocks in that page are not rendered properly 17:58:07 heh they actually use a password reset thing as an ex 17:58:10 though, "The recommended practice so far has been to use a task queuing system like celery, on top of a message queue server like rabbitmq to schedule the work. " 17:58:15 uh, not sure who was recommending that 17:59:05 we are obviously a bunch of "bare metal" folks here 17:59:23 oh and I just found this: https://pypi.org/project/tornado-smtp/ 17:59:30 yeah, I saw that one 17:59:36 https://github.com/rmoritz/tornado-smtp 17:59:43 it's abandoned but also extremely simple 17:59:49 more importantly we have a pretty small userbase who is tolerant of failures, so the extra scaling/resiliency we'd get from message queueing hardly matters 18:00:58 maybe that code will serve as a good example, at least (the tornado-smtp thing) 18:09:25 did require pyyaml force all servers to be at least python 2.7? 18:09:29 *requiring 18:14:49 not sure 18:21:57 CatfishMan (L27 GrFi) ASSERT(attacker) in 'attack.cc' at line 354 failed. (Pan) 19:24:37 do we produce ascii ttyrecs? 19:24:50 or utf8 (which apparently may be possible)? 20:05:43 I think unicode 20:06:07 !lg . -ttyrec 20:06:12 829. gammafunk, XL23 DEVM, T:87316: https://crawl.kelbi.org/crawl/ttyrec/gammafunk/ 2019-03-17.04:20:27.ttyrec.bz2 2019-03-17.07:23:01.ttyrec.bz2 2019-03-18.00:23:52.ttyrec.bz2 2019-03-18.01:38:03.ttyrec.bz2 2019-03-18.02:56:53.ttyrec.bz2 2019-03-18.03:38:46.ttyrec.bz2 2019-03-18.05:21:55.ttyrec.bz2 2019-03-18.07:03:59.ttyrec.bz2 2019-03-18.08:40:02.ttyrec.bz2 2019-03-18.20:34:15.ttyrec.bz2 2019-0... 20:06:17 rip 20:09:08 like those default corpse symbols we use 20:09:08 the cross, that is rendering properly in my ttyrec 21:59:01 -!- amalloy is now known as amalloy_ 22:12:04 Webtiles stash search interface allows selection of item from invisible menu 13https://crawl.develz.org/mantis/view.php?id=12061 by vt 22:36:36 -!- amalloy_ is now known as amalloy