IRC logs for #openttd on OFTC at 2023-11-02
⏴ go to previous day
00:38:24 *** Alkel_U3 has joined #openttd
01:38:52 *** HerzogDeXtEr has quit IRC (Read error: Connection reset by peer)
01:55:46 *** Wormnest has quit IRC (Quit: Leaving)
02:00:59 *** wallabra has quit IRC (Read error: Connection reset by peer)
02:01:47 *** wallabra has joined #openttd
03:32:18 *** pemensik|home has quit IRC (Read error: Connection reset by peer)
03:34:05 *** pemensik|home has joined #openttd
03:44:08 *** D-HUND has quit IRC (Ping timeout: 480 seconds)
07:27:02 *** Flygon has quit IRC (Read error: Connection reset by peer)
08:47:21 *** HerzogDeXtEr has joined #openttd
10:15:19 *** marchnex has joined #openttd
10:33:32 <peter1138> ^ We're doing it wrong ;p
10:37:59 <frosch123> repaired within 10 minutes? some compiler errors take that long to read :p
10:46:00 *** pemensik has joined #openttd
11:04:50 <peter1138> Hmm, I need to mock GetSpriteSize...
11:56:00 *** pemensik_ has joined #openttd
12:02:06 *** pemensik has quit IRC (Ping timeout: 480 seconds)
12:31:30 *** pemensik__ has joined #openttd
12:34:58 <peter1138> #8700 bugs me, original graphs were grey. Stylistically that was correct because that was the original colour.
12:37:36 *** pemensik_ has quit IRC (Ping timeout: 480 seconds)
12:50:14 *** virtualrandomnumber has joined #openttd
13:12:41 *** virtualrandomnumber has quit IRC (Quit: virtualrandomnumber)
13:23:56 <peter1138> Hmm, maybe I should make my random MIDI player shuffle the list and play that back, instead of picking 1 random entry from the list.
13:24:06 <peter1138> "It's not random enough!"
13:24:15 <peter1138> "The same track 4 times in a row!?"
13:24:38 <peter1138> Maybe I should grow up and listen to real music instead of computer game MIDIs...
13:28:55 *** virtualrandomnumber has joined #openttd
13:30:00 *** virtualrandomnumber has quit IRC ()
13:49:13 <goddess_ishtar> You mean computer game midis aren't real music?
13:52:55 <bungus> made with real instruments
13:53:24 <peter1138> This is a real synthesizer :D
14:03:21 <peter1138> Heh, so track 10 has a hidden section at the end... a.k.a broken.
14:19:58 <peter1138> Is crashing due to assert a valid way to fail a unit test? :D
14:26:20 <goddess_ishtar> task failed successfully?
14:26:44 <peter1138> No, if it asserts, it fails, if it doesn't assert, it's successful.
14:27:05 <peter1138> But the asserts are in the code that the unit test calls, not in the unit test itself.
14:27:46 <goddess_ishtar> oh, I meant in the meme way
14:39:45 <peter1138> LordAro, I guess we could try using throw instead of assert... :o
14:39:59 <alfagamma7> there are posts in the tt forums older than me myself heh
15:15:57 *** Wormnest has joined #openttd
15:20:40 <peter1138> Turns out my API doesn't work when I... try running it on the "live-test" instance instead of my development instance...
15:28:40 <Rubidium> peter1138: the sneaky solution would be to write the unit test for something tangentially related, and the unit test crashing because the window configuration is wrong is just a happy accident :D
15:32:05 <peter1138> Hmm, does catch22 have a way to "run this before the tests"?
15:34:10 <peter1138> I don't know what I mean :-)
15:34:44 <frosch123> constructor runs before the test, destructor runs after the test
15:36:13 <Rubidium> nice! An assert in an unit test does not even crash the test, as the test seems to be running in a subprocess
15:38:00 <peter1138> Rubidium, yes, it works quite well considering.
15:39:54 <peter1138> Now if I could iterate a vector and treat each object inside as a separate test that would be nice... but I doubt it.
17:12:43 <jfs> re. #11408, "It has nothing to do with masking the password. The passwords are never masked."
17:12:43 <jfs> shows how out of touch I am here 😄 that's true. I actually think I was the one to PR that "server admin might be able to read this password" warning in the first place, I'm quite sure I remember considering putting it in for the server password entry too and deciding against it back then
17:17:32 <merni> If only Unicode had been invented decades earlier than it was...
17:18:46 <Rubidium> merni: nah, if only the C++17 standard just had functions for sorting unicode/utf8 encoded strings. Now we use a different system depending on the operating system, which make changing/fixing it so much harder
17:19:22 <merni> Well, this is not sorting but searching, but yes :)
17:20:43 <merni> It is also very helpful when GNU hides the fact these functions are not actually properly multilingual/locale-aware, everywhere except source code comments
17:21:10 <frosch123> merni: the same applies to windows btw.
17:21:27 <frosch123> the C api functions only work for 8 bit locales, in utf-8 mode they only do ascii
17:21:53 <Rubidium> practically same difference... sorting requires a comparison, searching too. Given the way the standard works, the comparison is used in search and sort :D
17:21:55 <frosch123> funnily i am not even sure whether ottd ever sets a locale
17:22:23 <frosch123> so on windows with used non-unicode default locales, the current behavior may be even more random
17:23:36 <frosch123> ICU has specific search/filter methods, which are separate to the sorting. i would not be surprised if they do something different :p
17:29:37 <Rubidium> jfs: funnily the "server admin might be able to read this password" for companies is more in the realm of hypothetical (it's a salted MD5 hash); the server password is just sent plain text. So if you erroneously type in a password of something completely different, the server admin can just write the passwords straight to a log file or something
17:30:07 *** virtualrandomnumber has joined #openttd
17:30:16 *** virtualrandomnumber has quit IRC ()
17:32:22 <merni> frosch123: Is this fact stated somewhere visible, like on a man page or something
17:36:16 <frosch123> no, i tried it at work some months ago
17:36:45 <frosch123> so, result from experimentation 🙂
17:37:23 <frosch123> either way, ottd never calls setlocale, so the behavior is "random"
17:37:43 <frosch123> on linux systems you usually have a utf-8 locale by default, so it would do ascii
17:38:25 <frosch123> on windows you have 8 bit locales on western systems like in 1993, and shift-jis on japanese, also like in 199x
17:38:56 <frosch123> ottd always passed utf-8, so the behavior on windows will be just broken 🙂
17:40:57 <_jgr_> OTTD uses the W functions instead of the A ones, the behaviour isn't broken
17:41:41 <Rubidium> don't those functions require a wchar_t?
17:41:55 <_jgr_> Windows does support UTF-8 for the A functions these days though
17:42:35 <_jgr_> Yes, the various conversion wrappers are for going to/from wchar_t
17:43:31 <frosch123> stringfilter.cpp uses strcasestr, which we map to strnicmp
17:43:34 <Rubidium> so they wrap strncasecmp so it goes from char to wchar_t
17:46:04 <_jgr_> Changing the locale is usually not a good idea and for localised case operations you're better off not using the c functions at all
17:47:55 <frosch123> well, that's the whole point of the discussion 🙂 currently we use the locale-specific c-functions with the (unknown) default locale, and pass utf-8 data as char* to th em
17:50:29 <frosch123> truebrain: i guess the only solution to the copilot-requests is to disable notifications :/ no way to see who requests shit, and no way to reject the request
17:52:01 <truebrain> I didn't get any more emails after the first?
17:52:03 <Rubidium> how bad are we going to be if we just require ICU, and use ICU strings for anything UI related? That seems to be the easiest solution
17:52:19 <merni> ICU is already required on linux
17:52:30 <frosch123> info@ gets a weekly reminder
17:52:31 <LordAro> macos & windows have their own versions, no?
17:54:02 <frosch123> truebrain: also, do you understand the latest signing mail? they want to do a (manual?) code review, whether there is any side loading capability in ottd? would that be a hard block for #11391 ?
17:54:20 <merni> And ICU seems to be already used for sorting (at least in some places), just not in this particular case of StringFilter
17:54:22 <truebrain> hmm ... for now I am having troubles figuring out how to login to 1password again ..
17:54:30 <truebrain> new PC, and forgot how to do that 😛
17:55:48 <LordAro> step 1: open passwords.txt
17:56:24 <frosch123> silly you, always prepend a "." to hide those files
18:00:40 <frosch123> you can't cancel the trial :p
18:01:00 <Rubidium> merni: you can build perfectly fine without ICU on Linux, i.e. it is not required just highly recommended
18:05:25 <truebrain> frosch123: that is because of an email orudge sent to them (as it is also a reply to that)
18:06:02 <truebrain> basically, your cert expires next year, and the cert provider now demands a hardware token to sign
18:06:08 <truebrain> which doesn't work with our current flow
18:06:17 <frosch123> i know the imagemagick story
18:06:39 <frosch123> but they listed some weird requirement in the latest mail
18:07:04 <truebrain> orudge is handling it; so you would have to ask him 🙂
18:11:28 <truebrain> frosch123: ironically, it was already set to: ignore requests
18:11:43 <truebrain> but for some reason GitHub finds it required to keep repeating the email till you signed in for that account, I guess
18:11:49 <truebrain> I just did that, so hopefully it will shut up now
18:12:17 <truebrain> lol, and the link to Notification Settings from the email doesn't work 😛 Lovely
18:12:18 <frosch123> ah, that sounds plausible
18:13:56 <truebrain> I now have a watercooled system, so it pumps warm water in the radiator .. my setup has an option to shut down the fans if it is not all that hot .. so the water is 38 degrees .. which makes the radiator 38 degrees .. which makes it hot-for-the-touch to touch the case 😛
18:14:00 <truebrain> #first-world-problems
18:15:19 <frosch123> do we need to worry? i was under the impression that 30% of watercooled systems break to do leakage in the first year
18:15:38 <truebrain> let's see on what side of the statistics I fall
18:15:41 <Rubidium> it's no MBP, so it's not hosting anything important ;)
18:15:45 <truebrain> I did replace the system already, within a week .. so ...
18:16:07 <LordAro> with custom watercooling perhaps, but probably not with an AIO?
18:16:08 <truebrain> (the last one I had, had a pump which was a fixed speed .. and it was making a high-pitch noise .. that was SO annoying)
18:16:12 <LordAro> (not that i know which TB has)
18:16:19 <truebrain> I am not a total idiot
18:16:22 <truebrain> most of the time at least 😛
18:16:42 <truebrain> to proof me wrong, I also got RGB and a glass side on the case
18:16:43 <LordAro> i feel like that should be framed
18:16:45 <truebrain> so I now have pretty colours
18:16:59 <LordAro> i got pretty colours on my new graphics card
18:17:20 <frosch123> lol, mid-life crisis? :p
18:17:24 <LordAro> (my case is both under my desk out of sight, and also with solid doors)
18:17:33 <truebrain> frosch123: the nerd-variant of it? 😄
18:17:41 <frosch123> my case is black with minimal lightning
18:17:50 <truebrain> I do compile OpenTTD within a minute now
18:18:00 <frosch123> best-case scenario is when you can't tell whether it's on or off
18:18:49 <frosch123> truebrain: with LTO?
18:19:03 <truebrain> just a plain: mkdir build; cd build; cmake .. ; make -j15
18:26:01 <frosch123> truebrain: two years ago there was an incident with a german gaming streamer: they published a video about their new 60k gaming room with 2 new streaming PCs with water-cooling. and literally 3 weeks later they had to make an update video about how the water cooling caused a short-circuit, which put the PC and the whole room on fire...
18:37:52 <peter1138> Okay... if I use exceptions instead of asserts, the unit-test is nicer.
18:38:53 <peter1138> But that means using exceptions instead of asserts.
18:39:06 <DorpsGek> - Update: Translations from eints (by translators)
18:40:21 <Rubidium> peter1138: and runtime checks in releases, which don't happen with asserts (if we do not forget to turn them off)
18:41:09 <peter1138> Well, I suppose it's possible to also ... do that yes.
18:41:43 <peter1138> Although to be fair, this is not performance critical code, and if it's wrong it will fail unit-tests, so...
18:42:24 <LordAro> is the unit test designed in such a way that it's impossible to create a window without this?
18:42:46 <LordAro> then yeah, might as well leave it
18:42:56 <LordAro> throw in an [[unlikely]] or whatever :)
18:44:02 <peter1138> We have unlikely() though.
18:47:38 <peter1138> test cases: 68 | 67 passed | 1 failed
18:47:38 <peter1138> assertions: 878 | 869 passed | 9 failed
18:48:26 <peter1138> Do I need to do anything to remove a workflow over than remove the .yml file (and its script)?
18:53:53 <peter1138> So it turns out the testfixture stuff is reconstructed for each time... not exactly what I want.
19:19:08 *** pemensik__ has quit IRC (Ping timeout: 480 seconds)
19:32:40 <peter1138> Okay, this is a stageable.
19:48:35 <peter1138> Huh, well if it's not declared at that point, then I could just replace NAMEOF(x) with "x".
19:49:22 <truebrain> a CodeChange with a Fix commit in it
19:49:28 <truebrain> confusing reviewers like a pro 😄
19:49:53 <peter1138> I always forget what I am doing :p
19:54:02 <LordAro> did someone say something?
19:54:29 *** Smedles has quit IRC (Remote host closed the connection)
19:56:31 *** Smedles has joined #openttd
19:59:14 *** DorpsGek_vi[1] has joined #openttd
19:59:18 *** siciuvatiresubumbras has quit IRC (Remote host closed the connection)
19:59:18 *** _jgr_ has quit IRC (Remote host closed the connection)
19:59:18 *** peter1138[d] has quit IRC (Remote host closed the connection)
19:59:18 *** georgevb has quit IRC (Remote host closed the connection)
19:59:18 *** locosage has quit IRC (Remote host closed the connection)
19:59:18 *** frosch123 has quit IRC (Remote host closed the connection)
19:59:18 *** shrekshellraiser has quit IRC (Remote host closed the connection)
19:59:18 *** ahyangyi has quit IRC (Remote host closed the connection)
19:59:18 *** bungus has quit IRC (Remote host closed the connection)
19:59:18 *** johnfranklin has quit IRC (Remote host closed the connection)
19:59:18 *** merni has quit IRC (Remote host closed the connection)
19:59:18 *** michi_cc[d] has quit IRC (Remote host closed the connection)
19:59:18 *** FruitSalad has quit IRC (Remote host closed the connection)
19:59:18 *** kamnet has quit IRC (Remote host closed the connection)
19:59:18 *** jfs has quit IRC (Remote host closed the connection)
19:59:18 *** boogiebob has quit IRC (Remote host closed the connection)
19:59:18 *** wensimehrp has quit IRC (Remote host closed the connection)
19:59:18 *** yeah_its_gloria has quit IRC (Remote host closed the connection)
19:59:18 *** _glx_ has quit IRC (Remote host closed the connection)
19:59:18 *** andythenorth has quit IRC (Remote host closed the connection)
19:59:18 *** _zephyris has quit IRC (Remote host closed the connection)
19:59:18 *** truebrain has quit IRC (Remote host closed the connection)
19:59:18 *** markomarko has quit IRC (Remote host closed the connection)
19:59:18 *** brickblock19280 has quit IRC (Remote host closed the connection)
19:59:18 *** _pruple has quit IRC (Remote host closed the connection)
19:59:18 *** emperorjake has quit IRC (Remote host closed the connection)
19:59:18 *** DorpsGek_vi has quit IRC (Remote host closed the connection)
19:59:18 *** eeeeee9388 has quit IRC (Remote host closed the connection)
19:59:18 *** goddess_ishtar has quit IRC (Remote host closed the connection)
19:59:18 *** le_barista has quit IRC (Remote host closed the connection)
19:59:18 *** alfagamma7 has quit IRC (Remote host closed the connection)
19:59:18 *** talltyler has quit IRC (Remote host closed the connection)
20:01:10 <Rubidium> too bad it doesn't just call this a netsplit :D
20:01:34 <LordAro> all the best people here now
20:05:57 <peter1138> How do I detect the Windows compiler? _MSC_VER defined?
20:07:08 <Rubidium> that's usually how it's done in our code (IIRC)
20:08:03 <peter1138> Some places we check for __GNUC__/__clang__
20:10:54 <Rubidium> oh... for fun... clang-cl (the one you can use directly in MSVC) also defines _MSC_VER
20:13:42 <Rubidium> but I'd just YOLO it with _MSC_VER, and if that causes problems for someone using clang-cl, they can make a PR to fix it
20:14:48 *** peter1138[d] has joined #openttd
20:14:59 <peter1138> That's the output without the last Fix commit.
20:15:31 <peter1138> So the nameof() stuff is kinda needed otherwise you know there's an error... but no idea where.
20:16:27 <LordAro> compiler warning though
20:16:52 <LordAro> something inside the macro?
20:17:10 <peter1138> That's why I'm rewriting it for MSVC.
20:17:38 <peter1138> It looks like that compiler doesn't allow referencing the variable yet because it's still being defined. I think.
20:18:09 *** frosch123 has joined #openttd
20:18:09 <frosch123> you could also use __FILE__ and __LINE__
20:18:48 <frosch123> then people can actually copy/paste it, and do not need to adjust the _desc
20:19:59 <frosch123> debug.h even has a FILE_LINE macro
20:21:57 <peter1138> Presumably I'd need FILE_LINE in every WindowDesc definition?
20:22:33 <frosch123> is the nameof not in every one?
20:23:00 <peter1138> I was unsure by what you mean with "do not need to adjust the _desc"
20:23:44 <frosch123> yes, i meant adding FILE_LINE to all _desc
20:24:18 <frosch123> instead of relying on people to not write `WindowDesc _a(nameof(_b), ...)`
20:25:15 <frosch123> oh, WindowDesc are static instances in cpp files, so their names do not even need to be unique
20:37:45 <peter1138> Yeah, ideally the name would be self-including, but alas :D
20:38:02 <peter1138> with messages: window_desc->file := "/home/petern/src/openttd/src/ai/ai_gui.cpp" window_desc->line := 76
20:44:13 <peter1138> I've tweaked it to appear as FILE:LINE too.
20:44:55 <_glx_> funny, only gs and ai windows seem to warn during compile
20:47:41 <_glx_> ah no there are more occurences
20:47:54 <peter1138> You mean with the nameof() thing?
20:49:01 <peter1138> Which I'm now removing because frosch123-brains made it better.
20:49:41 *** truebrain has joined #openttd
20:49:41 <truebrain> hmmm ... brains .....
20:51:19 <frosch123> i don't think brains have water-cooling
20:51:32 <truebrain> is blood not mostly water?
20:52:01 <frosch123> yes, but your brain should not be filled with blood
20:52:09 <truebrain> neither should my PC!
20:52:33 <truebrain> ordering parts with DHL
20:52:41 <truebrain> being told arrives between 2000 and 2130
20:52:44 <truebrain> didn't say which timezone
20:54:36 *** goddess_ishtar has joined #openttd
20:54:36 <goddess_ishtar> oh good, that's hours and not years
20:54:42 <frosch123> is dutch dhl like german dhl? the time interval is always 90 minutes, no matter whether there is a day left or 5 minutes left to delivery? and then that interval is moving by 2 hours to later during the day
20:54:55 <truebrain> it just doesn't update
20:55:01 <truebrain> it says a 90 minute interval in the morning
20:55:18 <Rubidium> truebrain: they probably just thrown the package in your garbage and didn't ring the bell
20:55:39 <truebrain> then they always instantly mail you: YOUR PACKAGE IS ARRIVED
20:55:49 <truebrain> they love telling you the exact moment they really delivered it
20:57:09 <peter1138> Split them out, one fix and one change ;p
21:00:02 <peter1138> I used __FILE__, __LINE__ directly though, because not everything includes debug.h.
21:20:06 *** nielsm has quit IRC (Ping timeout: 480 seconds)
21:52:25 *** Wormnest has quit IRC (Ping timeout: 480 seconds)
21:55:33 *** Wolf01 has quit IRC (Ping timeout: 480 seconds)
22:01:36 *** ChanServ sets mode: +v tokai
22:08:31 *** tokai|noir has quit IRC (Ping timeout: 480 seconds)
22:13:24 *** marchnex has quit IRC (Quit: Page closed)
22:36:45 *** Wormnest has joined #openttd
23:06:32 *** virtualrandomnumber has joined #openttd
23:10:43 *** virtualrandomnumber has quit IRC ()
23:17:01 *** dihedral has joined #openttd
23:26:08 *** Farrokh[m] has quit IRC (Ping timeout: 480 seconds)
23:26:08 *** Gadg8eer[m] has quit IRC (Ping timeout: 480 seconds)
23:26:18 *** Bilb[m] has quit IRC (Ping timeout: 480 seconds)
23:26:18 *** Elysianthekitsunesheher[m] has quit IRC (Ping timeout: 480 seconds)
23:26:18 *** Heiki[m] has quit IRC (Ping timeout: 480 seconds)
23:26:18 *** xyii[m] has quit IRC (Ping timeout: 480 seconds)
23:26:18 *** amal[m] has quit IRC (Ping timeout: 480 seconds)
23:26:19 *** patrick[m]12 has quit IRC (Ping timeout: 482 seconds)
23:26:22 *** menelaos[m] has quit IRC (Ping timeout: 480 seconds)
23:26:22 *** soylent_cow[m] has quit IRC (Ping timeout: 480 seconds)
23:26:24 *** igor[m] has quit IRC (Ping timeout: 482 seconds)
23:26:24 *** shedidthedog[m] has quit IRC (Ping timeout: 482 seconds)
23:26:28 *** EmeraldSnorlax[m] has quit IRC (Ping timeout: 480 seconds)
23:26:28 *** pikaHeiki has quit IRC (Ping timeout: 480 seconds)
23:26:28 *** gdown has quit IRC (Ping timeout: 480 seconds)
23:26:28 *** jact[m] has quit IRC (Ping timeout: 480 seconds)
23:26:32 *** magdalena[m] has quit IRC (Ping timeout: 480 seconds)
23:26:32 *** blikjeham[m] has quit IRC (Ping timeout: 480 seconds)
23:26:32 *** jeremy[m]1 has quit IRC (Ping timeout: 480 seconds)
23:26:35 *** hamstonkid[m] has quit IRC (Ping timeout: 480 seconds)
23:26:35 *** giords[m] has quit IRC (Ping timeout: 480 seconds)
23:26:35 *** SergioMassa[m] has quit IRC (Ping timeout: 480 seconds)
23:26:36 *** karoline[m] has quit IRC (Ping timeout: 480 seconds)
23:26:38 *** gretel[m] has quit IRC (Ping timeout: 480 seconds)
23:26:39 *** emilyd[m] has quit IRC (Ping timeout: 480 seconds)
23:26:40 *** patricia[m]1 has quit IRC (Ping timeout: 482 seconds)
23:26:40 *** zzy2357[m] has quit IRC (Ping timeout: 482 seconds)
23:26:40 *** vista_narvas[m] has quit IRC (Ping timeout: 482 seconds)
23:26:44 *** einar[m] has quit IRC (Ping timeout: 480 seconds)
23:26:44 *** YungJudas[m] has quit IRC (Ping timeout: 480 seconds)
23:26:44 *** temeo[m] has quit IRC (Ping timeout: 480 seconds)
23:26:44 *** philip[m]123 has quit IRC (Ping timeout: 480 seconds)
23:26:44 *** kstar892[m] has quit IRC (Ping timeout: 480 seconds)
23:26:45 *** freu[m] has quit IRC (Ping timeout: 483 seconds)
23:26:45 *** joey[m]1 has quit IRC (Ping timeout: 483 seconds)
23:26:48 *** audunm[m] has quit IRC (Ping timeout: 480 seconds)
23:26:51 *** FelixActually[m] has quit IRC (Ping timeout: 480 seconds)
23:26:54 *** rudolfs[m] has quit IRC (Ping timeout: 483 seconds)
23:26:57 *** CornsMcGowan[m] has quit IRC (Ping timeout: 480 seconds)
23:26:57 *** andythenorth[m] has quit IRC (Ping timeout: 480 seconds)
23:26:57 *** wormnest[m] has quit IRC (Ping timeout: 480 seconds)
23:26:57 *** calbasi[m]1 has quit IRC (Ping timeout: 480 seconds)
23:26:58 *** fiddeldibu[m] has quit IRC (Ping timeout: 480 seconds)
23:26:59 *** cjmonagle[m] has quit IRC (Ping timeout: 480 seconds)
23:26:59 *** thelonelyellipsis[m] has quit IRC (Ping timeout: 480 seconds)
23:27:04 *** citronbleuv[m] has quit IRC (Ping timeout: 483 seconds)
23:27:06 *** JamesRoss[m] has quit IRC (Ping timeout: 480 seconds)
23:27:06 *** elliot[m] has quit IRC (Ping timeout: 480 seconds)
23:27:06 *** leward[m] has quit IRC (Ping timeout: 480 seconds)
23:27:06 *** luk3Z[m] has quit IRC (Ping timeout: 480 seconds)
23:27:08 *** yubvin[m] has quit IRC (Ping timeout: 480 seconds)
23:27:09 *** thomas[m]1234567 has quit IRC (Ping timeout: 483 seconds)
23:27:09 *** nolep[m] has quit IRC (Ping timeout: 483 seconds)
23:27:25 <peter1138> One of those days eh?
23:48:16 *** HerzogDeXtEr has quit IRC (Read error: Connection reset by peer)
continue to next day ⏵
