| 2024-07-27 00:04:35 +0200 | paddymahoney | (~paddymaho@pool-99-250-30-88.cpe.net.cable.rogers.com) (Ping timeout: 260 seconds) |
| 2024-07-27 00:04:48 +0200 | prolic_ | (~sasa@181.122.138.24) (Ping timeout: 276 seconds) |
| 2024-07-27 00:05:50 +0200 | <Inst> | no one likes sieve of atkin here? |
| 2024-07-27 00:09:52 +0200 | paddymahoney | (~paddymaho@pool-99-250-30-88.cpe.net.cable.rogers.com) |
| 2024-07-27 00:11:35 +0200 | <glguy> | slack1256: a name is a single thing. One type applied to another isn't a name but would be a Type. What does deriveFromJSON expect? |
| 2024-07-27 00:12:10 +0200 | foul_owl | (~kerry@174-21-147-232.tukw.qwest.net) (Ping timeout: 260 seconds) |
| 2024-07-27 00:12:58 +0200 | __monty__ | (~toonn@user/toonn) (Quit: leaving) |
| 2024-07-27 00:15:01 +0200 | <Inst> | i'm still reading the paper but it looks like it's actually much more condusive to FP than eratosthenes |
| 2024-07-27 00:19:14 +0200 | Inst | (~Inst@user/Inst) (Read error: Connection reset by peer) |
| 2024-07-27 00:21:54 +0200 | CiaoSen | (~Jura@2a05:5800:2ef:3300:e6b9:7aff:fe80:3d03) (Ping timeout: 260 seconds) |
| 2024-07-27 00:24:13 +0200 | CrunchyFlakes | (~CrunchyFl@ip92348280.dynamic.kabel-deutschland.de) (Read error: Connection reset by peer) |
| 2024-07-27 00:26:34 +0200 | foul_owl | (~kerry@185.216.231.180) |
| 2024-07-27 00:26:35 +0200 | CrunchyFlakes | (~CrunchyFl@ip92348280.dynamic.kabel-deutschland.de) |
| 2024-07-27 00:32:53 +0200 | SteelBlueSilk | (~SteelBlue@user/SteelBlueSilk) (Ping timeout: 248 seconds) |
| 2024-07-27 00:43:03 +0200 | gmg | (~user@user/gehmehgeh) (Quit: Leaving) |
| 2024-07-27 00:45:12 +0200 | acidjnk | (~acidjnk@p200300d6e72cfb67cc718b9c5fdaa04e.dip0.t-ipconnect.de) (Ping timeout: 252 seconds) |
| 2024-07-27 00:46:48 +0200 | Midjak | (~MarciZ@82.66.147.146) (Quit: This computer has gone to sleep) |
| 2024-07-27 00:51:19 +0200 | jerg | (~jerg@2001:a61:247a:4700::bb0) (Ping timeout: 252 seconds) |
| 2024-07-27 00:52:48 +0200 | <dsal> | Is there a way to do a sort of stateful update of values identified by a traversal? |
| 2024-07-27 00:53:20 +0200 | <dsal> | I've got a fairly complicated nested structure and want to be able to replace a particular field quite deep down. I've got a list of unique values I'd like to apply, but I'm not sure how to thread them through. |
| 2024-07-27 00:54:01 +0200 | <dsal> | I could do this without lens, but it seems like a pretty straightforward use case I'd like to avoid writing a bunch of code to do. |
| 2024-07-27 01:01:34 +0200 | <jackdk> | dsal: https://hackage.haskell.org/package/lens-5.3.2/docs/Control-Lens-Traversal.html#v:partsOf ? |
| 2024-07-27 01:02:21 +0200 | <dsal> | Yes, this looks like it might be the shape I was looking for. Thanks! |
| 2024-07-27 01:03:06 +0200 | bitdex | (~bitdex@gateway/tor-sasl/bitdex) |
| 2024-07-27 01:13:34 +0200 | <dsal> | I ended up with partsOf (super . long . traversed . pile . of . traversed . bits) %~ zipWith updateOne someStuff |
| 2024-07-27 01:14:11 +0200 | <EvanR> | lens poetry? |
| 2024-07-27 01:15:31 +0200 | <dsal> | So much better than writing out all that stuff. There are nine components to that traversal in the real code. |
| 2024-07-27 01:19:23 +0200 | peterbecich | (~Thunderbi@syn-047-229-123-186.res.spectrum.com) |
| 2024-07-27 01:23:12 +0200 | euleritian | (~euleritia@ip4d16fc38.dynamic.kabel-deutschland.de) (Read error: Connection reset by peer) |
| 2024-07-27 01:23:27 +0200 | euleritian | (~euleritia@ip4d16fc38.dynamic.kabel-deutschland.de) |
| 2024-07-27 01:26:37 +0200 | VedantT | (~VedantT@2603:6000:b500:29a9:ac9a:7661:5229:f762) |
| 2024-07-27 01:29:25 +0200 | Rodney- | (~Rodney@90.201.223.82) (Ping timeout: 248 seconds) |
| 2024-07-27 01:30:40 +0200 | VedantT | (~VedantT@2603:6000:b500:29a9:ac9a:7661:5229:f762) (Client Quit) |
| 2024-07-27 01:31:31 +0200 | szkl | (uid110435@2a03:5180:f:5::1:af63) (Quit: Connection closed for inactivity) |
| 2024-07-27 01:40:55 +0200 | JuanDaugherty | (~juan@user/JuanDaugherty) |
| 2024-07-27 01:42:29 +0200 | prolic_ | (~sasa@181.122.138.24) |
| 2024-07-27 01:44:22 +0200 | machinedgod | (~machinedg@d173-183-246-216.abhsia.telus.net) (Ping timeout: 244 seconds) |
| 2024-07-27 01:45:32 +0200 | Tuplanolla | (~Tuplanoll@91-159-69-59.elisa-laajakaista.fi) (Quit: Leaving.) |
| 2024-07-27 01:52:38 +0200 | waleee | (~waleee@h-176-10-144-38.NA.cust.bahnhof.se) (Ping timeout: 244 seconds) |
| 2024-07-27 01:55:33 +0200 | skyesoss | (~Thunderbi@128.135.204.35) (Ping timeout: 248 seconds) |
| 2024-07-27 01:59:32 +0200 | misterfish | (~misterfis@84.53.85.146) (Ping timeout: 252 seconds) |
| 2024-07-27 02:01:29 +0200 | ystael | (~ystael@user/ystael) (Ping timeout: 255 seconds) |
| 2024-07-27 02:03:23 +0200 | JuanDaugherty | (~juan@user/JuanDaugherty) (Quit: JuanDaugherty) |
| 2024-07-27 02:05:12 +0200 | hgolden | (~hgolden@2603:8000:9d00:3ed1:1ee4:1b7c:94a7:8fa7) (Remote host closed the connection) |
| 2024-07-27 02:05:53 +0200 | Rodney__ | (~Rodney@90.201.223.82) |
| 2024-07-27 02:07:39 +0200 | peterbecich | (~Thunderbi@syn-047-229-123-186.res.spectrum.com) (Ping timeout: 276 seconds) |
| 2024-07-27 02:08:20 +0200 | Lord_of_Life | (~Lord@user/lord-of-life/x-2819915) (Ping timeout: 252 seconds) |
| 2024-07-27 02:09:22 +0200 | Lord_of_Life | (~Lord@user/lord-of-life/x-2819915) |
| 2024-07-27 02:21:35 +0200 | mud | (~mud@user/kadoban) (Remote host closed the connection) |
| 2024-07-27 02:22:02 +0200 | mud | (~mud@user/kadoban) |
| 2024-07-27 02:31:48 +0200 | prolic_ | (~sasa@181.122.138.24) (Remote host closed the connection) |
| 2024-07-27 02:32:07 +0200 | califax | (~califax@user/califx) (Remote host closed the connection) |
| 2024-07-27 02:35:17 +0200 | califax | (~califax@user/califx) |
| 2024-07-27 02:46:39 +0200 | tomku | (~tomku@user/tomku) (Ping timeout: 276 seconds) |
| 2024-07-27 02:54:18 +0200 | <monochrom> | I have not learned the sieve of Atkin. I guess that's an implicit "not like" because the very decision to learn a million other things instead reflects what I like. |
| 2024-07-27 02:57:51 +0200 | <monochrom> | 35 years ago I liked computational number theory so much I would even go out of my way to learn the number field sieve. But today, "category theory and dependent type theory are so much easier". |
| 2024-07-27 02:59:12 +0200 | <monochrom> | But going back to the original point. Stop telling beginners how to split hair about what "sieve" means. |
| 2024-07-27 03:14:32 +0200 | peterbecich | (~Thunderbi@syn-047-229-123-186.res.spectrum.com) |
| 2024-07-27 03:31:05 +0200 | bolivood | (~bolivood@user/bolivood) (Ping timeout: 260 seconds) |
| 2024-07-27 03:35:10 +0200 | peterbecich | (~Thunderbi@syn-047-229-123-186.res.spectrum.com) (Ping timeout: 260 seconds) |
| 2024-07-27 04:01:53 +0200 | Rodney- | (~Rodney@90.201.223.82) |
| 2024-07-27 04:05:14 +0200 | Rodney__ | (~Rodney@90.201.223.82) (Ping timeout: 255 seconds) |
| 2024-07-27 04:07:29 +0200 | fiberchunks | (~mike@32.221.120.181) |
| 2024-07-27 04:08:28 +0200 | fiberchunks | (~mike@32.221.120.181) () |
| 2024-07-27 04:11:48 +0200 | fiberchunks | (~mike@32.221.120.181) |
| 2024-07-27 04:12:16 +0200 | td_ | (~td@i53870934.versanet.de) (Ping timeout: 252 seconds) |
| 2024-07-27 04:14:16 +0200 | td_ | (~td@i53870913.versanet.de) |
| 2024-07-27 04:27:10 +0200 | fiberchunks | (~mike@32.221.120.181) () |
| 2024-07-27 04:35:54 +0200 | ddellacosta | (~ddellacos@ool-44c73d29.dyn.optonline.net) |
| 2024-07-27 04:38:02 +0200 | tomku | (~tomku@user/tomku) |
| 2024-07-27 04:43:31 +0200 | terrorjack | (~terrorjac@2a01:4f8:c17:87f8::) (Quit: The Lounge - https://thelounge.chat) |
| 2024-07-27 04:46:22 +0200 | terrorjack | (~terrorjac@2a01:4f8:c17:87f8::) |
| 2024-07-27 05:00:01 +0200 | econo_ | (uid147250@id-147250.tinside.irccloud.com) (Quit: Connection closed for inactivity) |
| 2024-07-27 05:27:33 +0200 | Unicorn_Princess | (~Unicorn_P@user/Unicorn-Princess/x-3540542) |
| 2024-07-27 05:36:08 +0200 | torkel | (~sindu@83-243-191-191.fth.tafjordconnect.net) (Quit: WeeChat 4.3.5) |
| 2024-07-27 05:38:33 +0200 | JuanDaugherty | (~juan@user/JuanDaugherty) |
| 2024-07-27 05:41:19 +0200 | monochrom | (trebla@216.138.220.146) (Quit: ZNC 1.9.0+deb2build3 - https://znc.in) |
| 2024-07-27 05:49:35 +0200 | <jle`> | dsal: that sounds like also a good application of StateT |
| 2024-07-27 05:49:51 +0200 | <jle`> | er just State maybe |
| 2024-07-27 05:50:42 +0200 | <jle`> | ah Traversal + State is just mapAccumLOf |
| 2024-07-27 05:52:21 +0200 | aforemny | (~aforemny@i59F516C5.versanet.de) (Ping timeout: 248 seconds) |
| 2024-07-27 05:53:29 +0200 | aforemny | (~aforemny@i59F516D5.versanet.de) |
| 2024-07-27 05:53:30 +0200 | monochrom | (trebla@216.138.220.146) |
| 2024-07-27 05:53:43 +0200 | machinedgod | (~machinedg@d173-183-246-216.abhsia.telus.net) |
| 2024-07-27 05:54:41 +0200 | peterbecich | (~Thunderbi@syn-047-229-123-186.res.spectrum.com) |
| 2024-07-27 05:57:17 +0200 | sindu | (~sindu@83-243-191-191.fth.tafjordconnect.net) |
| 2024-07-27 05:59:41 +0200 | euleritian | (~euleritia@ip4d16fc38.dynamic.kabel-deutschland.de) (Remote host closed the connection) |
| 2024-07-27 05:59:55 +0200 | euleritian | (~euleritia@ip4d16fc38.dynamic.kabel-deutschland.de) |
| 2024-07-27 06:01:47 +0200 | Square2 | (~Square@user/square) (Ping timeout: 255 seconds) |
| 2024-07-27 06:10:14 +0200 | JuanDaugherty | (~juan@user/JuanDaugherty) (Quit: JuanDaugherty) |
| 2024-07-27 06:27:15 +0200 | peterbecich | (~Thunderbi@syn-047-229-123-186.res.spectrum.com) (Ping timeout: 260 seconds) |
| 2024-07-27 06:28:21 +0200 | slack1256 | (~slack1256@2803:c600:5111:80cb:d321:865d:b7ff:34ea) (Remote host closed the connection) |
| 2024-07-27 06:37:32 +0200 | skyesoss | (~Thunderbi@c-73-208-45-119.hsd1.il.comcast.net) |
| 2024-07-27 06:38:33 +0200 | sindu | (~sindu@83-243-191-191.fth.tafjordconnect.net) (Ping timeout: 252 seconds) |
| 2024-07-27 06:45:29 +0200 | hgolden | (~hgolden@2603:8000:9d00:3ed1:1ee4:1b7c:94a7:8fa7) |
| 2024-07-27 06:52:29 +0200 | machinedgod | (~machinedg@d173-183-246-216.abhsia.telus.net) (Ping timeout: 252 seconds) |
| 2024-07-27 06:58:46 +0200 | danza | (~danza@na-19-79-8.service.infuturo.it) |
| 2024-07-27 07:05:57 +0200 | danza | (~danza@na-19-79-8.service.infuturo.it) (Remote host closed the connection) |
| 2024-07-27 07:06:44 +0200 | danza | (~danza@na-19-79-8.service.infuturo.it) |
| 2024-07-27 07:17:54 +0200 | krei-se | (~krei-se@p5085de4b.dip0.t-ipconnect.de) (Quit: ZNC 1.9.1 - https://znc.in) |
| 2024-07-27 07:19:50 +0200 | krei-se | (~krei-se@p5085de4b.dip0.t-ipconnect.de) |
| 2024-07-27 07:27:14 +0200 | <dsal> | jle`: Yeah, I was in the process of writing it with State, but doing all of those tree descents is a lot more painful than just stating the path. |
| 2024-07-27 07:29:15 +0200 | euphores | (~SASL_euph@user/euphores) (Quit: Leaving.) |
| 2024-07-27 07:32:11 +0200 | <jle`> | dsal: yeah if you just want to zip with over zipWith works. but mapAccumLOf from Control.Lens.Traversal might capture the idea of a stateful map over a traversal nicely |
| 2024-07-27 07:32:39 +0200 | <dsal> | Oh. I missed the `Of` there. |
| 2024-07-27 07:32:56 +0200 | skyesoss | (~Thunderbi@c-73-208-45-119.hsd1.il.comcast.net) (Ping timeout: 272 seconds) |
| 2024-07-27 07:35:09 +0200 | <danza> | i don't use mapAccum enough |
| 2024-07-27 07:35:12 +0200 | <danza> | :t mapAccum |
| 2024-07-27 07:35:13 +0200 | <lambdabot> | error: |
| 2024-07-27 07:35:13 +0200 | <lambdabot> | • Variable not in scope: mapAccum |
| 2024-07-27 07:35:14 +0200 | <lambdabot> | • Perhaps you meant one of these: |
| 2024-07-27 07:35:20 +0200 | euphores | (~SASL_euph@user/euphores) |
| 2024-07-27 07:35:38 +0200 | <danza> | @hoogle mapAccum |
| 2024-07-27 07:35:39 +0200 | <lambdabot> | Data.IntMap.Internal mapAccum :: (a -> b -> (a, c)) -> a -> IntMap b -> (a, IntMap c) |
| 2024-07-27 07:35:39 +0200 | <lambdabot> | Data.IntMap.Lazy mapAccum :: (a -> b -> (a, c)) -> a -> IntMap b -> (a, IntMap c) |
| 2024-07-27 07:35:39 +0200 | <lambdabot> | Data.IntMap.Strict mapAccum :: (a -> b -> (a, c)) -> a -> IntMap b -> (a, IntMap c) |
| 2024-07-27 07:39:02 +0200 | <geekosaur> | don't you want mapAccumL? |
| 2024-07-27 07:39:37 +0200 | <danza> | who, me? |
| 2024-07-27 07:40:26 +0200 | <geekosaur> | yes |
| 2024-07-27 07:40:44 +0200 | <geekosaur> | @hoogle mapAccumL |
| 2024-07-27 07:40:45 +0200 | <lambdabot> | Data.List mapAccumL :: Traversable t => (a -> b -> (a, c)) -> a -> t b -> (a, t c) |
| 2024-07-27 07:40:45 +0200 | <lambdabot> | Data.Traversable mapAccumL :: Traversable t => (a -> b -> (a, c)) -> a -> t b -> (a, t c) |
| 2024-07-27 07:40:45 +0200 | <lambdabot> | GHC.OldList mapAccumL :: (acc -> x -> (acc, y)) -> acc -> [x] -> (acc, [y]) |
| 2024-07-27 07:41:36 +0200 | <danza> | huh yeah, well i was looking for a definition with a default direction |
| 2024-07-27 07:41:39 +0200 | <danza> | :t foldr |
| 2024-07-27 07:41:40 +0200 | <lambdabot> | Foldable t => (a -> b -> b) -> b -> t a -> b |
| 2024-07-27 07:41:42 +0200 | <danza> | :t fold |
| 2024-07-27 07:41:43 +0200 | <lambdabot> | (Foldable t, Monoid m) => t m -> m |
| 2024-07-27 07:42:13 +0200 | danza | (~danza@na-19-79-8.service.infuturo.it) (Quit: on the move) |
| 2024-07-27 07:45:45 +0200 | kimiamania | (~65804703@user/kimiamania) (Quit: PegeLinux) |
| 2024-07-27 07:45:55 +0200 | CrunchyFlakes | (~CrunchyFl@ip92348280.dynamic.kabel-deutschland.de) (Read error: Connection reset by peer) |
| 2024-07-27 07:46:52 +0200 | kimiamania | (~65804703@user/kimiamania) |
| 2024-07-27 07:48:22 +0200 | CrunchyFlakes | (~CrunchyFl@ip92348280.dynamic.kabel-deutschland.de) |
| 2024-07-27 07:49:57 +0200 | danza | (~danza@na-19-79-8.service.infuturo.it) |
| 2024-07-27 07:51:01 +0200 | stiell | (~stiell@gateway/tor-sasl/stiell) (Ping timeout: 260 seconds) |
| 2024-07-27 07:57:15 +0200 | skyesoss | (~Thunderbi@c-73-208-45-119.hsd1.il.comcast.net) |
| 2024-07-27 08:27:46 +0200 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) |
| 2024-07-27 08:30:07 +0200 | wootehfoot | (~wootehfoo@user/wootehfoot) |
| 2024-07-27 08:47:02 +0200 | misterfish | (~misterfis@84.53.85.146) |
| 2024-07-27 08:49:07 +0200 | lambdabot | (~lambdabot@haskell/bot/lambdabot) (Remote host closed the connection) |
| 2024-07-27 08:49:35 +0200 | lambdabot | (~lambdabot@silicon.int-e.eu) |
| 2024-07-27 08:49:35 +0200 | lambdabot | (~lambdabot@silicon.int-e.eu) (Changing host) |
| 2024-07-27 08:49:35 +0200 | lambdabot | (~lambdabot@haskell/bot/lambdabot) |
| 2024-07-27 08:49:35 +0200 | ChanServ | +v lambdabot |
| 2024-07-27 08:51:01 +0200 | Midjak | (~MarciZ@82.66.147.146) |
| 2024-07-27 08:56:17 +0200 | int-e | (~noone@int-e.eu) (Remote host closed the connection) |
| 2024-07-27 08:56:57 +0200 | int-e | (~noone@int-e.eu) |
| 2024-07-27 09:08:27 +0200 | econo_ | (uid147250@id-147250.tinside.irccloud.com) |
| 2024-07-27 09:15:47 +0200 | aforemny_ | (~aforemny@2001:9e8:6cdd:9b00:67d0:27e6:eba2:1a90) |
| 2024-07-27 09:15:49 +0200 | danza | (~danza@na-19-79-8.service.infuturo.it) (Quit: on the move) |
| 2024-07-27 09:15:51 +0200 | aforemny | (~aforemny@i59F516D5.versanet.de) (Ping timeout: 252 seconds) |
| 2024-07-27 09:21:05 +0200 | acidjnk | (~acidjnk@p200300d6e72cfb1421aec5076afe4c64.dip0.t-ipconnect.de) |
| 2024-07-27 09:21:09 +0200 | oo_miguel | (~Thunderbi@78.10.207.46) |
| 2024-07-27 09:22:01 +0200 | <Unicorn_Princess> | i should be using aeson & aeson-pretty for dealing with json? |
| 2024-07-27 09:28:22 +0200 | bolivood | (~bolivood@2a0d:6fc2:5d11:200:113a:493:cf26:6dea) |
| 2024-07-27 09:38:30 +0200 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 2024-07-27 09:39:12 +0200 | <Hecate> | Unicorn_Princess: usually yes |
| 2024-07-27 09:39:37 +0200 | oo_miguel | (~Thunderbi@78.10.207.46) (Remote host closed the connection) |
| 2024-07-27 09:41:19 +0200 | skyesoss | (~Thunderbi@c-73-208-45-119.hsd1.il.comcast.net) (Quit: skyesoss) |
| 2024-07-27 09:41:41 +0200 | <Unicorn_Princess> | thanks |
| 2024-07-27 09:48:16 +0200 | sindu | (~sindu@83-243-191-191.fth.tafjordconnect.net) |
| 2024-07-27 09:49:49 +0200 | Sgeo | (~Sgeo@user/sgeo) (Read error: Connection reset by peer) |
| 2024-07-27 09:55:16 +0200 | MadeleineSydney | (~Thunderbi@c-71-229-185-228.hsd1.co.comcast.net) |
| 2024-07-27 10:08:36 +0200 | euleritian | (~euleritia@ip4d16fc38.dynamic.kabel-deutschland.de) (Read error: Connection reset by peer) |
| 2024-07-27 10:09:20 +0200 | euleritian | (~euleritia@ip4d16fc38.dynamic.kabel-deutschland.de) |
| 2024-07-27 10:17:28 +0200 | sindu | (~sindu@83-243-191-191.fth.tafjordconnect.net) (Ping timeout: 252 seconds) |
| 2024-07-27 10:21:52 +0200 | cpressey | (~weechat@176.254.71.203) |
| 2024-07-27 10:22:29 +0200 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) |
| 2024-07-27 10:25:24 +0200 | <Axman6> | Can anyone explain why this isn't working? I want to get a name associated with a value (something that seems to work find in Clash) but I don't understand why I'm getting this error: https://paste.tomsmeding.com/49bV7Tuu |
| 2024-07-27 10:29:09 +0200 | cpressey | (~weechat@176.254.71.203) (Ping timeout: 248 seconds) |
| 2024-07-27 10:31:34 +0200 | <Lears> | Axman6: This worked: https://play-haskell.tomsmeding.com/saved/ICQgr1xB |
| 2024-07-27 10:32:17 +0200 | <Lears> | A type synonym breaks because the `l` disappears from the RHS of the => I guess? |
| 2024-07-27 10:33:25 +0200 | <Axman6> | Hmm, sadly I can't change the type, (:::) is from clash-prelude |
| 2024-07-27 10:34:14 +0200 | <Lears> | Maybe the functions that use it in clash also take other arguments that alleviate the ambiguity. You could use type applications or proxies. |
| 2024-07-27 10:38:42 +0200 | <Axman6> | I can;t even get your example to compile actually |
| 2024-07-27 10:39:51 +0200 | xff0x | (~xff0x@2405:6580:b080:900:8b26:ef3c:7f31:7c41) (Ping timeout: 276 seconds) |
| 2024-07-27 10:54:02 +0200 | tzh | (~tzh@c-76-115-131-146.hsd1.or.comcast.net) (Quit: zzz) |
| 2024-07-27 10:54:41 +0200 | jerg | (~jerg@2001:a61:247a:4700::bb0) |
| 2024-07-27 11:00:12 +0200 | Tuplanolla | (~Tuplanoll@91-159-69-59.elisa-laajakaista.fi) |
| 2024-07-27 11:06:10 +0200 | Inst | (~Inst@user/Inst) |
| 2024-07-27 11:12:20 +0200 | xff0x | (~xff0x@2405:6580:b080:900:8b26:ef3c:7f31:7c41) |
| 2024-07-27 11:12:24 +0200 | CiaoSen | (~Jura@2a05:5800:2ea:1100:e6b9:7aff:fe80:3d03) |
| 2024-07-27 11:19:07 +0200 | teqwve | (teqwve@static.141.38.201.195.clients.your-server.de) (Quit: cya) |
| 2024-07-27 11:21:12 +0200 | pkal | (~pkal@2a01:4f8:1c1b:a321::) (Remote host closed the connection) |
| 2024-07-27 11:21:20 +0200 | pkal | (~pkal@2a01:4f8:1c1b:a321::) |
| 2024-07-27 11:22:08 +0200 | pkal | (~pkal@2a01:4f8:1c1b:a321::) (Remote host closed the connection) |
| 2024-07-27 11:22:15 +0200 | pkal | (~pkal@2a01:4f8:1c1b:a321::) |
| 2024-07-27 11:27:41 +0200 | stiell | (~stiell@gateway/tor-sasl/stiell) |
| 2024-07-27 11:29:22 +0200 | sindu | (~sindu@83-243-191-191.fth.tafjordconnect.net) |
| 2024-07-27 11:34:01 +0200 | __monty__ | (~toonn@user/toonn) |
| 2024-07-27 11:34:27 +0200 | bolivood | (~bolivood@2a0d:6fc2:5d11:200:113a:493:cf26:6dea) (Ping timeout: 276 seconds) |
| 2024-07-27 11:44:35 +0200 | euleritian | (~euleritia@ip4d16fc38.dynamic.kabel-deutschland.de) (Read error: Connection reset by peer) |
| 2024-07-27 11:45:32 +0200 | euleritian | (~euleritia@77.22.252.56) |
| 2024-07-27 11:47:09 +0200 | MadeleineSydney | (~Thunderbi@c-71-229-185-228.hsd1.co.comcast.net) (Remote host closed the connection) |
| 2024-07-27 11:48:57 +0200 | danza | (~danza@151.47.28.68) |
| 2024-07-27 11:49:11 +0200 | euleritian | (~euleritia@77.22.252.56) (Read error: Connection reset by peer) |
| 2024-07-27 11:50:01 +0200 | euleritian | (~euleritia@77.22.252.56) |
| 2024-07-27 11:55:55 +0200 | Me-me | (~me-me@kc.randomserver.name) (Changing host) |
| 2024-07-27 11:55:55 +0200 | Me-me | (~me-me@user/me-me) |
| 2024-07-27 11:57:28 +0200 | sindu | (~sindu@83-243-191-191.fth.tafjordconnect.net) (Ping timeout: 245 seconds) |
| 2024-07-27 12:01:32 +0200 | aforemny | (~aforemny@2001:9e8:6cde:4700:6284:f31d:42a8:a868) |
| 2024-07-27 12:01:47 +0200 | aforemny_ | (~aforemny@2001:9e8:6cdd:9b00:67d0:27e6:eba2:1a90) (Ping timeout: 244 seconds) |
| 2024-07-27 12:12:53 +0200 | gmg | (~user@user/gehmehgeh) |
| 2024-07-27 12:13:35 +0200 | econo_ | (uid147250@id-147250.tinside.irccloud.com) (Quit: Connection closed for inactivity) |
| 2024-07-27 12:14:16 +0200 | takuan | (~takuan@178-116-218-225.access.telenet.be) |
| 2024-07-27 12:15:26 +0200 | danza | (~danza@151.47.28.68) (Quit: on the move) |
| 2024-07-27 12:18:25 +0200 | sindu | (~sindu@83-243-191-191.fth.tafjordconnect.net) |
| 2024-07-27 12:28:20 +0200 | euleritian | (~euleritia@77.22.252.56) (Ping timeout: 260 seconds) |
| 2024-07-27 12:29:08 +0200 | euleritian | (~euleritia@dynamic-176-006-138-243.176.6.pool.telefonica.de) |
| 2024-07-27 13:05:57 +0200 | sindu | (~sindu@83-243-191-191.fth.tafjordconnect.net) (Ping timeout: 248 seconds) |
| 2024-07-27 13:08:28 +0200 | bolivood | (~bolivood@2a0d:6fc2:5d11:200:dac:74e5:33ad:6838) |
| 2024-07-27 13:15:28 +0200 | danza | (~danza@151.47.28.68) |
| 2024-07-27 13:22:13 +0200 | sindu | (~sindu@83-243-191-191.fth.tafjordconnect.net) |
| 2024-07-27 13:27:50 +0200 | sindu | (~sindu@83-243-191-191.fth.tafjordconnect.net) (Ping timeout: 260 seconds) |
| 2024-07-27 13:29:09 +0200 | danza | (~danza@151.47.28.68) (Quit: glitching) |
| 2024-07-27 13:29:45 +0200 | danza | (~danza@151.47.28.68) |
| 2024-07-27 13:34:25 +0200 | danza | (~danza@151.47.28.68) (Client Quit) |
| 2024-07-27 13:35:28 +0200 | danza | (~danza@151.47.28.68) |
| 2024-07-27 13:39:56 +0200 | sindu | (~sindu@83-243-191-191.fth.tafjordconnect.net) |
| 2024-07-27 13:45:43 +0200 | CiaoSen | (~Jura@2a05:5800:2ea:1100:e6b9:7aff:fe80:3d03) (Ping timeout: 252 seconds) |
| 2024-07-27 13:47:00 +0200 | <Inst> | btw there's been no recent updates on graphql Rewriting it In Rust TM? |
| 2024-07-27 13:52:49 +0200 | aforemny | (~aforemny@2001:9e8:6cde:4700:6284:f31d:42a8:a868) (Ping timeout: 252 seconds) |
| 2024-07-27 13:56:08 +0200 | danza5049 | (~danza@151.47.19.9) |
| 2024-07-27 13:56:12 +0200 | danza | (~danza@151.47.28.68) (Read error: Connection reset by peer) |
| 2024-07-27 13:58:26 +0200 | danza5049 | danza |
| 2024-07-27 14:07:27 +0200 | aforemny | (~aforemny@2001:9e8:6cde:f100:f13d:7189:cb6f:5d03) |
| 2024-07-27 14:08:40 +0200 | danza | (~danza@151.47.19.9) (Quit: nap) |
| 2024-07-27 14:15:44 +0200 | chiselfuse | (~chiselfus@user/chiselfuse) (Remote host closed the connection) |
| 2024-07-27 14:16:48 +0200 | chiselfuse | (~chiselfus@user/chiselfuse) |
| 2024-07-27 14:18:59 +0200 | <probie> | Inst: Do you mean Hasura moving to Rust, or something else? |
| 2024-07-27 14:36:36 +0200 | <Inst> | yeah, i was suspecting it'd cost way more than anticipated and take longer than planned |
| 2024-07-27 14:36:40 +0200 | <Inst> | I don't see anything on graphql v3 |
| 2024-07-27 14:56:40 +0200 | L29Ah | (~L29Ah@wikipedia/L29Ah) (Read error: Connection reset by peer) |
| 2024-07-27 14:56:47 +0200 | noumenon | (~noumenon@113.51-175-156.customer.lyse.net) |
| 2024-07-27 14:57:29 +0200 | noumenon | (~noumenon@113.51-175-156.customer.lyse.net) (Remote host closed the connection) |
| 2024-07-27 15:01:39 +0200 | micro | (~micro@user/micro) (Ping timeout: 245 seconds) |
| 2024-07-27 15:02:39 +0200 | CrunchyFlakes | (~CrunchyFl@ip92348280.dynamic.kabel-deutschland.de) (Read error: Connection reset by peer) |
| 2024-07-27 15:05:11 +0200 | CrunchyFlakes | (~CrunchyFl@ip92348280.dynamic.kabel-deutschland.de) |
| 2024-07-27 15:07:30 +0200 | euleritian | (~euleritia@dynamic-176-006-138-243.176.6.pool.telefonica.de) (Ping timeout: 252 seconds) |
| 2024-07-27 15:15:39 +0200 | micro | (~micro@user/micro) |
| 2024-07-27 15:18:42 +0200 | cheater | (~Username@user/cheater) (Ping timeout: 276 seconds) |
| 2024-07-27 15:28:21 +0200 | myme | (~myme@2a01:799:d5c:5f00:4421:50a5:101e:8cb9) (Ping timeout: 248 seconds) |
| 2024-07-27 15:29:10 +0200 | myme | (~myme@2a01:799:d5c:5f00:8a75:ab8b:9550:20a2) |
| 2024-07-27 15:39:29 +0200 | L29Ah | (~L29Ah@wikipedia/L29Ah) |
| 2024-07-27 15:50:17 +0200 | noumenon | (~noumenon@113.51-175-156.customer.lyse.net) |
| 2024-07-27 16:04:04 +0200 | euleritian | (~euleritia@dynamic-176-006-138-243.176.6.pool.telefonica.de) |
| 2024-07-27 16:06:41 +0200 | CiaoSen | (~Jura@2a05:5800:2ea:1100:e6b9:7aff:fe80:3d03) |
| 2024-07-27 16:07:17 +0200 | Unicorn_Princess | (~Unicorn_P@user/Unicorn-Princess/x-3540542) (Remote host closed the connection) |
| 2024-07-27 16:15:36 +0200 | machinedgod | (~machinedg@d173-183-246-216.abhsia.telus.net) |
| 2024-07-27 16:42:51 +0200 | machinedgod | (~machinedg@d173-183-246-216.abhsia.telus.net) (Ping timeout: 244 seconds) |
| 2024-07-27 16:44:03 +0200 | danza | (~danza@151.47.19.9) |
| 2024-07-27 16:46:55 +0200 | Digitteknohippie | (~user@user/digit) |
| 2024-07-27 16:47:36 +0200 | Digit | (~user@user/digit) (Ping timeout: 252 seconds) |
| 2024-07-27 16:51:36 +0200 | billchenchina- | (~billchenc@118.38.173.226) |
| 2024-07-27 16:56:44 +0200 | Digitteknohippie | Digit |
| 2024-07-27 16:57:06 +0200 | Enrico63 | (~Enrico63@81.109.143.226) |
| 2024-07-27 16:58:18 +0200 | <Enrico63> | Hi, what's the best chatroom to ask about packages on hackage? I've just uploaded this (https://hackage.haskell.org/package/xnobar-0.0.0.0), but I have questions about it :) |
| 2024-07-27 16:58:46 +0200 | <Enrico63> | I mean, not questions about my own creation, ahah, but about how that page looks like |
| 2024-07-27 17:00:26 +0200 | <danza> | it looks broken. Those badges come from the README i suppose |
| 2024-07-27 17:03:30 +0200 | <danza> | and the module cannot be browsed. Maybe hackage failed, but not sure how to troubleshoot that besides trying a local build |
| 2024-07-27 17:03:35 +0200 | ell1 | (~ellie@user/ellie) |
| 2024-07-27 17:05:29 +0200 | ell | (~ellie@user/ellie) (Read error: Connection reset by peer) |
| 2024-07-27 17:05:29 +0200 | ell1 | ell |
| 2024-07-27 17:06:14 +0200 | <Enrico63> | Well, I've been using and building it on a daily basis :/ |
| 2024-07-27 17:06:42 +0200 | <Enrico63> | (But is this the right place for this topic?) |
| 2024-07-27 17:08:04 +0200 | <danza> | if there is no other conversation going on, i guess we can chat about that. There is also #hackage. Yeah maybe bthe bbuild works but the badges look failing, and maybe you did not build with haddock |
| 2024-07-27 17:08:25 +0200 | <danza> | (before i wanted to write "haddock failed") |
| 2024-07-27 17:08:56 +0200 | <Enrico63> | running cabal haddock in the shell succeeded |
| 2024-07-27 17:10:23 +0200 | <danza> | hmm yeah not sure how to troubleshoot that ... maybe in hindsight #hackage is better to ask for help. Admittedly i don't have much experience about that |
| 2024-07-27 17:10:28 +0200 | oo_miguel | (~Thunderbi@78.10.207.46) |
| 2024-07-27 17:13:08 +0200 | catties | civilization |
| 2024-07-27 17:13:23 +0200 | civilization | Catty |
| 2024-07-27 17:16:05 +0200 | CiaoSen | (~Jura@2a05:5800:2ea:1100:e6b9:7aff:fe80:3d03) (Ping timeout: 248 seconds) |
| 2024-07-27 17:19:14 +0200 | <Enrico63> | Thanks! :) |
| 2024-07-27 17:19:45 +0200 | danza | (~danza@151.47.19.9) (Changing host) |
| 2024-07-27 17:19:45 +0200 | danza | (~danza@user/danza) |
| 2024-07-27 17:20:32 +0200 | <danza> | well i did nothing :P |
| 2024-07-27 17:20:59 +0200 | <Enrico63> | Pointing me to the other room :P |
| 2024-07-27 17:22:37 +0200 | <danza> | well as i said i don't have much experience uploading so not sure how people address similar issues... i lurk in #hackage but don't recall chats about package errors. But maybe i just did not pay enough attention |
| 2024-07-27 17:23:05 +0200 | rvalue | (~rvalue@user/rvalue) (Ping timeout: 255 seconds) |
| 2024-07-27 17:23:19 +0200 | <tomsmeding> | Enrico63: er, what about clicking on the BuildFailed badge? https://hackage.haskell.org/package/xnobar-0.0.0.0/reports/2 |
| 2024-07-27 17:24:10 +0200 | <tomsmeding> | hackage is trying to build your package with base-4.18.1.0 (GHC 9.6.3), but your package's cabal file says it's only compatible with base < 4.18 (i.e. GHC < 9.6) |
| 2024-07-27 17:24:15 +0200 | <tomsmeding> | hence nothing works |
| 2024-07-27 17:25:25 +0200 | Square2 | (~Square@user/square) |
| 2024-07-27 17:25:38 +0200 | <tomsmeding> | danza: those badges are in the package description area -- the readme area is below all the metadata :) |
| 2024-07-27 17:25:59 +0200 | <tomsmeding> | hence I guessed that the badges were not from any readme but from hackage itself, and so it seems |
| 2024-07-27 17:26:51 +0200 | <danza> | thanks tomsmeding. Hadn't noticed them in other packages |
| 2024-07-27 17:27:31 +0200 | szkl | (uid110435@id-110435.uxbridge.irccloud.com) |
| 2024-07-27 17:27:32 +0200 | rvalue | (~rvalue@user/rvalue) |
| 2024-07-27 17:28:00 +0200 | <tomsmeding> | danza: I hadn't consciously noticed them either -- I conditioned myself to ignore such badges in github readmes because they never seemed to carry any info :p |
| 2024-07-27 17:28:17 +0200 | <tomsmeding> | but you explicitly mentioned badges, so I noticed them :p |
| 2024-07-27 17:28:43 +0200 | <tomsmeding> | I do wonder why hackage chose to use those badge images instead of putting this in metadata consistent with the rest of the interface |
| 2024-07-27 17:29:07 +0200 | <tomsmeding> | you get the "it's too obvious so I missed it" effect |
| 2024-07-27 17:30:06 +0200 | <danza> | i don't think it's a terrible idea anyways, lemme look some other package at random |
| 2024-07-27 17:30:35 +0200 | <Enrico63> | tomsmeding, does that mean I have to upload a new version already, if I want to fix? |
| 2024-07-27 17:30:44 +0200 | <Enrico63> | 0.0.0.0 sounded so good :/ |
| 2024-07-27 17:31:11 +0200 | <danza> | yeah they have always been there. Not beautiful but not awful either |
| 2024-07-27 17:31:16 +0200 | <tomsmeding> | I think only hackage admins have rights to update package metadata |
| 2024-07-27 17:31:22 +0200 | <tomsmeding> | without publishing a new version, that is |
| 2024-07-27 17:31:49 +0200 | <tomsmeding> | metadata revisions are like you see here under "Downloads": https://hackage.haskell.org/package/process |
| 2024-07-27 17:32:04 +0200 | <tomsmeding> | if you click "revised" you see that there's one metadata revision for this version of 'process' |
| 2024-07-27 17:32:17 +0200 | waleee | (~waleee@h-176-10-144-38.NA.cust.bahnhof.se) |
| 2024-07-27 17:32:27 +0200 | <tomsmeding> | oh |
| 2024-07-27 17:32:33 +0200 | <tomsmeding> | apparently package maintainers can also do that? |
| 2024-07-27 17:33:18 +0200 | <Enrico63> | Uh, I see it |
| 2024-07-27 17:34:12 +0200 | <tomsmeding> | Enrico63: go to your package page and click on "edit package information" under "Maintainer's Corner" |
| 2024-07-27 17:34:14 +0200 | <Enrico63> | It looks like I can modify the .cabal file directly from there |
| 2024-07-27 17:34:17 +0200 | <tomsmeding> | right |
| 2024-07-27 17:34:21 +0200 | <Enrico63> | yeah, yeah |
| 2024-07-27 17:34:25 +0200 | <tomsmeding> | (first time I go there too) |
| 2024-07-27 17:35:03 +0200 | <tomsmeding> | then to hope that hackage will actually do a rebuild upon metadata change |
| 2024-07-27 17:35:05 +0200 | <Enrico63> | What the heck, I do have to provide an upper bound! |
| 2024-07-27 17:35:17 +0200 | <tomsmeding> | hah, does it reject removing the upper bound? |
| 2024-07-27 17:35:22 +0200 | <Enrico63> | Yes... |
| 2024-07-27 17:35:31 +0200 | <tomsmeding> | '<5' is typical for base for "I dunno" |
| 2024-07-27 17:35:33 +0200 | <Enrico63> | Basically it will periodically break, won't it? :( |
| 2024-07-27 17:35:42 +0200 | <tomsmeding> | (stack generates this) |
| 2024-07-27 17:36:11 +0200 | <tomsmeding> | Enrico63: the idea of package bounds is that you only include versions you've tested with, so that people don't get broken build plans from the solver |
| 2024-07-27 17:36:27 +0200 | <tomsmeding> | so yes, that indeed means that things will periodically break and you have to continue testing with newer versions and bump bounds |
| 2024-07-27 17:36:32 +0200 | <tomsmeding> | in practice, however |
| 2024-07-27 17:36:46 +0200 | <tomsmeding> | this happens for actively maintained packages with maintainers that care about bounds |
| 2024-07-27 17:36:56 +0200 | <tomsmeding> | e.g. the boot packages like containers, process, text |
| 2024-07-27 17:37:39 +0200 | <tomsmeding> | if you are really quite sure that changes to 'base' will either break the entire world irrevocably or keep XNoBar working, feel free to put <5 there |
| 2024-07-27 17:38:19 +0200 | <Enrico63> | I've update to <5 |
| 2024-07-27 17:38:27 +0200 | <tomsmeding> | there is, by the way, also the option of uploading your own documentation to hackage for a package |
| 2024-07-27 17:38:30 +0200 | <tomsmeding> | there's docs about doing that somewhere |
| 2024-07-27 17:38:53 +0200 | <tomsmeding> | this is necessary if hackage can't build your package because e.g. you depend on some C system library that the hackage build machine doesn't have |
| 2024-07-27 17:38:54 +0200 | <Enrico63> | I wanted to try how good the automated thing would do |
| 2024-07-27 17:39:06 +0200 | <tomsmeding> | but making the automated thing work is always nicer |
| 2024-07-27 17:39:16 +0200 | <Enrico63> | I suppose I don't depend on such a thing, do I? :/ |
| 2024-07-27 17:39:26 +0200 | <tomsmeding> | we'll see :) |
| 2024-07-27 17:40:02 +0200 | <Enrico63> | The build banner shows still the old bound, I guess I just have to wait, right? |
| 2024-07-27 17:40:17 +0200 | <tomsmeding> | iirc hackage doesn't allow you to depend on internal libraries from other packages, but depending on internal libraries within your own package is probably fine |
| 2024-07-27 17:41:02 +0200 | <tomsmeding> | hackage tried to build your thing twice so far |
| 2024-07-27 17:41:07 +0200 | <tomsmeding> | https://hackage.haskell.org/package/xnobar-0.0.0.0/reports/ |
| 2024-07-27 17:41:19 +0200 | <tomsmeding> | probably good to give it a few hours, perhaps there's a build queue |
| 2024-07-27 17:41:29 +0200 | <Enrico63> | Yeah, I saw that before hasking, but I didn't really understand what it meant |
| 2024-07-27 17:41:31 +0200 | <Enrico63> | hasking, ahahah |
| 2024-07-27 17:41:33 +0200 | <tomsmeding> | :) |
| 2024-07-27 17:41:46 +0200 | <tomsmeding> | I don't know why it tried twice either |
| 2024-07-27 17:41:52 +0200 | <Enrico63> | Do you use xmobar by any chance? |
| 2024-07-27 17:41:56 +0200 | <tomsmeding> | no sorry |
| 2024-07-27 17:41:59 +0200 | <tomsmeding> | i3 user |
| 2024-07-27 17:42:03 +0200 | <Enrico63> | Ok, fair enough :) |
| 2024-07-27 17:42:12 +0200 | <Enrico63> | I was using that too, then I changed |
| 2024-07-27 17:43:00 +0200 | <Enrico63> | To xmonad, I mean. I wanted to have more control on things. Actually, what I'm really customizing a lot is just xmobar, not xmonad, really. |
| 2024-07-27 17:45:13 +0200 | <Enrico63> | Thank you very much for the explanations. I'll wait to see what happens to the build |
| 2024-07-27 17:45:21 +0200 | <tomsmeding> | hope it works :) |
| 2024-07-27 17:51:11 +0200 | Enrico63 | (~Enrico63@81.109.143.226) (Ping timeout: 256 seconds) |
| 2024-07-27 17:55:43 +0200 | danz38981 | (~danza@user/danza) |
| 2024-07-27 17:58:03 +0200 | danza | (~danza@user/danza) (Read error: Connection reset by peer) |
| 2024-07-27 17:58:34 +0200 | danz38981 | (~danza@user/danza) (Client Quit) |
| 2024-07-27 18:02:15 +0200 | Inst | (~Inst@user/Inst) (Remote host closed the connection) |
| 2024-07-27 18:02:43 +0200 | Inst | (~Inst@user/Inst) |
| 2024-07-27 18:04:15 +0200 | Inst | (~Inst@user/Inst) (Remote host closed the connection) |
| 2024-07-27 18:04:45 +0200 | Inst | (~Inst@user/Inst) |
| 2024-07-27 18:06:15 +0200 | Inst | (~Inst@user/Inst) (Remote host closed the connection) |
| 2024-07-27 18:06:42 +0200 | Inst | (~Inst@user/Inst) |
| 2024-07-27 18:14:27 +0200 | LawrenceBerkheim | (~LBerkheim@user/LawrenceBerkheim) |
| 2024-07-27 18:14:29 +0200 | <LawrenceBerkheim> | Good day gentlemen |
| 2024-07-27 18:14:34 +0200 | <LawrenceBerkheim> | Time to do some more haskell programming |
| 2024-07-27 18:23:38 +0200 | tzh | (~tzh@c-76-115-131-146.hsd1.or.comcast.net) |
| 2024-07-27 18:29:09 +0200 | ddellacosta | (~ddellacos@ool-44c73d29.dyn.optonline.net) (Ping timeout: 248 seconds) |
| 2024-07-27 18:31:17 +0200 | ddellacosta | (~ddellacos@ool-44c73d29.dyn.optonline.net) |
| 2024-07-27 18:42:43 +0200 | euleritian | (~euleritia@dynamic-176-006-138-243.176.6.pool.telefonica.de) (Ping timeout: 244 seconds) |
| 2024-07-27 18:45:06 +0200 | ddellacosta | (~ddellacos@ool-44c73d29.dyn.optonline.net) (Ping timeout: 265 seconds) |
| 2024-07-27 18:52:05 +0200 | ddellacosta | (~ddellacos@ool-44c73d29.dyn.optonline.net) |
| 2024-07-27 19:31:09 +0200 | JuanDaugherty | (~juan@user/JuanDaugherty) |
| 2024-07-27 19:35:04 +0200 | pavonia | (~user@user/siracusa) (Quit: Bye!) |
| 2024-07-27 19:38:38 +0200 | CrunchyFlakes | (~CrunchyFl@ip92348280.dynamic.kabel-deutschland.de) (Read error: Connection reset by peer) |
| 2024-07-27 19:38:48 +0200 | euleritian | (~euleritia@dynamic-176-006-138-243.176.6.pool.telefonica.de) |
| 2024-07-27 19:41:01 +0200 | CrunchyFlakes | (~CrunchyFl@146.52.130.128) |
| 2024-07-27 19:44:52 +0200 | CiaoSen | (~Jura@2a05:5800:2ea:1100:e6b9:7aff:fe80:3d03) |
| 2024-07-27 19:51:42 +0200 | LawrenceBerkheim | (~LBerkheim@user/LawrenceBerkheim) (Remote host closed the connection) |
| 2024-07-27 19:52:43 +0200 | <Inst> | heh, exceptions are useful for something, no? |
| 2024-07-27 19:53:21 +0200 | <Inst> | https://paste.tomsmeding.com/nml7kCLg |
| 2024-07-27 19:54:56 +0200 | <Inst> | ideally the exception checking would be handled by getnumber, but afaik that'd leak, and moreover, it'd attempt to do everything underneath the error handler code once the error was resolved |
| 2024-07-27 20:03:32 +0200 | peterbecich | (~Thunderbi@syn-047-229-123-186.res.spectrum.com) |
| 2024-07-27 20:05:15 +0200 | <hololeap> | you'd basically be replacing 'Maybe Double' with 'Either BadNumberException Double', which doesn't add much value |
| 2024-07-27 20:05:54 +0200 | <Inst> | this is just an idle exercise, but i was thinking |
| 2024-07-27 20:06:15 +0200 | <Inst> | let's say i want it to loop back to the start of the function if i received erroneous input |
| 2024-07-27 20:06:31 +0200 | <Inst> | XNonDecreasingIndentation works |
| 2024-07-27 20:07:08 +0200 | <Inst> | https://paste.tomsmeding.com/8AwxQHBi |
| 2024-07-27 20:07:14 +0200 | <Inst> | i know proper style is to avoid exceptions |
| 2024-07-27 20:07:27 +0200 | <hololeap> | unless you need the exception to carry something more than "nope, didn't work", Maybe works just fine |
| 2024-07-27 20:09:10 +0200 | <Inst> | i'm just wondering if you can get the second snippet to work without exceptions, i.e, maintain back to start logic without having to use annoying exceptions or memory leaking |
| 2024-07-27 20:09:25 +0200 | <geekosaur> | there's Cont if you don't mind leaking sanity |
| 2024-07-27 20:11:03 +0200 | <Inst> | as in, the cont type? |
| 2024-07-27 20:11:08 +0200 | <geekosaur> | yes |
| 2024-07-27 20:11:51 +0200 | <geekosaur> | lets you abort a computation with e.g. `Nothing` and the overlying logic can try again |
| 2024-07-27 20:12:27 +0200 | <Inst> | yeah i saw |
| 2024-07-27 20:12:29 +0200 | <Inst> | https://hackage.haskell.org/package/mtl-2.3.1/docs/Control-Monad-Cont.html |
| 2024-07-27 20:12:54 +0200 | <hololeap> | I'm not sure where the memory leak would be. 'first' and 'second' are going to be fully evaluated even with out the ! in front of them |
| 2024-07-27 20:15:03 +0200 | <hololeap> | since this is the IO monad, and order matters, so it has to evaluate those values in order to choose an execution path (somebody else can probably explain it in more accurate terms) |
| 2024-07-27 20:15:30 +0200 | <JuanDaugherty> | you can get actual leaks with just hs? |
| 2024-07-27 20:15:45 +0200 | <Inst> | the forcing isn't because of memory leaks, it's to force the thing to throw the exception asap |
| 2024-07-27 20:16:04 +0200 | <JuanDaugherty> | (as opposed to blowing up memory) |
| 2024-07-27 20:16:12 +0200 | <Inst> | otherwise it waits until the comparison before resetting |
| 2024-07-27 20:16:29 +0200 | <hololeap> | blowing up is just a leak in fast-motion |
| 2024-07-27 20:16:45 +0200 | <JuanDaugherty> | shit gets lost with leaks |
| 2024-07-27 20:17:01 +0200 | <Inst> | maybe what I actually want is ExceptT IO? |
| 2024-07-27 20:17:19 +0200 | gmg | (~user@user/gehmehgeh) (Remote host closed the connection) |
| 2024-07-27 20:17:20 +0200 | <Inst> | and giving up and just declaring I love monad transformers? |
| 2024-07-27 20:17:33 +0200 | <hololeap> | you might even try MaybeT and <|> to control the logic |
| 2024-07-27 20:18:01 +0200 | gmg | (~user@user/gehmehgeh) |
| 2024-07-27 20:19:31 +0200 | <monochrom> | Are you looking at the leak explained in my https://www.vex.net/~trebla/haskell/exception-tutorial.xhtml#catch ? The solution is to use try, not catch. |
| 2024-07-27 20:20:41 +0200 | <monochrom> | BTW you don't need !'s if you use readLn instead, it raises exceptions immediately. |
| 2024-07-27 20:21:17 +0200 | <monochrom> | In fact readLn has a well-defined order of I/O and raising exception, ! doesn't. |
| 2024-07-27 20:24:22 +0200 | <Inst> | i guess the issue is more that Haskell doesn't have while, and while you can substitute for it a bit with calling IO actions, it's not really the same as a goto because you end up returning |
| 2024-07-27 20:24:26 +0200 | <Inst> | that's what i mean by leaking |
| 2024-07-27 20:24:48 +0200 | <Inst> | you can be explicit in control flow but then you have indentations |
| 2024-07-27 20:25:52 +0200 | <monochrom> | The try version has no leak. The recursive call becomes a tail call, you get a while loop. |
| 2024-07-27 20:26:03 +0200 | <monochrom> | The catch version makes your recursive call non-tail. |
| 2024-07-27 20:26:38 +0200 | <monochrom> | You should stick to {try*, bracket*, finally} unless you really know why you have no option but to use catch directly. |
| 2024-07-27 20:27:17 +0200 | billchenchina- | (~billchenc@118.38.173.226) (Remote host closed the connection) |
| 2024-07-27 20:37:54 +0200 | CiaoSen | (~Jura@2a05:5800:2ea:1100:e6b9:7aff:fe80:3d03) (Ping timeout: 245 seconds) |
| 2024-07-27 20:40:43 +0200 | harveypwca | (~harveypwc@2601:246:d080:b40:1889:d9bf:2dd8:b288) |
| 2024-07-27 20:44:06 +0200 | <Inst> | yeah i tried to bite the bullet and use nondecreasingindentation, but it's now complaining? |
| 2024-07-27 20:44:51 +0200 | <Inst> | https://paste.tomsmeding.com/mFHBPeii |
| 2024-07-27 20:47:07 +0200 | <Inst> | does nondecreasingindentation simply not work on case? |
| 2024-07-27 20:50:26 +0200 | <geekosaur> | if you read the documentation, it applies specifically to `do` |
| 2024-07-27 20:50:37 +0200 | bitdex | (~bitdex@gateway/tor-sasl/bitdex) (Remote host closed the connection) |
| 2024-07-27 20:50:45 +0200 | <geekosaur> | "Specifically, the restriction that “a nested context must be indented further to the right than the enclosing context” is relaxed to allow the nested context to be at the same level as the enclosing context, if the enclosing context is a do expression." |
| 2024-07-27 20:51:17 +0200 | noumenon | (~noumenon@113.51-175-156.customer.lyse.net) (Read error: Connection reset by peer) |
| 2024-07-27 20:51:39 +0200 | bitdex | (~bitdex@gateway/tor-sasl/bitdex) |
| 2024-07-27 20:53:05 +0200 | <monochrom> | Ugh I see absolutely decresing indentation in that code. |
| 2024-07-27 20:53:40 +0200 | <Inst> | yeah, it's two levels |
| 2024-07-27 20:53:46 +0200 | <geekosaur> | (and afaict this exists solely so that you don't have to indent `else` in a multiline if-then-else in a `do`) |
| 2024-07-27 20:56:10 +0200 | <Inst> | https://gitlab.haskell.org/ghc/ghc/-/issues/20147 |
| 2024-07-27 20:56:13 +0200 | <monochrom> | Other people would be happy to show you how to indent this code properly. I won't, this is flawed logic in the first place --- why are you forcing the user to enter two numbers again from scratch just because they made a mistake in the 2nd number? |
| 2024-07-27 20:57:12 +0200 | <monochrom> | Instead, if you write one "readOneNumberUntilGood", then you simply have one single level of "x <- readOneNumberUntilGood; y <- readOneNumberUntilGood". |
| 2024-07-27 20:57:34 +0200 | <Inst> | i know, it's an obvious solution |
| 2024-07-27 20:57:45 +0200 | <Inst> | but the flawed logic created interesting problems that i wanted to solve |
| 2024-07-27 20:57:54 +0200 | <monochrom> | Inside readOneNumberUntilGood you just have one level of try-readLn or you can use readMaybe<$>getLine or anything. It won't suck. |
| 2024-07-27 20:58:43 +0200 | <monochrom> | If you really want on-error-start-from-scratch, that's the wrong code to write too. |
| 2024-07-27 20:59:21 +0200 | <monochrom> | You are supposed to have one single try around (read 1st number; read 2nd number), just like you had one single outer catch previously. |
| 2024-07-27 20:59:34 +0200 | <Inst> | ah, thanks |
| 2024-07-27 21:00:05 +0200 | jerg | (~jerg@2001:a61:247a:4700::bb0) (Ping timeout: 248 seconds) |
| 2024-07-27 21:05:23 +0200 | Enrico63 | (~Enrico63@81.109.143.226) |
| 2024-07-27 21:07:31 +0200 | <Enrico63> | tomsmeding, I suspect that updating only the package information is not enough to trigger a rebuild. Or 3 hours are not enough :D |
| 2024-07-27 21:17:13 +0200 | hololeap | . o ( https://bpa.st/ORTA ) |
| 2024-07-27 21:19:47 +0200 | L29Ah | (~L29Ah@wikipedia/L29Ah) () |
| 2024-07-27 21:19:52 +0200 | <tomsmeding> | Enrico63: click on that "edit package information" link again. See the bottom of that page. |
| 2024-07-27 21:20:03 +0200 | <tomsmeding> | (I'm discovering this stuff now too) |
| 2024-07-27 21:22:22 +0200 | JuanDaugherty | (~juan@user/JuanDaugherty) (Quit: JuanDaugherty) |
| 2024-07-27 21:24:04 +0200 | <Enrico63> | Done. But I'm not sure if there's a way to see the "in progress" build |
| 2024-07-27 21:24:20 +0200 | <Enrico63> | The list of reports still shows 2 rows |
| 2024-07-27 21:24:30 +0200 | <Enrico63> | Maybe it is trying right now |
| 2024-07-27 21:24:41 +0200 | <tomsmeding> | there is a build queue, but I don't know how long it is |
| 2024-07-27 21:24:44 +0200 | <Enrico63> | I suppose I'll find out |
| 2024-07-27 21:25:02 +0200 | <tomsmeding> | the "wait a few hours" resets now, I guess :p |
| 2024-07-27 21:25:17 +0200 | <monochrom> | :( |
| 2024-07-27 21:25:18 +0200 | <Enrico63> | ahahah, yeah, fair enough |
| 2024-07-27 21:25:38 +0200 | <Enrico63> | I'll go eat some dinner |
| 2024-07-27 21:25:46 +0200 | euleritian | (~euleritia@dynamic-176-006-138-243.176.6.pool.telefonica.de) (Read error: Connection reset by peer) |
| 2024-07-27 21:25:57 +0200 | <tomsmeding> | bon appetit :) |
| 2024-07-27 21:26:24 +0200 | ss4 | (~wootehfoo@user/wootehfoot) |
| 2024-07-27 21:26:57 +0200 | euleritian | (~euleritia@ip4d16fc38.dynamic.kabel-deutschland.de) |
| 2024-07-27 21:28:34 +0200 | wootehfoot | (~wootehfoo@user/wootehfoot) (Ping timeout: 244 seconds) |
| 2024-07-27 21:29:55 +0200 | Enrico63 | (~Enrico63@81.109.143.226) (Ping timeout: 256 seconds) |
| 2024-07-27 21:32:42 +0200 | <hololeap> | % :t (<*>) @((->) _) |
| 2024-07-27 21:32:42 +0200 | <yahb2> | (<*>) @((->) _) :: (w -> (a -> b)) -> (w -> a) -> w -> b |
| 2024-07-27 21:33:08 +0200 | <hololeap> | has anyone ever seen this used in the wild |
| 2024-07-27 21:33:28 +0200 | <hololeap> | in a way that made sense, not some obfuscation challenge |
| 2024-07-27 21:34:17 +0200 | hololeap | is just curious |
| 2024-07-27 21:35:03 +0200 | ss4 | (~wootehfoo@user/wootehfoot) (Ping timeout: 276 seconds) |
| 2024-07-27 21:40:32 +0200 | TactfulCitrus | (~al@2a02:8012:87a6:0:fbe0:6116:6e30:e047) |
| 2024-07-27 21:41:42 +0200 | michalz | (~michalz@185.246.207.218) |
| 2024-07-27 21:43:11 +0200 | TMA | (tma@twin.jikos.cz) (Ping timeout: 255 seconds) |
| 2024-07-27 21:44:27 +0200 | tram | (~tram@2a02:587:b43:7300:a89e:683a:2da1:a2ed) |
| 2024-07-27 21:44:55 +0200 | <ncf> | probably. i wouldn't be surprised if i saw that used in the agda codebase |
| 2024-07-27 21:45:09 +0200 | <mauke> | ah, good old S combinator |
| 2024-07-27 21:47:52 +0200 | <mauke> | did you know that the opposite of (<*>) is (=<<)? |
| 2024-07-27 21:48:16 +0200 | <ncf> | define opposite |
| 2024-07-27 21:49:49 +0200 | <ncf> | oh, (<*>) = (=<<) . flip and (=<<) = (<*>) . flip. neat |
| 2024-07-27 21:50:00 +0200 | <mauke> | (<*>) = \f g x -> f x (g x) |
| 2024-07-27 21:50:08 +0200 | <mauke> | (=<<) = \f g x -> f (g x) x |
| 2024-07-27 21:50:36 +0200 | <tram> | I'm writing my first parser and I came up with this: maybeTrash p = p *> pure () <|> pure ()! (type is Parser a -> Parser ()) Ok, I'm sure it's not a big deal, and maybe not good, but I feel like a genius, and I wanted to share the feeling before going out with friends that don't know Haskell... |
| 2024-07-27 21:50:40 +0200 | euleritian | (~euleritia@ip4d16fc38.dynamic.kabel-deutschland.de) (Read error: Connection reset by peer) |
| 2024-07-27 21:51:19 +0200 | <monochrom> | :) |
| 2024-07-27 21:51:24 +0200 | euleritian | (~euleritia@ip4d16fc38.dynamic.kabel-deutschland.de) |
| 2024-07-27 21:51:48 +0200 | <mauke> | :t optional |
| 2024-07-27 21:51:49 +0200 | <lambdabot> | Alternative f => f a -> f (Maybe a) |
| 2024-07-27 21:52:08 +0200 | <mauke> | :t \p -> optional p $> () |
| 2024-07-27 21:52:09 +0200 | <lambdabot> | error: |
| 2024-07-27 21:52:09 +0200 | <lambdabot> | • Variable not in scope: ($>) :: f (Maybe a) -> () -> t |
| 2024-07-27 21:52:09 +0200 | <lambdabot> | • Perhaps you meant one of these: |
| 2024-07-27 21:52:46 +0200 | <mauke> | :t \p -> optional p $> () |
| 2024-07-27 21:52:47 +0200 | <lambdabot> | Alternative f => f a -> f () |
| 2024-07-27 21:52:53 +0200 | <Inst> | hmmm, so when readLn fails, it throws an exception of type IOException? |
| 2024-07-27 21:53:51 +0200 | <ncf> | :t void . optional |
| 2024-07-27 21:53:52 +0200 | <lambdabot> | Alternative f => f a -> f () |
| 2024-07-27 21:54:01 +0200 | <ncf> | oops too late |
| 2024-07-27 21:55:33 +0200 | <tram> | mauke: :P nice! obviously it would be a thing. Haskell is too nice... |
| 2024-07-27 21:55:48 +0200 | <mauke> | Inst: yes |
| 2024-07-27 21:55:50 +0200 | <c_wraith> | Inst: I think it's documented as IOError, but that's the same type in GHC. |
| 2024-07-27 21:56:13 +0200 | <Inst> | is there a way to identify the exception type from GHCi? |
| 2024-07-27 21:56:20 +0200 | <mauke> | IOError is the "standard Haskell" type, which predates Exception IIRC |
| 2024-07-27 21:57:05 +0200 | ystael | (~ystael@user/ystael) |
| 2024-07-27 21:58:09 +0200 | <Inst> | also, you can't case over two different types of exceptions, right? |
| 2024-07-27 21:58:11 +0200 | <c_wraith> | Inst: no. The way GHC's exception mechanism works you can't identify the type of an error with any technique other than checking to see if it's a specific type |
| 2024-07-27 21:58:40 +0200 | <geekosaur> | IOError is from the Report. Exception/extensible exceptions came later (don't recall when but the publish date of RWH should be a good indicator because EE went in during printing) |
| 2024-07-27 21:59:45 +0200 | <c_wraith> | Inst: You can have handlers for multiple types of Exceptions, though. that's what `catches` does, for instance |
| 2024-07-27 22:00:45 +0200 | <c_wraith> | the documentation for catches ( https://hackage.haskell.org/package/base-4.20.0.1/docs/Control-Exception.html#v:catches ) shows the alternative |
| 2024-07-27 22:01:56 +0200 | <Inst> | yeah, but if you ask monochrom, then i should generally stick to try |
| 2024-07-27 22:02:24 +0200 | <c_wraith> | You can nest try too |
| 2024-07-27 22:03:13 +0200 | <c_wraith> | Though it's more common to just look for SomeException and then check for specific cases you care about |
| 2024-07-27 22:03:16 +0200 | stiell | (~stiell@gateway/tor-sasl/stiell) (Ping timeout: 260 seconds) |
| 2024-07-27 22:03:47 +0200 | <monochrom> | Would be nice if there were a "tries" analogous to "catches". |
| 2024-07-27 22:04:02 +0200 | <tram> | mauke: Ok, how can I "join" the result of optional wich is Maybe in my Parser wich is String -> Either e r |
| 2024-07-27 22:04:24 +0200 | <Inst> | interesting looking at the source code of catches |
| 2024-07-27 22:04:40 +0200 | <c_wraith> | monochrom: How do you type that - an open sum type? |
| 2024-07-27 22:05:05 +0200 | <monochrom> | catches already uses an existiential type "Handler". |
| 2024-07-27 22:05:20 +0200 | <c_wraith> | yeah, but that wouldn't help with tries |
| 2024-07-27 22:05:23 +0200 | <tram> | mauke: no that's not what I want... |
| 2024-07-27 22:05:36 +0200 | <tram> | nvm I'm late. thanks |
| 2024-07-27 22:05:37 +0200 | Enrico63 | (~Enrico63@81.109.143.226) |
| 2024-07-27 22:05:42 +0200 | tram | (~tram@2a02:587:b43:7300:a89e:683a:2da1:a2ed) () |
| 2024-07-27 22:06:09 +0200 | euleritian | (~euleritia@ip4d16fc38.dynamic.kabel-deutschland.de) (Read error: Connection reset by peer) |
| 2024-07-27 22:06:41 +0200 | euleritian | (~euleritia@ip4d16fc38.dynamic.kabel-deutschland.de) |
| 2024-07-27 22:07:48 +0200 | TMA | (tma@twin.jikos.cz) |
| 2024-07-27 22:09:21 +0200 | <c_wraith> | monochrom: tries would need to do some sort of trickery like (AllInstances Exception es) => IO a -> IO (Either (OneOf es) a) |
| 2024-07-27 22:11:55 +0200 | <c_wraith> | It's no wonder people just get SomeException and look for the cases they care about. Easier than using something like that. |
| 2024-07-27 22:13:40 +0200 | <mauke> | tries :: IO a -> [Handler e] -> IO (Either e a) |
| 2024-07-27 22:14:32 +0200 | <c_wraith> | that sort of loses the point of try |
| 2024-07-27 22:15:39 +0200 | <c_wraith> | try exists to make it clear what the scope of the error checking is - you get the exception or the value. Any errors caused by the handler are outside the scope of try, because there is no handler passed in. |
| 2024-07-27 22:15:42 +0200 | <mauke> | the alternative is to use more limited exception predicates and return SomeException, I think |
| 2024-07-27 22:15:51 +0200 | stiell | (~stiell@gateway/tor-sasl/stiell) |
| 2024-07-27 22:16:03 +0200 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 2024-07-27 22:16:13 +0200 | fr33domlover | (~fr33domlo@towards.vision) (Quit: The Lounge - https://thelounge.chat) |
| 2024-07-27 22:16:30 +0200 | <Inst> | hmmm, okay, and toEnum failure triggers the Errorcall datatype, which is nice |
| 2024-07-27 22:17:25 +0200 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) |
| 2024-07-27 22:19:44 +0200 | skyesoss | (~Thunderbi@c-73-208-45-119.hsd1.il.comcast.net) |
| 2024-07-27 22:20:20 +0200 | fr33domlover | (~fr33domlo@towards.vision) |
| 2024-07-27 22:23:41 +0200 | chiselfuse | (~chiselfus@user/chiselfuse) (Ping timeout: 260 seconds) |
| 2024-07-27 22:25:55 +0200 | chiselfuse | (~chiselfus@user/chiselfuse) |
| 2024-07-27 22:27:12 +0200 | target_i | (~target_i@user/target-i/x-6023099) |
| 2024-07-27 22:27:26 +0200 | peterbecich | (~Thunderbi@syn-047-229-123-186.res.spectrum.com) (Ping timeout: 265 seconds) |
| 2024-07-27 22:28:17 +0200 | Enrico63 | (~Enrico63@81.109.143.226) (Ping timeout: 256 seconds) |
| 2024-07-27 22:35:33 +0200 | tomku | (~tomku@user/tomku) (Ping timeout: 248 seconds) |
| 2024-07-27 22:35:46 +0200 | tomku | (~tomku@user/tomku) |
| 2024-07-27 22:39:23 +0200 | <Inst> | cool |
| 2024-07-27 22:39:32 +0200 | <Inst> | so that's why evaluate is there for (it's literally in the documentation) |
| 2024-07-27 22:39:59 +0200 | <Inst> | try $ evaluate =<< io action |
| 2024-07-27 22:40:06 +0200 | <c_wraith> | yep |
| 2024-07-27 22:41:02 +0200 | <c_wraith> | though be aware that sometimes you'll want to combine it with `force` from the deepseq package |
| 2024-07-27 22:41:24 +0200 | <Inst> | yeah i know, i used a ton of evaluate . force =<< in the past |
| 2024-07-27 22:41:24 +0200 | <c_wraith> | (or sometimes you'll want less of a sledgehammer and need to do a bunch of stuff by hand) |
| 2024-07-27 22:41:47 +0200 | <Inst> | basically i needed the result strict because otherwise it wouldn't trigger the exceptions I wanted |
| 2024-07-27 22:42:09 +0200 | <Inst> | so evaluate =<< forces the evaluation of data in the IO action |
| 2024-07-27 22:42:43 +0200 | <Inst> | letting try do its job instead of getting bypassed |
| 2024-07-27 22:47:29 +0200 | <monochrom> | In the case of "read <$> ..." you should use readLn or readIO instead. Or readMaybe and you get a Nothing/Just and it's pure, no exception needed. |
| 2024-07-27 22:47:54 +0200 | <Inst> | i'm using toEnum |
| 2024-07-27 22:48:28 +0200 | <monochrom> | OK then yeah evaluate is appropriate for toEnum errors or division by zero. |
| 2024-07-27 22:49:05 +0200 | <Inst> | also for tries, have you considered tryJust stacked? |
| 2024-07-27 22:49:44 +0200 | <monochrom> | I have. |
| 2024-07-27 22:50:04 +0200 | <monochrom> | But I am not sure you have the correct unstated assumption in the first place. |
| 2024-07-27 22:50:45 +0200 | <Inst> | i don't |
| 2024-07-27 22:50:51 +0200 | <monochrom> | Stacked tryJust has stacked semantics. Unstacked tryJust has unstacked semantics. |
| 2024-07-27 22:51:00 +0200 | koolazer | (~koo@user/koolazer) |
| 2024-07-27 22:52:37 +0200 | econo_ | (uid147250@id-147250.tinside.irccloud.com) |
| 2024-07-27 22:58:36 +0200 | TactfulCitrus | (~al@2a02:8012:87a6:0:fbe0:6116:6e30:e047) (Remote host closed the connection) |
| 2024-07-27 23:01:05 +0200 | cpressey | (~weechat@176.254.71.203) |
| 2024-07-27 23:03:20 +0200 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 2024-07-27 23:04:24 +0200 | cpressey | (~weechat@176.254.71.203) (Client Quit) |
| 2024-07-27 23:05:42 +0200 | takuan | (~takuan@178-116-218-225.access.telenet.be) (Remote host closed the connection) |
| 2024-07-27 23:12:26 +0200 | L29Ah | (~L29Ah@wikipedia/L29Ah) |
| 2024-07-27 23:13:56 +0200 | Midjak | (~MarciZ@82.66.147.146) (Quit: This computer has gone to sleep) |
| 2024-07-27 23:17:14 +0200 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) |
| 2024-07-27 23:18:13 +0200 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Client Quit) |
| 2024-07-27 23:20:14 +0200 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) |
| 2024-07-27 23:23:20 +0200 | michalz | (~michalz@185.246.207.218) (Quit: ZNC 1.9.0 - https://znc.in) |
| 2024-07-27 23:24:31 +0200 | <c_wraith> | Well. I got curious how awful it really would be, and... https://paste.tomsmeding.com/KdmeZ85v |
| 2024-07-27 23:24:59 +0200 | <c_wraith> | monochrom: ^ tries actually isn't that bad to use. It's more that it's a surprising amount of code to write |
| 2024-07-27 23:25:59 +0200 | <monochrom> | Oh... I see, you were aiming at type-level list of exception types. |
| 2024-07-27 23:26:49 +0200 | <c_wraith> | that's the obvious way to capture the semantics of try |
| 2024-07-27 23:30:13 +0200 | <c_wraith> | Honestly, it's probably slightly easier to use that than it is to manually write the type matching against SomeException yourself |
| 2024-07-27 23:35:14 +0200 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 2024-07-27 23:38:00 +0200 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) |
| 2024-07-27 23:44:03 +0200 | misterfish | (~misterfis@84.53.85.146) (Ping timeout: 252 seconds) |
| 2024-07-27 23:46:04 +0200 | <jle`> | kjkjkjkjjkk |
| 2024-07-27 23:47:33 +0200 | CrunchyFlakes | (~CrunchyFl@146.52.130.128) (Read error: Connection reset by peer) |
| 2024-07-27 23:50:28 +0200 | CrunchyFlakes | (~CrunchyFl@146.52.130.128) |
| 2024-07-27 23:53:53 +0200 | harveypwca | (~harveypwc@2601:246:d080:b40:1889:d9bf:2dd8:b288) (Quit: Leaving) |
| 2024-07-27 23:59:47 +0200 | <Inst> | really? |