| 2025-05-19 00:00:05 +0200 | <EvanR> | sounds like it |
| 2025-05-19 00:00:56 +0200 | <EvanR> | dumb as nail step 0 sanity check: write some lazy code in ghci which you know should be fast and not use much live memory, and make sure your tools confirm it |
| 2025-05-19 00:01:28 +0200 | <bwe> | Shouldn't the profiler help me finding the space leak? |
| 2025-05-19 00:01:42 +0200 | <EvanR> | so at least you are working with two extremes with two different characters |
| 2025-05-19 00:01:49 +0200 | sabathan2 | (~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr) (Remote host closed the connection) |
| 2025-05-19 00:01:56 +0200 | <EvanR> | dumb efficient code and real space leaking code |
| 2025-05-19 00:02:04 +0200 | <EvanR> | and can tell the difference |
| 2025-05-19 00:02:05 +0200 | ljdarj1 | (~Thunderbi@user/ljdarj) ljdarj |
| 2025-05-19 00:02:10 +0200 | sabathan2 | (~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr) |
| 2025-05-19 00:02:18 +0200 | <EvanR> | if you already know all this then ignore me |
| 2025-05-19 00:02:56 +0200 | <EvanR> | personally I've only been able to use profiling to notice a speak leak and not solve any |
| 2025-05-19 00:03:02 +0200 | <EvanR> | space* |
| 2025-05-19 00:04:08 +0200 | loonycyborg | (loonycybor@wesnoth/developer/loonycyborg) loonycyborg |
| 2025-05-19 00:04:09 +0200 | ljdarj | (~Thunderbi@user/ljdarj) (Ping timeout: 245 seconds) |
| 2025-05-19 00:04:09 +0200 | ljdarj1 | ljdarj |
| 2025-05-19 00:09:23 +0200 | <bwe> | EvanR: I don't. - How do you solve a space leak? |
| 2025-05-19 00:09:49 +0200 | <darkling> | Meteor patches. :) |
| 2025-05-19 00:12:08 +0200 | <EvanR> | step 0, make sure it's a space leak by looking at a profile and judging that the problem shouldn't be amassing so much live memory |
| 2025-05-19 00:12:34 +0200 | <EvanR> | the result might be, it's not actually a space leak and your problem is just that bad |
| 2025-05-19 00:13:55 +0200 | <EvanR> | otherwise step 1, figure out your main driver of evaluation. Like printing out lines of outputs, writing to IORef, storing to a database. These can be quite late in the game so |
| 2025-05-19 00:14:24 +0200 | <EvanR> | step 2, trace backward to see if you can evaluate something sooner using bang patterns, strict record fields, "primed utilities" |
| 2025-05-19 00:15:27 +0200 | <EvanR> | or the evaluate :: a -> IO a thing from Control.Exceptions, which obviously only works in IO |
| 2025-05-19 00:17:33 +0200 | <EvanR> | iterating step 2 might not fix it, but it ideally does |
| 2025-05-19 00:18:53 +0200 | xff0x | (~xff0x@om126236151042.32.openmobile.ne.jp) |
| 2025-05-19 00:20:04 +0200 | <EvanR> | (note storing to IORef or MVar doesn't automatically evaluate anything, but there are primed utilities for that) |
| 2025-05-19 00:25:37 +0200 | JuanDaugherty | (~juan@user/JuanDaugherty) JuanDaugherty |
| 2025-05-19 00:26:21 +0200 | ttybitnik | (~ttybitnik@user/wolper) (Ping timeout: 276 seconds) |
| 2025-05-19 00:29:39 +0200 | <haskellbridge> | <thirdofmay18081814goya> at the point of a type error, is it possible to introspect the state of the constraints stack? |
| 2025-05-19 00:30:26 +0200 | <bwe> | Then, what does cause the space leak in the first place? A (temporary) value that is only kept longer in memory after its initial use because another use has not completed yet. |
| 2025-05-19 00:31:24 +0200 | <EvanR> | it's usually a thunk that is holding a bunch of data, and you thought it was evaluated already, letting all that data go |
| 2025-05-19 00:31:40 +0200 | sabathan2 | (~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr) (Remote host closed the connection) |
| 2025-05-19 00:31:51 +0200 | <EvanR> | the solution is to make sure it gets evaluated at the time you wanted |
| 2025-05-19 00:32:05 +0200 | sabathan2 | (~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr) |
| 2025-05-19 00:32:06 +0200 | <int-e> | In Haskell a common source of space leaks is so-called thunks, an implementation detail of lazy evaluation. Basically, rather than storing a value, the heap contains an object describing how to compute the value, and pointers to all the required ingredients. Which can also be thunks, so this can build up to a sizeable amount of memory. |
| 2025-05-19 00:32:42 +0200 | <bwe> | ... and I do that with the prime variants of functions, bang pattern etc. |
| 2025-05-19 00:33:17 +0200 | <EvanR> | if necessary yeah, the reasons for it being necessary are the deviled details, but those are the tools to control the when and what |
| 2025-05-19 00:33:54 +0200 | <EvanR> | for a simple example of details |
| 2025-05-19 00:34:03 +0200 | <EvanR> | consider let x = f a b c in y |
| 2025-05-19 00:34:34 +0200 | <EvanR> | if you evaluate y and the value of x is not used any time soon, then f, a, b, and c are all waiting around |
| 2025-05-19 00:34:52 +0200 | <bwe> | (consuming memory) |
| 2025-05-19 00:34:54 +0200 | <EvanR> | (if x is not used at all then it should be collected) |
| 2025-05-19 00:35:19 +0200 | <EvanR> | solution let !x = f a b c in y |
| 2025-05-19 00:35:42 +0200 | <EvanR> | which is the same as let x = f a b c in x `seq` y |
| 2025-05-19 00:36:00 +0200 | <bwe> | evaluate x (so you can let go of f, a, b, c in memory) |
| 2025-05-19 00:36:13 +0200 | <EvanR> | yes as long as f a b and c aren't also needed for something |
| 2025-05-19 00:36:25 +0200 | <bwe> | what if? |
| 2025-05-19 00:36:37 +0200 | <bwe> | evaluate that thing, too? |
| 2025-05-19 00:37:22 +0200 | <EvanR> | there's no one size fits all solution, even this example may actually benefit from leaving the bang off |
| 2025-05-19 00:37:33 +0200 | <EvanR> | f, a, b, and c may take up less memory than the result |
| 2025-05-19 00:37:53 +0200 | sabathan2 | (~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr) (Remote host closed the connection) |
| 2025-05-19 00:37:59 +0200 | <EvanR> | programs can grow or shrink as they are "reduced" |
| 2025-05-19 00:38:14 +0200 | sabathan2 | (~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr) |
| 2025-05-19 00:41:31 +0200 | <EvanR> | this is why you usually don't see anyone recommending put ! on every binding |
| 2025-05-19 00:42:19 +0200 | mhatta | (~mhatta@www21123ui.sakura.ne.jp) (Remote host closed the connection) |
| 2025-05-19 00:44:10 +0200 | mhatta | (~mhatta@www21123ui.sakura.ne.jp) |
| 2025-05-19 00:45:28 +0200 | sabathan2 | (~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr) (Remote host closed the connection) |
| 2025-05-19 00:45:44 +0200 | va10323 | (~v324@2802:8010:a026:e900:f93f:d782:dc7c:aeed) |
| 2025-05-19 00:45:49 +0200 | sabathan2 | (~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr) |
| 2025-05-19 00:51:16 +0200 | sabathan2 | (~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr) (Remote host closed the connection) |
| 2025-05-19 00:51:16 +0200 | <bwe> | Does the ghci interactive debugger show the thunks (currently kept in memory) / showing the currently allocated memory? ... I still wonder how to pinpoint the location of the space leaks in my code. |
| 2025-05-19 00:51:44 +0200 | sabathan2 | (~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr) |
| 2025-05-19 00:54:09 +0200 | target_i | (~target_i@user/target-i/x-6023099) (Quit: leaving) |
| 2025-05-19 00:54:13 +0200 | <bwe> | Thanks for your inputs, anyways. It gives how I approach things now a different spin: Being aware of where yet to be evaluated stuff occupies memory because it hasn't been used in the second, third place yet. |
| 2025-05-19 00:54:28 +0200 | <bwe> | (and solving by enforcing the evaluation) |
| 2025-05-19 00:56:52 +0200 | sabathan2 | (~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr) (Remote host closed the connection) |
| 2025-05-19 00:57:15 +0200 | sabathan2 | (~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr) |
| 2025-05-19 01:01:21 +0200 | xff0x | (~xff0x@om126236151042.32.openmobile.ne.jp) (Read error: Connection reset by peer) |
| 2025-05-19 01:03:59 +0200 | <EvanR> | ghci can show thunks I think, not sure what the flag is |
| 2025-05-19 01:05:24 +0200 | sabathan2 | (~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr) (Remote host closed the connection) |
| 2025-05-19 01:05:47 +0200 | sabathan2 | (~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr) |
| 2025-05-19 01:12:50 +0200 | weary-traveler | (~user@user/user363627) user363627 |
| 2025-05-19 01:14:30 +0200 | <geekosaur> | use :print or :sprint instead of just typing the expression |
| 2025-05-19 01:14:54 +0200 | <geekosaur> | most useful at breakpoints, since for top level stuff it'll just show _|_ |
| 2025-05-19 01:15:34 +0200 | __monty__ | (~toonn@user/toonn) (Quit: leaving) |
| 2025-05-19 01:16:39 +0200 | todi | (~todi@p57803331.dip0.t-ipconnect.de) (Ping timeout: 252 seconds) |
| 2025-05-19 01:19:08 +0200 | <haskellbridge> | <sm> bwe some related resources, possibly helpful: https://academy.fpblock.com/haskell/tutorial/all-about-strictness , https://github.com/haskell-perf/checklist , https://haskell.foundation/hs-opt-handbook.github.io |
| 2025-05-19 01:19:23 +0200 | sabathan2 | (~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr) (Remote host closed the connection) |
| 2025-05-19 01:19:44 +0200 | sabathan2 | (~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr) |
| 2025-05-19 01:21:56 +0200 | todi | (~todi@p57803331.dip0.t-ipconnect.de) todi |
| 2025-05-19 01:25:29 +0200 | sabathan2 | (~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr) (Remote host closed the connection) |
| 2025-05-19 01:25:50 +0200 | sabathan2 | (~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr) |
| 2025-05-19 01:28:50 +0200 | sprotte24 | (~sprotte24@p200300d16f0fc00010c55f6c38487736.dip0.t-ipconnect.de) (Quit: Leaving) |
| 2025-05-19 01:32:24 +0200 | jmcantrell | (~weechat@user/jmcantrell) jmcantrell |
| 2025-05-19 01:37:04 +0200 | craunts7 | (~craunts@136.158.8.87) |
| 2025-05-19 01:37:21 +0200 | xff0x | (~xff0x@om126236151042.32.openmobile.ne.jp) |
| 2025-05-19 01:37:33 +0200 | sabathan2 | (~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr) (Remote host closed the connection) |
| 2025-05-19 01:37:54 +0200 | sabathan2 | (~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr) |
| 2025-05-19 01:37:56 +0200 | acidjnk | (~acidjnk@p200300d6e71c4f033d258f2e8b70eea4.dip0.t-ipconnect.de) (Ping timeout: 272 seconds) |
| 2025-05-19 01:45:23 +0200 | j1n37- | (~j1n37@user/j1n37) (Read error: Connection reset by peer) |
| 2025-05-19 01:48:28 +0200 | j1n37 | (~j1n37@user/j1n37) j1n37 |
| 2025-05-19 01:48:38 +0200 | Tuplanolla | (~Tuplanoll@91-159-69-59.elisa-laajakaista.fi) (Quit: Leaving.) |
| 2025-05-19 01:52:36 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 244 seconds) |
| 2025-05-19 01:53:03 +0200 | <haskellbridge> | <thirdofmay18081814goya> hm is it possible to introspect the state of "TcM" (the type checker monad) at the point of a particular type error? |
| 2025-05-19 01:53:12 +0200 | <haskellbridge> | <thirdofmay18081814goya> e.g. query its stateful values |
| 2025-05-19 01:53:26 +0200 | <haskellbridge> | <thirdofmay18081814goya> can it get dumped anywhere? |
| 2025-05-19 01:54:28 +0200 | Frostillicus | (~Frostilli@pool-71-174-119-69.bstnma.fios.verizon.net) |
| 2025-05-19 01:56:01 +0200 | ljdarj | (~Thunderbi@user/ljdarj) (Ping timeout: 265 seconds) |
| 2025-05-19 01:58:16 +0200 | xff0x | (~xff0x@om126236151042.32.openmobile.ne.jp) (Read error: Connection reset by peer) |
| 2025-05-19 01:59:57 +0200 | Frostillicus | (~Frostilli@pool-71-174-119-69.bstnma.fios.verizon.net) (Ping timeout: 276 seconds) |
| 2025-05-19 02:01:30 +0200 | va10323 | (~v324@2802:8010:a026:e900:f93f:d782:dc7c:aeed) (Remote host closed the connection) |
| 2025-05-19 02:01:31 +0200 | tolgo | (~Thunderbi@199.115.144.130) |
| 2025-05-19 02:03:43 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-05-19 02:03:54 +0200 | jespada | (~jespada@r186-48-57-38.dialup.adsl.anteldata.net.uy) (Ping timeout: 260 seconds) |
| 2025-05-19 02:07:38 +0200 | sabathan2 | (~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr) (Remote host closed the connection) |
| 2025-05-19 02:07:45 +0200 | tolgo | (~Thunderbi@199.115.144.130) (Quit: tolgo) |
| 2025-05-19 02:07:58 +0200 | sabathan2 | (~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr) |
| 2025-05-19 02:12:07 +0200 | XZDX | (~xzdx@2607:fb90:8d8a:12c:214:51ff:fe83:9855) |
| 2025-05-19 02:14:11 +0200 | XZDX | (~xzdx@2607:fb90:8d8a:12c:214:51ff:fe83:9855) (Changing host) |
| 2025-05-19 02:14:11 +0200 | XZDX | (~xzdx@user/XZDX) XZDX |
| 2025-05-19 02:20:45 +0200 | <geekosaur> | seems like a #GHC:matrix.org question |
| 2025-05-19 02:23:57 +0200 | sabathan2 | (~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr) (Remote host closed the connection) |
| 2025-05-19 02:24:17 +0200 | sabathan2 | (~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr) |
| 2025-05-19 02:30:27 +0200 | <haskellbridge> | <thirdofmay18081814goya> ooo i'll ask there, ty! |
| 2025-05-19 02:32:16 +0200 | peterbecich | (~Thunderbi@syn-047-229-123-186.res.spectrum.com) (Ping timeout: 252 seconds) |
| 2025-05-19 02:32:42 +0200 | <EvanR> | folks we've been lied to this whole time |
| 2025-05-19 02:33:27 +0200 | <EvanR> | the "garbage collector" doesn't actually identify and collect garbage. It identifies and collects non-garbage! |
| 2025-05-19 02:34:18 +0200 | <EvanR> | treasure collector |
| 2025-05-19 02:34:20 +0200 | <int-e> | It's the Sherlock Holmes approach to garbage collection. |
| 2025-05-19 02:35:50 +0200 | <int-e> | (once you've identified all reachable objects, whatever remains must, by definition, be garbage) |
| 2025-05-19 02:36:06 +0200 | <int-e> | Mark & sweep operates that way too. But reference counting does not. |
| 2025-05-19 02:36:28 +0200 | <monochrom> | haha I mistakenly wrote {-# language GHC2010 #-}. (Brain conflating Haskell2010 with GHC2021.) |
| 2025-05-19 02:36:38 +0200 | <int-e> | (Mark & sweep is just less efficient about going through the garbage while discarding it.) |
| 2025-05-19 02:37:08 +0200 | <EvanR> | the sweep in mark and sweep is actively sweeping away garbage |
| 2025-05-19 02:37:13 +0200 | <monochrom> | s/garbage collector/scavenger/ |
| 2025-05-19 02:37:30 +0200 | <EvanR> | while moving collector is actively saving good stuff from destruction |
| 2025-05-19 02:37:31 +0200 | <monochrom> | "Haskell is an easter-egg scavenger language!" |
| 2025-05-19 02:38:05 +0200 | <int-e> | quick, evacuate, before the arena is reset |
| 2025-05-19 02:38:05 +0200 | <EvanR> | oh yeah reference counting |
| 2025-05-19 02:38:25 +0200 | <monochrom> | rescuer. evacuator. emergency responder. Red Cross/Cresent. |
| 2025-05-19 02:38:33 +0200 | <EvanR> | in godot it is said that reference counting "is not garbage collection, we don't have a garbage collector" |
| 2025-05-19 02:39:01 +0200 | <EvanR> | so the scope of garbage collector is incredibly shrinking as people strive to undefine things |
| 2025-05-19 02:39:04 +0200 | <int-e> | monochrom: GHC's RTS uses "scavenge" and "evacuate" as verbs internally |
| 2025-05-19 02:39:06 +0200 | <monochrom> | I am not that strict. Reference counting counts, too. |
| 2025-05-19 02:40:13 +0200 | <int-e> | monochrom: and I assumed that you said "scavenger" alluding to that |
| 2025-05-19 02:40:45 +0200 | <monochrom> | OK one more pun. People are still going to block BlockArguments when the time comes for GHC2030. |
| 2025-05-19 02:41:09 +0200 | <EvanR> | they better have a good argument |
| 2025-05-19 02:42:04 +0200 | <EvanR> | unless they decision has already been made and BlockArgument arguments will themselves be blocked |
| 2025-05-19 02:42:20 +0200 | <monochrom> | :) |
| 2025-05-19 02:44:01 +0200 | <EvanR> | I'm writing a pretty printer and like, the logic to decide when and what the newline and then how much to indent doesn't seem related to the subject matter of the thing being pretty printed |
| 2025-05-19 02:44:15 +0200 | <EvanR> | is there a thing to map to where pretty printing has been solved |
| 2025-05-19 02:44:21 +0200 | <EvanR> | the pretty printable |
| 2025-05-19 02:44:32 +0200 | <EvanR> | to newline* |
| 2025-05-19 02:44:49 +0200 | <EvanR> | non standard gerunds don't mix well with typos |
| 2025-05-19 02:49:17 +0200 | <monochrom> | Yes it is solved. A pretty-printing library provides two things and you use both: 1. You tell the render function how wide (how many columns). 2. You use an operator that means "can break line here if necessary; if not, just a space". |
| 2025-05-19 02:49:19 +0200 | <haskellbridge> | <sm> I don't know if it's ever entirely solved, but pretty-simple or pretty-show might have ideas ? |
| 2025-05-19 02:51:49 +0200 | sabathan2 | (~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr) (Remote host closed the connection) |
| 2025-05-19 02:52:10 +0200 | sabathan2 | (~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr) |
| 2025-05-19 02:55:44 +0200 | <monochrom> | The Hughes and SPJ paper should have how to implement it. |
| 2025-05-19 02:57:46 +0200 | <EvanR> | monochrom, what theory is all this |
| 2025-05-19 02:57:56 +0200 | sabathan2 | (~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr) (Remote host closed the connection) |
| 2025-05-19 02:58:15 +0200 | <EvanR> | is there a paper |
| 2025-05-19 02:58:16 +0200 | sabathan2 | (~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr) |
| 2025-05-19 02:58:33 +0200 | <monochrom> | Yes, that paper. |
| 2025-05-19 02:58:55 +0200 | <monochrom> | "The Design of a Pretty-printing Library" |
| 2025-05-19 02:59:19 +0200 | <monochrom> | the haddock of Text.PrettyPrint.HughesPJ has a link. |
| 2025-05-19 02:59:36 +0200 | <EvanR> | uhg John Hughes |
| 2025-05-19 02:59:41 +0200 | <EvanR> | can't stand those movies |
| 2025-05-19 03:01:10 +0200 | <monochrom> | Wait does he sometimes call himself Edmond Dantes? |
| 2025-05-19 03:03:34 +0200 | sabathan2 | (~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr) (Remote host closed the connection) |
| 2025-05-19 03:03:57 +0200 | sabathan2 | (~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr) |
| 2025-05-19 03:07:29 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 248 seconds) |
| 2025-05-19 03:08:27 +0200 | <EvanR> | had to look that one up! |
| 2025-05-19 03:09:44 +0200 | <monochrom> | Yeah I was looking at imdb.com and it says "(as Edmond Dantes)" for Beethoven movies. |
| 2025-05-19 03:10:29 +0200 | zlqrvx | (~zlqrvx@2001:8003:8c8b:e00:374a:bdcb:457c:d1e3) (Quit: ZNC 1.9.1 - https://znc.in) |
| 2025-05-19 03:18:02 +0200 | sabathan2 | (~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr) (Remote host closed the connection) |
| 2025-05-19 03:18:24 +0200 | sabathan2 | (~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr) |
| 2025-05-19 03:18:52 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-05-19 03:24:03 +0200 | sabathan2 | (~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr) (Remote host closed the connection) |
| 2025-05-19 03:24:24 +0200 | sabathan2 | (~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr) |
| 2025-05-19 03:29:58 +0200 | sabathan2 | (~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr) (Remote host closed the connection) |
| 2025-05-19 03:30:22 +0200 | sabathan2 | (~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr) |
| 2025-05-19 03:32:21 +0200 | xff0x | (~xff0x@fsb6a9491c.tkyc517.ap.nuro.jp) |
| 2025-05-19 03:36:07 +0200 | img | (~img@user/img) (Quit: ZNC 1.8.2 - https://znc.in) |
| 2025-05-19 03:37:24 +0200 | img | (~img@user/img) img |
| 2025-05-19 03:38:00 +0200 | sabathan2 | (~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr) (Remote host closed the connection) |
| 2025-05-19 03:38:22 +0200 | sabathan2 | (~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr) |
| 2025-05-19 03:45:45 +0200 | sabathan2 | (~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr) (Remote host closed the connection) |
| 2025-05-19 03:46:06 +0200 | sabathan2 | (~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr) |
| 2025-05-19 03:53:52 +0200 | sabathan2 | (~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr) (Remote host closed the connection) |
| 2025-05-19 03:54:15 +0200 | sabathan2 | (~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr) |
| 2025-05-19 04:00:13 +0200 | sabathan2 | (~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr) (Remote host closed the connection) |
| 2025-05-19 04:00:33 +0200 | sabathan2 | (~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr) |
| 2025-05-19 04:06:13 +0200 | sabathan2 | (~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr) (Remote host closed the connection) |
| 2025-05-19 04:06:34 +0200 | sabathan2 | (~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr) |
| 2025-05-19 04:07:21 +0200 | myxos | (~myxos@syn-065-028-251-121.res.spectrum.com) (Remote host closed the connection) |
| 2025-05-19 04:13:41 +0200 | td_ | (~td@i5387091A.versanet.de) (Ping timeout: 248 seconds) |
| 2025-05-19 04:18:12 +0200 | sabathan2 | (~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr) (Remote host closed the connection) |
| 2025-05-19 04:18:35 +0200 | sabathan2 | (~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr) |
| 2025-05-19 04:23:14 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 272 seconds) |
| 2025-05-19 04:24:14 +0200 | sabathan2 | (~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr) (Remote host closed the connection) |
| 2025-05-19 04:24:37 +0200 | sabathan2 | (~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr) |
| 2025-05-19 04:28:09 +0200 | Square2 | (~Square@user/square) (Ping timeout: 276 seconds) |
| 2025-05-19 04:30:33 +0200 | sabathan2 | (~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr) (Remote host closed the connection) |
| 2025-05-19 04:30:54 +0200 | sabathan2 | (~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr) |
| 2025-05-19 04:32:04 +0200 | XZDX | (~xzdx@user/XZDX) (Remote host closed the connection) |
| 2025-05-19 04:34:19 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-05-19 04:36:18 +0200 | sabathan2 | (~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr) (Remote host closed the connection) |
| 2025-05-19 04:36:38 +0200 | sabathan2 | (~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr) |
| 2025-05-19 04:42:37 +0200 | sabathan2 | (~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr) (Remote host closed the connection) |
| 2025-05-19 04:42:57 +0200 | sabathan2 | (~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr) |
| 2025-05-19 04:45:42 +0200 | peterbecich | (~Thunderbi@syn-047-229-123-186.res.spectrum.com) peterbecich |