| 2024-05-01 00:01:18 +0200 | <mauke> | ich begreif es auch nicht |
| 2024-05-01 00:04:16 +0200 | Square3 | (~Square4@user/square) |
| 2024-05-01 00:07:15 +0200 | Square | (~Square@user/square) (Ping timeout: 260 seconds) |
| 2024-05-01 00:08:24 +0200 | masterbuilder | (~quassel@user/masterbuilder) (Ping timeout: 260 seconds) |
| 2024-05-01 00:08:34 +0200 | masterbuilder | (~quassel@user/masterbuilder) |
| 2024-05-01 00:10:55 +0200 | barak | (~barak@2a0d:6fc2:68c1:7200:3cf2:a87d:a02b:3e21) (Quit: WeeChat 4.2.2) |
| 2024-05-01 00:11:08 +0200 | phma | (~phma@2001:5b0:2172:9258:5c6c:8366:4239:d1fd) (Read error: Connection reset by peer) |
| 2024-05-01 00:13:16 +0200 | madeleine-sydney | (~madeleine@c-76-155-235-153.hsd1.co.comcast.net) (Quit: Konversation terminated!) |
| 2024-05-01 00:14:54 +0200 | __monty__ | (~toonn@user/toonn) (Quit: leaving) |
| 2024-05-01 00:19:20 +0200 | waldo | (~waldo@user/waldo) |
| 2024-05-01 00:20:49 +0200 | phma | (~phma@host-67-44-208-133.hnremote.net) |
| 2024-05-01 00:46:06 +0200 | Nixkernal | (~Nixkernal@240.17.194.178.dynamic.wline.res.cust.swisscom.ch) (Ping timeout: 252 seconds) |
| 2024-05-01 00:46:26 +0200 | peterbecich | (~Thunderbi@syn-047-229-123-186.res.spectrum.com) |
| 2024-05-01 00:53:35 +0200 | <EvanR> | int-e, i met a guy in seattle recently who is making and selling neon signs |
| 2024-05-01 00:53:51 +0200 | <EvanR> | bars around here still have a lot of em xD |
| 2024-05-01 00:58:50 +0200 | <waldo> | you know what they will do then |
| 2024-05-01 00:58:59 +0200 | <waldo> | nuke the subduction zone |
| 2024-05-01 01:04:42 +0200 | sord937 | (~sord937@gateway/tor-sasl/sord937) (Quit: sord937) |
| 2024-05-01 01:10:16 +0200 | target_i | (~target_i@user/target-i/x-6023099) (Quit: leaving) |
| 2024-05-01 01:10:28 +0200 | acidjnk | (~acidjnk@p200300d6e714dc3178eb6b7df1157d0e.dip0.t-ipconnect.de) (Ping timeout: 260 seconds) |
| 2024-05-01 01:11:02 +0200 | wroathe | (~wroathe@user/wroathe) |
| 2024-05-01 01:12:10 +0200 | xff0x | (~xff0x@softbank219059019218.bbtec.net) |
| 2024-05-01 01:19:17 +0200 | peterbecich | (~Thunderbi@syn-047-229-123-186.res.spectrum.com) (Ping timeout: 240 seconds) |
| 2024-05-01 01:30:19 +0200 | Sgeo | (~Sgeo@user/sgeo) |
| 2024-05-01 01:43:07 +0200 | <jackdk> | I'm trying to find a blog post where the author (ab?)used the typeclass system to track the set of "resources" (or was it tables?) that a function needed to do its work. From memory it it involved the use of `Dict` and some evil coercions to satisfy different type classes with empty dictionaries, and may have been posted within the last year or so? Does anyone know what I'm talking about? |
| 2024-05-01 01:47:27 +0200 | sawilagar | (~sawilagar@user/sawilagar) (Ping timeout: 268 seconds) |
| 2024-05-01 01:49:48 +0200 | <[Leary]> | jackdk: I don't know it, but I recall the paper 'The Foil: Capture-Avoiding Substitution With No Sharp Edges' describes similar techniques for tracking name freshness. |
| 2024-05-01 01:52:36 +0200 | <geekosaur> | I find https://prophetlabs.de/posts/unsafeCoerceDict.html but doesn't quite sound like the same thing |
| 2024-05-01 01:52:41 +0200 | Tuplanolla | (~Tuplanoll@91-159-69-59.elisa-laajakaista.fi) (Quit: Leaving.) |
| 2024-05-01 01:53:37 +0200 | wroathe | (~wroathe@user/wroathe) (Ping timeout: 268 seconds) |
| 2024-05-01 01:58:08 +0200 | waldo | (~waldo@user/waldo) (Quit: waldo) |
| 2024-05-01 02:03:32 +0200 | lol_ | jcarpenter2 |
| 2024-05-01 02:04:01 +0200 | gmg | (~user@user/gehmehgeh) (Quit: Leaving) |
| 2024-05-01 02:04:38 +0200 | peterbecich | (~Thunderbi@syn-047-229-123-186.res.spectrum.com) |
| 2024-05-01 02:08:23 +0200 | <jackdk> | Thanks but it's neither of those. It was more like a typelevel answer to the question "what resources is this function going to touch?" in a way that let you accumulate the names in a constraint and pull them down to the value level to write out a policy or equivalent |
| 2024-05-01 02:14:39 +0200 | mima | (~mmh@aftr-62-216-211-165.dynamic.mnet-online.de) (Ping timeout: 260 seconds) |
| 2024-05-01 02:43:47 +0200 | wroathe | (~wroathe@24-152-179-157.fttp.usinternet.com) |
| 2024-05-01 02:43:47 +0200 | wroathe | (~wroathe@24-152-179-157.fttp.usinternet.com) (Changing host) |
| 2024-05-01 02:43:47 +0200 | wroathe | (~wroathe@user/wroathe) |
| 2024-05-01 02:44:57 +0200 | whatsupdoc | (uid509081@id-509081.hampstead.irccloud.com) |
| 2024-05-01 02:47:05 +0200 | xff0x | (~xff0x@softbank219059019218.bbtec.net) (Ping timeout: 252 seconds) |
| 2024-05-01 02:51:02 +0200 | <jackdk> | It was https://reasonablypolymorphic.com/blog/abusing-constraints/ |
| 2024-05-01 02:53:14 +0200 | talismanick | (~user@2601:644:937c:ed10::ae5) |
| 2024-05-01 02:55:23 +0200 | <talismanick> | If a free monad is a tree of expressions, is there a DAG analogue? |
| 2024-05-01 02:57:02 +0200 | <geekosaur> | oh, right, I saw that a few months ago |
| 2024-05-01 03:00:13 +0200 | <geekosaur> | talismanick, isn't it actually a DAG anyway? cycles would severely limit the monads you could use to "interpret" it |
| 2024-05-01 03:02:05 +0200 | pointlessslippe1 | (~pointless@212.82.82.3) (Ping timeout: 240 seconds) |
| 2024-05-01 03:09:19 +0200 | <ski> | hmm .. i guess you could have an operation that requires that its opeands "overlap" (have some common substructures), in some particular fashion. so a recursive decomposition of a problem (corresponding to matching on such a constructor operation) would then naturally allow dynamic programming (iow a DAG, rather than a tree, recursive decomposition/structuring of the original problem), presumably |
| 2024-05-01 03:10:01 +0200 | fryguybob | (~fryguybob@024-094-050-022.inf.spectrum.com) (Quit: leaving) |
| 2024-05-01 03:11:26 +0200 | <c_wraith> | You don't need any special structure for that, though |
| 2024-05-01 03:11:30 +0200 | <c_wraith> | You just need sharing. |
| 2024-05-01 03:14:28 +0200 | <ski> | yea, but how do you detect, or enforce, the sharing, of the iput structure, to justify the sharing of the output computation ? |
| 2024-05-01 03:14:36 +0200 | <ski> | s/iput/input/ |
| 2024-05-01 03:14:50 +0200 | <c_wraith> | pick f carefully. |
| 2024-05-01 03:15:01 +0200 | <c_wraith> | you can embed basically anything you want into f |
| 2024-05-01 03:15:04 +0200 | <ski> | iow, i'm thinking of something like a catamorphism |
| 2024-05-01 03:15:53 +0200 | waldo | (~waldo@user/waldo) |
| 2024-05-01 03:18:29 +0200 | <ski> | given an array/vector with indices from `0' to `n-1' (incl.), we could decompose this into one slice from `0' to `n-2' and one from `1' to `n-1', guaranteed to overlap on the `1' to `n-2' part. eventually, we'd get down to singleton slices, which could be the base case of a dynamic programming, then results percolating back up in a "lattive"-like structure, rather than a tree, proper, thereby taking |
| 2024-05-01 03:18:35 +0200 | <ski> | advantage of the sharing |
| 2024-05-01 03:23:41 +0200 | <talismanick> | I'm feeling a little stupid, then, trying to understand https://hackage.haskell.org/package/zsdd/docs/Data-Diagram.html |
| 2024-05-01 03:24:25 +0200 | <ski> | basically, we have, if `Just (ar01,ar12) = decompose ar012', `Just (ar0,ar1a) = decompose ar01' and `Just (ar1b,ar2) = decompose ar12', then `ar1a = ar1b' |
| 2024-05-01 03:26:03 +0200 | <talismanick> | because, if one can assume "maximal sharing", I feel like I can see in my head how a BDD might be implemented with a (real) free monad |
| 2024-05-01 03:27:48 +0200 | otto_s | (~user@p4ff27e40.dip0.t-ipconnect.de) (Ping timeout: 252 seconds) |
| 2024-05-01 03:29:11 +0200 | <ski> | or, in terms of composition, if `Compose (Compose ar0 ar1a) (Compose ar1b ar2) = ar012', then `ar1a = ar1b'. so we have something like `Compose :: (ar0 :: Slice n) -> (ar1 :: Slice n) -> Agree ar0 ar1 => Slice (1+n)', where `Agree (Singleton x) (Singleton y)' as well as `(ar1a = ar1b) => Agree (Compose ar0 ar1a) (Compose ar1b ar2)' (where `Agree :: Slice n -> Slice n -> Constraint') |
| 2024-05-01 03:29:12 +0200 | otto_s | (~user@p4ff27c65.dip0.t-ipconnect.de) |
| 2024-05-01 03:29:18 +0200 | <talismanick> | is it the kind of thing where it becomes obvious when you write it down? |
| 2024-05-01 03:30:28 +0200 | <ski> | hm, is "BDD" Binary Decision Diagram ? |
| 2024-05-01 03:31:09 +0200 | <talismanick> | yeah |
| 2024-05-01 03:31:19 +0200 | ski | doesn't recall what those re |
| 2024-05-01 03:31:22 +0200 | <ski> | s/re/are/ |
| 2024-05-01 03:31:46 +0200 | <talismanick> | https://en.wikipedia.org/wiki/Binary_decision_diagram |
| 2024-05-01 03:32:04 +0200 | <talismanick> | kind of like SAT solving |
| 2024-05-01 03:36:16 +0200 | <talismanick> | Is the problem is that laziness memoizes and shares for you without asking, making every tree equivalent to a DAG but not the one you want? |
| 2024-05-01 03:38:18 +0200 | <c_wraith> | well, no. The problem is sharing only happens when explicitly introduced, and doing that is going to require bookkeeping. And the memory cost of that bookkeeping is ridiculous. |
| 2024-05-01 03:43:11 +0200 | waleee | (~waleee@h-176-10-144-38.NA.cust.bahnhof.se) (Quit: WeeChat 4.1.2) |
| 2024-05-01 03:46:30 +0200 | ski | . o O ( "BDD-Based Deductive Databasee" <https://bddbddb.sourceforge.net/> ; "Soufflé - A Datalog Synthesis Tool for Static Analysis" <https://souffle-lang.github.io> ) |
| 2024-05-01 03:47:32 +0200 | <ski> | there's also a problem that when traversing a structure with sharing, producing a new parallel structure, that would normally lose all sharing |
| 2024-05-01 03:49:07 +0200 | <ski> | (what i was thinking about was encoding the sharing in the type, or rather, in the decomposition process, making it mandatory, thereby making sure it will happen in the result as well) |
| 2024-05-01 03:49:59 +0200 | <ski> | (not clear how would apply something like that to BDDs, though) |
| 2024-05-01 03:50:54 +0200 | wroathe | (~wroathe@user/wroathe) (Ping timeout: 252 seconds) |
| 2024-05-01 03:59:28 +0200 | <talismanick> | ski: I think Souffle now uses a concurrent B-tree/trie hybrid (lexicographically-ordered B-tree?) |
| 2024-05-01 03:59:41 +0200 | <talismanick> | found it: https://souffle-lang.github.io/pdf/pmam19.pdf |
| 2024-05-01 04:01:01 +0200 | <c_wraith> | B-trees are already lexicographically ordered. I'm betting it's more like adjusting the number of bits in a node in order keep the fan-out within particular bounds. |
| 2024-05-01 04:01:17 +0200 | <c_wraith> | Which... sounds sorta like Patricia Tries, actually. |
| 2024-05-01 04:02:45 +0200 | <c_wraith> | Ah, not quite. Patricia tries have a fixed fanout of 2 |
| 2024-05-01 04:05:28 +0200 | ski | only heard someone mention Soufflé the other week, recognized the mention of BDDBDDB, but hasn't looked at it |
| 2024-05-01 04:08:09 +0200 | <talismanick> | c_wraith: the cost of bookkeeping is prohibitive for free monads in general, you mean? |
| 2024-05-01 04:09:58 +0200 | <talismanick> | The reduction of a Boolean function is canonical (up to variable ordering), so maybe it's not a problem in this case... |
| 2024-05-01 04:11:39 +0200 | Katarushisu1 | (~Katarushi@finc-20-b2-v4wan-169598-cust1799.vm7.cable.virginm.net) (Read error: Connection reset by peer) |
| 2024-05-01 04:11:54 +0200 | <talismanick> | It's probably be none-too-expensive to preface the interpreter with the reduction rules, so long as the free monad/binary decision tree is built and consumed incrementally, right? |
| 2024-05-01 04:12:09 +0200 | <c_wraith> | no, I mean that if a problem like this is hard, there are just a *lot* of distinct subproblems. |
| 2024-05-01 04:13:50 +0200 | Katarushisu1 | (~Katarushi@finc-20-b2-v4wan-169598-cust1799.vm7.cable.virginm.net) |
| 2024-05-01 04:17:42 +0200 | Axman4765 | (~Axman6@user/axman6) |
| 2024-05-01 04:17:49 +0200 | Axman4765 | Bynbo7 |
| 2024-05-01 04:21:27 +0200 | cashew | (~cashewsta@65.17.175.150) |
| 2024-05-01 04:27:50 +0200 | td_ | (~td@i53870902.versanet.de) (Ping timeout: 245 seconds) |
| 2024-05-01 04:29:44 +0200 | td_ | (~td@i53870927.versanet.de) |
| 2024-05-01 04:42:35 +0200 | Square3 | (~Square4@user/square) (Ping timeout: 268 seconds) |
| 2024-05-01 04:43:21 +0200 | gues54302 | (~username@3.184.70.115.static.exetel.com.au) |
| 2024-05-01 04:43:24 +0200 | terrorjack | (~terrorjac@2a01:4f8:c17:87f8::) (Quit: The Lounge - https://thelounge.chat) |
| 2024-05-01 04:45:19 +0200 | terrorjack | (~terrorjac@2a01:4f8:c17:87f8::) |
| 2024-05-01 04:45:22 +0200 | peterbecich | (~Thunderbi@syn-047-229-123-186.res.spectrum.com) (Ping timeout: 268 seconds) |
| 2024-05-01 04:48:03 +0200 | waldo | (~waldo@user/waldo) (Quit: waldo) |
| 2024-05-01 04:50:10 +0200 | Bynbo7 | (~Axman6@user/axman6) (Remote host closed the connection) |
| 2024-05-01 04:51:31 +0200 | demon-cat | (~demon-cat@dund-15-b2-v4wan-169642-cust1347.vm6.cable.virginm.net) (Remote host closed the connection) |
| 2024-05-01 04:51:55 +0200 | demon-cat | (~demon-cat@dund-15-b2-v4wan-169642-cust1347.vm6.cable.virginm.net) |
| 2024-05-01 04:52:49 +0200 | ddellacosta | (~ddellacos@ool-44c73d29.dyn.optonline.net) |
| 2024-05-01 04:52:51 +0200 | gues54302 | (~username@3.184.70.115.static.exetel.com.au) (Ping timeout: 260 seconds) |
| 2024-05-01 04:58:09 +0200 | tri | (~tri@ool-18bc2e74.dyn.optonline.net) |
| 2024-05-01 05:02:59 +0200 | tri | (~tri@ool-18bc2e74.dyn.optonline.net) (Ping timeout: 264 seconds) |
| 2024-05-01 05:05:58 +0200 | madeleine-sydney | (~madeleine@c-76-155-235-153.hsd1.co.comcast.net) |
| 2024-05-01 05:06:05 +0200 | aforemny_ | (~aforemny@i59F516CA.versanet.de) (Ping timeout: 240 seconds) |
| 2024-05-01 05:07:14 +0200 | aforemny | (~aforemny@2001:9e8:6cea:d00:aab5:d1b:ca3e:df36) |
| 2024-05-01 05:40:34 +0200 | philopsos | (~caecilius@user/philopsos) |
| 2024-05-01 05:41:11 +0200 | cashew | (~cashewsta@65.17.175.150) (Quit: Leaving...) |
| 2024-05-01 05:52:53 +0200 | bitdex | (~bitdex@gateway/tor-sasl/bitdex) |
| 2024-05-01 05:59:56 +0200 | bitdex | (~bitdex@gateway/tor-sasl/bitdex) (Remote host closed the connection) |
| 2024-05-01 06:01:09 +0200 | bitdex | (~bitdex@gateway/tor-sasl/bitdex) |
| 2024-05-01 06:06:15 +0200 | _ht | (~Thunderbi@28-52-174-82.ftth.glasoperator.nl) |
| 2024-05-01 06:07:04 +0200 | philopsos | (~caecilius@user/philopsos) (Ping timeout: 268 seconds) |
| 2024-05-01 06:07:22 +0200 | stiell_ | (~stiell@gateway/tor-sasl/stiell) (Remote host closed the connection) |
| 2024-05-01 06:08:13 +0200 | stiell_ | (~stiell@gateway/tor-sasl/stiell) |
| 2024-05-01 06:08:15 +0200 | machinedgod | (~machinedg@d173-183-246-216.abhsia.telus.net) (Ping timeout: 245 seconds) |
| 2024-05-01 06:17:29 +0200 | madeleine-sydney | (~madeleine@c-76-155-235-153.hsd1.co.comcast.net) (Quit: Konversation terminated!) |
| 2024-05-01 06:22:30 +0200 | tri | (~tri@ool-18bc2e74.dyn.optonline.net) |
| 2024-05-01 06:26:58 +0200 | peterbecich | (~Thunderbi@syn-047-229-123-186.res.spectrum.com) |
| 2024-05-01 06:37:40 +0200 | ChaiTRex | (~ChaiTRex@user/chaitrex) |
| 2024-05-01 06:41:39 +0200 | madeleine-sydney | (~madeleine@c-76-155-235-153.hsd1.co.comcast.net) |
| 2024-05-01 06:49:10 +0200 | philopsos | (~caecilius@user/philopsos) |
| 2024-05-01 07:00:15 +0200 | peterbecich | (~Thunderbi@syn-047-229-123-186.res.spectrum.com) (Ping timeout: 260 seconds) |
| 2024-05-01 07:02:56 +0200 | sroso | (~sroso@user/SrOso) |
| 2024-05-01 07:03:38 +0200 | gues45965 | (~username@3.184.70.115.static.exetel.com.au) |
| 2024-05-01 07:07:26 +0200 | gues45965 | (~username@3.184.70.115.static.exetel.com.au) (Remote host closed the connection) |
| 2024-05-01 07:09:43 +0200 | gues22599 | (~username@3.184.70.115.static.exetel.com.au) |
| 2024-05-01 07:12:34 +0200 | gues96208 | (~username@3.184.70.115.static.exetel.com.au) |
| 2024-05-01 07:14:21 +0200 | takuan | (~takuan@178-116-218-225.access.telenet.be) |
| 2024-05-01 07:14:57 +0200 | <Axman6> | Hello #haskellers, can I ask a favour of someone on Matrix? Can you just say some things in here so I can see if I've fixed something that's breaking for me in glirc. I probably need to see a few messages to know if it's improved |
| 2024-05-01 07:16:15 +0200 | Axma55792 | (~Axman6@user/axman6) |
| 2024-05-01 07:16:22 +0200 | Axma55792 | Bynbo7 |
| 2024-05-01 07:30:56 +0200 | euphores | (~SASL_euph@user/euphores) (Quit: Leaving.) |
| 2024-05-01 07:36:15 +0200 | tri | (~tri@ool-18bc2e74.dyn.optonline.net) (Remote host closed the connection) |
| 2024-05-01 07:36:44 +0200 | qqq | (~qqq@92.43.167.61) |
| 2024-05-01 07:37:30 +0200 | xff0x | (~xff0x@softbank219059019218.bbtec.net) |
| 2024-05-01 07:43:15 +0200 | <haskellbridge> | <geekosaur> does this help? |
| 2024-05-01 07:46:56 +0200 | Sgeo | (~Sgeo@user/sgeo) (Read error: Connection reset by peer) |
| 2024-05-01 07:49:12 +0200 | euphores | (~SASL_euph@user/euphores) |
| 2024-05-01 08:26:50 +0200 | rvalue | (~rvalue@user/rvalue) (Read error: Connection reset by peer) |
| 2024-05-01 08:26:55 +0200 | tri | (~tri@ool-18bc2e74.dyn.optonline.net) |
| 2024-05-01 08:27:19 +0200 | rvalue | (~rvalue@user/rvalue) |
| 2024-05-01 08:31:15 +0200 | tri | (~tri@ool-18bc2e74.dyn.optonline.net) (Ping timeout: 260 seconds) |
| 2024-05-01 08:36:27 +0200 | raym | (~ray@user/raym) |
| 2024-05-01 08:37:49 +0200 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) |
| 2024-05-01 08:39:49 +0200 | acidjnk | (~acidjnk@p200300d6e714dc53acbe2cc37902b0bc.dip0.t-ipconnect.de) |
| 2024-05-01 08:45:00 +0200 | danza | (~francesco@151.43.220.194) |
| 2024-05-01 08:47:02 +0200 | pointlessslippe1 | (~pointless@212.82.82.3) |
| 2024-05-01 08:54:55 +0200 | danza | (~francesco@151.43.220.194) (Ping timeout: 245 seconds) |
| 2024-05-01 08:57:03 +0200 | philopsos | (~caecilius@user/philopsos) (Ping timeout: 272 seconds) |
| 2024-05-01 09:00:01 +0200 | mikess | (~mikess@user/mikess) (Ping timeout: 246 seconds) |
| 2024-05-01 09:03:26 +0200 | gues22599 | (~username@3.184.70.115.static.exetel.com.au) (Ping timeout: 268 seconds) |
| 2024-05-01 09:03:28 +0200 | gues96208 | (~username@3.184.70.115.static.exetel.com.au) (Ping timeout: 255 seconds) |
| 2024-05-01 09:05:34 +0200 | chexum | (~quassel@gateway/tor-sasl/chexum) (Remote host closed the connection) |
| 2024-05-01 09:06:08 +0200 | chexum | (~quassel@gateway/tor-sasl/chexum) |
| 2024-05-01 09:09:32 +0200 | <[exa]> | Axman6: might be the case that there's a matrix-specific channel with plenty of people hyperactive about this topic |
| 2024-05-01 09:12:17 +0200 | gues90080 | (~username@ppp121-45-202-250.cbr-trn-nor-bras38.tpg.internode.on.net) |
| 2024-05-01 09:18:22 +0200 | Tuplanolla | (~Tuplanoll@91-159-69-59.elisa-laajakaista.fi) |
| 2024-05-01 09:20:10 +0200 | tolt_ | (~weechat-h@li219-154.members.linode.com) |
| 2024-05-01 09:22:00 +0200 | gmg | (~user@user/gehmehgeh) |
| 2024-05-01 09:22:47 +0200 | tolt | (~weechat-h@li219-154.members.linode.com) (Ping timeout: 264 seconds) |
| 2024-05-01 09:29:36 +0200 | raym | (~ray@user/raym) (Quit: upgrading kernel, brb) |
| 2024-05-01 09:32:44 +0200 | __monty__ | (~toonn@user/toonn) |
| 2024-05-01 09:32:56 +0200 | tolt_ | tolt |
| 2024-05-01 09:36:20 +0200 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 2024-05-01 09:36:57 +0200 | mima | (~mmh@aftr-62-216-211-100.dynamic.mnet-online.de) |
| 2024-05-01 09:54:42 +0200 | sord937 | (~sord937@gateway/tor-sasl/sord937) |
| 2024-05-01 09:58:06 +0200 | econo_ | (uid147250@id-147250.tinside.irccloud.com) (Quit: Connection closed for inactivity) |
| 2024-05-01 10:01:22 +0200 | causal | (~eric@50.35.88.207) (Quit: WeeChat 4.1.1) |
| 2024-05-01 10:09:13 +0200 | danza | (~francesco@151.43.219.217) |
| 2024-05-01 10:19:25 +0200 | tzh | (~tzh@c-73-164-206-160.hsd1.or.comcast.net) (Quit: zzz) |
| 2024-05-01 10:21:33 +0200 | esph | (~weechat@user/esph) |
| 2024-05-01 10:21:35 +0200 | talismanick | (~user@2601:644:937c:ed10::ae5) (Ping timeout: 245 seconds) |
| 2024-05-01 10:26:15 +0200 | danza | (~francesco@151.43.219.217) (Ping timeout: 255 seconds) |
| 2024-05-01 10:32:05 +0200 | hseg | (~gesh@77.137.75.224) |
| 2024-05-01 10:34:15 +0200 | <hseg> | Hi. I'm packaging some haskell programs, and am planning to build them with stack. Other than manually editing stack.yaml, is there a way to set the snapshot to lts-22.19+ghc-9.6.5 ? |
| 2024-05-01 10:34:53 +0200 | <hseg> | I know I can set the lts part by stack config set resolver lts-22.19, but does stack not have a way to write the compiler version to use? |
| 2024-05-01 10:36:24 +0200 | <hseg> | (alternatively, where can I track progress on cutting an lts using ghc 9.6.5? It has a bugfix that's critical on my system) |
| 2024-05-01 10:37:09 +0200 | sawilagar | (~sawilagar@user/sawilagar) |
| 2024-05-01 10:37:33 +0200 | oo_miguel | (~Thunderbi@78-11-181-16.static.ip.netia.com.pl) |
| 2024-05-01 10:42:43 +0200 | xff0x | (~xff0x@softbank219059019218.bbtec.net) (Ping timeout: 268 seconds) |
| 2024-05-01 10:43:44 +0200 | xff0x | (~xff0x@softbank219059019218.bbtec.net) |
| 2024-05-01 10:53:27 +0200 | acidjnk | (~acidjnk@p200300d6e714dc53acbe2cc37902b0bc.dip0.t-ipconnect.de) (Ping timeout: 256 seconds) |
| 2024-05-01 11:25:35 +0200 | jinsun | (~jinsun@user/jinsun) |
| 2024-05-01 11:26:10 +0200 | FinnElija | (~finn_elij@user/finn-elija/x-0085643) (Remote host closed the connection) |
| 2024-05-01 11:26:54 +0200 | FinnElija | (~finn_elij@user/finn-elija/x-0085643) |
| 2024-05-01 11:29:30 +0200 | gues90080 | (~username@ppp121-45-202-250.cbr-trn-nor-bras38.tpg.internode.on.net) (Ping timeout: 245 seconds) |
| 2024-05-01 11:31:10 +0200 | barak | (~barak@2a0d:6fc2:68c1:7200:3cf2:a87d:a02b:3e21) |
| 2024-05-01 11:32:25 +0200 | xff0x | (~xff0x@softbank219059019218.bbtec.net) (Ping timeout: 245 seconds) |
| 2024-05-01 11:41:52 +0200 | oo_miguel1 | (~Thunderbi@78-11-181-16.static.ip.netia.com.pl) |
| 2024-05-01 11:43:15 +0200 | oo_miguel | (~Thunderbi@78-11-181-16.static.ip.netia.com.pl) (Ping timeout: 245 seconds) |
| 2024-05-01 11:43:15 +0200 | oo_miguel1 | oo_miguel |
| 2024-05-01 11:45:32 +0200 | aosync_ | aws |
| 2024-05-01 11:45:48 +0200 | aws | (~alews@141.94.77.100) (Changing host) |
| 2024-05-01 11:45:48 +0200 | aws | (~alews@user/aws) |
| 2024-05-01 11:53:33 +0200 | <lyxia> | hseg: https://docs.haskellstack.org/en/stable/yaml_configuration/#compiler |
| 2024-05-01 11:57:58 +0200 | L29Ah | (~L29Ah@wikipedia/L29Ah) () |
| 2024-05-01 12:02:23 +0200 | hseg | (~gesh@77.137.75.224) (Ping timeout: 264 seconds) |
| 2024-05-01 12:04:04 +0200 | L29Ah | (~L29Ah@wikipedia/L29Ah) |
| 2024-05-01 12:08:24 +0200 | hseg | (~gesh@77.137.75.224) |
| 2024-05-01 12:09:08 +0200 | <hseg> | lyxia: thanks! In hindsight, it makes sense that such an off-the-beaten-path configuration would need manual intervention |
| 2024-05-01 12:21:47 +0200 | mwnaylor | (~user@2601:5cf:837e:2bb0::f472) (Ping timeout: 260 seconds) |
| 2024-05-01 12:47:25 +0200 | guest7621 | (~username@120.17.103.254) |
| 2024-05-01 12:48:34 +0200 | gues51644 | (~username@120.17.103.254) |
| 2024-05-01 12:49:41 +0200 | xff0x | (~xff0x@softbank219059019218.bbtec.net) |
| 2024-05-01 12:51:41 +0200 | Lord_of_Life_ | (~Lord@user/lord-of-life/x-2819915) |
| 2024-05-01 12:52:07 +0200 | Lord_of_Life | (~Lord@user/lord-of-life/x-2819915) (Ping timeout: 260 seconds) |
| 2024-05-01 12:53:04 +0200 | Lord_of_Life_ | Lord_of_Life |
| 2024-05-01 13:13:07 +0200 | gues51644 | (~username@120.17.103.254) (Read error: Connection reset by peer) |
| 2024-05-01 13:13:07 +0200 | guest7621 | (~username@120.17.103.254) (Read error: Connection reset by peer) |
| 2024-05-01 13:17:43 +0200 | destituion | (~destituio@2a02:2121:340:2456:fffe:d0f:7737:dd1) (Ping timeout: 255 seconds) |
| 2024-05-01 13:18:39 +0200 | Maxdaman1us | (~Maxdamant@user/maxdamantus) (Ping timeout: 256 seconds) |
| 2024-05-01 13:21:20 +0200 | L29Ah | (~L29Ah@wikipedia/L29Ah) (Remote host closed the connection) |
| 2024-05-01 13:23:45 +0200 | L29Ah | (~L29Ah@wikipedia/L29Ah) |
| 2024-05-01 13:23:57 +0200 | destituion | (~destituio@2a02:2121:340:2456:fffe:d0f:7737:dd1) |
| 2024-05-01 13:26:25 +0200 | raehik | (~raehik@rdng-25-b2-v4wan-169990-cust1344.vm39.cable.virginm.net) |
| 2024-05-01 13:34:20 +0200 | Maxdamantus | (~Maxdamant@user/maxdamantus) |
| 2024-05-01 13:35:25 +0200 | mei | (~mei@user/mei) (Remote host closed the connection) |
| 2024-05-01 13:36:01 +0200 | mei | (~mei@user/mei) |
| 2024-05-01 13:41:20 +0200 | acidjnk | (~acidjnk@p200300d6e714dc53acbe2cc37902b0bc.dip0.t-ipconnect.de) |
| 2024-05-01 13:44:01 +0200 | Square | (~Square@user/square) |
| 2024-05-01 13:45:55 +0200 | madeleine-sydney | (~madeleine@c-76-155-235-153.hsd1.co.comcast.net) (Quit: Konversation terminated!) |
| 2024-05-01 13:52:50 +0200 | mreh | (~matthew@host86-160-168-68.range86-160.btcentralplus.com) |
| 2024-05-01 13:54:30 +0200 | euleritian | (~euleritia@77.22.252.56) (Ping timeout: 268 seconds) |
| 2024-05-01 13:54:41 +0200 | euleritian | (~euleritia@dynamic-176-001-013-250.176.1.pool.telefonica.de) |
| 2024-05-01 13:55:48 +0200 | mreh | (~matthew@host86-160-168-68.range86-160.btcentralplus.com) (Client Quit) |
| 2024-05-01 13:58:39 +0200 | xff0x | (~xff0x@softbank219059019218.bbtec.net) (Ping timeout: 255 seconds) |
| 2024-05-01 13:59:09 +0200 | raehik | (~raehik@rdng-25-b2-v4wan-169990-cust1344.vm39.cable.virginm.net) (Ping timeout: 272 seconds) |
| 2024-05-01 14:07:51 +0200 | raehik | (~raehik@rdng-25-b2-v4wan-169990-cust1344.vm39.cable.virginm.net) |
| 2024-05-01 14:09:39 +0200 | ddellacosta | (~ddellacos@ool-44c73d29.dyn.optonline.net) (Ping timeout: 252 seconds) |
| 2024-05-01 14:11:37 +0200 | sroso | (~sroso@user/SrOso) (Quit: Leaving :)) |
| 2024-05-01 14:21:12 +0200 | Xe | (~cadey@perl/impostor/xe) (Ping timeout: 252 seconds) |
| 2024-05-01 14:23:05 +0200 | Xe | (~cadey@perl/impostor/xe) |
| 2024-05-01 14:31:38 +0200 | mima | (~mmh@aftr-62-216-211-100.dynamic.mnet-online.de) (Ping timeout: 252 seconds) |
| 2024-05-01 14:32:59 +0200 | bitdex | (~bitdex@gateway/tor-sasl/bitdex) (Quit: = "") |
| 2024-05-01 14:37:47 +0200 | euleritian | (~euleritia@dynamic-176-001-013-250.176.1.pool.telefonica.de) (Read error: Connection reset by peer) |
| 2024-05-01 14:38:04 +0200 | euleritian | (~euleritia@ip4d16fc38.dynamic.kabel-deutschland.de) |
| 2024-05-01 14:38:05 +0200 | ski_ | (~ski@ext-1-033.eduroam.chalmers.se) (Ping timeout: 240 seconds) |
| 2024-05-01 14:45:21 +0200 | Maxdamantus | (~Maxdamant@user/maxdamantus) (Ping timeout: 256 seconds) |
| 2024-05-01 14:45:35 +0200 | SteelBlueSilk | (~SteelBlue@user/SteelBlueSilk) (Ping timeout: 264 seconds) |
| 2024-05-01 14:46:48 +0200 | euleritian | (~euleritia@ip4d16fc38.dynamic.kabel-deutschland.de) (Ping timeout: 255 seconds) |
| 2024-05-01 14:47:23 +0200 | raehik | (~raehik@rdng-25-b2-v4wan-169990-cust1344.vm39.cable.virginm.net) (Ping timeout: 264 seconds) |
| 2024-05-01 14:48:03 +0200 | euleritian | (~euleritia@dynamic-176-001-013-250.176.1.pool.telefonica.de) |
| 2024-05-01 14:48:48 +0200 | euleritian | (~euleritia@dynamic-176-001-013-250.176.1.pool.telefonica.de) (Read error: Connection reset by peer) |
| 2024-05-01 14:49:17 +0200 | euleritian | (~euleritia@dynamic-176-001-013-250.176.1.pool.telefonica.de) |
| 2024-05-01 14:51:24 +0200 | yin | (~yin@user/zero) |
| 2024-05-01 15:05:16 +0200 | yin | (~yin@user/zero) (Ping timeout: 255 seconds) |
| 2024-05-01 15:09:04 +0200 | Square | (~Square@user/square) (Ping timeout: 260 seconds) |
| 2024-05-01 15:16:02 +0200 | mzschr | (~mzschr@2a07-a880-4603-1035-18b5-1e9f-f698-63a6.pool6.ovpn.com) |
| 2024-05-01 15:21:20 +0200 | Maxdamantus | (~Maxdamant@user/maxdamantus) |
| 2024-05-01 15:23:17 +0200 | demon-cat | (~demon-cat@dund-15-b2-v4wan-169642-cust1347.vm6.cable.virginm.net) (Read error: Connection reset by peer) |
| 2024-05-01 15:27:22 +0200 | dfip^ | (~cd@c-98-242-74-66.hsd1.ga.comcast.net) |
| 2024-05-01 15:46:24 +0200 | tri | (~tri@ool-18bbef1a.static.optonline.net) |
| 2024-05-01 15:47:08 +0200 | mikess | (~mikess@user/mikess) |
| 2024-05-01 15:50:26 +0200 | hseg | (~gesh@77.137.75.224) (Quit: WeeChat 4.2.2) |
| 2024-05-01 15:50:51 +0200 | tri | (~tri@ool-18bbef1a.static.optonline.net) (Ping timeout: 260 seconds) |
| 2024-05-01 15:58:44 +0200 | fireking04 | (~karl@175.176.41.51) |
| 2024-05-01 16:01:57 +0200 | gorignak | (~gorignak@user/gorignak) |
| 2024-05-01 16:10:22 +0200 | fireking04 | (~karl@175.176.41.51) (Read error: Connection reset by peer) |
| 2024-05-01 16:18:29 +0200 | zer0bitz | (~zer0bitz@user/zer0bitz) (Ping timeout: 240 seconds) |
| 2024-05-01 16:18:35 +0200 | euleritian | (~euleritia@dynamic-176-001-013-250.176.1.pool.telefonica.de) (Read error: Connection reset by peer) |
| 2024-05-01 16:18:53 +0200 | euleritian | (~euleritia@ip4d16fc38.dynamic.kabel-deutschland.de) |
| 2024-05-01 16:19:49 +0200 | Teacup | (~teacup@user/teacup) () |
| 2024-05-01 16:20:07 +0200 | Teacup | (~teacup@user/teacup) |
| 2024-05-01 16:21:53 +0200 | zer0bitz | (~zer0bitz@user/zer0bitz) |
| 2024-05-01 16:21:53 +0200 | paotsaq | (~paotsaq@127.209.37.188.rev.vodafone.pt) (Quit: ZNC 1.9.0 - https://znc.in) |
| 2024-05-01 16:23:23 +0200 | euleritian | (~euleritia@ip4d16fc38.dynamic.kabel-deutschland.de) (Read error: Connection reset by peer) |
| 2024-05-01 16:24:04 +0200 | euleritian | (~euleritia@ip4d16fc38.dynamic.kabel-deutschland.de) |
| 2024-05-01 16:25:10 +0200 | sp1ff | (~user@c-24-21-45-157.hsd1.wa.comcast.net) (Read error: Connection reset by peer) |
| 2024-05-01 16:25:23 +0200 | sp1ff | (~user@c-24-21-45-157.hsd1.wa.comcast.net) |
| 2024-05-01 16:29:14 +0200 | paotsaq | (~paotsaq@127.209.37.188.rev.vodafone.pt) |
| 2024-05-01 16:32:39 +0200 | machinedgod | (~machinedg@d173-183-246-216.abhsia.telus.net) |
| 2024-05-01 16:43:28 +0200 | euleritian | (~euleritia@ip4d16fc38.dynamic.kabel-deutschland.de) (Ping timeout: 268 seconds) |
| 2024-05-01 16:43:51 +0200 | euleritian | (~euleritia@dynamic-176-001-013-250.176.1.pool.telefonica.de) |
| 2024-05-01 16:45:16 +0200 | euleritian | (~euleritia@dynamic-176-001-013-250.176.1.pool.telefonica.de) (Read error: Connection reset by peer) |
| 2024-05-01 16:45:33 +0200 | euleritian | (~euleritia@ip4d16fc38.dynamic.kabel-deutschland.de) |
| 2024-05-01 16:51:08 +0200 | L29Ah | (~L29Ah@wikipedia/L29Ah) (Read error: Connection timed out) |
| 2024-05-01 17:09:04 +0200 | gorignak | (~gorignak@user/gorignak) (Ping timeout: 268 seconds) |
| 2024-05-01 17:10:52 +0200 | euleritian | (~euleritia@ip4d16fc38.dynamic.kabel-deutschland.de) (Ping timeout: 260 seconds) |
| 2024-05-01 17:11:23 +0200 | euleritian | (~euleritia@dynamic-176-001-013-250.176.1.pool.telefonica.de) |
| 2024-05-01 17:14:35 +0200 | L29Ah | (~L29Ah@wikipedia/L29Ah) |
| 2024-05-01 17:16:58 +0200 | billchenchina | (~billchenc@103.118.42.229) |
| 2024-05-01 17:17:49 +0200 | billchenchina | (~billchenc@103.118.42.229) (Max SendQ exceeded) |
| 2024-05-01 17:19:03 +0200 | euleritian | (~euleritia@dynamic-176-001-013-250.176.1.pool.telefonica.de) (Read error: Connection reset by peer) |
| 2024-05-01 17:19:31 +0200 | billchenchina | (~billchenc@103.118.42.229) |
| 2024-05-01 17:19:44 +0200 | euleritian | (~euleritia@dynamic-176-001-013-250.176.1.pool.telefonica.de) |
| 2024-05-01 17:20:21 +0200 | billchenchina | (~billchenc@103.118.42.229) (Max SendQ exceeded) |
| 2024-05-01 17:20:36 +0200 | mzschr | (~mzschr@2a07-a880-4603-1035-18b5-1e9f-f698-63a6.pool6.ovpn.com) (Quit: Client closed) |
| 2024-05-01 17:21:28 +0200 | billchenchina | (~billchenc@103.118.42.229) |
| 2024-05-01 17:22:22 +0200 | billchenchina | (~billchenc@103.118.42.229) (Max SendQ exceeded) |
| 2024-05-01 17:24:11 +0200 | billchenchina | (~billchenc@103.118.42.229) |
| 2024-05-01 17:24:57 +0200 | billchenchina | (~billchenc@103.118.42.229) (Max SendQ exceeded) |
| 2024-05-01 17:25:34 +0200 | billchenchina | (~billchenc@103.118.42.229) |
| 2024-05-01 17:26:27 +0200 | billchenchina | (~billchenc@103.118.42.229) (Max SendQ exceeded) |
| 2024-05-01 17:26:57 +0200 | billchenchina | (~billchenc@103.118.42.229) |
| 2024-05-01 17:27:49 +0200 | billchenchina | (~billchenc@103.118.42.229) (Max SendQ exceeded) |
| 2024-05-01 17:28:30 +0200 | billchenchina | (~billchenc@103.118.42.229) |
| 2024-05-01 17:29:05 +0200 | billchenchina | (~billchenc@103.118.42.229) (Max SendQ exceeded) |
| 2024-05-01 17:29:28 +0200 | raym | (~ray@user/raym) |
| 2024-05-01 17:30:00 +0200 | billchenchina | (~billchenc@103.118.42.229) |
| 2024-05-01 17:30:32 +0200 | billchenchina | (~billchenc@103.118.42.229) (Client Quit) |
| 2024-05-01 17:35:57 +0200 | euleritian | (~euleritia@dynamic-176-001-013-250.176.1.pool.telefonica.de) (Read error: Connection reset by peer) |
| 2024-05-01 17:36:14 +0200 | euleritian | (~euleritia@ip4d16fc38.dynamic.kabel-deutschland.de) |
| 2024-05-01 17:40:27 +0200 | euleritian | (~euleritia@ip4d16fc38.dynamic.kabel-deutschland.de) (Ping timeout: 256 seconds) |
| 2024-05-01 17:40:37 +0200 | <shapr> | does anyone know how hackage calculates test coverage % ? |
| 2024-05-01 17:40:49 +0200 | euleritian | (~euleritia@dynamic-176-001-013-250.176.1.pool.telefonica.de) |
| 2024-05-01 17:42:25 +0200 | <shapr> | aha, I think I found it |
| 2024-05-01 17:43:07 +0200 | <shapr> | yup, I think it's https://github.com/haskell/hackage-server/blob/master/exes/BuildClient.hs#L594 |
| 2024-05-01 17:45:15 +0200 | tri | (~tri@ool-18bbef1a.static.optonline.net) |
| 2024-05-01 17:45:35 +0200 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) |
| 2024-05-01 17:46:51 +0200 | euleritian | (~euleritia@dynamic-176-001-013-250.176.1.pool.telefonica.de) (Read error: Connection reset by peer) |
| 2024-05-01 17:47:09 +0200 | euleritian | (~euleritia@ip4d16fc38.dynamic.kabel-deutschland.de) |
| 2024-05-01 17:47:33 +0200 | wootehfoot | (~wootehfoo@user/wootehfoot) |
| 2024-05-01 17:49:27 +0200 | euleritian | (~euleritia@ip4d16fc38.dynamic.kabel-deutschland.de) (Read error: Connection reset by peer) |
| 2024-05-01 17:49:51 +0200 | tri | (~tri@ool-18bbef1a.static.optonline.net) (Ping timeout: 259 seconds) |
| 2024-05-01 17:50:22 +0200 | euleritian | (~euleritia@ip4d16fc38.dynamic.kabel-deutschland.de) |
| 2024-05-01 17:52:48 +0200 | zer0bitz | (~zer0bitz@user/zer0bitz) (Quit: https://zer0bitz.dy.fi) |
| 2024-05-01 17:55:45 +0200 | sawilagar | (~sawilagar@user/sawilagar) (Ping timeout: 245 seconds) |
| 2024-05-01 18:06:39 +0200 | euleritian | (~euleritia@ip4d16fc38.dynamic.kabel-deutschland.de) (Ping timeout: 260 seconds) |
| 2024-05-01 18:07:23 +0200 | euleritian | (~euleritia@dynamic-176-001-013-250.176.1.pool.telefonica.de) |
| 2024-05-01 18:14:36 +0200 | euleritian | (~euleritia@dynamic-176-001-013-250.176.1.pool.telefonica.de) (Read error: Connection reset by peer) |
| 2024-05-01 18:14:57 +0200 | euleritian | (~euleritia@ip4d16fc38.dynamic.kabel-deutschland.de) |
| 2024-05-01 18:15:21 +0200 | machinedgod | (~machinedg@d173-183-246-216.abhsia.telus.net) (Ping timeout: 268 seconds) |
| 2024-05-01 18:15:48 +0200 | zer0bitz | (~zer0bitz@user/zer0bitz) |
| 2024-05-01 18:17:45 +0200 | tri | (~tri@ool-18bbef1a.static.optonline.net) |
| 2024-05-01 18:20:06 +0200 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: Textual IRC Client: www.textualapp.com) |
| 2024-05-01 18:20:40 +0200 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) |
| 2024-05-01 18:20:47 +0200 | euleritian | (~euleritia@ip4d16fc38.dynamic.kabel-deutschland.de) (Read error: Connection reset by peer) |
| 2024-05-01 18:20:53 +0200 | euleritian | (~euleritia@dynamic-176-001-013-250.176.1.pool.telefonica.de) |
| 2024-05-01 18:21:14 +0200 | euleritian | (~euleritia@dynamic-176-001-013-250.176.1.pool.telefonica.de) (Read error: Connection reset by peer) |
| 2024-05-01 18:21:32 +0200 | euleritian | (~euleritia@ip4d16fc38.dynamic.kabel-deutschland.de) |
| 2024-05-01 18:21:38 +0200 | fireking04 | (~karl@112.206.68.79) |
| 2024-05-01 18:21:41 +0200 | tri | (~tri@ool-18bbef1a.static.optonline.net) (Ping timeout: 240 seconds) |
| 2024-05-01 18:24:55 +0200 | arkeet | (~arkeet@moriya.ca) (Quit: ZNC 1.8.2 - https://znc.in) |
| 2024-05-01 18:25:11 +0200 | arkeet | (~arkeet@moriya.ca) |
| 2024-05-01 18:26:38 +0200 | fireking04 | (~karl@112.206.68.79) (Remote host closed the connection) |
| 2024-05-01 18:28:37 +0200 | euleritian | (~euleritia@ip4d16fc38.dynamic.kabel-deutschland.de) (Read error: Connection reset by peer) |
| 2024-05-01 18:28:47 +0200 | euleritian | (~euleritia@dynamic-176-001-013-250.176.1.pool.telefonica.de) |
| 2024-05-01 18:29:07 +0200 | euleritian | (~euleritia@dynamic-176-001-013-250.176.1.pool.telefonica.de) (Read error: Connection reset by peer) |
| 2024-05-01 18:29:36 +0200 | euleritian | (~euleritia@ip4d16fc38.dynamic.kabel-deutschland.de) |
| 2024-05-01 18:36:29 +0200 | euleritian | (~euleritia@ip4d16fc38.dynamic.kabel-deutschland.de) (Read error: Connection reset by peer) |
| 2024-05-01 18:37:07 +0200 | euleritian | (~euleritia@ip4d16fc38.dynamic.kabel-deutschland.de) |
| 2024-05-01 18:43:05 +0200 | yin | (~yin@user/zero) |
| 2024-05-01 18:43:40 +0200 | <yin> | /reconnect |
| 2024-05-01 18:44:02 +0200 | yin | (~yin@user/zero) (Client Quit) |
| 2024-05-01 18:44:16 +0200 | yin | (~yin@user/zero) |
| 2024-05-01 18:47:21 +0200 | target_i | (~target_i@user/target-i/x-6023099) |
| 2024-05-01 18:48:49 +0200 | mima | (~mmh@aftr-62-216-211-127.dynamic.mnet-online.de) |
| 2024-05-01 18:49:04 +0200 | tzh | (~tzh@c-73-164-206-160.hsd1.or.comcast.net) |
| 2024-05-01 18:50:06 +0200 | euleritian | (~euleritia@ip4d16fc38.dynamic.kabel-deutschland.de) (Remote host closed the connection) |
| 2024-05-01 18:50:34 +0200 | euleritian | (~euleritia@ip4d16fc38.dynamic.kabel-deutschland.de) |
| 2024-05-01 18:55:21 +0200 | sord937 | (~sord937@gateway/tor-sasl/sord937) (Quit: sord937) |
| 2024-05-01 18:56:00 +0200 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 2024-05-01 18:59:40 +0200 | danza | (~francesco@151.57.139.226) |
| 2024-05-01 19:03:16 +0200 | gaff | (~gaff@49.207.212.165) |
| 2024-05-01 19:04:11 +0200 | euleritian | (~euleritia@ip4d16fc38.dynamic.kabel-deutschland.de) (Remote host closed the connection) |
| 2024-05-01 19:04:55 +0200 | euleritian | (~euleritia@ip4d16fc38.dynamic.kabel-deutschland.de) |
| 2024-05-01 19:05:08 +0200 | euleritian | (~euleritia@ip4d16fc38.dynamic.kabel-deutschland.de) (Read error: Connection reset by peer) |
| 2024-05-01 19:05:32 +0200 | euleritian | (~euleritia@ip4d16fc38.dynamic.kabel-deutschland.de) |
| 2024-05-01 19:05:38 +0200 | <gaff> | I have some code here https://goonlinetools.com/snapshot/code/#r7dkw4j84woahyak9mbns5 that has 2 ways to define Applicative instance for EitherT. I would like to know if there is any difference between the two definitions for <*>. |
| 2024-05-01 19:07:32 +0200 | hseg | (~gesh@77.137.75.224) |
| 2024-05-01 19:07:59 +0200 | <hseg> | Using stack with allow-newer, how can I get stack to dump the build plan it computed? |
| 2024-05-01 19:09:42 +0200 | <gaff> | Appreciate any help. |
| 2024-05-01 19:16:22 +0200 | danza | (~francesco@151.57.139.226) (Ping timeout: 255 seconds) |
| 2024-05-01 19:19:00 +0200 | danza | (~francesco@151.57.139.226) |
| 2024-05-01 19:20:51 +0200 | mima | (~mmh@aftr-62-216-211-127.dynamic.mnet-online.de) (Ping timeout: 255 seconds) |
| 2024-05-01 19:22:55 +0200 | <mauke> | gaff: I think it would depend on how >>= and <*> are defined for m |
| 2024-05-01 19:25:35 +0200 | <gaff> | mauke: I am not clear why you are saying so. In any case, let us assume `m` is `StateT s Identity`. |
| 2024-05-01 19:26:24 +0200 | danza | (~francesco@151.57.139.226) (Remote host closed the connection) |
| 2024-05-01 19:28:27 +0200 | k`` | (~k``@152.1.137.158) |
| 2024-05-01 19:28:31 +0200 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) |
| 2024-05-01 19:29:18 +0200 | <k``> | Is there any particular reason that `Data.Bits.shiftR` is undefined for shifts greater than `bitSize`, but `Data.Bits.shiftL` is not? |
| 2024-05-01 19:29:52 +0200 | euleritian | (~euleritia@ip4d16fc38.dynamic.kabel-deutschland.de) (Ping timeout: 255 seconds) |
| 2024-05-01 19:30:15 +0200 | euleritian | (~euleritia@dynamic-176-001-013-250.176.1.pool.telefonica.de) |
| 2024-05-01 19:33:04 +0200 | <geekosaur> | whether it's meaningful depends on the type. consider `Integer` |
| 2024-05-01 19:33:49 +0200 | <k``> | It's not relevant to `Integer`. |
| 2024-05-01 19:33:49 +0200 | <geekosaur> | also, signed vs. unsigned occurs to me as a potential problem, but I haven't looked to see if it's relevant |
| 2024-05-01 19:34:53 +0200 | <k``> | (I assume that when it describes comparing things to `bitSize`, it means only for types where `bitSize` is a nonbottom, nonnegative value.) |
| 2024-05-01 19:34:55 +0200 | hseg | (~gesh@77.137.75.224) (Ping timeout: 246 seconds) |
| 2024-05-01 19:38:10 +0200 | <geekosaur> | I could also see it depending on ISA: whether shift-right is logical (0 shifts in) or arithmetic (carry bit shifts in) |
| 2024-05-01 19:40:22 +0200 | euleritian | (~euleritia@dynamic-176-001-013-250.176.1.pool.telefonica.de) (Read error: Connection reset by peer) |
| 2024-05-01 19:40:39 +0200 | euleritian | (~euleritia@ip4d16fc38.dynamic.kabel-deutschland.de) |
| 2024-05-01 19:42:10 +0200 | <lyxia> | gaff: the second either always runs the two computations |
| 2024-05-01 19:43:34 +0200 | <lyxia> | gaff: let m = EitherT (modify (+ 1) >> pure (Left ())) :: EitherT () (State Int) () in m *> m |
| 2024-05-01 19:44:35 +0200 | <geekosaur> | sorry, that'd be per bit. I wonder if some ISA simply rejects shifts > bitSize |
| 2024-05-01 19:44:51 +0200 | <geekosaur> | (i.e. traps) |
| 2024-05-01 19:44:53 +0200 | <Franciman> | i miss haskell's syntax T.T |
| 2024-05-01 19:45:06 +0200 | <Franciman> | ocaml's one is a pain sometimes |
| 2024-05-01 19:46:39 +0200 | <gaff> | lyxia: Not sure what you are saying there. |
| 2024-05-01 19:52:21 +0200 | Axman6 | (~Axman6@user/axman6) (Ping timeout: 258 seconds) |
| 2024-05-01 19:52:46 +0200 | Axman6 | (~Axman6@user/axman6) |
| 2024-05-01 19:53:02 +0200 | Bynbo7 | (~Axman6@user/axman6) (Ping timeout: 244 seconds) |
| 2024-05-01 19:53:03 +0200 | <geekosaur> | "Also, Intel's manual[1] states that the results are undefined when cnt is greater than the operand size, but at least for 32- and 64-bit data sizes it has been observed that shift operations are performed by (cnt mod n), with n being the data size." |
| 2024-05-01 19:53:08 +0200 | Axma89310 | (~Axman6@user/axman6) |
| 2024-05-01 19:54:10 +0200 | <geekosaur> | so yeh, it comes down to the ISA |
| 2024-05-01 19:54:54 +0200 | <geekosaur> | k`` ^^ |
| 2024-05-01 19:57:37 +0200 | justsomeguy | (~justsomeg@user/justsomeguy) (Ping timeout: 272 seconds) |
| 2024-05-01 19:58:04 +0200 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 2024-05-01 19:59:48 +0200 | justsomeguy | (~justsomeg@user/justsomeguy) |
| 2024-05-01 20:04:02 +0200 | hseg | (~gesh@77.137.75.224) |
| 2024-05-01 20:05:34 +0200 | gaff | (~gaff@49.207.212.165) () |
| 2024-05-01 20:05:51 +0200 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) |
| 2024-05-01 20:11:29 +0200 | <justsomeguy> | What do you guys think of this monad video: https://www.youtube.com/watch?v=C2w45qRc3aU ? |
| 2024-05-01 20:12:31 +0200 | <ncf> | i'm sure it's excellent since it starts with "the absolute best" |
| 2024-05-01 20:13:20 +0200 | peterbecich | (~Thunderbi@syn-047-229-123-186.res.spectrum.com) |
| 2024-05-01 20:17:40 +0200 | <monochrom> | How long is it? |
| 2024-05-01 20:20:48 +0200 | <dolio> | 15 minutes |
| 2024-05-01 20:21:52 +0200 | mrmr1553343 | (~mrmr@user/mrmr) (Ping timeout: 256 seconds) |
| 2024-05-01 20:24:17 +0200 | <probie> | I think this is a better monad video https://www.youtube.com/watch?v=dQw4w9WgXcQ |
| 2024-05-01 20:24:55 +0200 | <dolio> | Seconded. |
| 2024-05-01 20:24:57 +0200 | <k``> | Seems like the processor issues make sense for `unsafeShiftR`, but maybe not `shiftR`. And the inconsistency between R and L is still unexplained... |
| 2024-05-01 20:27:19 +0200 | mrmr1553343 | (~mrmr@user/mrmr) |
| 2024-05-01 20:29:27 +0200 | <monochrom> | Rick Astley actually has his own youtube channel and posts his official MVs. I be damned. |
| 2024-05-01 20:29:58 +0200 | <c_wraith> | he's even released new stuff recently. and it's quite good. |
| 2024-05-01 20:30:00 +0200 | danza | (~francesco@151.19.252.90) |
| 2024-05-01 20:30:52 +0200 | <ncf> | i knew he was never gonna let me down |
| 2024-05-01 20:30:54 +0200 | <geekosaur> | the docs look reversed for unsafeShiftR vs. shiftR (compare shiftL) |
| 2024-05-01 20:32:46 +0200 | <k``> | Oh wow. Looks like it's a documentation issue... |
| 2024-05-01 20:33:53 +0200 | justsomeguy | (~justsomeg@user/justsomeguy) (Quit: WeeChat 3.6) |
| 2024-05-01 20:34:23 +0200 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 2024-05-01 20:35:55 +0200 | <k``> | > shiftL 1 64 :: Word64 |
| 2024-05-01 20:35:56 +0200 | <lambdabot> | 0 |
| 2024-05-01 20:36:20 +0200 | <k``> | > shiftL 1 64 :: Int64 |
| 2024-05-01 20:36:21 +0200 | <lambdabot> | 0 |
| 2024-05-01 20:36:53 +0200 | <k``> | shiftL 1 128 :: Int |
| 2024-05-01 20:37:16 +0200 | <k``> | > shiftL 1 128 :: Int -- Simon says |
| 2024-05-01 20:37:17 +0200 | <lambdabot> | 0 |
| 2024-05-01 20:37:32 +0200 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) |
| 2024-05-01 20:37:37 +0200 | <k``> | > shiftR 1 128 :: Int |
| 2024-05-01 20:37:38 +0200 | <lambdabot> | 0 |
| 2024-05-01 20:38:03 +0200 | <k``> | > bit 128 :: Int |
| 2024-05-01 20:38:05 +0200 | <lambdabot> | 0 |
| 2024-05-01 20:38:12 +0200 | <k``> | Cool. |
| 2024-05-01 20:39:23 +0200 | dfip^ | (~cd@c-98-242-74-66.hsd1.ga.comcast.net) (Remote host closed the connection) |
| 2024-05-01 20:40:53 +0200 | peterbecich | (~Thunderbi@syn-047-229-123-186.res.spectrum.com) (Ping timeout: 268 seconds) |
| 2024-05-01 20:50:16 +0200 | euleritian | (~euleritia@ip4d16fc38.dynamic.kabel-deutschland.de) (Read error: Connection reset by peer) |
| 2024-05-01 20:51:07 +0200 | euleritian | (~euleritia@ip4d16fc38.dynamic.kabel-deutschland.de) |
| 2024-05-01 20:52:32 +0200 | danza | (~francesco@151.19.252.90) (Ping timeout: 260 seconds) |
| 2024-05-01 20:52:32 +0200 | euleritian | (~euleritia@ip4d16fc38.dynamic.kabel-deutschland.de) (Read error: Connection reset by peer) |
| 2024-05-01 20:52:57 +0200 | euleritian | (~euleritia@ip4d16fc38.dynamic.kabel-deutschland.de) |
| 2024-05-01 21:00:51 +0200 | michalz | (~michalz@185.246.207.218) |
| 2024-05-01 21:02:40 +0200 | michalz | (~michalz@185.246.207.218) (Client Quit) |
| 2024-05-01 21:05:43 +0200 | michalz | (~michalz@185.246.207.218) |
| 2024-05-01 21:07:11 +0200 | michalz | (~michalz@185.246.207.218) (Client Quit) |
| 2024-05-01 21:09:15 +0200 | emmanuelux | (~emmanuelu@user/emmanuelux) |
| 2024-05-01 21:09:46 +0200 | michalz | (~michalz@185.246.207.200) |
| 2024-05-01 21:11:00 +0200 | madeleine-sydney | (~madeleine@c-76-155-235-153.hsd1.co.comcast.net) |
| 2024-05-01 21:13:34 +0200 | malte | (~malte@mal.tc) (Remote host closed the connection) |
| 2024-05-01 21:14:12 +0200 | tessd | (~test@evw199.neoplus.adsl.tpnet.pl) |
| 2024-05-01 21:14:44 +0200 | malte | (~malte@mal.tc) |
| 2024-05-01 21:34:02 +0200 | Batzy | (~quassel@user/batzy) |
| 2024-05-01 21:35:41 +0200 | Guest67 | (~Guest67@129.170.197.127) |
| 2024-05-01 21:38:12 +0200 | <Guest67> | Could anyone help me understand why this code doesn’t work/what the correct way of achieving this sort of functionality is? The type error lies with the parameter x in goo, when I left-arrow bind it to ref. |
| 2024-05-01 21:38:12 +0200 | <Guest67> | x :: ST s (STRef s [Int]) |
| 2024-05-01 21:38:13 +0200 | <Guest67> | x = newSTRef $ [1..10] |
| 2024-05-01 21:38:13 +0200 | <Guest67> | foo :: STRef s [Int] -> ST s () |
| 2024-05-01 21:38:14 +0200 | <Guest67> | foo ref = modifySTRef ref (0 :) |
| 2024-05-01 21:38:14 +0200 | <Guest67> | goo :: ST s (STRef s [Int]) -> [Int] |
| 2024-05-01 21:38:15 +0200 | <Guest67> | goo x = runST $ do |
| 2024-05-01 21:38:15 +0200 | <Guest67> | ref <- x — type error here |
| 2024-05-01 21:38:16 +0200 | <Guest67> | foo ref |
| 2024-05-01 21:38:16 +0200 | <Guest67> | readSTRef ref |
| 2024-05-01 21:38:40 +0200 | <Guest67> | In foo, that's not supposed to be a smiley face, it's supposed to be "(0 : )" |
| 2024-05-01 21:39:58 +0200 | <mauke> | goo's type looks sus |
| 2024-05-01 21:40:14 +0200 | <mauke> | :t runST |
| 2024-05-01 21:40:15 +0200 | <lambdabot> | (forall s. ST s a) -> a |
| 2024-05-01 21:40:37 +0200 | <mauke> | runST requires its argument to be fully polymorphic in s |
| 2024-05-01 21:40:46 +0200 | <mauke> | but goo does not |
| 2024-05-01 21:40:57 +0200 | <Guest67> | Does readSTRef ref not return a value that's fully polymorphic in s? |
| 2024-05-01 21:41:06 +0200 | <mauke> | :t readSTRef |
| 2024-05-01 21:41:07 +0200 | <lambdabot> | STRef s a -> ST s a |
| 2024-05-01 21:41:11 +0200 | <mauke> | depends |
| 2024-05-01 21:41:22 +0200 | <mauke> | readSTRef has no special requirements on s |
| 2024-05-01 21:41:36 +0200 | <mauke> | it just passes through whatever s it gets |
| 2024-05-01 21:42:06 +0200 | <mauke> | the way goo is declared, the caller of goo gets to choose an 's' |
| 2024-05-01 21:42:41 +0200 | <monochrom> | If you want an elementary answer, goo should not take that parameter. |
| 2024-05-01 21:43:00 +0200 | <mauke> | that is, there could be some specific type T and someone could create a value of type ST T (STRef T [Int]) and pass it to goo |
| 2024-05-01 21:43:20 +0200 | <mauke> | and that's not valid as an argument to runST |
| 2024-05-01 21:43:22 +0200 | <monochrom> | If you want an advanced answer, if you really want goo to take that parameter, then "goo :: (forall s. ST s (STRef s [Int])) -> [Int]" |
| 2024-05-01 21:43:42 +0200 | <monochrom> | I don't have time to further explain the advanced answer if you don't understand it. |
| 2024-05-01 21:44:29 +0200 | AlexNoo_ | (~AlexNoo@94.233.240.47) |
| 2024-05-01 21:44:29 +0200 | AlexNoo_ | (~AlexNoo@94.233.240.47) (Client Quit) |
| 2024-05-01 21:44:31 +0200 | <mauke> | ^ monochrom's code basically says: "you don't get to choose an s; you must give me a polymorphic value that works with all possible choices of s" |
| 2024-05-01 21:46:55 +0200 | noumenon | (~noumenon@113.51-175-156.customer.lyse.net) |
| 2024-05-01 21:49:58 +0200 | <shapr> | hackage codebase is kinda rough |
| 2024-05-01 21:50:11 +0200 | <Guest67> | Thanks. That makes sense in a vacuum, but it kind of conflicts with my understand of why newSTRef [1..10] returns something of type ST s (STRef s [Int]) to begin with. I thought the whole point of doing that is that it forces the type variable s to become "rigid", so the variable x is no longer a polymorphic value that works with all choices of |
| 2024-05-01 21:50:12 +0200 | <Guest67> | it. But it turns out that their suggestion works, and I can apply goo to x |
| 2024-05-01 21:50:30 +0200 | <monochrom> | Here is another elementary answer. goo can take that parameter, but don't call runST. goo :: ST s (STRef s [Int]) -> ST s [Int]. Have someone else write "runST (goo x)". |
| 2024-05-01 21:52:13 +0200 | <monochrom> | s/conflicts/confirms/ . The erroneous code is precisely a victim of a rigid s. |
| 2024-05-01 21:53:41 +0200 | <mauke> | newSTRef just links up the STRef with its surrounding context (that is, it forces the two 's' parameters to be the same) |
| 2024-05-01 21:54:06 +0200 | <mauke> | 's' can still be arbitrary |
| 2024-05-01 21:55:43 +0200 | <Guest67> | But if that's the case, why can't I do runST $ newSTRef [1..10] |
| 2024-05-01 21:56:42 +0200 | <mauke> | that one I don't have a good understanding/explanation of |
| 2024-05-01 21:56:50 +0200 | <monochrom> | Before I answer that, I ask back why would anyone want that to be legal? |
| 2024-05-01 21:56:54 +0200 | <mauke> | but the type of runST is (forall s. ST s a) -> a |
| 2024-05-01 21:57:01 +0200 | <ncf> | s would escape its scope |
| 2024-05-01 21:57:07 +0200 | <geekosaur> | because outside the runST, s has no type |
| 2024-05-01 21:57:10 +0200 | <mauke> | and in that example, the 'a' would have to contain an 's' somehow |
| 2024-05-01 21:57:28 +0200 | <mauke> | because we're trying to return a result of type STRef s [Int] |
| 2024-05-01 21:57:29 +0200 | <geekosaur> | but newSTRef oproduces a value whose type includes an s |
| 2024-05-01 21:57:51 +0200 | <monochrom> | The purpose of runST is to never leak out mutable variables. So why should "runST (make a mutable variable and return it)" be legal? |
| 2024-05-01 21:58:14 +0200 | <monochrom> | The rank-2 type is designed to ban that. |
| 2024-05-01 21:58:32 +0200 | <Guest67> | I don't want it to be legal, I'm moreso curious about why it is the case that it prevents that from happening |
| 2024-05-01 21:58:46 +0200 | <geekosaur> | okay, let's go back to that forall |
| 2024-05-01 21:58:50 +0200 | <geekosaur> | it does two things |
| 2024-05-01 21:59:08 +0200 | <geekosaur> | the first one we already discussed: "must accept any type for s" |
| 2024-05-01 21:59:26 +0200 | <geekosaur> | the second is that it delimits where s is meaningful: inside the parentheses where the forall occurs |
| 2024-05-01 21:59:35 +0200 | <geekosaur> | outside those parenthses, s doesn't exist |
| 2024-05-01 22:01:23 +0200 | <mauke> | from a "who gets to choose" point of view, the caller of runST gets to choose 'a', but 's' has to be left polymorphic (as demanded by runST) |
| 2024-05-01 22:01:42 +0200 | <mauke> | this causes a conflict if 'a' includes 's' |
| 2024-05-01 22:02:03 +0200 | <mauke> | (like if 'a = STRef s [Int]') |
| 2024-05-01 22:02:23 +0200 | tessd | (~test@evw199.neoplus.adsl.tpnet.pl) (Remote host closed the connection) |
| 2024-05-01 22:02:54 +0200 | <mauke> | if the caller gets to choose 'a', it implicitly also chooses 's', and that's illegal |
| 2024-05-01 22:04:03 +0200 | <Guest67> | So that part makes sense. But then why can I apply goo, which now requires s to be fully polymorphic, to the result of the newSTRef? I'm implicitly choosing 's' by choosing 'a', so the result is no longer fully polymorphic in s right? |
| 2024-05-01 22:04:57 +0200 | <monochrom> | Which version of goo now? |
| 2024-05-01 22:05:00 +0200 | <mauke> | in your original code, a = [Int] |
| 2024-05-01 22:05:34 +0200 | <Guest67> | The new one, where the type signature is (forall s. ST s (STRef s [Int])) -> [Int] |
| 2024-05-01 22:05:45 +0200 | sawilagar | (~sawilagar@user/sawilagar) |
| 2024-05-01 22:06:36 +0200 | <mauke> | that still uses runST at type (forall s. ST s [Int]) -> [Int] |
| 2024-05-01 22:07:15 +0200 | <mauke> | because the action you're passing to runST doesn't try to return an STRef. it just returns a list |
| 2024-05-01 22:08:49 +0200 | <monochrom> | "(forall s. ST s (STRef s [Int]))" stays fully polymorphic. I thought you knew that's what the "forall" is doing. |
| 2024-05-01 22:09:11 +0200 | _ht | (~Thunderbi@28-52-174-82.ftth.glasoperator.nl) (Remote host closed the connection) |
| 2024-05-01 22:10:10 +0200 | <monochrom> | The words "the result of the newSTRef" is ambiguous. The wrong interpretation leads to the wrong conclusion. |
| 2024-05-01 22:10:18 +0200 | <lyxia> | Instead of thinking in terms of rigid/"polymorphic" type variables, think in terms of input/output. newSTRef :: forall s. a -> ST s (STRef s a) takes a type s as an input. All of the ST functions except runST take s as an input. runST takes a function which takes a type s as an input, which means that runST (somehow) produces an s to be able to call that function. |
| 2024-05-01 22:11:00 +0200 | <monochrom> | Yeah, that. |
| 2024-05-01 22:12:28 +0200 | <monochrom> | Maybe I should teach that in my course too. (Currently I teach "caller chooses", "callee chooses".) |
| 2024-05-01 22:13:27 +0200 | <monochrom> | (OK I am not teaching rank-2 types yet, so "caller chooses" has sufficed so far.) |
| 2024-05-01 22:15:08 +0200 | Luj | (~Luj@2a01:e0a:5f9:9681:627d:73c1:73b3:2561) (Quit: Ping timeout (120 seconds)) |
| 2024-05-01 22:15:26 +0200 | Luj | (~Luj@2a01:e0a:5f9:9681:d999:72f4:b788:a2bb) |
| 2024-05-01 22:16:01 +0200 | tri | (~tri@ool-18bbef1a.static.optonline.net) |
| 2024-05-01 22:16:24 +0200 | demon-cat | (~demon-cat@dund-15-b2-v4wan-169642-cust1347.vm6.cable.virginm.net) |
| 2024-05-01 22:20:23 +0200 | tri | (~tri@ool-18bbef1a.static.optonline.net) (Ping timeout: 264 seconds) |
| 2024-05-01 22:23:01 +0200 | SteelBlueSilk | (~SteelBlue@c-98-42-249-36.hsd1.ca.comcast.net) |
| 2024-05-01 22:23:01 +0200 | SteelBlueSilk | (~SteelBlue@c-98-42-249-36.hsd1.ca.comcast.net) (Changing host) |
| 2024-05-01 22:23:01 +0200 | SteelBlueSilk | (~SteelBlue@user/SteelBlueSilk) |
| 2024-05-01 22:25:21 +0200 | sawilagar | (~sawilagar@user/sawilagar) (Quit: Leaving) |
| 2024-05-01 22:28:22 +0200 | k`` | (~k``@152.1.137.158) (Remote host closed the connection) |
| 2024-05-01 22:31:27 +0200 | madeleine-sydney | (~madeleine@c-76-155-235-153.hsd1.co.comcast.net) (Quit: Konversation terminated!) |
| 2024-05-01 22:36:54 +0200 | sawilagar | (~sawilagar@user/sawilagar) |
| 2024-05-01 22:39:05 +0200 | yin | (~yin@user/zero) (Ping timeout: 256 seconds) |
| 2024-05-01 22:39:34 +0200 | michalz | (~michalz@185.246.207.200) (Quit: ZNC 1.8.2 - https://znc.in) |
| 2024-05-01 22:42:12 +0200 | Square | (~Square@user/square) |
| 2024-05-01 22:43:40 +0200 | Guest67 | (~Guest67@129.170.197.127) (Ping timeout: 250 seconds) |
| 2024-05-01 22:46:41 +0200 | waleee | (~waleee@h-176-10-144-38.NA.cust.bahnhof.se) |
| 2024-05-01 22:46:58 +0200 | tri | (~tri@ool-18bbef1a.static.optonline.net) |
| 2024-05-01 22:46:58 +0200 | xdminsy | (~xdminsy@117.147.70.233) (Read error: Connection reset by peer) |
| 2024-05-01 22:47:08 +0200 | manwithluck | (manwithluc@gateway/vpn/protonvpn/manwithluck) (Read error: Connection reset by peer) |
| 2024-05-01 22:47:35 +0200 | manwithluck | (manwithluc@gateway/vpn/protonvpn/manwithluck) |
| 2024-05-01 22:49:01 +0200 | peterbecich | (~Thunderbi@syn-047-229-123-186.res.spectrum.com) |
| 2024-05-01 22:51:28 +0200 | tri | (~tri@ool-18bbef1a.static.optonline.net) (Ping timeout: 256 seconds) |
| 2024-05-01 22:54:21 +0200 | takuan | (~takuan@178-116-218-225.access.telenet.be) (Ping timeout: 252 seconds) |
| 2024-05-01 23:00:14 +0200 | yin | (~yin@user/zero) |
| 2024-05-01 23:07:05 +0200 | xdminsy | (~xdminsy@117.147.70.233) |
| 2024-05-01 23:09:31 +0200 | hseg | (~gesh@77.137.75.224) (Ping timeout: 260 seconds) |