2024/05/01

2024-05-01 00:01:18 +0200 <mauke> ich begreif es auch nicht
2024-05-01 00:04:16 +0200Square3(~Square4@user/square)
2024-05-01 00:07:15 +0200Square(~Square@user/square) (Ping timeout: 260 seconds)
2024-05-01 00:08:24 +0200masterbuilder(~quassel@user/masterbuilder) (Ping timeout: 260 seconds)
2024-05-01 00:08:34 +0200masterbuilder(~quassel@user/masterbuilder)
2024-05-01 00:10:55 +0200barak(~barak@2a0d:6fc2:68c1:7200:3cf2:a87d:a02b:3e21) (Quit: WeeChat 4.2.2)
2024-05-01 00:11:08 +0200phma(~phma@2001:5b0:2172:9258:5c6c:8366:4239:d1fd) (Read error: Connection reset by peer)
2024-05-01 00:13:16 +0200madeleine-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 +0200waldo(~waldo@user/waldo)
2024-05-01 00:20:49 +0200phma(~phma@host-67-44-208-133.hnremote.net)
2024-05-01 00:46:06 +0200Nixkernal(~Nixkernal@240.17.194.178.dynamic.wline.res.cust.swisscom.ch) (Ping timeout: 252 seconds)
2024-05-01 00:46:26 +0200peterbecich(~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 +0200sord937(~sord937@gateway/tor-sasl/sord937) (Quit: sord937)
2024-05-01 01:10:16 +0200target_i(~target_i@user/target-i/x-6023099) (Quit: leaving)
2024-05-01 01:10:28 +0200acidjnk(~acidjnk@p200300d6e714dc3178eb6b7df1157d0e.dip0.t-ipconnect.de) (Ping timeout: 260 seconds)
2024-05-01 01:11:02 +0200wroathe(~wroathe@user/wroathe)
2024-05-01 01:12:10 +0200xff0x(~xff0x@softbank219059019218.bbtec.net)
2024-05-01 01:19:17 +0200peterbecich(~Thunderbi@syn-047-229-123-186.res.spectrum.com) (Ping timeout: 240 seconds)
2024-05-01 01:30:19 +0200Sgeo(~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 +0200sawilagar(~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 +0200Tuplanolla(~Tuplanoll@91-159-69-59.elisa-laajakaista.fi) (Quit: Leaving.)
2024-05-01 01:53:37 +0200wroathe(~wroathe@user/wroathe) (Ping timeout: 268 seconds)
2024-05-01 01:58:08 +0200waldo(~waldo@user/waldo) (Quit: waldo)
2024-05-01 02:03:32 +0200lol_jcarpenter2
2024-05-01 02:04:01 +0200gmg(~user@user/gehmehgeh) (Quit: Leaving)
2024-05-01 02:04:38 +0200peterbecich(~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 +0200mima(~mmh@aftr-62-216-211-165.dynamic.mnet-online.de) (Ping timeout: 260 seconds)
2024-05-01 02:43:47 +0200wroathe(~wroathe@24-152-179-157.fttp.usinternet.com)
2024-05-01 02:43:47 +0200wroathe(~wroathe@24-152-179-157.fttp.usinternet.com) (Changing host)
2024-05-01 02:43:47 +0200wroathe(~wroathe@user/wroathe)
2024-05-01 02:44:57 +0200whatsupdoc(uid509081@id-509081.hampstead.irccloud.com)
2024-05-01 02:47:05 +0200xff0x(~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 +0200talismanick(~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 +0200pointlessslippe1(~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 +0200fryguybob(~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 +0200waldo(~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 +0200otto_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 +0200otto_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 +0200skidoesn'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 +0200waleee(~waleee@h-176-10-144-38.NA.cust.bahnhof.se) (Quit: WeeChat 4.1.2)
2024-05-01 03:46:30 +0200ski. 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 +0200wroathe(~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 +0200skionly 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 +0200Katarushisu1(~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 +0200Katarushisu1(~Katarushi@finc-20-b2-v4wan-169598-cust1799.vm7.cable.virginm.net)
2024-05-01 04:17:42 +0200Axman4765(~Axman6@user/axman6)
2024-05-01 04:17:49 +0200Axman4765Bynbo7
2024-05-01 04:21:27 +0200cashew(~cashewsta@65.17.175.150)
2024-05-01 04:27:50 +0200td_(~td@i53870902.versanet.de) (Ping timeout: 245 seconds)
2024-05-01 04:29:44 +0200td_(~td@i53870927.versanet.de)
2024-05-01 04:42:35 +0200Square3(~Square4@user/square) (Ping timeout: 268 seconds)
2024-05-01 04:43:21 +0200gues54302(~username@3.184.70.115.static.exetel.com.au)
2024-05-01 04:43:24 +0200terrorjack(~terrorjac@2a01:4f8:c17:87f8::) (Quit: The Lounge - https://thelounge.chat)
2024-05-01 04:45:19 +0200terrorjack(~terrorjac@2a01:4f8:c17:87f8::)
2024-05-01 04:45:22 +0200peterbecich(~Thunderbi@syn-047-229-123-186.res.spectrum.com) (Ping timeout: 268 seconds)
2024-05-01 04:48:03 +0200waldo(~waldo@user/waldo) (Quit: waldo)
2024-05-01 04:50:10 +0200Bynbo7(~Axman6@user/axman6) (Remote host closed the connection)
2024-05-01 04:51:31 +0200demon-cat(~demon-cat@dund-15-b2-v4wan-169642-cust1347.vm6.cable.virginm.net) (Remote host closed the connection)
2024-05-01 04:51:55 +0200demon-cat(~demon-cat@dund-15-b2-v4wan-169642-cust1347.vm6.cable.virginm.net)
2024-05-01 04:52:49 +0200ddellacosta(~ddellacos@ool-44c73d29.dyn.optonline.net)
2024-05-01 04:52:51 +0200gues54302(~username@3.184.70.115.static.exetel.com.au) (Ping timeout: 260 seconds)
2024-05-01 04:58:09 +0200tri(~tri@ool-18bc2e74.dyn.optonline.net)
2024-05-01 05:02:59 +0200tri(~tri@ool-18bc2e74.dyn.optonline.net) (Ping timeout: 264 seconds)
2024-05-01 05:05:58 +0200madeleine-sydney(~madeleine@c-76-155-235-153.hsd1.co.comcast.net)
2024-05-01 05:06:05 +0200aforemny_(~aforemny@i59F516CA.versanet.de) (Ping timeout: 240 seconds)
2024-05-01 05:07:14 +0200aforemny(~aforemny@2001:9e8:6cea:d00:aab5:d1b:ca3e:df36)
2024-05-01 05:40:34 +0200philopsos(~caecilius@user/philopsos)
2024-05-01 05:41:11 +0200cashew(~cashewsta@65.17.175.150) (Quit: Leaving...)
2024-05-01 05:52:53 +0200bitdex(~bitdex@gateway/tor-sasl/bitdex)
2024-05-01 05:59:56 +0200bitdex(~bitdex@gateway/tor-sasl/bitdex) (Remote host closed the connection)
2024-05-01 06:01:09 +0200bitdex(~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 +0200philopsos(~caecilius@user/philopsos) (Ping timeout: 268 seconds)
2024-05-01 06:07:22 +0200stiell_(~stiell@gateway/tor-sasl/stiell) (Remote host closed the connection)
2024-05-01 06:08:13 +0200stiell_(~stiell@gateway/tor-sasl/stiell)
2024-05-01 06:08:15 +0200machinedgod(~machinedg@d173-183-246-216.abhsia.telus.net) (Ping timeout: 245 seconds)
2024-05-01 06:17:29 +0200madeleine-sydney(~madeleine@c-76-155-235-153.hsd1.co.comcast.net) (Quit: Konversation terminated!)
2024-05-01 06:22:30 +0200tri(~tri@ool-18bc2e74.dyn.optonline.net)
2024-05-01 06:26:58 +0200peterbecich(~Thunderbi@syn-047-229-123-186.res.spectrum.com)
2024-05-01 06:37:40 +0200ChaiTRex(~ChaiTRex@user/chaitrex)
2024-05-01 06:41:39 +0200madeleine-sydney(~madeleine@c-76-155-235-153.hsd1.co.comcast.net)
2024-05-01 06:49:10 +0200philopsos(~caecilius@user/philopsos)
2024-05-01 07:00:15 +0200peterbecich(~Thunderbi@syn-047-229-123-186.res.spectrum.com) (Ping timeout: 260 seconds)
2024-05-01 07:02:56 +0200sroso(~sroso@user/SrOso)
2024-05-01 07:03:38 +0200gues45965(~username@3.184.70.115.static.exetel.com.au)
2024-05-01 07:07:26 +0200gues45965(~username@3.184.70.115.static.exetel.com.au) (Remote host closed the connection)
2024-05-01 07:09:43 +0200gues22599(~username@3.184.70.115.static.exetel.com.au)
2024-05-01 07:12:34 +0200gues96208(~username@3.184.70.115.static.exetel.com.au)
2024-05-01 07:14:21 +0200takuan(~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 +0200Axma55792(~Axman6@user/axman6)
2024-05-01 07:16:22 +0200Axma55792Bynbo7
2024-05-01 07:30:56 +0200euphores(~SASL_euph@user/euphores) (Quit: Leaving.)
2024-05-01 07:36:15 +0200tri(~tri@ool-18bc2e74.dyn.optonline.net) (Remote host closed the connection)
2024-05-01 07:36:44 +0200qqq(~qqq@92.43.167.61)
2024-05-01 07:37:30 +0200xff0x(~xff0x@softbank219059019218.bbtec.net)
2024-05-01 07:43:15 +0200 <haskellbridge> <g​eekosaur> does this help?
2024-05-01 07:46:56 +0200Sgeo(~Sgeo@user/sgeo) (Read error: Connection reset by peer)
2024-05-01 07:49:12 +0200euphores(~SASL_euph@user/euphores)
2024-05-01 08:26:50 +0200rvalue(~rvalue@user/rvalue) (Read error: Connection reset by peer)
2024-05-01 08:26:55 +0200tri(~tri@ool-18bc2e74.dyn.optonline.net)
2024-05-01 08:27:19 +0200rvalue(~rvalue@user/rvalue)
2024-05-01 08:31:15 +0200tri(~tri@ool-18bc2e74.dyn.optonline.net) (Ping timeout: 260 seconds)
2024-05-01 08:36:27 +0200raym(~ray@user/raym)
2024-05-01 08:37:49 +0200tromp(~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl)
2024-05-01 08:39:49 +0200acidjnk(~acidjnk@p200300d6e714dc53acbe2cc37902b0bc.dip0.t-ipconnect.de)
2024-05-01 08:45:00 +0200danza(~francesco@151.43.220.194)
2024-05-01 08:47:02 +0200pointlessslippe1(~pointless@212.82.82.3)
2024-05-01 08:54:55 +0200danza(~francesco@151.43.220.194) (Ping timeout: 245 seconds)
2024-05-01 08:57:03 +0200philopsos(~caecilius@user/philopsos) (Ping timeout: 272 seconds)
2024-05-01 09:00:01 +0200mikess(~mikess@user/mikess) (Ping timeout: 246 seconds)
2024-05-01 09:03:26 +0200gues22599(~username@3.184.70.115.static.exetel.com.au) (Ping timeout: 268 seconds)
2024-05-01 09:03:28 +0200gues96208(~username@3.184.70.115.static.exetel.com.au) (Ping timeout: 255 seconds)
2024-05-01 09:05:34 +0200chexum(~quassel@gateway/tor-sasl/chexum) (Remote host closed the connection)
2024-05-01 09:06:08 +0200chexum(~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 +0200gues90080(~username@ppp121-45-202-250.cbr-trn-nor-bras38.tpg.internode.on.net)
2024-05-01 09:18:22 +0200Tuplanolla(~Tuplanoll@91-159-69-59.elisa-laajakaista.fi)
2024-05-01 09:20:10 +0200tolt_(~weechat-h@li219-154.members.linode.com)
2024-05-01 09:22:00 +0200gmg(~user@user/gehmehgeh)
2024-05-01 09:22:47 +0200tolt(~weechat-h@li219-154.members.linode.com) (Ping timeout: 264 seconds)
2024-05-01 09:29:36 +0200raym(~ray@user/raym) (Quit: upgrading kernel, brb)
2024-05-01 09:32:44 +0200__monty__(~toonn@user/toonn)
2024-05-01 09:32:56 +0200tolt_tolt
2024-05-01 09:36:20 +0200tromp(~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…)
2024-05-01 09:36:57 +0200mima(~mmh@aftr-62-216-211-100.dynamic.mnet-online.de)
2024-05-01 09:54:42 +0200sord937(~sord937@gateway/tor-sasl/sord937)
2024-05-01 09:58:06 +0200econo_(uid147250@id-147250.tinside.irccloud.com) (Quit: Connection closed for inactivity)
2024-05-01 10:01:22 +0200causal(~eric@50.35.88.207) (Quit: WeeChat 4.1.1)
2024-05-01 10:09:13 +0200danza(~francesco@151.43.219.217)
2024-05-01 10:19:25 +0200tzh(~tzh@c-73-164-206-160.hsd1.or.comcast.net) (Quit: zzz)
2024-05-01 10:21:33 +0200esph(~weechat@user/esph)
2024-05-01 10:21:35 +0200talismanick(~user@2601:644:937c:ed10::ae5) (Ping timeout: 245 seconds)
2024-05-01 10:26:15 +0200danza(~francesco@151.43.219.217) (Ping timeout: 255 seconds)
2024-05-01 10:32:05 +0200hseg(~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 +0200sawilagar(~sawilagar@user/sawilagar)
2024-05-01 10:37:33 +0200oo_miguel(~Thunderbi@78-11-181-16.static.ip.netia.com.pl)
2024-05-01 10:42:43 +0200xff0x(~xff0x@softbank219059019218.bbtec.net) (Ping timeout: 268 seconds)
2024-05-01 10:43:44 +0200xff0x(~xff0x@softbank219059019218.bbtec.net)
2024-05-01 10:53:27 +0200acidjnk(~acidjnk@p200300d6e714dc53acbe2cc37902b0bc.dip0.t-ipconnect.de) (Ping timeout: 256 seconds)
2024-05-01 11:25:35 +0200jinsun(~jinsun@user/jinsun)
2024-05-01 11:26:10 +0200FinnElija(~finn_elij@user/finn-elija/x-0085643) (Remote host closed the connection)
2024-05-01 11:26:54 +0200FinnElija(~finn_elij@user/finn-elija/x-0085643)
2024-05-01 11:29:30 +0200gues90080(~username@ppp121-45-202-250.cbr-trn-nor-bras38.tpg.internode.on.net) (Ping timeout: 245 seconds)
2024-05-01 11:31:10 +0200barak(~barak@2a0d:6fc2:68c1:7200:3cf2:a87d:a02b:3e21)
2024-05-01 11:32:25 +0200xff0x(~xff0x@softbank219059019218.bbtec.net) (Ping timeout: 245 seconds)
2024-05-01 11:41:52 +0200oo_miguel1(~Thunderbi@78-11-181-16.static.ip.netia.com.pl)
2024-05-01 11:43:15 +0200oo_miguel(~Thunderbi@78-11-181-16.static.ip.netia.com.pl) (Ping timeout: 245 seconds)
2024-05-01 11:43:15 +0200oo_miguel1oo_miguel
2024-05-01 11:45:32 +0200aosync_aws
2024-05-01 11:45:48 +0200aws(~alews@141.94.77.100) (Changing host)
2024-05-01 11:45:48 +0200aws(~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 +0200L29Ah(~L29Ah@wikipedia/L29Ah) ()
2024-05-01 12:02:23 +0200hseg(~gesh@77.137.75.224) (Ping timeout: 264 seconds)
2024-05-01 12:04:04 +0200L29Ah(~L29Ah@wikipedia/L29Ah)
2024-05-01 12:08:24 +0200hseg(~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 +0200mwnaylor(~user@2601:5cf:837e:2bb0::f472) (Ping timeout: 260 seconds)
2024-05-01 12:47:25 +0200guest7621(~username@120.17.103.254)
2024-05-01 12:48:34 +0200gues51644(~username@120.17.103.254)
2024-05-01 12:49:41 +0200xff0x(~xff0x@softbank219059019218.bbtec.net)
2024-05-01 12:51:41 +0200Lord_of_Life_(~Lord@user/lord-of-life/x-2819915)
2024-05-01 12:52:07 +0200Lord_of_Life(~Lord@user/lord-of-life/x-2819915) (Ping timeout: 260 seconds)
2024-05-01 12:53:04 +0200Lord_of_Life_Lord_of_Life
2024-05-01 13:13:07 +0200gues51644(~username@120.17.103.254) (Read error: Connection reset by peer)
2024-05-01 13:13:07 +0200guest7621(~username@120.17.103.254) (Read error: Connection reset by peer)
2024-05-01 13:17:43 +0200destituion(~destituio@2a02:2121:340:2456:fffe:d0f:7737:dd1) (Ping timeout: 255 seconds)
2024-05-01 13:18:39 +0200Maxdaman1us(~Maxdamant@user/maxdamantus) (Ping timeout: 256 seconds)
2024-05-01 13:21:20 +0200L29Ah(~L29Ah@wikipedia/L29Ah) (Remote host closed the connection)
2024-05-01 13:23:45 +0200L29Ah(~L29Ah@wikipedia/L29Ah)
2024-05-01 13:23:57 +0200destituion(~destituio@2a02:2121:340:2456:fffe:d0f:7737:dd1)
2024-05-01 13:26:25 +0200raehik(~raehik@rdng-25-b2-v4wan-169990-cust1344.vm39.cable.virginm.net)
2024-05-01 13:34:20 +0200Maxdamantus(~Maxdamant@user/maxdamantus)
2024-05-01 13:35:25 +0200mei(~mei@user/mei) (Remote host closed the connection)
2024-05-01 13:36:01 +0200mei(~mei@user/mei)
2024-05-01 13:41:20 +0200acidjnk(~acidjnk@p200300d6e714dc53acbe2cc37902b0bc.dip0.t-ipconnect.de)
2024-05-01 13:44:01 +0200Square(~Square@user/square)
2024-05-01 13:45:55 +0200madeleine-sydney(~madeleine@c-76-155-235-153.hsd1.co.comcast.net) (Quit: Konversation terminated!)
2024-05-01 13:52:50 +0200mreh(~matthew@host86-160-168-68.range86-160.btcentralplus.com)
2024-05-01 13:54:30 +0200euleritian(~euleritia@77.22.252.56) (Ping timeout: 268 seconds)
2024-05-01 13:54:41 +0200euleritian(~euleritia@dynamic-176-001-013-250.176.1.pool.telefonica.de)
2024-05-01 13:55:48 +0200mreh(~matthew@host86-160-168-68.range86-160.btcentralplus.com) (Client Quit)
2024-05-01 13:58:39 +0200xff0x(~xff0x@softbank219059019218.bbtec.net) (Ping timeout: 255 seconds)
2024-05-01 13:59:09 +0200raehik(~raehik@rdng-25-b2-v4wan-169990-cust1344.vm39.cable.virginm.net) (Ping timeout: 272 seconds)
2024-05-01 14:07:51 +0200raehik(~raehik@rdng-25-b2-v4wan-169990-cust1344.vm39.cable.virginm.net)
2024-05-01 14:09:39 +0200ddellacosta(~ddellacos@ool-44c73d29.dyn.optonline.net) (Ping timeout: 252 seconds)
2024-05-01 14:11:37 +0200sroso(~sroso@user/SrOso) (Quit: Leaving :))
2024-05-01 14:21:12 +0200Xe(~cadey@perl/impostor/xe) (Ping timeout: 252 seconds)
2024-05-01 14:23:05 +0200Xe(~cadey@perl/impostor/xe)
2024-05-01 14:31:38 +0200mima(~mmh@aftr-62-216-211-100.dynamic.mnet-online.de) (Ping timeout: 252 seconds)
2024-05-01 14:32:59 +0200bitdex(~bitdex@gateway/tor-sasl/bitdex) (Quit: = "")
2024-05-01 14:37:47 +0200euleritian(~euleritia@dynamic-176-001-013-250.176.1.pool.telefonica.de) (Read error: Connection reset by peer)
2024-05-01 14:38:04 +0200euleritian(~euleritia@ip4d16fc38.dynamic.kabel-deutschland.de)
2024-05-01 14:38:05 +0200ski_(~ski@ext-1-033.eduroam.chalmers.se) (Ping timeout: 240 seconds)
2024-05-01 14:45:21 +0200Maxdamantus(~Maxdamant@user/maxdamantus) (Ping timeout: 256 seconds)
2024-05-01 14:45:35 +0200SteelBlueSilk(~SteelBlue@user/SteelBlueSilk) (Ping timeout: 264 seconds)
2024-05-01 14:46:48 +0200euleritian(~euleritia@ip4d16fc38.dynamic.kabel-deutschland.de) (Ping timeout: 255 seconds)
2024-05-01 14:47:23 +0200raehik(~raehik@rdng-25-b2-v4wan-169990-cust1344.vm39.cable.virginm.net) (Ping timeout: 264 seconds)
2024-05-01 14:48:03 +0200euleritian(~euleritia@dynamic-176-001-013-250.176.1.pool.telefonica.de)
2024-05-01 14:48:48 +0200euleritian(~euleritia@dynamic-176-001-013-250.176.1.pool.telefonica.de) (Read error: Connection reset by peer)
2024-05-01 14:49:17 +0200euleritian(~euleritia@dynamic-176-001-013-250.176.1.pool.telefonica.de)
2024-05-01 14:51:24 +0200yin(~yin@user/zero)
2024-05-01 15:05:16 +0200yin(~yin@user/zero) (Ping timeout: 255 seconds)
2024-05-01 15:09:04 +0200Square(~Square@user/square) (Ping timeout: 260 seconds)
2024-05-01 15:16:02 +0200mzschr(~mzschr@2a07-a880-4603-1035-18b5-1e9f-f698-63a6.pool6.ovpn.com)
2024-05-01 15:21:20 +0200Maxdamantus(~Maxdamant@user/maxdamantus)
2024-05-01 15:23:17 +0200demon-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 +0200dfip^(~cd@c-98-242-74-66.hsd1.ga.comcast.net)
2024-05-01 15:46:24 +0200tri(~tri@ool-18bbef1a.static.optonline.net)
2024-05-01 15:47:08 +0200mikess(~mikess@user/mikess)
2024-05-01 15:50:26 +0200hseg(~gesh@77.137.75.224) (Quit: WeeChat 4.2.2)
2024-05-01 15:50:51 +0200tri(~tri@ool-18bbef1a.static.optonline.net) (Ping timeout: 260 seconds)
2024-05-01 15:58:44 +0200fireking04(~karl@175.176.41.51)
2024-05-01 16:01:57 +0200gorignak(~gorignak@user/gorignak)
2024-05-01 16:10:22 +0200fireking04(~karl@175.176.41.51) (Read error: Connection reset by peer)
2024-05-01 16:18:29 +0200zer0bitz(~zer0bitz@user/zer0bitz) (Ping timeout: 240 seconds)
2024-05-01 16:18:35 +0200euleritian(~euleritia@dynamic-176-001-013-250.176.1.pool.telefonica.de) (Read error: Connection reset by peer)
2024-05-01 16:18:53 +0200euleritian(~euleritia@ip4d16fc38.dynamic.kabel-deutschland.de)
2024-05-01 16:19:49 +0200Teacup(~teacup@user/teacup) ()
2024-05-01 16:20:07 +0200Teacup(~teacup@user/teacup)
2024-05-01 16:21:53 +0200zer0bitz(~zer0bitz@user/zer0bitz)
2024-05-01 16:21:53 +0200paotsaq(~paotsaq@127.209.37.188.rev.vodafone.pt) (Quit: ZNC 1.9.0 - https://znc.in)
2024-05-01 16:23:23 +0200euleritian(~euleritia@ip4d16fc38.dynamic.kabel-deutschland.de) (Read error: Connection reset by peer)
2024-05-01 16:24:04 +0200euleritian(~euleritia@ip4d16fc38.dynamic.kabel-deutschland.de)
2024-05-01 16:25:10 +0200sp1ff(~user@c-24-21-45-157.hsd1.wa.comcast.net) (Read error: Connection reset by peer)
2024-05-01 16:25:23 +0200sp1ff(~user@c-24-21-45-157.hsd1.wa.comcast.net)
2024-05-01 16:29:14 +0200paotsaq(~paotsaq@127.209.37.188.rev.vodafone.pt)
2024-05-01 16:32:39 +0200machinedgod(~machinedg@d173-183-246-216.abhsia.telus.net)
2024-05-01 16:43:28 +0200euleritian(~euleritia@ip4d16fc38.dynamic.kabel-deutschland.de) (Ping timeout: 268 seconds)
2024-05-01 16:43:51 +0200euleritian(~euleritia@dynamic-176-001-013-250.176.1.pool.telefonica.de)
2024-05-01 16:45:16 +0200euleritian(~euleritia@dynamic-176-001-013-250.176.1.pool.telefonica.de) (Read error: Connection reset by peer)
2024-05-01 16:45:33 +0200euleritian(~euleritia@ip4d16fc38.dynamic.kabel-deutschland.de)
2024-05-01 16:51:08 +0200L29Ah(~L29Ah@wikipedia/L29Ah) (Read error: Connection timed out)
2024-05-01 17:09:04 +0200gorignak(~gorignak@user/gorignak) (Ping timeout: 268 seconds)
2024-05-01 17:10:52 +0200euleritian(~euleritia@ip4d16fc38.dynamic.kabel-deutschland.de) (Ping timeout: 260 seconds)
2024-05-01 17:11:23 +0200euleritian(~euleritia@dynamic-176-001-013-250.176.1.pool.telefonica.de)
2024-05-01 17:14:35 +0200L29Ah(~L29Ah@wikipedia/L29Ah)
2024-05-01 17:16:58 +0200billchenchina(~billchenc@103.118.42.229)
2024-05-01 17:17:49 +0200billchenchina(~billchenc@103.118.42.229) (Max SendQ exceeded)
2024-05-01 17:19:03 +0200euleritian(~euleritia@dynamic-176-001-013-250.176.1.pool.telefonica.de) (Read error: Connection reset by peer)
2024-05-01 17:19:31 +0200billchenchina(~billchenc@103.118.42.229)
2024-05-01 17:19:44 +0200euleritian(~euleritia@dynamic-176-001-013-250.176.1.pool.telefonica.de)
2024-05-01 17:20:21 +0200billchenchina(~billchenc@103.118.42.229) (Max SendQ exceeded)
2024-05-01 17:20:36 +0200mzschr(~mzschr@2a07-a880-4603-1035-18b5-1e9f-f698-63a6.pool6.ovpn.com) (Quit: Client closed)
2024-05-01 17:21:28 +0200billchenchina(~billchenc@103.118.42.229)
2024-05-01 17:22:22 +0200billchenchina(~billchenc@103.118.42.229) (Max SendQ exceeded)
2024-05-01 17:24:11 +0200billchenchina(~billchenc@103.118.42.229)
2024-05-01 17:24:57 +0200billchenchina(~billchenc@103.118.42.229) (Max SendQ exceeded)
2024-05-01 17:25:34 +0200billchenchina(~billchenc@103.118.42.229)
2024-05-01 17:26:27 +0200billchenchina(~billchenc@103.118.42.229) (Max SendQ exceeded)
2024-05-01 17:26:57 +0200billchenchina(~billchenc@103.118.42.229)
2024-05-01 17:27:49 +0200billchenchina(~billchenc@103.118.42.229) (Max SendQ exceeded)
2024-05-01 17:28:30 +0200billchenchina(~billchenc@103.118.42.229)
2024-05-01 17:29:05 +0200billchenchina(~billchenc@103.118.42.229) (Max SendQ exceeded)
2024-05-01 17:29:28 +0200raym(~ray@user/raym)
2024-05-01 17:30:00 +0200billchenchina(~billchenc@103.118.42.229)
2024-05-01 17:30:32 +0200billchenchina(~billchenc@103.118.42.229) (Client Quit)
2024-05-01 17:35:57 +0200euleritian(~euleritia@dynamic-176-001-013-250.176.1.pool.telefonica.de) (Read error: Connection reset by peer)
2024-05-01 17:36:14 +0200euleritian(~euleritia@ip4d16fc38.dynamic.kabel-deutschland.de)
2024-05-01 17:40:27 +0200euleritian(~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 +0200euleritian(~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 +0200tri(~tri@ool-18bbef1a.static.optonline.net)
2024-05-01 17:45:35 +0200tromp(~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl)
2024-05-01 17:46:51 +0200euleritian(~euleritia@dynamic-176-001-013-250.176.1.pool.telefonica.de) (Read error: Connection reset by peer)
2024-05-01 17:47:09 +0200euleritian(~euleritia@ip4d16fc38.dynamic.kabel-deutschland.de)
2024-05-01 17:47:33 +0200wootehfoot(~wootehfoo@user/wootehfoot)
2024-05-01 17:49:27 +0200euleritian(~euleritia@ip4d16fc38.dynamic.kabel-deutschland.de) (Read error: Connection reset by peer)
2024-05-01 17:49:51 +0200tri(~tri@ool-18bbef1a.static.optonline.net) (Ping timeout: 259 seconds)
2024-05-01 17:50:22 +0200euleritian(~euleritia@ip4d16fc38.dynamic.kabel-deutschland.de)
2024-05-01 17:52:48 +0200zer0bitz(~zer0bitz@user/zer0bitz) (Quit: https://zer0bitz.dy.fi)
2024-05-01 17:55:45 +0200sawilagar(~sawilagar@user/sawilagar) (Ping timeout: 245 seconds)
2024-05-01 18:06:39 +0200euleritian(~euleritia@ip4d16fc38.dynamic.kabel-deutschland.de) (Ping timeout: 260 seconds)
2024-05-01 18:07:23 +0200euleritian(~euleritia@dynamic-176-001-013-250.176.1.pool.telefonica.de)
2024-05-01 18:14:36 +0200euleritian(~euleritia@dynamic-176-001-013-250.176.1.pool.telefonica.de) (Read error: Connection reset by peer)
2024-05-01 18:14:57 +0200euleritian(~euleritia@ip4d16fc38.dynamic.kabel-deutschland.de)
2024-05-01 18:15:21 +0200machinedgod(~machinedg@d173-183-246-216.abhsia.telus.net) (Ping timeout: 268 seconds)
2024-05-01 18:15:48 +0200zer0bitz(~zer0bitz@user/zer0bitz)
2024-05-01 18:17:45 +0200tri(~tri@ool-18bbef1a.static.optonline.net)
2024-05-01 18:20:06 +0200tromp(~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: Textual IRC Client: www.textualapp.com)
2024-05-01 18:20:40 +0200tromp(~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl)
2024-05-01 18:20:47 +0200euleritian(~euleritia@ip4d16fc38.dynamic.kabel-deutschland.de) (Read error: Connection reset by peer)
2024-05-01 18:20:53 +0200euleritian(~euleritia@dynamic-176-001-013-250.176.1.pool.telefonica.de)
2024-05-01 18:21:14 +0200euleritian(~euleritia@dynamic-176-001-013-250.176.1.pool.telefonica.de) (Read error: Connection reset by peer)
2024-05-01 18:21:32 +0200euleritian(~euleritia@ip4d16fc38.dynamic.kabel-deutschland.de)
2024-05-01 18:21:38 +0200fireking04(~karl@112.206.68.79)
2024-05-01 18:21:41 +0200tri(~tri@ool-18bbef1a.static.optonline.net) (Ping timeout: 240 seconds)
2024-05-01 18:24:55 +0200arkeet(~arkeet@moriya.ca) (Quit: ZNC 1.8.2 - https://znc.in)
2024-05-01 18:25:11 +0200arkeet(~arkeet@moriya.ca)
2024-05-01 18:26:38 +0200fireking04(~karl@112.206.68.79) (Remote host closed the connection)
2024-05-01 18:28:37 +0200euleritian(~euleritia@ip4d16fc38.dynamic.kabel-deutschland.de) (Read error: Connection reset by peer)
2024-05-01 18:28:47 +0200euleritian(~euleritia@dynamic-176-001-013-250.176.1.pool.telefonica.de)
2024-05-01 18:29:07 +0200euleritian(~euleritia@dynamic-176-001-013-250.176.1.pool.telefonica.de) (Read error: Connection reset by peer)
2024-05-01 18:29:36 +0200euleritian(~euleritia@ip4d16fc38.dynamic.kabel-deutschland.de)
2024-05-01 18:36:29 +0200euleritian(~euleritia@ip4d16fc38.dynamic.kabel-deutschland.de) (Read error: Connection reset by peer)
2024-05-01 18:37:07 +0200euleritian(~euleritia@ip4d16fc38.dynamic.kabel-deutschland.de)
2024-05-01 18:43:05 +0200yin(~yin@user/zero)
2024-05-01 18:43:40 +0200 <yin> /reconnect
2024-05-01 18:44:02 +0200yin(~yin@user/zero) (Client Quit)
2024-05-01 18:44:16 +0200yin(~yin@user/zero)
2024-05-01 18:47:21 +0200target_i(~target_i@user/target-i/x-6023099)
2024-05-01 18:48:49 +0200mima(~mmh@aftr-62-216-211-127.dynamic.mnet-online.de)
2024-05-01 18:49:04 +0200tzh(~tzh@c-73-164-206-160.hsd1.or.comcast.net)
2024-05-01 18:50:06 +0200euleritian(~euleritia@ip4d16fc38.dynamic.kabel-deutschland.de) (Remote host closed the connection)
2024-05-01 18:50:34 +0200euleritian(~euleritia@ip4d16fc38.dynamic.kabel-deutschland.de)
2024-05-01 18:55:21 +0200sord937(~sord937@gateway/tor-sasl/sord937) (Quit: sord937)
2024-05-01 18:56:00 +0200tromp(~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…)
2024-05-01 18:59:40 +0200danza(~francesco@151.57.139.226)
2024-05-01 19:03:16 +0200gaff(~gaff@49.207.212.165)
2024-05-01 19:04:11 +0200euleritian(~euleritia@ip4d16fc38.dynamic.kabel-deutschland.de) (Remote host closed the connection)
2024-05-01 19:04:55 +0200euleritian(~euleritia@ip4d16fc38.dynamic.kabel-deutschland.de)
2024-05-01 19:05:08 +0200euleritian(~euleritia@ip4d16fc38.dynamic.kabel-deutschland.de) (Read error: Connection reset by peer)
2024-05-01 19:05:32 +0200euleritian(~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 +0200hseg(~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 +0200danza(~francesco@151.57.139.226) (Ping timeout: 255 seconds)
2024-05-01 19:19:00 +0200danza(~francesco@151.57.139.226)
2024-05-01 19:20:51 +0200mima(~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 +0200danza(~francesco@151.57.139.226) (Remote host closed the connection)
2024-05-01 19:28:27 +0200k``(~k``@152.1.137.158)
2024-05-01 19:28:31 +0200tromp(~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 +0200euleritian(~euleritia@ip4d16fc38.dynamic.kabel-deutschland.de) (Ping timeout: 255 seconds)
2024-05-01 19:30:15 +0200euleritian(~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 +0200hseg(~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 +0200euleritian(~euleritia@dynamic-176-001-013-250.176.1.pool.telefonica.de) (Read error: Connection reset by peer)
2024-05-01 19:40:39 +0200euleritian(~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 +0200Axman6(~Axman6@user/axman6) (Ping timeout: 258 seconds)
2024-05-01 19:52:46 +0200Axman6(~Axman6@user/axman6)
2024-05-01 19:53:02 +0200Bynbo7(~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 +0200Axma89310(~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 +0200justsomeguy(~justsomeg@user/justsomeguy) (Ping timeout: 272 seconds)
2024-05-01 19:58:04 +0200tromp(~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…)
2024-05-01 19:59:48 +0200justsomeguy(~justsomeg@user/justsomeguy)
2024-05-01 20:04:02 +0200hseg(~gesh@77.137.75.224)
2024-05-01 20:05:34 +0200gaff(~gaff@49.207.212.165) ()
2024-05-01 20:05:51 +0200tromp(~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 +0200peterbecich(~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 +0200mrmr1553343(~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 +0200mrmr1553343(~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 +0200danza(~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 +0200justsomeguy(~justsomeg@user/justsomeguy) (Quit: WeeChat 3.6)
2024-05-01 20:34:23 +0200tromp(~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 +0200tromp(~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 +0200dfip^(~cd@c-98-242-74-66.hsd1.ga.comcast.net) (Remote host closed the connection)
2024-05-01 20:40:53 +0200peterbecich(~Thunderbi@syn-047-229-123-186.res.spectrum.com) (Ping timeout: 268 seconds)
2024-05-01 20:50:16 +0200euleritian(~euleritia@ip4d16fc38.dynamic.kabel-deutschland.de) (Read error: Connection reset by peer)
2024-05-01 20:51:07 +0200euleritian(~euleritia@ip4d16fc38.dynamic.kabel-deutschland.de)
2024-05-01 20:52:32 +0200danza(~francesco@151.19.252.90) (Ping timeout: 260 seconds)
2024-05-01 20:52:32 +0200euleritian(~euleritia@ip4d16fc38.dynamic.kabel-deutschland.de) (Read error: Connection reset by peer)
2024-05-01 20:52:57 +0200euleritian(~euleritia@ip4d16fc38.dynamic.kabel-deutschland.de)
2024-05-01 21:00:51 +0200michalz(~michalz@185.246.207.218)
2024-05-01 21:02:40 +0200michalz(~michalz@185.246.207.218) (Client Quit)
2024-05-01 21:05:43 +0200michalz(~michalz@185.246.207.218)
2024-05-01 21:07:11 +0200michalz(~michalz@185.246.207.218) (Client Quit)
2024-05-01 21:09:15 +0200emmanuelux(~emmanuelu@user/emmanuelux)
2024-05-01 21:09:46 +0200michalz(~michalz@185.246.207.200)
2024-05-01 21:11:00 +0200madeleine-sydney(~madeleine@c-76-155-235-153.hsd1.co.comcast.net)
2024-05-01 21:13:34 +0200malte(~malte@mal.tc) (Remote host closed the connection)
2024-05-01 21:14:12 +0200tessd(~test@evw199.neoplus.adsl.tpnet.pl)
2024-05-01 21:14:44 +0200malte(~malte@mal.tc)
2024-05-01 21:34:02 +0200Batzy(~quassel@user/batzy)
2024-05-01 21:35:41 +0200Guest67(~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 +0200AlexNoo_(~AlexNoo@94.233.240.47)
2024-05-01 21:44:29 +0200AlexNoo_(~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 +0200noumenon(~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 +0200tessd(~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 +0200sawilagar(~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 +0200Luj(~Luj@2a01:e0a:5f9:9681:627d:73c1:73b3:2561) (Quit: Ping timeout (120 seconds))
2024-05-01 22:15:26 +0200Luj(~Luj@2a01:e0a:5f9:9681:d999:72f4:b788:a2bb)
2024-05-01 22:16:01 +0200tri(~tri@ool-18bbef1a.static.optonline.net)
2024-05-01 22:16:24 +0200demon-cat(~demon-cat@dund-15-b2-v4wan-169642-cust1347.vm6.cable.virginm.net)
2024-05-01 22:20:23 +0200tri(~tri@ool-18bbef1a.static.optonline.net) (Ping timeout: 264 seconds)
2024-05-01 22:23:01 +0200SteelBlueSilk(~SteelBlue@c-98-42-249-36.hsd1.ca.comcast.net)
2024-05-01 22:23:01 +0200SteelBlueSilk(~SteelBlue@c-98-42-249-36.hsd1.ca.comcast.net) (Changing host)
2024-05-01 22:23:01 +0200SteelBlueSilk(~SteelBlue@user/SteelBlueSilk)
2024-05-01 22:25:21 +0200sawilagar(~sawilagar@user/sawilagar) (Quit: Leaving)
2024-05-01 22:28:22 +0200k``(~k``@152.1.137.158) (Remote host closed the connection)
2024-05-01 22:31:27 +0200madeleine-sydney(~madeleine@c-76-155-235-153.hsd1.co.comcast.net) (Quit: Konversation terminated!)
2024-05-01 22:36:54 +0200sawilagar(~sawilagar@user/sawilagar)
2024-05-01 22:39:05 +0200yin(~yin@user/zero) (Ping timeout: 256 seconds)
2024-05-01 22:39:34 +0200michalz(~michalz@185.246.207.200) (Quit: ZNC 1.8.2 - https://znc.in)
2024-05-01 22:42:12 +0200Square(~Square@user/square)
2024-05-01 22:43:40 +0200Guest67(~Guest67@129.170.197.127) (Ping timeout: 250 seconds)
2024-05-01 22:46:41 +0200waleee(~waleee@h-176-10-144-38.NA.cust.bahnhof.se)
2024-05-01 22:46:58 +0200tri(~tri@ool-18bbef1a.static.optonline.net)
2024-05-01 22:46:58 +0200xdminsy(~xdminsy@117.147.70.233) (Read error: Connection reset by peer)
2024-05-01 22:47:08 +0200manwithluck(manwithluc@gateway/vpn/protonvpn/manwithluck) (Read error: Connection reset by peer)
2024-05-01 22:47:35 +0200manwithluck(manwithluc@gateway/vpn/protonvpn/manwithluck)
2024-05-01 22:49:01 +0200peterbecich(~Thunderbi@syn-047-229-123-186.res.spectrum.com)
2024-05-01 22:51:28 +0200tri(~tri@ool-18bbef1a.static.optonline.net) (Ping timeout: 256 seconds)
2024-05-01 22:54:21 +0200takuan(~takuan@178-116-218-225.access.telenet.be) (Ping timeout: 252 seconds)
2024-05-01 23:00:14 +0200yin(~yin@user/zero)
2024-05-01 23:07:05 +0200xdminsy(~xdminsy@117.147.70.233)
2024-05-01 23:09:31 +0200hseg(~gesh@77.137.75.224) (Ping timeout: 260 seconds)
2024-05-01 23:14:18 +0200gmg(~user@user/gehmehgeh) (Ping timeout: 260 seconds)
2024-05-01 23:16:39 +0200tri(~tri@ool-18bbef1a.static.optonline.net)
2024-05-01 23:16:49 +0200gmg(~user@user/gehmehgeh)
2024-05-01 23:19:42 +0200mwnaylor(~user@2601:5cf:837e:2bb0::9c1d)
2024-05-01 23:21:18 +0200tri(~tri@ool-18bbef1a.static.optonline.net) (Ping timeout: 252 seconds)
2024-05-01 23:33:27 +0200ocra8(ocra8@user/ocra8) (Quit: WeeChat 4.2.2)
2024-05-01 23:35:17 +0200 <tomsmeding> monochrom: are you teaching existentials in data types?
2024-05-01 23:35:26 +0200 <tomsmeding> data Exists f where Exists :: f a -> Exists f
2024-05-01 23:35:48 +0200 <tomsmeding> that's another instance of this idea, except "producer chooses" vs "consumer chooses"
2024-05-01 23:35:58 +0200 <tomsmeding> never mind that haskell notates both with 'forall'
2024-05-01 23:36:13 +0200 <haskellbridge> <s​m> g'day all. Isn't there a CPP macro for checking the value of a cabal package flag ?
2024-05-01 23:36:58 +0200 <haskellbridge> <s​m> I thought so, but can't find it
2024-05-01 23:39:16 +0200ocra8(ocra8@user/ocra8)
2024-05-01 23:40:18 +0200 <tomsmeding> sm: I don't think so
2024-05-01 23:40:49 +0200 <c_wraith> sm: I think the typical thing is to put -DFLAGNAME in a cpp-options field when the flag is set
2024-05-01 23:41:04 +0200 <tomsmeding> e.g. search for 'if flag(debug)' here https://hackage.haskell.org/package/accelerate-1.3.0.0/accelerate.cabal
2024-05-01 23:41:28 +0200 <tomsmeding> of course you can name this define suggestively, like FLAG_yourthing
2024-05-01 23:41:33 +0200 <haskellbridge> <s​m> I guess you're right, thank you
2024-05-01 23:41:56 +0200acidjnk(~acidjnk@p200300d6e714dc53acbe2cc37902b0bc.dip0.t-ipconnect.de) (Ping timeout: 260 seconds)
2024-05-01 23:42:21 +0200 <haskellbridge> <s​m> I want to include ghc-debug support, but not by default as it's not yet widely packaged
2024-05-01 23:42:58 +0200 <haskellbridge> <s​m> because ghc-debug-brick looked pretty powerful, even if I couldn't figure out a whole lot
2024-05-01 23:43:49 +0200 <haskellbridge> <s​m> (I couldn't see a lot of source symbols, even when I built for profiling and with that info-tables ghc option)
2024-05-01 23:52:40 +0200peterbecich(~Thunderbi@syn-047-229-123-186.res.spectrum.com) (Ping timeout: 268 seconds)