| 2024-09-17 00:01:09 +0200 | athan_ | (~athan@syn-098-153-145-140.biz.spectrum.com) |
| 2024-09-17 00:03:13 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 252 seconds) |
| 2024-09-17 00:03:54 +0200 | __monty__ | (~toonn@user/toonn) (Quit: leaving) |
| 2024-09-17 00:07:43 +0200 | ZharMeny` | ZharMeny |
| 2024-09-17 00:10:59 +0200 | hughjfchen | (~hughjfche@vmi556545.contaboserver.net) (Ping timeout: 260 seconds) |
| 2024-09-17 00:11:34 +0200 | <geekosaur> | tbh if performance matters to me I don't use Haskell. that said, the stuff I do these days mostly doesn't need to squeeze performance |
| 2024-09-17 00:11:47 +0200 | <geekosaur> | (this is a "right tool for the job" thing) |
| 2024-09-17 00:13:00 +0200 | <d34df00d> | Well, that's my favourite pastime — trying to understand haskell + performance and maybe make the code slightly better. |
| 2024-09-17 00:14:06 +0200 | <geekosaur> | in general, the higher level or otherwise more abstracted from the hardware a language is, the harder it is to reason about or get performance |
| 2024-09-17 00:14:40 +0200 | <geekosaur> | the flip side being that the closer to the HW it is, the harder it is to write in the first place |
| 2024-09-17 00:14:50 +0200 | <geekosaur> | so it's a balancing act |
| 2024-09-17 00:15:40 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) |
| 2024-09-17 00:20:05 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 248 seconds) |
| 2024-09-17 00:20:15 +0200 | lambdaRule | (~lambdaRul@d108-172-198-192.bchsia.telus.net) |
| 2024-09-17 00:20:38 +0200 | acidjnk | (~acidjnk@p200300d6e72cfb571c92fe2f1c989eb0.dip0.t-ipconnect.de) (Ping timeout: 272 seconds) |
| 2024-09-17 00:23:05 +0200 | <geekosaur> | Haskell and Python make it easy to write what you intend (admittedly, in somewhat different styles), but performance issues are really hard |
| 2024-09-17 00:23:13 +0200 | <geekosaur> | asm's a nightmare to write |
| 2024-09-17 00:23:33 +0200 | <lambdaRule> | I'm reading QuickCheck code, the module Poly makes me wonder how those newtype (A,B,C) suppose to be used. (https://github.com/nick8325/quickcheck/blob/d66336ce59e0e3536afcef4f2e147b7028d89dd0/src/Test/Quic…) Anyone knows how? |
| 2024-09-17 00:23:49 +0200 | <geekosaur> | C makes you do everything yourself and mostly makes it really easy to shoot yourself in the foot, but performance is easy to reason about |
| 2024-09-17 00:24:27 +0200 | vglfr | (~vglfr@2607:fb91:8a4:82b7:ad3:f757:ccf9:424d) (Read error: Connection reset by peer) |
| 2024-09-17 00:24:47 +0200 | vglfr | (~vglfr@2601:14d:4e01:1370:593a:1997:8b5e:410b) |
| 2024-09-17 00:26:33 +0200 | <geekosaur> | lambdaRule, I believe the point here is that if you have Integers with e.g. different ranges or other constraints, you can either wrap them and derive-through things like Eq yourself, or you can use the predefined A,B,C etc. |
| 2024-09-17 00:27:37 +0200 | <geekosaur> | (which is in part a hackaround for Haskell not having subtyping) |
| 2024-09-17 00:28:15 +0200 | <geekosaur> | a third alternative may be to use Liquid Haskell instead, since it has subtyping |
| 2024-09-17 00:30:28 +0200 | <geekosaur> | for examples, consider that you have ages and number-of-days represented as integers. for testing purposes you might use A for the former and B for the latter. that said, if you have enough of them you may want to do it properly with your own newtype wrappers Age and Day so you can more easily keep straight what represents what |
| 2024-09-17 00:30:41 +0200 | Square2 | (~Square4@user/square) (Ping timeout: 248 seconds) |
| 2024-09-17 00:31:59 +0200 | <EvanR> | C performance is easy to reason about?! It regularly outperforms my mental model by orders of magnitude xD |
| 2024-09-17 00:32:07 +0200 | <EvanR> | it's way too fast |
| 2024-09-17 00:32:30 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) |
| 2024-09-17 00:32:40 +0200 | <geekosaur> | lambdarule, anyway, given the stuff they provide for it, that's what it looks like to me |
| 2024-09-17 00:32:46 +0200 | <lambdaRule> | I have two more questions: 1. A,B,C have same code except their type name, why are they written like that? 2. The header comment of Poly said these data types are used for testing polymorphic properties, how these newtypes would be used differently than simply choose Int to generate data for a poly type? |
| 2024-09-17 00:33:10 +0200 | <lambdaRule> | --still reading your answers |
| 2024-09-17 00:33:15 +0200 | <geekosaur> | I am unclear on their use of "polymorphic" |
| 2024-09-17 00:33:24 +0200 | <geekosaur> | the rest, well, finish reading first |
| 2024-09-17 00:34:15 +0200 | <geekosaur> | the whole point of `newtype` is that it gives a new name and distinct "identity" to an existing type, so you can treat them differently even though (in this case) they're all "just integers" |
| 2024-09-17 00:34:39 +0200 | <geekosaur> | for example, adding two ages together doesn't make sense, but ages are integers |
| 2024-09-17 00:35:21 +0200 | <EvanR> | the candidates collectively have 250 years among them |
| 2024-09-17 00:35:54 +0200 | <EvanR> | just kidding |
| 2024-09-17 00:36:07 +0200 | <monochrom> | Computing averages of ages requires adding them. >:) |
| 2024-09-17 00:36:10 +0200 | <geekosaur> | but act like they have 15 |
| 2024-09-17 00:36:58 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 252 seconds) |
| 2024-09-17 00:36:59 +0200 | <monochrom> | And yeah also when we say "the two of you have total age 200 why are you still childish" |
| 2024-09-17 00:38:13 +0200 | <monochrom> | Haha, computing geometric means of ages requires multiplying them, too. >:D |
| 2024-09-17 00:38:30 +0200 | <monochrom> | And standard deviations etc |
| 2024-09-17 00:38:54 +0200 | <geekosaur> | yeh, there are exceptions. but in general adding two ages together is a mistake and you want some kind of override operation which by existence says "something special is happening here" / makes you think about whether you're doing something sensible with it |
| 2024-09-17 00:39:08 +0200 | <geekosaur> | this is the point of `newtype` |
| 2024-09-17 00:39:17 +0200 | <monochrom> | "How to break typeclass laws with statistics" |
| 2024-09-17 00:39:55 +0200 | <geekosaur> | but, for simple apps you may skip the newtype, but then you need to test them and use different properties as part of it, so you have the convenience newtypes A,B,C,ordA,ordB,ordC |
| 2024-09-17 00:40:29 +0200 | <geekosaur> | (the latter being things you can add together but not add unwrapped numbers to without unwrapping them or wrapping the unwrapped number, for example) |
| 2024-09-17 00:40:50 +0200 | <monochrom> | But more seriously: |
| 2024-09-17 00:40:53 +0200 | <geekosaur> | this is kinda half-assed type safety for quick and dirty apps |
| 2024-09-17 00:42:09 +0200 | <monochrom> | PHP has a type for time. Initially, they had a default value for time too. Then there was an outcry, even among PHP people, because no default value can ever make sense for time. |
| 2024-09-17 00:42:33 +0200 | <geekosaur> | (my own take on which being, if you've reached the point where you're doing property-based testing, you've reached the point where you should do it right up front) |
| 2024-09-17 00:42:55 +0200 | Guest|84 | (~Guest|84@178.60.115.105) |
| 2024-09-17 00:43:18 +0200 | Guest|84 | (~Guest|84@178.60.115.105) (Client Quit) |
| 2024-09-17 00:43:41 +0200 | <monochrom> | There was a poorly written basic math textbook that went "old temperature was 100F, new temperature is 120F, what's the percentage increase?" which makes no sense because 0F is also an arbitrary reference point. |
| 2024-09-17 00:45:21 +0200 | <geekosaur> | and, like time, there's no reasonable reference point for temperature |
| 2024-09-17 00:45:43 +0200 | <geekosaur> | (in the classical days there was, but then came quantum temperature and ruined it for everyone) |
| 2024-09-17 00:46:41 +0200 | spew | (~spew@2806:2a0:1522:8662::728c) (Quit: spew) |
| 2024-09-17 00:46:45 +0200 | vglfr | (~vglfr@2601:14d:4e01:1370:593a:1997:8b5e:410b) (Ping timeout: 248 seconds) |
| 2024-09-17 00:47:01 +0200 | spew | (~spew@2806:2a0:1522:8662::728c) |
| 2024-09-17 00:47:04 +0200 | vglfr | (~vglfr@2607:fb91:8a4:82b7:ad3:f757:ccf9:424d) |
| 2024-09-17 00:47:45 +0200 | <monochrom> | Using 0K as the reference point, and in the context of thermodynamics, "percentage increase" can be a useful notion. |
| 2024-09-17 00:47:55 +0200 | <geekosaur> | again, only classically |
| 2024-09-17 00:48:22 +0200 | <geekosaur> | (granting, at the moment if you're talking thermodynamics then you're talking classical physics) |
| 2024-09-17 00:48:24 +0200 | <monochrom> | But that textbook was for paramedics, and trying poorly to make a word problem that uses paramedic vocabulary. |
| 2024-09-17 00:49:37 +0200 | <monochrom> | A lot of word problems are really poorly contrived. |
| 2024-09-17 00:50:22 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) |
| 2024-09-17 00:50:56 +0200 | <EvanR> | points in space or points in time are intangible, we juggle vectors and matrices all day that represents the moves between them |
| 2024-09-17 00:51:16 +0200 | <geekosaur> | (damn you, Einstein) |
| 2024-09-17 00:51:31 +0200 | <EvanR> | there's no rubick's cube only rubick's cube group |
| 2024-09-17 00:52:17 +0200 | <EvanR> | rubik's cube?! |
| 2024-09-17 00:52:24 +0200 | <geekosaur> | (and Einstein's not through with us even yet. the latest is evidence that gravity can be repulsive) |
| 2024-09-17 00:53:02 +0200 | EvanR | fires up the gravity capacitor and flies away |
| 2024-09-17 00:53:40 +0200 | <geekosaur> | won't work here; we're definitely positive compared to the average density of the universe |
| 2024-09-17 00:54:27 +0200 | <geekosaur> | the trick is the GR transformation matrix (Hamiltonian, I think?) depends on the average density of the universe. |
| 2024-09-17 00:54:55 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 252 seconds) |
| 2024-09-17 00:55:08 +0200 | <geekosaur> | in Einstein's day and for decades afterward, that was considered to be 0 because the universe is mostly empty space. |
| 2024-09-17 00:55:39 +0200 | lambdaRule | (~lambdaRul@d108-172-198-192.bchsia.telus.net) (Quit: Client closed) |
| 2024-09-17 00:55:47 +0200 | <geekosaur> | but within the past ~10 years, we've found there's a lot of mass-energy in places we thought were completely empty. which means the average mass-density is positive. |
| 2024-09-17 00:56:36 +0200 | <geekosaur> | which means any local region where the mass-energy density is less than the average, the transformation matrix is negative: gravity is repulsive |
| 2024-09-17 00:56:54 +0200 | EvanR | eyes this story with suspicion |
| 2024-09-17 00:57:25 +0200 | <EvanR> | the maximally negatively curved milne universe is still pretty cool ngl |
| 2024-09-17 00:58:33 +0200 | troojg | (~troojg@user/troojg) |
| 2024-09-17 01:03:39 +0200 | Sgeo | (~Sgeo@user/sgeo) |
| 2024-09-17 01:04:17 +0200 | xff0x_ | (~xff0x@2405:6580:b080:900:faf:b23:bfac:f0c0) (Quit: xff0x_) |
| 2024-09-17 01:04:27 +0200 | vglfr | (~vglfr@2607:fb91:8a4:82b7:ad3:f757:ccf9:424d) (Ping timeout: 252 seconds) |
| 2024-09-17 01:08:22 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) |
| 2024-09-17 01:08:55 +0200 | xff0x | (~xff0x@2405:6580:b080:900:4168:f973:63de:e89d) |
| 2024-09-17 01:11:06 +0200 | <geekosaur> | we are known to be in a "cosmic void" (https://www.space.com/hubble-tension-universe-expansion-supervoid) |
| 2024-09-17 01:11:55 +0200 | <geekosaur> | the question is, is it so void that its mass-energy density is below the universe's average? if it is, then galaxies within the void are being pushed apart |
| 2024-09-17 01:13:24 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 260 seconds) |
| 2024-09-17 01:19:49 +0200 | ystael | (~ystael@user/ystael) (Ping timeout: 260 seconds) |
| 2024-09-17 01:20:44 +0200 | <geekosaur> | this has a somewhat more formal description plus a link to a paper |
| 2024-09-17 01:20:46 +0200 | <geekosaur> | https://manoa.hawaii.edu/news/article.php?aId=8383 |
| 2024-09-17 01:22:00 +0200 | szkl | (uid110435@id-110435.uxbridge.irccloud.com) |
| 2024-09-17 01:23:53 +0200 | <geekosaur> | although I'm not finding the paper that further claimed that the apparent repulsion was actual repulsion because the average density of the universe is positive instead of 0 and voids have lower than that density |
| 2024-09-17 01:24:00 +0200 | pavonia | (~user@user/siracusa) |
| 2024-09-17 01:24:22 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) |
| 2024-09-17 01:28:53 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 248 seconds) |
| 2024-09-17 01:33:13 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) |
| 2024-09-17 01:33:32 +0200 | vglfr | (~vglfr@2601:14d:4e01:1370:9b8b:3d63:7b3f:ede3) |
| 2024-09-17 01:34:23 +0200 | <d34df00d> | Also, speaking of performance. |
| 2024-09-17 01:34:35 +0200 | d34df00d | shamelessly plugging https://0xd34df00d.me/posts/2024/09/naive-nfas.html |
| 2024-09-17 01:34:50 +0200 | <geekosaur> | anyway the claim in the paper I'm remembering is that going by the Milky Way's actual velocity, instead of being pulled into the "Great Attracttor" as originally believed, there's a 16km/s sideways push that means we'll just miss it instead. btu while they could measure it reproducibly, computing the gravitational pulls didn't reproduce that sideways "push" |
| 2024-09-17 01:35:41 +0200 | <geekosaur> | then the researchers thought "wait a minute. if there are large voids we can see, that means the average density of space must be above the density within those voids, what does this do to the GR transformation matrices?" |
| 2024-09-17 01:36:25 +0200 | <geekosaur> | the answer turned out to be, within the error bars, a 16km/s repulsion from the void in the UManoa paper I linked |
| 2024-09-17 01:36:42 +0200 | <haskellbridge> | <@mad:matrix.org> Every time I look at those universe diagrams I get very scared of the cosmic spiders that weave it ... |
| 2024-09-17 01:37:03 +0200 | <geekosaur> | so GR calculations just got a lot more complicated because all of those zeroes that aren't zeroes any more, so all the shortcuts don't work any more |
| 2024-09-17 01:38:26 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 265 seconds) |
| 2024-09-17 01:38:39 +0200 | mxs | (~mxs@user/mxs) (Quit: The Lounge - https://thelounge.chat) |
| 2024-09-17 01:39:33 +0200 | Smiles | (uid551636@id-551636.lymington.irccloud.com) |
| 2024-09-17 01:44:37 +0200 | m5zs7k | (aquares@web10.mydevil.net) (Quit: m5zs7k) |
| 2024-09-17 01:48:26 +0200 | m5zs7k | (aquares@web10.mydevil.net) |
| 2024-09-17 01:48:49 +0200 | <dolio> | How could the average density be 0? Does that count 'dark energy' as negative density or something? |
| 2024-09-17 01:49:15 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) |
| 2024-09-17 01:52:45 +0200 | <geekosaur> | "near enough as no matter": it was believed that, despite all the stuff we can see, the gaps between them all are so large that they massive "outweigh" the mass-energy |
| 2024-09-17 01:53:13 +0200 | <dolio> | Okay, so not actually 0, but very close. |
| 2024-09-17 01:53:14 +0200 | <geekosaur> | (think about it: if it weren't very near 0, the sky would be gray at night, not black with some stars visible) |
| 2024-09-17 01:53:17 +0200 | <geekosaur> | yes |
| 2024-09-17 01:53:43 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 245 seconds) |
| 2024-09-17 01:54:07 +0200 | <geekosaur> | thing is, while it was thought to be "0, close enough", the very existence of voids says "no, it's not close enough to 0" |
| 2024-09-17 01:55:43 +0200 | <geekosaur> | if everywhere not containing a galactic supercluster were a void, that'd be one thing. but voids and supervoids turn out to be patchy |
| 2024-09-17 01:59:54 +0200 | <geekosaur> | this also has a detail that helps to confirm it: the better we get at looking, the more loose matter we see… except in those voids |
| 2024-09-17 02:00:54 +0200 | <geekosaur> | one might think stuff would randomly wander into them and they'd gradually lose their "void-ness", but if gravitation is actually repulsive in voids, then they actively expel anything they have in them and become more "void" |
| 2024-09-17 02:01:08 +0200 | <dolio> | Yeah, I mean, wikipedia says that the working definition is that a void has an average density less than 1/10 the average density of the universe. I guess you can only tell if that matters by knowing the actual average density, though? |
| 2024-09-17 02:01:28 +0200 | <geekosaur> | right. and we're getting better at that all the time |
| 2024-09-17 02:02:00 +0200 | <geekosaur> | as I said at the start of this, it's only within the past 10ish years that we've been in a position to talk about the actual average density |
| 2024-09-17 02:02:38 +0200 | <geekosaur> | and the best we can do still is adding up the clusters and subtracting out the voids |
| 2024-09-17 02:03:04 +0200 | <geekosaur> | uh, put that wrong. computing a relative average I guess |
| 2024-09-17 02:04:08 +0200 | <geekosaur> | so the numbers are very definitely subject to change, but we already have enough evidence to say with certainty that, since voids exist and are easy to spot with our current tech, they are necessarily below the average mass-energy density |
| 2024-09-17 02:04:33 +0200 | <geekosaur> | by enough that said average must be significant enough that we have to try to take it into account |
| 2024-09-17 02:04:44 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) |
| 2024-09-17 02:05:47 +0200 | <geekosaur> | that's still a developing story, though, as there's still large error bars on said average density |
| 2024-09-17 02:06:26 +0200 | califax | (~califax@user/califx) (Ping timeout: 260 seconds) |
| 2024-09-17 02:06:33 +0200 | califax_ | (~califax@user/califx) |
| 2024-09-17 02:06:35 +0200 | weary-traveler | (~user@user/user363627) (Remote host closed the connection) |
| 2024-09-17 02:07:50 +0200 | califax_ | califax |
| 2024-09-17 02:09:18 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 246 seconds) |
| 2024-09-17 02:10:12 +0200 | spew | (~spew@2806:2a0:1522:8662::728c) (Ping timeout: 272 seconds) |
| 2024-09-17 02:16:59 +0200 | troojg | (~troojg@user/troojg) (Ping timeout: 260 seconds) |
| 2024-09-17 02:19:28 +0200 | xff0x | (~xff0x@2405:6580:b080:900:4168:f973:63de:e89d) (Quit: xff0x) |
| 2024-09-17 02:22:04 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) |
| 2024-09-17 02:26:27 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 246 seconds) |
| 2024-09-17 02:26:40 +0200 | xff0x | (~xff0x@2405:6580:b080:900:6f94:c8d2:12bd:b16a) |
| 2024-09-17 02:29:34 +0200 | <geekosaur> | looks like https://adsabs.harvard.edu/full/2008IAUS..244..146T |
| 2024-09-17 02:30:44 +0200 | <geekosaur> | except it's like a decade too early and I see no discussion about a revised average density (they say "really empty" which implies they're still using the "0, close enough" value) |
| 2024-09-17 02:38:54 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) |
| 2024-09-17 02:42:10 +0200 | <geekosaur> | and it appears to have been swallowed up by MOND theories that propose a different way to do the same thing |
| 2024-09-17 02:42:25 +0200 | peterbecich | (~Thunderbi@syn-047-229-123-186.res.spectrum.com) |
| 2024-09-17 02:43:41 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 265 seconds) |
| 2024-09-17 02:47:07 +0200 | xff0x | (~xff0x@2405:6580:b080:900:6f94:c8d2:12bd:b16a) (Ping timeout: 252 seconds) |
| 2024-09-17 02:53:11 +0200 | Tuplanolla | (~Tuplanoll@91-159-69-59.elisa-laajakaista.fi) (Quit: Leaving.) |
| 2024-09-17 02:56:04 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) |
| 2024-09-17 02:59:33 +0200 | machinedgod | (~machinedg@d50-99-47-73.abhsia.telus.net) (Ping timeout: 245 seconds) |
| 2024-09-17 03:00:53 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 255 seconds) |
| 2024-09-17 03:12:29 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) |
| 2024-09-17 03:16:51 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 246 seconds) |
| 2024-09-17 03:19:32 +0200 | athan_ | (~athan@syn-098-153-145-140.biz.spectrum.com) (Quit: Konversation terminated!) |
| 2024-09-17 03:21:13 +0200 | morb | (~morb@pool-108-41-100-120.nycmny.fios.verizon.net) |
| 2024-09-17 03:27:46 +0200 | szkl | (uid110435@id-110435.uxbridge.irccloud.com) (Quit: Connection closed for inactivity) |
| 2024-09-17 03:29:04 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) |
| 2024-09-17 03:39:16 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 265 seconds) |
| 2024-09-17 03:39:22 +0200 | xff0x | (~xff0x@fsb6a9491c.tkyc517.ap.nuro.jp) |
| 2024-09-17 03:40:15 +0200 | ZharMeny | (~ZharMeny@user/ZharMeny) (Quit: ERC 5.5.0.29.1 (IRC client for GNU Emacs 29.4)) |
| 2024-09-17 03:44:35 +0200 | emmanuelux | (~emmanuelu@user/emmanuelux) (Quit: au revoir) |
| 2024-09-17 03:46:10 +0200 | peterbecich | (~Thunderbi@syn-047-229-123-186.res.spectrum.com) (Ping timeout: 252 seconds) |
| 2024-09-17 03:48:31 +0200 | Smiles | (uid551636@id-551636.lymington.irccloud.com) (Quit: Connection closed for inactivity) |
| 2024-09-17 03:52:55 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) |
| 2024-09-17 03:57:32 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 252 seconds) |
| 2024-09-17 04:10:34 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) |
| 2024-09-17 04:14:57 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 246 seconds) |
| 2024-09-17 04:15:23 +0200 | hiecaq | (~hiecaq@user/hiecaq) (Quit: ERC 5.5.0.29.1 (IRC client for GNU Emacs 29.4)) |
| 2024-09-17 04:18:30 +0200 | sourcetarius | (~sourcetar@user/sourcetarius) (Quit: sourcetarius) |
| 2024-09-17 04:21:47 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) |
| 2024-09-17 04:23:08 +0200 | hiecaq | (~hiecaq@user/hiecaq) |
| 2024-09-17 04:27:04 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 260 seconds) |
| 2024-09-17 04:30:13 +0200 | morb | (~morb@pool-108-41-100-120.nycmny.fios.verizon.net) (Remote host closed the connection) |
| 2024-09-17 04:37:37 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) |
| 2024-09-17 04:39:54 +0200 | td_ | (~td@i53870903.versanet.de) (Ping timeout: 260 seconds) |
| 2024-09-17 04:40:22 +0200 | peterbecich | (~Thunderbi@syn-047-229-123-186.res.spectrum.com) |
| 2024-09-17 04:41:29 +0200 | td_ | (~td@i53870933.versanet.de) |
| 2024-09-17 04:42:16 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 252 seconds) |
| 2024-09-17 04:49:57 +0200 | cheater | (~Username@user/cheater) (Ping timeout: 252 seconds) |
| 2024-09-17 04:49:59 +0200 | cheater_ | (~Username@user/cheater) |
| 2024-09-17 04:49:59 +0200 | cheater_ | cheater |
| 2024-09-17 04:51:33 +0200 | AlexZenon | (~alzenon@94.233.241.202) (Ping timeout: 248 seconds) |
| 2024-09-17 04:52:45 +0200 | AlexNoo | (~AlexNoo@94.233.241.202) (Ping timeout: 276 seconds) |