| 2024-12-05 00:01:10 +0100 | cyanteeth | (~cyanteeth@user/cyanteeth) cyanteeth |
| 2024-12-05 00:01:27 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
| 2024-12-05 00:05:29 +0100 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 2024-12-05 00:06:28 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 252 seconds) |
| 2024-12-05 00:10:30 +0100 | cyanteeth | (~cyanteeth@user/cyanteeth) (Ping timeout: 252 seconds) |
| 2024-12-05 00:12:41 +0100 | poscat | (~poscat@user/poscat) poscat |
| 2024-12-05 00:15:04 +0100 | falafel | (~falafel@2603:8000:b4f0:62a0:2d1c:7dad:d29d:19e) (Ping timeout: 260 seconds) |
| 2024-12-05 00:17:13 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
| 2024-12-05 00:17:55 +0100 | poscat | (~poscat@user/poscat) (Ping timeout: 265 seconds) |
| 2024-12-05 00:23:46 +0100 | poscat | (~poscat@user/poscat) poscat |
| 2024-12-05 00:24:12 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 265 seconds) |
| 2024-12-05 00:26:21 +0100 | poscat | (~poscat@user/poscat) (Client Quit) |
| 2024-12-05 00:32:07 +0100 | poscat | (~poscat@user/poscat) poscat |
| 2024-12-05 00:35:17 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
| 2024-12-05 00:39:59 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 245 seconds) |
| 2024-12-05 00:47:12 +0100 | aztex | (~aztex@mob-194-230-148-208.cgn.sunrise.net) |
| 2024-12-05 00:50:50 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
| 2024-12-05 00:52:49 +0100 | Leary | (~Leary@user/Leary/x-0910699) Leary |
| 2024-12-05 00:55:14 +0100 | weary-traveler | (~user@user/user363627) (Remote host closed the connection) |
| 2024-12-05 00:55:54 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 260 seconds) |
| 2024-12-05 00:56:52 +0100 | peterbecich | (~Thunderbi@syn-047-229-123-186.res.spectrum.com) peterbecich |
| 2024-12-05 01:00:45 +0100 | sindu | (~sindu@176.75.224.1) (Ping timeout: 260 seconds) |
| 2024-12-05 01:02:37 +0100 | biberu\ | (~biberu@user/biberu) biberu |
| 2024-12-05 01:04:24 +0100 | <aztex> | Is it possible to have some kind of postcondition monad. Basically something which runs the monadic computation and then applies some postcondition on the generated value. |
| 2024-12-05 01:04:25 +0100 | <aztex> | Something like |
| 2024-12-05 01:04:25 +0100 | <aztex> | ``` |
| 2024-12-05 01:04:26 +0100 | <aztex> | newtype Foo s m a = Foo { runFoo :: (a -> Bool) -> s -> m (a, s) } |
| 2024-12-05 01:04:26 +0100 | <aztex> | ``` |
| 2024-12-05 01:04:50 +0100 | <aztex> | I am struggling to write the Monad instance for this |
| 2024-12-05 01:04:50 +0100 | <Axman6> | please don't paste multiple lines of code here (you don't need ``` on IRC) |
| 2024-12-05 01:05:07 +0100 | <aztex> | okay got it |
| 2024-12-05 01:05:10 +0100 | <geekosaur> | that wouldn't be a property of the Monad, but of the runner |
| 2024-12-05 01:05:12 +0100 | biberu | (~biberu@user/biberu) (Ping timeout: 244 seconds) |
| 2024-12-05 01:05:12 +0100 | biberu\ | biberu |
| 2024-12-05 01:05:18 +0100 | Homarid8 | (~Homarid8@85-76-108-84-nat.elisa-mobile.fi) |
| 2024-12-05 01:05:22 +0100 | <Homarid8> | @index liftM2 |
| 2024-12-05 01:05:22 +0100 | <lambdabot> | Control.Monad |
| 2024-12-05 01:05:33 +0100 | <geekosaur> | Monad gives you >>= which runs on every step, not an entire monadic computation |
| 2024-12-05 01:05:33 +0100 | <haskellbridge> | <sm> good thread: https://www.reddit.com/r/haskell/comments/1h5oxcg/do_you_think_haskell_will_become_more_mainstream |
| 2024-12-05 01:05:43 +0100 | <Axman6> | aztex: can you write fmap for that type? |
| 2024-12-05 01:06:17 +0100 | <aztex> | I am able to directly derive Functor |
| 2024-12-05 01:06:33 +0100 | <Axman6> | what about Applicative? |
| 2024-12-05 01:06:39 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
| 2024-12-05 01:06:57 +0100 | cyanteeth | (~cyanteeth@user/cyanteeth) cyanteeth |
| 2024-12-05 01:06:59 +0100 | <aztex> | didnt try writing Applicative. The main important thing for me is the Monad instance |
| 2024-12-05 01:07:08 +0100 | <geekosaur> | note that writing it yourself instead of deriving it will tell you things about your type |
| 2024-12-05 01:07:12 +0100 | <Homarid8> | @index ap |
| 2024-12-05 01:07:12 +0100 | <lambdabot> | Control.Monad |
| 2024-12-05 01:07:27 +0100 | <Axman6> | Homarid8: you can do that in /msg if that's all you're doing here |
| 2024-12-05 01:09:01 +0100 | cyanteeth | (~cyanteeth@user/cyanteeth) (Remote host closed the connection) |
| 2024-12-05 01:11:06 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 252 seconds) |
| 2024-12-05 01:11:55 +0100 | <aztex> | geekosaur what you said about "that wouldn't be a property of the Monad, but of the runner" makes sense |
| 2024-12-05 01:11:58 +0100 | <Axman6> | I'm unsure if that can be a monad - I guess the a in the predicate is in positive position... |
| 2024-12-05 01:13:34 +0100 | <Leary> | It's almost `SelectT Bool (StateT s m) a`, so it probably can. |
| 2024-12-05 01:13:47 +0100 | <aztex> | However the problem is that my runFoo :: Foo s m a -> (a -> Bool) -> s -> m (a, s) type would allow me to run the postcondition on the final resulting a |
| 2024-12-05 01:14:00 +0100 | <aztex> | I was hoping to do the postcondition check on every step of the >>= |
| 2024-12-05 01:14:12 +0100 | <probie> | what is the intended behaviour if it fails? |
| 2024-12-05 01:15:01 +0100 | <aztex> | Probably should add a Maybe there |
| 2024-12-05 01:15:03 +0100 | cyanteeth40 | (~cyanteeth@user/cyanteeth) cyanteeth |
| 2024-12-05 01:15:11 +0100 | <geekosaur> | hm, that's an interesting point. this might have been possible before MonadFail, but >>= can't assume MonadFail I think? |
| 2024-12-05 01:15:36 +0100 | <aztex> | newtype Foo s m a = Foo { runFoo :: (a -> Bool) -> s -> m (Maybe (a, s)) } |
| 2024-12-05 01:15:37 +0100 | <Leary> | You can always take an `Alternative` or `MonadFail` constraint on the `Monad` instance. |
| 2024-12-05 01:15:47 +0100 | <aztex> | so failure would be Nothing |
| 2024-12-05 01:15:52 +0100 | cyanteeth40 | cyanteeth |
| 2024-12-05 01:16:01 +0100 | mange | (~user@user/mange) mange |
| 2024-12-05 01:16:38 +0100 | <aztex> | Leary never came across SelectT |
| 2024-12-05 01:17:37 +0100 | cyanteeth | (~cyanteeth@user/cyanteeth) (Quit: Client closed) |
| 2024-12-05 01:17:48 +0100 | cyanteeth | (~cyanteeth@user/cyanteeth) cyanteeth |
| 2024-12-05 01:20:28 +0100 | cyanteeth | (~cyanteeth@user/cyanteeth) (Client Quit) |
| 2024-12-05 01:21:09 +0100 | cyanteeth5 | (~cyanteeth@user/cyanteeth) cyanteeth |
| 2024-12-05 01:22:00 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
| 2024-12-05 01:24:23 +0100 | sonolin | (~michael@user/sonolin) (Quit: WeeChat 4.4.3) |
| 2024-12-05 01:24:47 +0100 | sprotte24 | (~sprotte24@134.245.44.87) (Quit: Leaving) |
| 2024-12-05 01:25:41 +0100 | sonolin | (~michael@174-26-31-216.phnx.qwest.net) |
| 2024-12-05 01:26:13 +0100 | sonolin | (~michael@174-26-31-216.phnx.qwest.net) (Changing host) |
| 2024-12-05 01:26:13 +0100 | sonolin | (~michael@user/sonolin) sonolin |
| 2024-12-05 01:27:01 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 248 seconds) |
| 2024-12-05 01:29:07 +0100 | cyanteeth5 | bees |
| 2024-12-05 01:29:40 +0100 | bees | cyanteeth |
| 2024-12-05 01:30:17 +0100 | cyanteeth | (~cyanteeth@user/cyanteeth) (Quit: Client closed) |
| 2024-12-05 01:37:46 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
| 2024-12-05 01:37:54 +0100 | peterbecich | (~Thunderbi@syn-047-229-123-186.res.spectrum.com) (Ping timeout: 260 seconds) |
| 2024-12-05 01:39:32 +0100 | aztex | (~aztex@mob-194-230-148-208.cgn.sunrise.net) (Quit: Client closed) |
| 2024-12-05 01:40:55 +0100 | Smiles | (uid551636@id-551636.lymington.irccloud.com) (Quit: Connection closed for inactivity) |
| 2024-12-05 01:42:22 +0100 | dtman34 | (~dtman34@2601:447:d080:1a3c:67d0:baca:d09c:498d) (Quit: ZNC 1.8.2+deb3.1 - https://znc.in) |
| 2024-12-05 01:42:43 +0100 | dtman34 | (~dtman34@c-174-53-203-90.hsd1.mn.comcast.net) dtman34 |
| 2024-12-05 01:42:53 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 255 seconds) |
| 2024-12-05 01:44:51 +0100 | aztex | (~aztex@mob-194-230-148-208.cgn.sunrise.net) |
| 2024-12-05 01:45:01 +0100 | aztex | (~aztex@mob-194-230-148-208.cgn.sunrise.net) (Client Quit) |
| 2024-12-05 01:48:08 +0100 | <Homarid8> | data = transpose . reverse gives me parse error on input ‘=’ in ghci why is that? Data.List is imported |
| 2024-12-05 01:48:32 +0100 | <probie> | data is a keyword and not a valid variable name |
| 2024-12-05 01:48:35 +0100 | <Axman6> | data is a reserved word |
| 2024-12-05 01:48:50 +0100 | <Axman6> | data Bool = False | True |
| 2024-12-05 01:49:07 +0100 | <Homarid8> | Thanks, that makes sense |
| 2024-12-05 01:52:03 +0100 | troojg | (~troojg@user/troojg) troojg |
| 2024-12-05 01:53:34 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
| 2024-12-05 01:53:45 +0100 | tv | (~tv@user/tv) tv |
| 2024-12-05 01:54:59 +0100 | acidjnk_new3 | (~acidjnk@p200300d6e7283f433921c55fec8b6dfb.dip0.t-ipconnect.de) (Ping timeout: 245 seconds) |
| 2024-12-05 01:56:29 +0100 | Tuplanolla | (~Tuplanoll@91-159-69-59.elisa-laajakaista.fi) (Quit: Leaving.) |
| 2024-12-05 01:58:59 +0100 | alexherbo2 | (~alexherbo@2a02-8440-3118-f7e7-7572-88f5-5565-7769.rev.sfr.net) (Remote host closed the connection) |
| 2024-12-05 02:00:23 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 265 seconds) |
| 2024-12-05 02:11:37 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
| 2024-12-05 02:16:30 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 244 seconds) |
| 2024-12-05 02:17:55 +0100 | ezzieyguywuf | (~Unknown@user/ezzieyguywuf) ezzieyguywuf |
| 2024-12-05 02:19:10 +0100 | peterbecich | (~Thunderbi@syn-047-229-123-186.res.spectrum.com) peterbecich |
| 2024-12-05 02:27:23 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
| 2024-12-05 02:32:20 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 260 seconds) |
| 2024-12-05 02:36:33 +0100 | sonolin_ | (~michael@174-26-31-216.phnx.qwest.net) |
| 2024-12-05 02:37:03 +0100 | sonolin_ | (~michael@174-26-31-216.phnx.qwest.net) (Changing host) |
| 2024-12-05 02:37:03 +0100 | sonolin_ | (~michael@user/sonolin) sonolin |
| 2024-12-05 02:40:02 +0100 | sonolin | (~michael@user/sonolin) (Ping timeout: 248 seconds) |
| 2024-12-05 02:40:07 +0100 | sonolin_ | sonolin |
| 2024-12-05 02:43:10 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
| 2024-12-05 02:45:09 +0100 | troojg | (~troojg@user/troojg) (Ping timeout: 252 seconds) |
| 2024-12-05 02:46:31 +0100 | bitdex | (~bitdex@gateway/tor-sasl/bitdex) bitdex |
| 2024-12-05 02:48:10 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 252 seconds) |
| 2024-12-05 02:56:31 +0100 | peterbecich | (~Thunderbi@syn-047-229-123-186.res.spectrum.com) (Ping timeout: 264 seconds) |
| 2024-12-05 02:58:57 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
| 2024-12-05 03:03:50 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 260 seconds) |
| 2024-12-05 03:11:30 +0100 | st_aldini | (~Thunderbi@2605:a601:a07c:af00:edd4:453a:4c88:19a0) (Ping timeout: 248 seconds) |
| 2024-12-05 03:14:44 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
| 2024-12-05 03:16:02 +0100 | foul_owl | (~kerry@185.219.141.161) (Ping timeout: 252 seconds) |
| 2024-12-05 03:19:33 +0100 | billchenchina | (~billchenc@113.57.152.160) billchenchina |
| 2024-12-05 03:25:42 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 272 seconds) |
| 2024-12-05 03:31:07 +0100 | foul_owl | (~kerry@174-21-81-201.tukw.qwest.net) foul_owl |
| 2024-12-05 03:32:24 +0100 | billchenchina- | (~billchenc@103.118.42.229) billchenchina |
| 2024-12-05 03:34:39 +0100 | billchenchina | (~billchenc@113.57.152.160) (Ping timeout: 252 seconds) |
| 2024-12-05 03:35:55 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
| 2024-12-05 03:40:13 +0100 | Smiles | (uid551636@id-551636.lymington.irccloud.com) Smiles |
| 2024-12-05 03:40:57 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 252 seconds) |
| 2024-12-05 03:45:22 +0100 | AlexZenon | (~alzenon@5.139.233.9) (Ping timeout: 252 seconds) |
| 2024-12-05 03:45:41 +0100 | machinedgod | (~machinedg@d108-173-18-100.abhsia.telus.net) (Ping timeout: 248 seconds) |
| 2024-12-05 03:48:51 +0100 | billchenchina- | (~billchenc@103.118.42.229) (Remote host closed the connection) |
| 2024-12-05 03:49:28 +0100 | troojg | (~troojg@user/troojg) troojg |
| 2024-12-05 03:49:36 +0100 | AlexZenon | (~alzenon@5.139.233.9) |
| 2024-12-05 03:49:45 +0100 | OftenFaded | (~OftenFade@user/tisktisk) (Quit: Client closed) |
| 2024-12-05 03:51:43 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
| 2024-12-05 03:52:40 +0100 | Homarid8 | (~Homarid8@85-76-108-84-nat.elisa-mobile.fi) (Ping timeout: 240 seconds) |
| 2024-12-05 03:54:18 +0100 | foul_owl | (~kerry@174-21-81-201.tukw.qwest.net) (Ping timeout: 246 seconds) |
| 2024-12-05 03:55:38 +0100 | mauke | (~mauke@user/mauke) (Ping timeout: 252 seconds) |
| 2024-12-05 03:56:24 +0100 | mauke | (~mauke@user/mauke) mauke |
| 2024-12-05 03:56:53 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 248 seconds) |
| 2024-12-05 04:06:03 +0100 | td_ | (~td@i53870906.versanet.de) (Ping timeout: 265 seconds) |
| 2024-12-05 04:07:03 +0100 | foul_owl | (~kerry@185.219.141.161) foul_owl |
| 2024-12-05 04:07:32 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
| 2024-12-05 04:07:42 +0100 | td_ | (~td@i5387090D.versanet.de) td_ |
| 2024-12-05 04:12:18 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 248 seconds) |
| 2024-12-05 04:23:18 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
| 2024-12-05 04:26:40 +0100 | jle` | (~jle`@2603:8001:3b02:84d4:5110:3f6f:fbf2:ee63) (Ping timeout: 260 seconds) |
| 2024-12-05 04:27:06 +0100 | jle` | (~jle`@2603:8001:3b02:84d4:6ee:46b6:7128:c679) jle` |
| 2024-12-05 04:28:25 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 260 seconds) |
| 2024-12-05 04:29:45 +0100 | matsurago | (~matsurago@240b:10:b3a1:1700:b208:b72c:53fc:819f) |
| 2024-12-05 04:39:06 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
| 2024-12-05 04:45:45 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 246 seconds) |
| 2024-12-05 04:49:03 +0100 | troojg | (~troojg@user/troojg) (Ping timeout: 276 seconds) |
| 2024-12-05 04:55:31 +0100 | haritz | (~hrtz@user/haritz) (Ping timeout: 252 seconds) |
| 2024-12-05 04:55:57 +0100 | haritz | (~hrtz@82-69-11-11.dsl.in-addr.zen.co.uk) |
| 2024-12-05 04:56:00 +0100 | haritz | (~hrtz@82-69-11-11.dsl.in-addr.zen.co.uk) (Changing host) |
| 2024-12-05 04:56:00 +0100 | haritz | (~hrtz@user/haritz) haritz |
| 2024-12-05 04:57:09 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
| 2024-12-05 05:02:00 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 252 seconds) |
| 2024-12-05 05:02:44 +0100 | td_ | (~td@i5387090D.versanet.de) (Ping timeout: 252 seconds) |
| 2024-12-05 05:04:45 +0100 | td_ | (~td@i5387092C.versanet.de) |
| 2024-12-05 05:07:09 +0100 | Square | (~Square@user/square) Square |
| 2024-12-05 05:10:30 +0100 | poscat | (~poscat@user/poscat) (Ping timeout: 276 seconds) |
| 2024-12-05 05:12:56 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
| 2024-12-05 05:14:00 +0100 | stiell_ | (~stiell@gateway/tor-sasl/stiell) (Ping timeout: 264 seconds) |
| 2024-12-05 05:14:07 +0100 | stiell | (~stiell@gateway/tor-sasl/stiell) stiell |
| 2024-12-05 05:15:13 +0100 | poscat | (~poscat@user/poscat) poscat |
| 2024-12-05 05:17:26 +0100 | aforemny | (~aforemny@i577BEE5E.versanet.de) aforemny |
| 2024-12-05 05:17:29 +0100 | aforemny_ | (~aforemny@2001:9e8:6cc3:9500:59e1:615b:5b80:729c) (Ping timeout: 245 seconds) |
| 2024-12-05 05:18:18 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 276 seconds) |
| 2024-12-05 05:27:18 +0100 | peterbecich | (~Thunderbi@syn-047-229-123-186.res.spectrum.com) peterbecich |
| 2024-12-05 05:28:43 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
| 2024-12-05 05:30:44 +0100 | <Leary> | Is it just me, or should `do{} = pure ()`. |
| 2024-12-05 05:33:32 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 252 seconds) |
| 2024-12-05 05:37:03 +0100 | falafel | (~falafel@2603:8000:b4f0:62a0:b920:5a10:d45a:73eb) falafel |
| 2024-12-05 05:37:33 +0100 | <probie> | Allowing empty do blocks and assigning them meaning seems like an accident waiting to happen |
| 2024-12-05 05:40:24 +0100 | eL_Bart0 | (eL_Bart0@dietunichtguten.org) (Ping timeout: 276 seconds) |
| 2024-12-05 05:43:39 +0100 | <Leary> | I suppose beginners who're prone to layout errors would get worse error messages. No other issues spring to mind. |
| 2024-12-05 05:44:31 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
| 2024-12-05 05:46:07 +0100 | falafel | (~falafel@2603:8000:b4f0:62a0:b920:5a10:d45a:73eb) (Ping timeout: 252 seconds) |
| 2024-12-05 05:49:09 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 245 seconds) |
| 2024-12-05 05:51:18 +0100 | <probie> | but what do you gain from it? |
| 2024-12-05 05:51:39 +0100 | <probie> | It's not a `do` block normally ends with an implicit `pure ()` |
| 2024-12-05 05:51:46 +0100 | <probie> | s/not a/not like a/ |
| 2024-12-05 05:57:30 +0100 | <Leary> | It seems morally correct (you can think of a do block /opening/ with a implicit `pure ()`), and it's prettier in some contexts. |
| 2024-12-05 06:00:17 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
| 2024-12-05 06:01:37 +0100 | Pixi` | (~Pixi@user/pixi) Pixi |
| 2024-12-05 06:02:09 +0100 | zmt01 | (~zmt00@user/zmt00) zmt00 |
| 2024-12-05 06:02:11 +0100 | homo_ | (~homo@82-128-196-26.bb.dnainternet.fi) |
| 2024-12-05 06:02:25 +0100 | sam113102 | (~sam@modemcable220.199-203-24.mc.videotron.ca) sam113101 |
| 2024-12-05 06:02:46 +0100 | homo_ | (~homo@82-128-196-26.bb.dnainternet.fi) (Changing host) |
| 2024-12-05 06:02:46 +0100 | homo_ | (~homo@user/homo) homo |
| 2024-12-05 06:03:06 +0100 | astra | (sid289983@user/amish) (Ping timeout: 246 seconds) |
| 2024-12-05 06:03:08 +0100 | falafel | (~falafel@2603:8000:b4f0:62a0:51d5:65dc:cf2e:603c) falafel |
| 2024-12-05 06:03:08 +0100 | ShannonB2 | (~ShannonB@user/ShannonB) ShannonB |
| 2024-12-05 06:03:09 +0100 | JamesMowery439 | (~JamesMowe@ip68-228-212-232.ph.ph.cox.net) JamesMowery |
| 2024-12-05 06:03:13 +0100 | gabiruh | (~gabiruh@vps19177.publiccloud.com.br) (Ping timeout: 252 seconds) |
| 2024-12-05 06:03:17 +0100 | econo_ | (uid147250@id-147250.tinside.irccloud.com) (Ping timeout: 248 seconds) |
| 2024-12-05 06:03:17 +0100 | haskellbridge | (~hackager@syn-024-093-192-219.res.spectrum.com) (Ping timeout: 248 seconds) |
| 2024-12-05 06:03:17 +0100 | arkeet | (~arkeet@moriya.ca) (Ping timeout: 248 seconds) |
| 2024-12-05 06:03:17 +0100 | degraafk | (sid71464@id-71464.lymington.irccloud.com) (Ping timeout: 248 seconds) |
| 2024-12-05 06:03:21 +0100 | edwardk | (sid47016@haskell/developer/edwardk) (Read error: Connection reset by peer) |
| 2024-12-05 06:03:21 +0100 | dy | (sid3438@user/dy) (Read error: Connection reset by peer) |
| 2024-12-05 06:03:21 +0100 | buhman | (sid411355@user/buhman) (Read error: Connection reset by peer) |
| 2024-12-05 06:03:22 +0100 | jackdk | (sid373013@cssa/jackdk) (Read error: Connection reset by peer) |
| 2024-12-05 06:03:22 +0100 | hovsater | (sid499516@user/hovsater) (Read error: Connection reset by peer) |
| 2024-12-05 06:03:22 +0100 | Boarders_____ | (sid425905@id-425905.lymington.irccloud.com) (Read error: Connection reset by peer) |
| 2024-12-05 06:03:22 +0100 | Adeon | (sid418992@id-418992.lymington.irccloud.com) (Read error: Connection reset by peer) |
| 2024-12-05 06:03:22 +0100 | monochrm | (trebla@216.138.220.146) |
| 2024-12-05 06:03:22 +0100 | b20n | (sid115913@id-115913.uxbridge.irccloud.com) (Read error: Connection reset by peer) |
| 2024-12-05 06:03:24 +0100 | tnks | (sid412124@id-412124.helmsley.irccloud.com) (Ping timeout: 272 seconds) |
| 2024-12-05 06:03:29 +0100 | econo_ | (uid147250@id-147250.tinside.irccloud.com) |
| 2024-12-05 06:03:31 +0100 | edwardk | (sid47016@haskell/developer/edwardk) edwardk |
| 2024-12-05 06:03:32 +0100 | dy | (sid3438@user/dy) \\\\\ |
| 2024-12-05 06:03:32 +0100 | degraafk | (sid71464@id-71464.lymington.irccloud.com) degraafk |
| 2024-12-05 06:03:33 +0100 | b20n | (sid115913@id-115913.uxbridge.irccloud.com) b20n |
| 2024-12-05 06:03:33 +0100 | hovsater | (sid499516@user/hovsater) hovsater |
| 2024-12-05 06:03:34 +0100 | Adeon | (sid418992@id-418992.lymington.irccloud.com) Adeon |
| 2024-12-05 06:03:34 +0100 | jackdk | (sid373013@cssa/jackdk) jackdk |
| 2024-12-05 06:03:35 +0100 | Boarders_____ | (sid425905@id-425905.lymington.irccloud.com) |
| 2024-12-05 06:03:35 +0100 | Smiles | (uid551636@id-551636.lymington.irccloud.com) (Ping timeout: 252 seconds) |
| 2024-12-05 06:03:36 +0100 | haskellbridge | (~hackager@syn-024-093-192-219.res.spectrum.com) hackager |
| 2024-12-05 06:03:36 +0100 | ChanServ | +v haskellbridge |
| 2024-12-05 06:03:39 +0100 | buhman | (sid411355@user/buhman) buhman |
| 2024-12-05 06:03:44 +0100 | bw | (sid2730@user/betawaffle) (Ping timeout: 264 seconds) |
| 2024-12-05 06:03:44 +0100 | SanchayanMaity | (sid478177@id-478177.hampstead.irccloud.com) (Ping timeout: 264 seconds) |
| 2024-12-05 06:03:48 +0100 | olivial | (~benjaminl@user/benjaminl) (Ping timeout: 246 seconds) |
| 2024-12-05 06:03:48 +0100 | delyan_ | (sid523379@id-523379.hampstead.irccloud.com) (Ping timeout: 246 seconds) |
| 2024-12-05 06:03:49 +0100 | sam113101 | (~sam@modemcable220.199-203-24.mc.videotron.ca) (Read error: Connection reset by peer) |
| 2024-12-05 06:03:51 +0100 | sam113102 | sam113101 |
| 2024-12-05 06:04:13 +0100 | lbseale | (~quassel@user/ep1ctetus) (Remote host closed the connection) |
| 2024-12-05 06:04:19 +0100 | gabiruh | (~gabiruh@vps19177.publiccloud.com.br) gabiruh |
| 2024-12-05 06:04:19 +0100 | arkeet | (~arkeet@moriya.ca) |
| 2024-12-05 06:04:30 +0100 | delyan_ | (sid523379@id-523379.hampstead.irccloud.com) |
| 2024-12-05 06:04:30 +0100 | sonolin | (~michael@user/sonolin) (Ping timeout: 246 seconds) |
| 2024-12-05 06:04:30 +0100 | Pixi | (~Pixi@user/pixi) (Ping timeout: 246 seconds) |
| 2024-12-05 06:04:30 +0100 | pabs3 | (~pabs3@user/pabs3) (Ping timeout: 246 seconds) |
| 2024-12-05 06:04:30 +0100 | abrar | (~abrar@pool-72-78-199-167.phlapa.fios.verizon.net) (Ping timeout: 246 seconds) |
| 2024-12-05 06:04:33 +0100 | astra | (sid289983@id-289983.hampstead.irccloud.com) |
| 2024-12-05 06:04:51 +0100 | Ekho | (~Ekho@user/ekho) (Ping timeout: 246 seconds) |
| 2024-12-05 06:04:51 +0100 | monochrom | (trebla@216.138.220.146) (Ping timeout: 246 seconds) |
| 2024-12-05 06:04:51 +0100 | acarrico | (~acarrico@dhcp-209-99-192-63.greenmountainaccess.net) (Ping timeout: 246 seconds) |
| 2024-12-05 06:04:51 +0100 | joeyh | (~joeyh@kitenet.net) (Ping timeout: 246 seconds) |
| 2024-12-05 06:04:52 +0100 | monochrm | monochrom |
| 2024-12-05 06:04:53 +0100 | zmt00 | (~zmt00@user/zmt00) (Ping timeout: 248 seconds) |
| 2024-12-05 06:04:53 +0100 | JamesMowery43 | (~JamesMowe@ip68-228-212-232.ph.ph.cox.net) (Ping timeout: 248 seconds) |
| 2024-12-05 06:04:53 +0100 | JamesMowery439 | JamesMowery43 |
| 2024-12-05 06:04:54 +0100 | joeyh_ | (~joeyh@kitenet.net) |
| 2024-12-05 06:04:58 +0100 | r-sta | (~r-sta@sgyl-37-b2-v4wan-168528-cust2421.vm6.cable.virginm.net) |
| 2024-12-05 06:05:03 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 252 seconds) |
| 2024-12-05 06:05:16 +0100 | pavonia | (~user@user/siracusa) (Quit: Bye!) |
| 2024-12-05 06:05:19 +0100 | ShannonB | (~ShannonB@user/ShannonB) (Ping timeout: 272 seconds) |
| 2024-12-05 06:05:19 +0100 | tnks | (sid412124@id-412124.helmsley.irccloud.com) tnks |
| 2024-12-05 06:05:19 +0100 | ShannonB2 | ShannonB |
| 2024-12-05 06:05:28 +0100 | lbseale | (~quassel@user/ep1ctetus) ep1ctetus |
| 2024-12-05 06:05:53 +0100 | homo | (~homo@user/homo) (Ping timeout: 248 seconds) |
| 2024-12-05 06:06:13 +0100 | <r-sta> | i was talking to Axeman6 about hackage repos. he said my example was no good, but I have something else which might work. ill link a repo 1 sec |
| 2024-12-05 06:06:24 +0100 | bw | (sid2730@user/betawaffle) betawaffle |
| 2024-12-05 06:06:29 +0100 | SanchayanMaity | (sid478177@id-478177.hampstead.irccloud.com) SanchayanMaity |
| 2024-12-05 06:06:38 +0100 | sonolin | (~michael@174-26-31-216.phnx.qwest.net) |
| 2024-12-05 06:06:45 +0100 | abrar | (~abrar@pool-72-78-199-167.phlapa.fios.verizon.net) |
| 2024-12-05 06:06:47 +0100 | homo_ | homo |
| 2024-12-05 06:06:53 +0100 | olivial | (~benjaminl@user/benjaminl) benjaminl |
| 2024-12-05 06:07:08 +0100 | Smiles | (uid551636@id-551636.lymington.irccloud.com) Smiles |
| 2024-12-05 06:08:06 +0100 | pabs3 | (~pabs3@user/pabs3) pabs3 |
| 2024-12-05 06:08:26 +0100 | <r-sta> | https://github.com/munston/store/tree/main/store |
| 2024-12-05 06:08:44 +0100 | acarrico | (~acarrico@dhcp-209-99-192-63.greenmountainaccess.net) |
| 2024-12-05 06:10:14 +0100 | <haskellbridge> | <sm> an automated persistent values kind of thing ? |
| 2024-12-05 06:11:10 +0100 | Ekho- | (~Ekho@user/ekho) Ekho |
| 2024-12-05 06:11:55 +0100 | forell | (~forell@user/forell) (Quit: ZNC - https://znc.in) |
| 2024-12-05 06:12:19 +0100 | forell | (~forell@user/forell) forell |
| 2024-12-05 06:13:20 +0100 | peterbecich | (~Thunderbi@syn-047-229-123-186.res.spectrum.com) (Ping timeout: 255 seconds) |
| 2024-12-05 06:16:04 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
| 2024-12-05 06:16:20 +0100 | <r-sta> | is this the kind of thing that could make a good library to put on hackage? |
| 2024-12-05 06:17:05 +0100 | <haskellbridge> | <sm> maybe some day r-sta |
| 2024-12-05 06:17:23 +0100 | <r-sta> | not today? |
| 2024-12-05 06:18:01 +0100 | <haskellbridge> | <sm> I wouldn't |
| 2024-12-05 06:18:01 +0100 | <r-sta> | what do you mean about persistent values? |
| 2024-12-05 06:18:09 +0100 | <r-sta> | fair |
| 2024-12-05 06:19:00 +0100 | <r-sta> | its supposed to be the core of my project |
| 2024-12-05 06:19:12 +0100 | Smiles | (uid551636@id-551636.lymington.irccloud.com) (Quit: Connection closed for inactivity) |
| 2024-12-05 06:19:20 +0100 | <r-sta> | its so abstract and generally useful i thought it might make a good shared library |
| 2024-12-05 06:19:59 +0100 | <r-sta> | because its not actually specific to the project, it has none of its domain restriction to particular application |
| 2024-12-05 06:20:00 +0100 | <haskellbridge> | <sm> I am imagining you're making a thing where you can declare types with a special Class and any values of those types are automatically saved and reloaded (making them "persistent") using hidden IO. Did I guess right ? |
| 2024-12-05 06:20:20 +0100 | falafel | (~falafel@2603:8000:b4f0:62a0:51d5:65dc:cf2e:603c) (Remote host closed the connection) |
| 2024-12-05 06:20:25 +0100 | <r-sta> | yeah. |
| 2024-12-05 06:20:29 +0100 | <r-sta> | disconcertingly so |
| 2024-12-05 06:20:33 +0100 | <r-sta> | is this a common thing? |
| 2024-12-05 06:20:41 +0100 | falafel | (~falafel@2603:8000:b4f0:62a0:90bb:2f36:5363:97ac) falafel |
| 2024-12-05 06:20:46 +0100 | <r-sta> | am i reinventing the wheel? |
| 2024-12-05 06:20:53 +0100 | <r-sta> | hows my implementation... seems ok |
| 2024-12-05 06:21:41 +0100 | <haskellbridge> | <sm> it's a pretty common concept in general, though usually it's not automatic/hidden. "ORM" is a related term to search for, which usually saves values/objects in a database |
| 2024-12-05 06:21:43 +0100 | <r-sta> | the way i ended up having it was you save all the updates, and can map over all of them, or just use the most recent to advance to produce the next, in the cascade |
| 2024-12-05 06:22:13 +0100 | <haskellbridge> | <sm> if you've got it working, a good next step would be to add some tiny example apps (like a todo list) |
| 2024-12-05 06:22:19 +0100 | <r-sta> | hmm, ORM seems a bit oop |
| 2024-12-05 06:22:34 +0100 | <r-sta> | sm: it has a working example |
| 2024-12-05 06:22:38 +0100 | <r-sta> | its just an incrament |
| 2024-12-05 06:22:55 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 264 seconds) |
| 2024-12-05 06:23:09 +0100 | <haskellbridge> | <sm> https://hackage.haskell.org/package/persistent is one well-known "ORM" for haskell |
| 2024-12-05 06:23:24 +0100 | <r-sta> | eg: testStore2 = cascade False incramentTestStore |
| 2024-12-05 06:23:30 +0100 | <haskellbridge> | <sm> I don't know if there's anything lightweight like yours on hackage - worth searching |
| 2024-12-05 06:23:51 +0100 | <r-sta> | its brutal |
| 2024-12-05 06:23:55 +0100 | <r-sta> | i have no idea what its doing |
| 2024-12-05 06:24:25 +0100 | <haskellbridge> | <sm> maybe this ? https://hackage.haskell.org/package/vault |
| 2024-12-05 06:24:25 +0100 | <r-sta> | ... |
| 2024-12-05 06:24:43 +0100 | <r-sta> | it makes weird mutability |
| 2024-12-05 06:24:47 +0100 | <haskellbridge> | <sm> if yours works, congrats! That's cool |
| 2024-12-05 06:24:56 +0100 | <r-sta> | its a bit limited |
| 2024-12-05 06:25:17 +0100 | <r-sta> | id like to understand the implications of the mutability more |
| 2024-12-05 06:25:26 +0100 | <r-sta> | its messing with my head because im used to haskell being pure |
| 2024-12-05 06:26:33 +0100 | <r-sta> | valult looks cool, but it uses overwrites |
| 2024-12-05 06:27:10 +0100 | <r-sta> | my thing is like, kind of like a Map, but where all the previous inserts are stored |
| 2024-12-05 06:27:17 +0100 | <haskellbridge> | <sm> oh you store with a append-only journal/event log ? |
| 2024-12-05 06:27:34 +0100 | <r-sta> | its like a versioning |
| 2024-12-05 06:27:46 +0100 | <haskellbridge> | <sm> that's cool too. I used that to save a game's info |
| 2024-12-05 06:27:48 +0100 | <r-sta> | they are updated parameters from learning in my use case |
| 2024-12-05 06:28:22 +0100 | <r-sta> | i guess it solves basically the "i want to write here, but there is something already here" problem |
| 2024-12-05 06:28:55 +0100 | <r-sta> | another good example was trading data, which is obtained over previous day intervals |
| 2024-12-05 06:29:11 +0100 | <r-sta> | the storeMap could allow the format to be changed over the entire store |
| 2024-12-05 06:29:26 +0100 | <r-sta> | subsequent server calls, for incramented day intervals |
| 2024-12-05 06:30:10 +0100 | <r-sta> | this version does not use the cascade, which provides the previous value, to obtain the next, which uses an IO server call |
| 2024-12-05 06:30:27 +0100 | <r-sta> | im having difficulty at the moment doing something like combinatorics |
| 2024-12-05 06:30:33 +0100 | <r-sta> | eg zipping 2 cascades |
| 2024-12-05 06:31:01 +0100 | califax | (~califax@user/califx) (Remote host closed the connection) |
| 2024-12-05 06:31:05 +0100 | <r-sta> | i have a self updating object, cascading along in a store, and its also producing updates to the parameters of a test object in another store |
| 2024-12-05 06:31:20 +0100 | califax | (~califax@user/califx) califx |
| 2024-12-05 06:31:39 +0100 | <r-sta> | and to make matters worse, they are both ensemble objects, with all the components needing their own stores |
| 2024-12-05 06:32:12 +0100 | <r-sta> | since if you train only one object in a mixture, it just saves to that store, in this mutable way, so you dont need to replace it to the source |
| 2024-12-05 06:32:50 +0100 | <haskellbridge> | <sm> perhaps simplifying could help |
| 2024-12-05 06:33:06 +0100 | <r-sta> | it seems like its a horrible combination algebra |
| 2024-12-05 06:33:26 +0100 | <r-sta> | parallel things in mixtures, bluagh |
| 2024-12-05 06:33:54 +0100 | <r-sta> | i think the mutability thing is meaning i cant conceptualise even the zip properly |
| 2024-12-05 06:34:07 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
| 2024-12-05 06:34:26 +0100 | <r-sta> | the whole idea of having a source to read from, but not needing to access that to write saves |
| 2024-12-05 06:34:56 +0100 | <r-sta> | i only read and not write an object so its leaving something dangling sort of |
| 2024-12-05 06:35:08 +0100 | <r-sta> | not like a simple parallel zip |
| 2024-12-05 06:35:16 +0100 | <haskellbridge> | <sm> there's a great saying, have you heard it ? Do The Simplest Thing That Could Possibly Work |
| 2024-12-05 06:35:52 +0100 | <haskellbridge> | <sm> +(https://wiki.c2.com/?DoTheSimplestThingThatCouldPossiblyWork) |
| 2024-12-05 06:36:03 +0100 | <r-sta> | what about "find the underlying abstraction at all costs" |
| 2024-12-05 06:36:39 +0100 | <r-sta> | might not be a contradiction |
| 2024-12-05 06:36:40 +0100 | <haskellbridge> | <sm> the former could be a stepping stone toward the latter.. you can't always just find the abstraction in one go |
| 2024-12-05 06:37:03 +0100 | <r-sta> | but it would likely be the simpler option were it available |
| 2024-12-05 06:37:55 +0100 | <r-sta> | one part has a buffer of machines that opperate in a ring with a comunication scanner sharing data between them in a 2 state deepstate system, with the machines connected in series |
| 2024-12-05 06:38:29 +0100 | <r-sta> | they output samples and comunication vectors which the scanner takes and passes as input to the next in the series, along with the error addorned sample from the proposal output |
| 2024-12-05 06:38:50 +0100 | <r-sta> | i need to store, the machines, and the communication scanner for the ring |
| 2024-12-05 06:38:52 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 272 seconds) |
| 2024-12-05 06:39:22 +0100 | <r-sta> | when i update the entire parametrization, then each of the stores needs to be updated |
| 2024-12-05 06:39:59 +0100 | <r-sta> | i guess it makes a difference that my ensemble containers have combined support coeffecients |
| 2024-12-05 06:40:01 +0100 | <haskellbridge> | <sm> that link is well worth reading some time, it's not as trivial as it might sound |
| 2024-12-05 06:40:14 +0100 | <haskellbridge> | <sm> afk a bit, good luck |
| 2024-12-05 06:40:52 +0100 | <r-sta> | this means that they are all updated simultaniously, and all the stores need to be aswell |
| 2024-12-05 06:41:11 +0100 | <r-sta> | maybe the first step to a simple algebra, is just having several stores saved to at once |
| 2024-12-05 06:41:34 +0100 | <r-sta> | but then they kind of dont cascade properly |
| 2024-12-05 06:42:27 +0100 | <r-sta> | i cant quite interlace the parallelism |
| 2024-12-05 06:43:06 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
| 2024-12-05 06:43:11 +0100 | <r-sta> | or maybe i should just abandon the idea of the cascade, since this just goes along one store |
| 2024-12-05 06:43:41 +0100 | <r-sta> | i can do something like reading in all the different stores at the same time |
| 2024-12-05 06:43:54 +0100 | <r-sta> | like, all the seperately stored mixture components |
| 2024-12-05 06:44:42 +0100 | <r-sta> | but if they are sequencing through, as in buffering over a stream, then after the store is read from, it is not written to in the manner of a cascade |
| 2024-12-05 06:44:52 +0100 | <r-sta> | i cant quite square the circle on that one |
| 2024-12-05 06:47:57 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 252 seconds) |
| 2024-12-05 06:50:25 +0100 | sonolin | (~michael@174-26-31-216.phnx.qwest.net) (Quit: WeeChat 4.4.3) |
| 2024-12-05 06:53:39 +0100 | michalz | (~michalz@185.246.207.222) |
| 2024-12-05 06:58:51 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
| 2024-12-05 07:00:57 +0100 | <r-sta> | well, heres what chatGPT makes of all that |
| 2024-12-05 07:00:58 +0100 | <r-sta> | https://chatgpt.com/share/67514182-58e4-800b-a7b6-0dc4e36ab7d1 |
| 2024-12-05 07:01:05 +0100 | <r-sta> | it seems to be more retarded than usual |
| 2024-12-05 07:02:12 +0100 | <r-sta> | it seems to insist i traverse the container to store the entries |
| 2024-12-05 07:02:44 +0100 | <r-sta> | i think maybe the problem is that i was bypassing the Functor instance with a simultanious update |
| 2024-12-05 07:02:50 +0100 | <r-sta> | at least that makes more sense to me now |
| 2024-12-05 07:04:12 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 272 seconds) |
| 2024-12-05 07:04:22 +0100 | <jle`> | i have pretty much never had any luck with chat gpt and haskell |
| 2024-12-05 07:06:45 +0100 | falafel | (~falafel@2603:8000:b4f0:62a0:90bb:2f36:5363:97ac) (Ping timeout: 272 seconds) |
| 2024-12-05 07:14:38 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
| 2024-12-05 07:18:20 +0100 | r-sta | (~r-sta@sgyl-37-b2-v4wan-168528-cust2421.vm6.cable.virginm.net) (Quit: Client closed) |
| 2024-12-05 07:18:57 +0100 | cyanteeth | (~cyanteeth@user/cyanteeth) cyanteeth |
| 2024-12-05 07:19:07 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 252 seconds) |
| 2024-12-05 07:20:07 +0100 | cyanteeth | (~cyanteeth@user/cyanteeth) (Client Quit) |
| 2024-12-05 07:20:17 +0100 | hsw_ | (~hsw@112-104-8-145.adsl.dynamic.seed.net.tw) (Quit: Leaving) |
| 2024-12-05 07:22:12 +0100 | anpad | (~pandeyan@user/anpad) (Quit: ZNC 1.8.2 - https://znc.in) |
| 2024-12-05 07:22:40 +0100 | takuan | (~takuan@178-116-218-225.access.telenet.be) |
| 2024-12-05 07:24:34 +0100 | anpad | (~pandeyan@user/anpad) anpad |
| 2024-12-05 07:27:03 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
| 2024-12-05 07:27:36 +0100 | cyanteeth | (~cyanteeth@user/cyanteeth) cyanteeth |
| 2024-12-05 07:29:11 +0100 | cyanteeth | (~cyanteeth@user/cyanteeth) (Client Quit) |
| 2024-12-05 07:29:11 +0100 | hgolden | (~hgolden@syn-172-251-233-141.res.spectrum.com) (Remote host closed the connection) |
| 2024-12-05 07:29:36 +0100 | cyanteeth | (~cyanteeth@user/cyanteeth) cyanteeth |
| 2024-12-05 07:31:40 +0100 | alp | (~alp@2001:861:8ca0:4940:d20d:7a7b:c9a4:67d6) |
| 2024-12-05 07:32:02 +0100 | peterbecich | (~Thunderbi@syn-047-229-123-186.res.spectrum.com) peterbecich |
| 2024-12-05 07:33:29 +0100 | cyanteeth | (~cyanteeth@user/cyanteeth) (Client Quit) |
| 2024-12-05 07:34:09 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 252 seconds) |
| 2024-12-05 07:36:04 +0100 | vanishingideal | (~vanishing@user/vanishingideal) (Quit: leaving) |
| 2024-12-05 07:37:49 +0100 | ZLima12 | (~zlima12@user/meow/ZLima12) (Remote host closed the connection) |
| 2024-12-05 07:38:58 +0100 | ZLima12 | (~zlima12@user/meow/ZLima12) ZLima12 |
| 2024-12-05 07:39:12 +0100 | bitdex | (~bitdex@gateway/tor-sasl/bitdex) (Ping timeout: 264 seconds) |
| 2024-12-05 07:40:49 +0100 | bitdex | (~bitdex@gateway/tor-sasl/bitdex) bitdex |
| 2024-12-05 07:42:32 +0100 | cyanteeth | (~cyanteeth@user/cyanteeth) cyanteeth |
| 2024-12-05 07:42:45 +0100 | cyanteeth | (~cyanteeth@user/cyanteeth) (Client Quit) |
| 2024-12-05 07:44:03 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
| 2024-12-05 07:44:29 +0100 | cyanteeth | (~cyanteeth@user/cyanteeth) cyanteeth |
| 2024-12-05 07:47:50 +0100 | cyanteeth | (~cyanteeth@user/cyanteeth) (Client Quit) |
| 2024-12-05 07:49:10 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 272 seconds) |
| 2024-12-05 07:50:11 +0100 | cyanteeth | (~cyanteeth@user/cyanteeth) cyanteeth |
| 2024-12-05 07:59:50 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
| 2024-12-05 08:03:37 +0100 | youthlic | (~Thunderbi@user/youthlic) (Remote host closed the connection) |
| 2024-12-05 08:04:03 +0100 | youthlic | (~Thunderbi@user/youthlic) youthlic |
| 2024-12-05 08:04:03 +0100 | cyanteeth | (~cyanteeth@user/cyanteeth) (Quit: Client closed) |
| 2024-12-05 08:05:43 +0100 | Square2 | (~Square4@user/square) Square |
| 2024-12-05 08:06:48 +0100 | gmg | (~user@user/gehmehgeh) (Ping timeout: 264 seconds) |
| 2024-12-05 08:09:15 +0100 | Square | (~Square@user/square) (Ping timeout: 276 seconds) |
| 2024-12-05 08:12:15 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 246 seconds) |
| 2024-12-05 08:27:58 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
| 2024-12-05 08:29:00 +0100 | falafel | (~falafel@2603:8000:b4f0:62a0:b3cc:4b47:af87:68a) falafel |
| 2024-12-05 08:32:34 +0100 | alp | (~alp@2001:861:8ca0:4940:d20d:7a7b:c9a4:67d6) (Remote host closed the connection) |
| 2024-12-05 08:32:51 +0100 | alp | (~alp@2001:861:8ca0:4940:7a91:e577:35cf:be5f) |
| 2024-12-05 08:36:40 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 272 seconds) |
| 2024-12-05 08:43:24 +0100 | peterbecich | (~Thunderbi@syn-047-229-123-186.res.spectrum.com) (Ping timeout: 246 seconds) |
| 2024-12-05 08:45:03 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
| 2024-12-05 08:47:16 +0100 | ash3en | (~Thunderbi@ip1f10cbd6.dynamic.kabel-deutschland.de) ash3en |
| 2024-12-05 08:48:18 +0100 | voonij | (~voonij@2401:b60:16:19f::) |
| 2024-12-05 08:48:18 +0100 | voonij | (~voonij@2401:b60:16:19f::) (Remote host closed the connection) |
| 2024-12-05 08:48:30 +0100 | <haskellbridge> | <hellwolf> it doesn't get tired listening and replying though. |
| 2024-12-05 08:49:44 +0100 | gmg | (~user@user/gehmehgeh) gehmehgeh |
| 2024-12-05 08:49:46 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 265 seconds) |
| 2024-12-05 08:49:47 +0100 | ash3en | (~Thunderbi@ip1f10cbd6.dynamic.kabel-deutschland.de) (Client Quit) |
| 2024-12-05 08:49:59 +0100 | lortabac | (~lortabac@2a01:e0a:541:b8f0:55ab:e185:7f81:54a4) lortabac |
| 2024-12-05 08:50:10 +0100 | ft | (~ft@p508db9c7.dip0.t-ipconnect.de) (Quit: leaving) |
| 2024-12-05 08:50:51 +0100 | falafel | (~falafel@2603:8000:b4f0:62a0:b3cc:4b47:af87:68a) (Ping timeout: 276 seconds) |
| 2024-12-05 08:53:14 +0100 | L29Ah | (~L29Ah@wikipedia/L29Ah) (Read error: Connection reset by peer) |
| 2024-12-05 08:58:04 +0100 | CiaoSen | (~Jura@2a05:5800:2db:c400:ca4b:d6ff:fec1:99da) CiaoSen |
| 2024-12-05 09:00:02 +0100 | caconym | (~caconym@user/caconym) (Quit: bye) |
| 2024-12-05 09:00:37 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
| 2024-12-05 09:00:40 +0100 | caconym | (~caconym@user/caconym) caconym |
| 2024-12-05 09:01:00 +0100 | Sgeo | (~Sgeo@user/sgeo) (Read error: Connection reset by peer) |
| 2024-12-05 09:05:15 +0100 | falafel | (~falafel@2603:8000:b4f0:62a0:5dd1:c8e6:c0ca:df8d) falafel |
| 2024-12-05 09:05:48 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 246 seconds) |
| 2024-12-05 09:07:50 +0100 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) |
| 2024-12-05 09:36:47 +0100 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 2024-12-05 09:38:27 +0100 | korrykatti | (~korrykatt@user/korrykatti) korrykatti |
| 2024-12-05 09:39:24 +0100 | zmt01 | (~zmt00@user/zmt00) (Read error: Connection reset by peer) |
| 2024-12-05 09:39:48 +0100 | zmt01 | (~zmt00@user/zmt00) zmt00 |
| 2024-12-05 09:45:18 +0100 | acidjnk_new3 | (~acidjnk@p200300d6e7283f313597cdba6c3bdfe2.dip0.t-ipconnect.de) acidjnk |
| 2024-12-05 09:47:42 +0100 | korrykatti | (~korrykatt@user/korrykatti) (Remote host closed the connection) |
| 2024-12-05 09:51:58 +0100 | merijn | (~merijn@77.242.116.146) merijn |
| 2024-12-05 09:52:00 +0100 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) |
| 2024-12-05 09:54:50 +0100 | yangby | (~secret@218.74.35.115) yangby |
| 2024-12-05 09:55:16 +0100 | vpan | (~vpan@212.117.1.172) |
| 2024-12-05 09:58:07 +0100 | machinedgod | (~machinedg@d108-173-18-100.abhsia.telus.net) machinedgod |
| 2024-12-05 10:07:03 +0100 | zenmov | (~zenmov@user/zenmov) (Ping timeout: 252 seconds) |
| 2024-12-05 10:07:14 +0100 | mari-estel | (~mari-este@user/mari-estel) mari-estel |
| 2024-12-05 10:10:36 +0100 | Smiles | (uid551636@id-551636.lymington.irccloud.com) Smiles |
| 2024-12-05 10:11:14 +0100 | falafel | (~falafel@2603:8000:b4f0:62a0:5dd1:c8e6:c0ca:df8d) (Ping timeout: 260 seconds) |
| 2024-12-05 10:18:56 +0100 | zenmov | (~zenmov@user/zenmov) zenmov |
| 2024-12-05 10:19:24 +0100 | stiell | (~stiell@gateway/tor-sasl/stiell) (Ping timeout: 264 seconds) |
| 2024-12-05 10:20:26 +0100 | lxsameer | (~lxsameer@Serene/lxsameer) lxsameer |
| 2024-12-05 10:22:28 +0100 | stiell | (~stiell@gateway/tor-sasl/stiell) stiell |
| 2024-12-05 10:34:28 +0100 | <vpan> | hi, I scrape a link from a web page using the scalpel library, but I need to convert it from relative to absolute. For that I need access to the URL passed to `scrapeURL` in my equivalent of `textComment` in this example - https://github.com/fimad/scalpel/blob/master/examples/example-from-documentation/Main.hs . How would I go about that? |
| 2024-12-05 10:34:29 +0100 | <vpan> | I think I could try combining `SraperT` with `ReaderT`, but it feels overcomplicated. Is that the best approach? |
| 2024-12-05 10:36:59 +0100 | eL_Bart0 | (eL_Bart0@dietunichtguten.org) |
| 2024-12-05 10:38:04 +0100 | econo_ | (uid147250@id-147250.tinside.irccloud.com) (Quit: Connection closed for inactivity) |
| 2024-12-05 10:44:23 +0100 | <kaol> | I'd just do it on the result. scrapedAbsoluteUrl <- makeAbsolute url <$> scrapeURL url yourParser or something like that. Whatever your makeAbsolute and yourParser are called. |
| 2024-12-05 10:45:14 +0100 | Flow | (~none@gentoo/developer/flow) (Ping timeout: 272 seconds) |
| 2024-12-05 10:46:51 +0100 | <kaol> | Hmm, scrapeURL returns a list? map (makeAbsolute url) then instead. |
| 2024-12-05 10:47:42 +0100 | kuribas | (~user@ip-188-118-57-242.reverse.destiny.be) |
| 2024-12-05 10:48:01 +0100 | <kaol> | Or if you prefer going the other way, just make your equivalent of comments into a regular function that takes the url. |
| 2024-12-05 10:51:01 +0100 | voonij | (~voonij@2401:b60:16:19f::) |
| 2024-12-05 10:51:11 +0100 | voonij | cokpolbb |
| 2024-12-05 10:53:48 +0100 | <vpan> | converting the URL outside the scraper function is indeed a lot simpler, somehow that did not cross my mind. :) Thanks, kaol! |
| 2024-12-05 10:53:49 +0100 | <vpan> | And by "make your equivalent of comments into a regular function that takes the url" you mean a wrapper function with an additional argument? |
| 2024-12-05 10:54:15 +0100 | cokpolbb | (~voonij@2401:b60:16:19f::) (Remote host closed the connection) |
| 2024-12-05 10:55:46 +0100 | manwithluck | (manwithluc@gateway/vpn/protonvpn/manwithluck) (Ping timeout: 252 seconds) |
| 2024-12-05 10:56:15 +0100 | <kaol> | I meant like yourParser :: String -> Scraper String [Comment] and using it like scrapeURL url $ yourParser url |
| 2024-12-05 10:56:42 +0100 | manwithluck | (~manwithlu@194.177.28.193) manwithluck |
| 2024-12-05 10:56:56 +0100 | voonij | (~voonij@2401:b60:16:19f::) |
| 2024-12-05 10:57:19 +0100 | <kaol> | I'm not sure I'd think of it in terms of wrappers. It's just plain old function. |
| 2024-12-05 10:59:36 +0100 | voonij | (~voonij@2401:b60:16:19f::) (Remote host closed the connection) |
| 2024-12-05 11:00:16 +0100 | voonij | (~voonij@163.123.195.138) |
| 2024-12-05 11:01:22 +0100 | <vpan> | maybe wrappers have a more specific meaning in Haskell context. But that's what I thought - a function that wraps the scraper function and takes the URL arg. I'll try that as the struct created inside the scraper function would not have to be recreated to fix the URLs. |
| 2024-12-05 11:01:49 +0100 | merijn | (~merijn@77.242.116.146) (Ping timeout: 252 seconds) |
| 2024-12-05 11:02:07 +0100 | CrunchyFlakes | (~CrunchyFl@31.19.233.78) (Quit: ZNC 1.8.2 - https://znc.in) |
| 2024-12-05 11:02:20 +0100 | voonij | (~voonij@163.123.195.138) (Remote host closed the connection) |
| 2024-12-05 11:03:12 +0100 | <kaol> | In a sense every function in haskell is wrapping a value of the type you have after the rightmost ->. The more values you apply to it the closer you get to it. |
| 2024-12-05 11:04:55 +0100 | <kaol> | But that's what's going on all over the language so I'm going to just call them functions. |
| 2024-12-05 11:05:34 +0100 | merijn | (~merijn@77.242.116.146) merijn |
| 2024-12-05 11:05:58 +0100 | CrunchyFlakes | (~CrunchyFl@ip1f13e94e.dynamic.kabel-deutschland.de) |
| 2024-12-05 11:10:03 +0100 | merijn | (~merijn@77.242.116.146) (Ping timeout: 252 seconds) |
| 2024-12-05 11:15:05 +0100 | tzh | (~tzh@c-76-115-131-146.hsd1.or.comcast.net) (Quit: zzz) |
| 2024-12-05 11:16:27 +0100 | kuribas | (~user@ip-188-118-57-242.reverse.destiny.be) (Read error: Connection reset by peer) |
| 2024-12-05 11:16:44 +0100 | kuribas | (~user@ip-188-118-57-242.reverse.destiny.be) kuribas |
| 2024-12-05 11:21:01 +0100 | merijn | (~merijn@77.242.116.146) merijn |
| 2024-12-05 11:27:56 +0100 | <int-e> | . o O ( every year I forget how to do topological sorting ) |
| 2024-12-05 11:29:47 +0100 | <int-e> | (notably the fact that one can abuse sortBy for that because it's secretly parsimonious) |
| 2024-12-05 11:30:32 +0100 | mari-estel | (~mari-este@user/mari-estel) (Quit: errands) |
| 2024-12-05 11:36:26 +0100 | <int-e> | ...no, that's not right. Never mind. |
| 2024-12-05 11:37:24 +0100 | califax | (~califax@user/califx) (Ping timeout: 264 seconds) |
| 2024-12-05 11:37:41 +0100 | califax | (~califax@user/califx) califx |
| 2024-12-05 11:38:00 +0100 | <mauke> | if you're doing AoC, it doesn't really require topo-sort |
| 2024-12-05 11:39:27 +0100 | CiaoSen | (~Jura@2a05:5800:2db:c400:ca4b:d6ff:fec1:99da) (Ping timeout: 246 seconds) |
| 2024-12-05 11:39:49 +0100 | <int-e> | yeah I just realized |
| 2024-12-05 11:40:21 +0100 | CrunchyFlakes | (~CrunchyFl@ip1f13e94e.dynamic.kabel-deutschland.de) (Ping timeout: 248 seconds) |
| 2024-12-05 11:40:39 +0100 | <int-e> | (and checked the input for that property) |
| 2024-12-05 11:41:43 +0100 | CrunchyFlakes | (~CrunchyFl@ip1f13e94e.dynamic.kabel-deutschland.de) |
| 2024-12-05 11:49:51 +0100 | Flow | (~none@gentoo/developer/flow) flow |
| 2024-12-05 11:57:51 +0100 | <ncf> | spoilers innit |
| 2024-12-05 12:04:18 +0100 | lortabac | (~lortabac@2a01:e0a:541:b8f0:55ab:e185:7f81:54a4) (Quit: WeeChat 4.4.2) |
| 2024-12-05 12:06:01 +0100 | L29Ah | (~L29Ah@wikipedia/L29Ah) L29Ah |
| 2024-12-05 12:07:26 +0100 | <int-e> | ncf: Somwhat sorry, but that's why I don't IRC before AoC... |
| 2024-12-05 12:07:46 +0100 | alexherbo2 | (~alexherbo@2a02-8440-3119-aba0-d82c-edc8-91e5-31b0.rev.sfr.net) alexherbo2 |
| 2024-12-05 12:08:24 +0100 | matsurago | (~matsurago@240b:10:b3a1:1700:b208:b72c:53fc:819f) (Quit: Leaving) |
| 2024-12-05 12:10:20 +0100 | merijn | (~merijn@77.242.116.146) (Ping timeout: 265 seconds) |
| 2024-12-05 12:10:50 +0100 | lxsameer | (~lxsameer@Serene/lxsameer) (Ping timeout: 265 seconds) |
| 2024-12-05 12:12:24 +0100 | __monty__ | (~toonn@user/toonn) toonn |
| 2024-12-05 12:16:24 +0100 | <ncf> | fair enough |
| 2024-12-05 12:22:07 +0100 | merijn | (~merijn@77.242.116.146) merijn |
| 2024-12-05 12:25:33 +0100 | V | (~v@ircpuzzles/2022/april/winner/V) (Remote host closed the connection) |
| 2024-12-05 12:35:08 +0100 | sprotte24 | (~sprotte24@p200300d16f0cca00d937d3551ba9ea91.dip0.t-ipconnect.de) |
| 2024-12-05 12:44:49 +0100 | lortabac | (~lortabac@2a01:e0a:541:b8f0:55ab:e185:7f81:54a4) lortabac |
| 2024-12-05 13:00:08 +0100 | caconym | (~caconym@user/caconym) (Quit: bye) |
| 2024-12-05 13:02:19 +0100 | ash3en | (~Thunderbi@149.222.206.227) ash3en |
| 2024-12-05 13:02:24 +0100 | alp | (~alp@2001:861:8ca0:4940:7a91:e577:35cf:be5f) (Ping timeout: 246 seconds) |
| 2024-12-05 13:02:32 +0100 | caconym | (~caconym@user/caconym) caconym |
| 2024-12-05 13:04:18 +0100 | ash3en | (~Thunderbi@149.222.206.227) (Client Quit) |
| 2024-12-05 13:12:48 +0100 | fp | (~Thunderbi@130.233.70.169) fp |
| 2024-12-05 13:15:19 +0100 | fp | (~Thunderbi@130.233.70.169) (Remote host closed the connection) |
| 2024-12-05 13:16:41 +0100 | CiaoSen | (~Jura@2a05:5800:2db:c400:ca4b:d6ff:fec1:99da) CiaoSen |
| 2024-12-05 13:18:41 +0100 | alp | (~alp@128-79-174-146.hfc.dyn.abo.bbox.fr) |
| 2024-12-05 13:20:25 +0100 | fp | (~Thunderbi@2001:708:20:1406::1370) fp |
| 2024-12-05 13:23:21 +0100 | lxsameer | (~lxsameer@Serene/lxsameer) lxsameer |
| 2024-12-05 13:26:34 +0100 | V | (~v@ircpuzzles/2022/april/winner/V) V |
| 2024-12-05 13:40:26 +0100 | chaouki | (~chaouki@196.65.182.78) |
| 2024-12-05 13:42:31 +0100 | chaouki | (~chaouki@196.65.182.78) (Client Quit) |
| 2024-12-05 13:43:28 +0100 | weary-traveler | (~user@user/user363627) user363627 |
| 2024-12-05 13:43:50 +0100 | alexherbo2 | (~alexherbo@2a02-8440-3119-aba0-d82c-edc8-91e5-31b0.rev.sfr.net) (Remote host closed the connection) |
| 2024-12-05 13:44:09 +0100 | alexherbo2 | (~alexherbo@2a02-8440-3119-aba0-d82c-edc8-91e5-31b0.rev.sfr.net) alexherbo2 |
| 2024-12-05 13:44:11 +0100 | <hellwolf> | What do y'all think of this linear-types enabled syntax: https://paste.tomsmeding.com/79QRiSy8 |
| 2024-12-05 13:44:18 +0100 | <hellwolf> | (a working example) |
| 2024-12-05 13:45:14 +0100 | <hellwolf> | ahh, I should have renamed lift to impure before I share. |
| 2024-12-05 13:50:12 +0100 | <int-e> | Lovecraftian function names for conjuring horrors of the depth. |
| 2024-12-05 13:52:18 +0100 | <SrPx> | I'm trying to set up parallelism on Haskell. I've added 'ghc-options: -threaded' to my cabal, imported parallel. I'm testing: "print $ a `par` b `par` c `par` d `pseq` (a, b, c, d)", where `a b c d` are slow computations (just a busy loop). the time is the same as if I didn't use `par` at all. am I missing something? |
| 2024-12-05 13:53:50 +0100 | <int-e> | What are the types of a,b,c,d? They'll only be evaluated to WHNF. |
| 2024-12-05 13:54:08 +0100 | <SrPx> | just a busy loop count 0 k = k; count p k = count (p - 1) (k + 1) |
| 2024-12-05 13:55:22 +0100 | <int-e> | hmm, that should work... are you passing rts flags to actually use several cores? Say, +RTS -N -RTS? |
| 2024-12-05 13:55:30 +0100 | <hellwolf> | 12-05 14:50 <int-e> Lovecraftian function names for conjuring horrors of the depth. |
| 2024-12-05 13:55:30 +0100 | <hellwolf> | :) was that for me? Happy to hear about alternatives. |
| 2024-12-05 13:55:56 +0100 | <int-e> | hellwolf: I just saw the primes. Otherwise my brain shut off the moment I saw erc20 |
| 2024-12-05 13:56:59 +0100 | <hellwolf> | heh, okay. I am just doing my part to bring the good part of Haskell to people who didn't know its powers. |
| 2024-12-05 13:57:14 +0100 | <hellwolf> | fully aware of the baggage comes with the domain |
| 2024-12-05 13:58:08 +0100 | <haskellbridge> | <hellwolf> oh wait, haskellbridge are you leaking my IP |
| 2024-12-05 14:00:22 +0100 | <SrPx> | int-e: hmm it works kinda, thanks. but seems like the time goes from 4s to 2s, any idea why? |
| 2024-12-05 14:00:37 +0100 | <SrPx> | it takes ~1s to run each call to `a` |
| 2024-12-05 14:00:47 +0100 | <SrPx> | in a single thread, I mean |
| 2024-12-05 14:00:57 +0100 | ash3en | (~Thunderbi@149.222.206.227) ash3en |
| 2024-12-05 14:01:30 +0100 | <int-e> | SrPx: You're probably building a big thunk for the results. |
| 2024-12-05 14:01:52 +0100 | <int-e> | (`count` is lazy in `k` as written) |
| 2024-12-05 14:02:14 +0100 | <SrPx> | I've annotated both args as strict but still only 2x speedup |
| 2024-12-05 14:02:17 +0100 | <SrPx> | is there anything else I'd need to do? |
| 2024-12-05 14:02:52 +0100 | <int-e> | SrPx: my own test: https://paste.tomsmeding.com/zRVxioGI |
| 2024-12-05 14:03:17 +0100 | <int-e> | And that's 4x faster for me with +RTS -N4 -RTS |
| 2024-12-05 14:04:31 +0100 | ash3en | (~Thunderbi@149.222.206.227) (Client Quit) |
| 2024-12-05 14:05:28 +0100 | <SrPx> | yep that's a 4x to me |
| 2024-12-05 14:05:33 +0100 | <SrPx> | it is almost like mine, let me investigate |
| 2024-12-05 14:05:34 +0100 | <int-e> | (there's no deep reason for using GHC.Conc; I just didn't want to depend on an extra package) |
| 2024-12-05 14:05:51 +0100 | <SrPx> | me neither, glad to know |
| 2024-12-05 14:06:47 +0100 | <int-e> | SrPx: I guess the other pitfall is that a,b,c,d need to look distinct to the compiler, or they may be shared. |
| 2024-12-05 14:09:07 +0100 | <SrPx> | why would my version be shared and not yours? i'm calling count with different numbers |
| 2024-12-05 14:09:15 +0100 | <SrPx> | not sure i get what ghc could be doing here |
| 2024-12-05 14:09:29 +0100 | <int-e> | I don't know; I haven't seen your code. |
| 2024-12-05 14:09:43 +0100 | <SrPx> | oh i apologizei should have posted it anyway |
| 2024-12-05 14:09:46 +0100 | <int-e> | I didn't know whether you are using distinct numbers. |
| 2024-12-05 14:10:15 +0100 | <SrPx> | https://gist.github.com/VictorTaelin/eb32b4031e727985ea67186be22c4c59 |
| 2024-12-05 14:12:05 +0100 | <int-e> | Oh that's actually confusing. Try replacing `pseq` by `par`. |
| 2024-12-05 14:12:54 +0100 | <SrPx> | no effect. weird |
| 2024-12-05 14:13:58 +0100 | ubert | (~Thunderbi@2a02:8109:ab8a:5a00:a4e1:49be:2d3e:5be8) ubert |
| 2024-12-05 14:14:21 +0100 | <int-e> | Uhm, why are you binding x0 to x3 strictly |
| 2024-12-05 14:14:23 +0100 | <Leary> | SrPx: Unbang x0--x3; that will cause them to be evaluated prematurely. |
| 2024-12-05 14:14:37 +0100 | pavonia | (~user@user/siracusa) siracusa |
| 2024-12-05 14:14:37 +0100 | <SrPx> | just one among many things i tried |
| 2024-12-05 14:16:19 +0100 | <SrPx> | seems like the issue is Word64 ? |
| 2024-12-05 14:18:36 +0100 | <int-e> | Hmm, -fno-omit-yields helps. But it also makes the code slower. |
| 2024-12-05 14:19:01 +0100 | <SrPx> | well I'll just hope it is some kind of micro optimization for this case and try on the actual program |
| 2024-12-05 14:19:07 +0100 | <SrPx> | at least it works with integers, ty |
| 2024-12-05 14:22:46 +0100 | merijn | (~merijn@77.242.116.146) (Ping timeout: 265 seconds) |
| 2024-12-05 14:25:22 +0100 | <int-e> | SrPx: it's some scheduling weirdness (that probably won't happen if your workers allocate memory): https://paste.tomsmeding.com/wegFKtYH |
| 2024-12-05 14:25:45 +0100 | <int-e> | (that `yield` makes a difference.) |
| 2024-12-05 14:26:32 +0100 | merijn | (~merijn@77.242.116.146) merijn |
| 2024-12-05 14:30:03 +0100 | <SrPx> | interesting, thank you |
| 2024-12-05 14:30:14 +0100 | <SrPx> | I guess also that wouldn't happen with forkIO? |
| 2024-12-05 14:30:18 +0100 | weary-traveler | (~user@user/user363627) (Remote host closed the connection) |
| 2024-12-05 14:32:01 +0100 | <SrPx> | btw big file but just in case anyone want to have a look, I ported HVM to Haskell (and it was the best decision I made), this is the file responsible for computing the result on lazy-mode: https://github.com/HigherOrderCO/HVM3/blob/main/src/HVML/Collapse.hs |
| 2024-12-05 14:32:36 +0100 | <SrPx> | lazy-mode isn't meant to be very parallel, but we can still have some grain of parallelism because it is safe to execute two calls to 'collapseDupAt' in parallel |
| 2024-12-05 14:32:40 +0100 | <SrPx> | so, for example, these lines: |
| 2024-12-05 14:32:56 +0100 | <SrPx> | fun0 <- collapseDupsAt state reduceAt book (loc + 0) |
| 2024-12-05 14:32:59 +0100 | <SrPx> | arg0 <- collapseDupsAt state reduceAt book (loc + 1) |
| 2024-12-05 14:33:06 +0100 | <SrPx> | could be safely executed in parallel |
| 2024-12-05 14:33:39 +0100 | <SrPx> | (ignoring the fact this is under the state monad so I'd probably need to update the state to a thread safe map - that's just tracking some indices though, shouldn't b ehard) |
| 2024-12-05 14:33:51 +0100 | <SrPx> | so basically I'm wondering if I should use `forkIO` or `par` here |
| 2024-12-05 14:34:20 +0100 | <SrPx> | it basically generates a tree that can have arbitrary shape/depth, so I guess just using forkIO won't be ideal as one branch can take much less work than the other |
| 2024-12-05 14:34:44 +0100 | <SrPx> | I assume `par` is creating a work stealing queue internally and that I can abuse of it (i.e., create billions of it, one for each branching node in my tree) without issues, right? |
| 2024-12-05 14:35:01 +0100 | <SrPx> | so I suppose all that I need to do is to remove the monadic state and then use `par` on each node |
| 2024-12-05 14:35:18 +0100 | <SrPx> | just sharing this plan here in case anyone has a thought or advice (: |
| 2024-12-05 14:36:46 +0100 | mange | (~user@user/mange) (Quit: Zzz...) |
| 2024-12-05 14:37:01 +0100 | <SrPx> | (so tldr if my understanding is right: if I used `forkIO` I'd probably need to create my own task stealing queue, while `par` has one built-in so I can just use the Haskell native implementation instead?) |
| 2024-12-05 14:39:01 +0100 | <haskellbridge> | <hellwolf> if your functions are pure, use par. I have a hunch that you won't need forkIO for that case. I don't have definitive proof for that statement, but I have a high confidence level of it . |
| 2024-12-05 14:40:13 +0100 | <SrPx> | thanks that's highly appreciated! |
| 2024-12-05 14:42:59 +0100 | bitdex | (~bitdex@gateway/tor-sasl/bitdex) (Quit: = "") |
| 2024-12-05 14:44:39 +0100 | <int-e> | SrPx: IIUC the scheduler will schedule https://gitlab.haskell.org/ghc/ghc/-/blob/master/libraries/ghc-internal/src/GHC/Internal/Conc/Sync… on capabilities that are otherwise idle. And `getSpark#` accesses an internal queue of sparks. |
| 2024-12-05 14:46:19 +0100 | <SrPx> | oh interesting to see it, ty |
| 2024-12-05 14:47:44 +0100 | <int-e> | I'm still not sure what happens with your program. I mean we probably get to print (x0,x1,x2,x3) and that starts evaluating x0, without the scheduler getting a chance to run on that capability. But there should be other capabilities looking for work regardless. |
| 2024-12-05 14:48:33 +0100 | <int-e> | And if there are at least 5 of them, those should pick up x1 to x3 but evidently that doesn't happen. |
| 2024-12-05 14:50:12 +0100 | <int-e> | (I'm saying 5 becauyse with 4 there's some additional uncertainty about what happens with x0) |
| 2024-12-05 14:53:04 +0100 | motherfsck | (~motherfsc@user/motherfsck) (Ping timeout: 252 seconds) |
| 2024-12-05 15:01:07 +0100 | CiaoSen | (~Jura@2a05:5800:2db:c400:ca4b:d6ff:fec1:99da) (Ping timeout: 252 seconds) |
| 2024-12-05 15:09:19 +0100 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 2024-12-05 15:20:34 +0100 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) |
| 2024-12-05 15:21:30 +0100 | ystael | (~ystael@user/ystael) (Ping timeout: 276 seconds) |
| 2024-12-05 15:21:58 +0100 | acidjnk_new3 | (~acidjnk@p200300d6e7283f313597cdba6c3bdfe2.dip0.t-ipconnect.de) (Ping timeout: 252 seconds) |
| 2024-12-05 15:23:53 +0100 | JuanDaugherty | (~juan@user/JuanDaugherty) JuanDaugherty |
| 2024-12-05 15:24:22 +0100 | visilii_ | (~visilii@94.25.68.206) |
| 2024-12-05 15:26:04 +0100 | foul_owl | (~kerry@185.219.141.161) (Ping timeout: 252 seconds) |
| 2024-12-05 15:26:39 +0100 | foul_owl | (~kerry@185.219.141.161) foul_owl |
| 2024-12-05 15:27:21 +0100 | j1n37 | (~j1n37@user/j1n37) (Read error: Connection reset by peer) |
| 2024-12-05 15:27:23 +0100 | comerijn | (~merijn@77.242.116.146) merijn |
| 2024-12-05 15:28:10 +0100 | visilii | (~visilii@188.254.126.79) (Ping timeout: 260 seconds) |
| 2024-12-05 15:29:10 +0100 | alexherbo2 | (~alexherbo@2a02-8440-3119-aba0-d82c-edc8-91e5-31b0.rev.sfr.net) (Ping timeout: 240 seconds) |
| 2024-12-05 15:29:40 +0100 | Smiles | (uid551636@id-551636.lymington.irccloud.com) (Quit: Connection closed for inactivity) |
| 2024-12-05 15:30:05 +0100 | merijn | (~merijn@77.242.116.146) (Ping timeout: 252 seconds) |
| 2024-12-05 15:30:58 +0100 | j1n37 | (~j1n37@user/j1n37) j1n37 |
| 2024-12-05 15:31:05 +0100 | weary-traveler | (~user@user/user363627) user363627 |
| 2024-12-05 15:32:57 +0100 | acidjnk_new3 | (~acidjnk@p200300d6e7283f313597cdba6c3bdfe2.dip0.t-ipconnect.de) acidjnk |
| 2024-12-05 15:33:20 +0100 | Sgeo | (~Sgeo@user/sgeo) Sgeo |
| 2024-12-05 15:36:10 +0100 | motherfsck | (~motherfsc@user/motherfsck) motherfsck |
| 2024-12-05 15:40:39 +0100 | hiecaq | (~hiecaq@user/hiecaq) hiecaq |
| 2024-12-05 15:49:22 +0100 | <albet70> | let s (x:xs) = x: s [i | i<- xs, mod i x /= 0] in s [2..], why in s [2..9] will crash? |
| 2024-12-05 15:49:54 +0100 | yangby | (~secret@218.74.35.115) (Ping timeout: 240 seconds) |
| 2024-12-05 15:51:39 +0100 | <int-e> | there's no case for s [] |
| 2024-12-05 15:51:50 +0100 | yangby | (~secret@218.72.98.138) yangby |
| 2024-12-05 15:52:39 +0100 | <albet70> | how to change it? |
| 2024-12-05 16:00:21 +0100 | ystael | (~ystael@user/ystael) ystael |
| 2024-12-05 16:00:39 +0100 | erty | (~user@user/aeroplane) aeroplane |
| 2024-12-05 16:02:57 +0100 | JuanDaugherty | (~juan@user/JuanDaugherty) (Quit: JuanDaugherty) |
| 2024-12-05 16:10:03 +0100 | fp | (~Thunderbi@2001:708:20:1406::1370) (Ping timeout: 252 seconds) |
| 2024-12-05 16:11:31 +0100 | sprotte24 | (~sprotte24@p200300d16f0cca00d937d3551ba9ea91.dip0.t-ipconnect.de) (Read error: Connection reset by peer) |
| 2024-12-05 16:13:19 +0100 | mari-estel | (~mari-este@user/mari-estel) mari-estel |
| 2024-12-05 16:35:32 +0100 | kuribas | (~user@ip-188-118-57-242.reverse.destiny.be) (Remote host closed the connection) |
| 2024-12-05 16:37:50 +0100 | Smiles | (uid551636@id-551636.lymington.irccloud.com) Smiles |
| 2024-12-05 16:38:57 +0100 | <ncf> | add a case for s [] ? |
| 2024-12-05 16:39:15 +0100 | <SrPx> | int-e: (shrugs) |
| 2024-12-05 16:40:23 +0100 | Square | (~Square@user/square) Square |
| 2024-12-05 16:41:18 +0100 | lortabac | (~lortabac@2a01:e0a:541:b8f0:55ab:e185:7f81:54a4) (Quit: WeeChat 4.4.2) |
| 2024-12-05 16:44:32 +0100 | Square2 | (~Square4@user/square) (Ping timeout: 252 seconds) |
| 2024-12-05 16:47:26 +0100 | mari-estel | (~mari-este@user/mari-estel) (Quit: too busy) |
| 2024-12-05 16:48:09 +0100 | homo | (~homo@user/homo) (Quit: homo) |
| 2024-12-05 16:48:31 +0100 | homo | (~homo@82-128-196-26.bb.dnainternet.fi) |
| 2024-12-05 16:48:51 +0100 | homo | (~homo@82-128-196-26.bb.dnainternet.fi) (Changing host) |
| 2024-12-05 16:48:51 +0100 | homo | (~homo@user/homo) homo |
| 2024-12-05 16:49:33 +0100 | comerijn | (~merijn@77.242.116.146) (Ping timeout: 245 seconds) |
| 2024-12-05 17:01:30 +0100 | euphores | (~SASL_euph@user/euphores) (Quit: Leaving.) |
| 2024-12-05 17:01:44 +0100 | merijn | (~merijn@77.242.116.146) merijn |
| 2024-12-05 17:04:00 +0100 | ash3en | (~Thunderbi@149.222.206.227) ash3en |
| 2024-12-05 17:04:00 +0100 | ash3en | (~Thunderbi@149.222.206.227) (Client Quit) |
| 2024-12-05 17:05:09 +0100 | ystael | (~ystael@user/ystael) (Ping timeout: 248 seconds) |
| 2024-12-05 17:06:50 +0100 | briandaed | (~root@user/briandaed) briandaed |
| 2024-12-05 17:06:51 +0100 | ystael | (~ystael@user/ystael) ystael |
| 2024-12-05 17:10:19 +0100 | hiecaq | (~hiecaq@user/hiecaq) (Quit: ERC 5.6.0.30.1 (IRC client for GNU Emacs 30.0.92)) |
| 2024-12-05 17:12:58 +0100 | raym | (~ray@user/raym) (Quit: kernel update, rebooting...) |
| 2024-12-05 17:17:34 +0100 | <hellwolf> | hlint hints me to use tuple secion |
| 2024-12-05 17:18:35 +0100 | <enikar> | hellwolf: https://neilmitchell.blogspot.com/2019/01/ignoring-hlint.html |
| 2024-12-05 17:18:40 +0100 | <hellwolf> | "Suggestion: Use tuple-section" "Found: \ ctx -> (Dict, ctx, f a) Perhaps: (Dict,, f a)" |
| 2024-12-05 17:18:47 +0100 | <enikar> | if that can help :) |
| 2024-12-05 17:18:56 +0100 | <hellwolf> | yea, I have disabled a few. |
| 2024-12-05 17:19:09 +0100 | <hellwolf> | does anyone have an opinion about TupleSections |
| 2024-12-05 17:19:29 +0100 | <hellwolf> | it's in both 2021, and 2024 |
| 2024-12-05 17:19:33 +0100 | <hellwolf> | *GHC |
| 2024-12-05 17:20:47 +0100 | <geekosaur> | it's a very old extension and many people think it fixes a flaw in the Haskell Report |
| 2024-12-05 17:20:57 +0100 | <enikar> | I used it times to times. If the code is clearer with it's ok. If it obfuscates the code, don't use it! |
| 2024-12-05 17:21:26 +0100 | ubert | (~Thunderbi@2a02:8109:ab8a:5a00:a4e1:49be:2d3e:5be8) (Quit: ubert) |
| 2024-12-05 17:23:24 +0100 | <hellwolf> | okay, I will use it. |
| 2024-12-05 17:23:50 +0100 | <hellwolf> | also, I actually just noticed that (<<) is not defined, while (=<<) is. |
| 2024-12-05 17:24:04 +0100 | <hellwolf> | am I missing anything obvious, why it is the case. |
| 2024-12-05 17:26:42 +0100 | <geekosaur> | it's always been the case, I'm not sure why that decision was made. But it was semi-corrected with <* |
| 2024-12-05 17:27:06 +0100 | <hellwolf> | Incidentally, for my own parameterized monad, "(=<<) = flip (>>=)" typechecks, "(<<) = flip (>>)" doesn't, without signatures for them. Adding a signature of course worked in both case. |
| 2024-12-05 17:27:14 +0100 | <hellwolf> | I wonder if there is some connection there. |
| 2024-12-05 17:27:23 +0100 | <geekosaur> | Maybe |
| 2024-12-05 17:27:35 +0100 | <hellwolf> | (probably, it seems idiosyncratic to my case) |
| 2024-12-05 17:27:38 +0100 | <hellwolf> | *probably not |
| 2024-12-05 17:27:51 +0100 | <dminuoso> | I smell monomorphism restriction. |
| 2024-12-05 17:27:52 +0100 | <geekosaur> | I think =<< exists only because it's concatMap |
| 2024-12-05 17:28:14 +0100 | <dminuoso> | % f = (+) |
| 2024-12-05 17:28:14 +0100 | <yahb2> | <no output> |
| 2024-12-05 17:28:20 +0100 | <hellwolf> | I see the choice are for programming style, like flipping word orders in English. |
| 2024-12-05 17:29:02 +0100 | <hellwolf> | > :type flip (>>) |
| 2024-12-05 17:29:04 +0100 | <lambdabot> | <hint>:1:1: error: parse error on input ‘:’ |
| 2024-12-05 17:29:12 +0100 | <hellwolf> | > :t flip (>>) |
| 2024-12-05 17:29:13 +0100 | <lambdabot> | <hint>:1:1: error: parse error on input ‘:’ |
| 2024-12-05 17:29:20 +0100 | <hellwolf> | % :t flip (>>) |
| 2024-12-05 17:29:20 +0100 | <yahb2> | flip (>>) :: Monad m => m b -> m a -> m b |
| 2024-12-05 17:29:36 +0100 | <hellwolf> | so many bots... sorry I am not familiar which one I should use. |
| 2024-12-05 17:29:39 +0100 | <dminuoso> | It's hard to say without full code. |
| 2024-12-05 17:30:02 +0100 | <dminuoso> | In principle it should work, but there's so many dark corners of the type system.. |
| 2024-12-05 17:30:04 +0100 | <hellwolf> | I will post again after commit/push the code. |
| 2024-12-05 17:30:28 +0100 | <hellwolf> | yea, I suspect it's just my case. |
| 2024-12-05 17:30:39 +0100 | <hellwolf> | but I probably should ignore defining (<<) |
| 2024-12-05 17:31:11 +0100 | <dminuoso> | % :set -XMonomorphismRestriction |
| 2024-12-05 17:31:11 +0100 | <yahb2> | <no output> |
| 2024-12-05 17:31:15 +0100 | <dminuoso> | % a = flip (<<) |
| 2024-12-05 17:31:16 +0100 | <yahb2> | <interactive>:37:10: error: [GHC-88464] ; Variable not in scope: (<<) :: a -> b -> c ; Suggested fix: ; Perhaps use one of these: ; ‘<’ (imported from Prelude), ‘<$’ (imported... |
| 2024-12-05 17:31:20 +0100 | <dminuoso> | % a = flip (>>) |
| 2024-12-05 17:31:20 +0100 | <yahb2> | <interactive>:39:10: error: [GHC-39999] ; • Ambiguous type variable ‘m0’ arising from a use of ‘>>’ ; prevents the constraint ‘(Monad m0)’ from being solved. ; Relevant bindings inc... |
| 2024-12-05 17:31:26 +0100 | <dminuoso> | % import Control.Applicative |
| 2024-12-05 17:31:26 +0100 | <yahb2> | <no output> |
| 2024-12-05 17:31:28 +0100 | <dminuoso> | % a = flip (>>) |
| 2024-12-05 17:31:28 +0100 | <yahb2> | <interactive>:43:10: error: [GHC-39999] ; • Ambiguous type variable ‘m0’ arising from a use of ‘>>’ ; prevents the constraint ‘(Monad m0)’ from being solved. ; Relevant bindings inc... |
| 2024-12-05 17:31:40 +0100 | <dminuoso> | Ah its already there. |
| 2024-12-05 17:31:59 +0100 | <dminuoso> | hellwolf: Im guessing that `:t flip (>>)` uses NoMonomorphismRestriction. |
| 2024-12-05 17:32:08 +0100 | <dminuoso> | % :set -XNoMonomorphismRestriction |
| 2024-12-05 17:32:08 +0100 | <yahb2> | <no output> |
| 2024-12-05 17:32:11 +0100 | <dminuoso> | % a = flip (>>) |
| 2024-12-05 17:32:11 +0100 | <yahb2> | <no output> |
| 2024-12-05 17:32:16 +0100 | <dminuoso> | See the difference? |
| 2024-12-05 17:32:51 +0100 | <merijn> | hellwolf: TupleSesctions are, like, the least controversial extension possible :p |
| 2024-12-05 17:33:25 +0100 | <hellwolf> | ELJS problem only |
| 2024-12-05 17:34:00 +0100 | <hellwolf> | 12-05 18:32 <dminuoso> See the difference? not really... |
| 2024-12-05 17:34:21 +0100 | <hellwolf> | oh, i see now |
| 2024-12-05 17:35:08 +0100 | <dminuoso> | % :set -XMonomorphismRestriction |
| 2024-12-05 17:35:08 +0100 | <yahb2> | <no output> |
| 2024-12-05 17:35:30 +0100 | <dminuoso> | % a = flip (>>) |
| 2024-12-05 17:35:30 +0100 | <yahb2> | <interactive>:51:10: error: [GHC-39999] ; • Ambiguous type variable ‘m0’ arising from a use of ‘>>’ ; prevents the constraint ‘(Monad m0)’ from being solved. ; Relevant bindings inc... |
| 2024-12-05 17:36:06 +0100 | <hellwolf> | not to my GHCi though, I guess you have a different eval environment in the bot. |
| 2024-12-05 17:36:26 +0100 | <dminuoso> | hellwolf: GHCi has NoMonomorphismRestriction by default. |
| 2024-12-05 17:36:34 +0100 | <dminuoso> | GHC has MonomorphismRestriction by default. |
| 2024-12-05 17:36:37 +0100 | <hellwolf> | ah, no. I need to do assignment |
| 2024-12-05 17:36:39 +0100 | <hellwolf> | yes, I got it. |
| 2024-12-05 17:36:57 +0100 | <dminuoso> | And yeah, like I said, it seems :t seems by default to use `NoMonomorphismRestriction` |
| 2024-12-05 17:37:19 +0100 | <dminuoso> | The extension is confusing enough as it is, to have GHCi behave differently by default, and :t even more is just double treachery. |
| 2024-12-05 17:38:42 +0100 | <hellwolf> | right. It has been awhile since I watched rae's talk about MR, |
| 2024-12-05 17:39:57 +0100 | <enikar> | I still don't understand what MonomophismRestriction means. However I tried to read docs about it many times. Finally I gave up on this subject. |
| 2024-12-05 17:41:12 +0100 | <dminuoso> | enikar: The idea is really simple. Polymorphic code is implemented as a kind of routine that accepts a dictionary. |
| 2024-12-05 17:41:42 +0100 | <dminuoso> | enikar: That means, that polymorphic code itself cannot memoize, because it would lose this "function taking a dictionary property" |
| 2024-12-05 17:41:47 +0100 | <hellwolf> | I think it manifests when you have, either a habit with or of convenience within a specific package like testing, where you omit type signatures |
| 2024-12-05 17:42:25 +0100 | <hellwolf> | otherwise, you are unlikely to trip over it. |
| 2024-12-05 17:42:31 +0100 | <dminuoso> | enikar: So if you had some `f ... = where x :: Int; x = <expensive expression>`, and you used x in multiple places, it could not memoize x on the first usage. |
| 2024-12-05 17:42:41 +0100 | <hellwolf> | I think one explanation is that it helps that it doesn't overeagerly bind to Num instances |
| 2024-12-05 17:42:52 +0100 | <dminuoso> | Sorry, ignore `x :: Int` but assume it turns out as some `Num a` |
| 2024-12-05 17:42:55 +0100 | <hellwolf> | for small functions, you just monomorphically use a specific type's functionl. |
| 2024-12-05 17:43:08 +0100 | <dminuoso> | So `f ... = where x :: Num a => a; x = <expensive expression>` |
| 2024-12-05 17:43:50 +0100 | <dminuoso> | enikar: Because the type system automatically generalizes and people leave type signatures away, this has the unfortunate consequence that where bindings or top-level bindings often dont memoize as often as you want, and introduce unexpected performance problems. |
| 2024-12-05 17:44:02 +0100 | <dminuoso> | because they end up with types like `Num a => a` |
| 2024-12-05 17:44:13 +0100 | <dminuoso> | (which internally becomes a function, that cannot memoize) |
| 2024-12-05 17:45:02 +0100 | <dminuoso> | All MMR does is force this into a concrete type if it can like `Int` in case of `Num a` via defaulting, or demand a type signature of you (so either the choice of a polymorphic type that cannot memoize is explicit) |
| 2024-12-05 17:45:30 +0100 | <dminuoso> | The idea is that the occasional type error asking you for a type signature is more obvious and easier to deal with than hard to detect performance problems |
| 2024-12-05 17:46:19 +0100 | <enikar> | I'm used to write all type signatures for top-level functions, even for the main action |
| 2024-12-05 17:46:23 +0100 | <hellwolf> | for lambdas in let/where clauses, that makes sense. I find top-level signatures nowadays more of a norm, otherwise. |
| 2024-12-05 17:46:27 +0100 | ystael | (~ystael@user/ystael) (Ping timeout: 276 seconds) |
| 2024-12-05 17:46:34 +0100 | <dminuoso> | enikar: Sure. For where clauses most people dont do it as thoroughly though. |
| 2024-12-05 17:46:43 +0100 | <dminuoso> | (or let bindings) |
| 2024-12-05 17:47:51 +0100 | <enikar> | sometimes I write the type of function inside a where clause, for documentation purpose. That helps me to think. |
| 2024-12-05 17:48:35 +0100 | <dminuoso> | Of course that requires you to think where to monomorphise for memoization. :) |
| 2024-12-05 17:48:40 +0100 | <hellwolf> | sometimes it's necessary, when AllowAmbiguousTypes or UndecidableInstances are overly abundant |
| 2024-12-05 17:48:55 +0100 | <geekosaur> | I've taken to always writing type signatures even in let/where |
| 2024-12-05 17:49:15 +0100 | <hellwolf> | oh my... :D care to show a sample code from your code base? |
| 2024-12-05 17:49:15 +0100 | <dminuoso> | I very consistently write them too, but browsing through hackage I would say I'm definitely not in the majority. |
| 2024-12-05 17:49:36 +0100 | <dminuoso> | Heck, its one of the reasons I prefer optics over lens. |
| 2024-12-05 17:50:15 +0100 | <dminuoso> | If it says `A_Prism` I know what it means, but some combination of mathematical constraints - my brain capacity is just too limited. :( |
| 2024-12-05 17:50:25 +0100 | <hellwolf> | I think I am a hlint-driven style follower, I think twice if I had to disable a warning from it. And top-level signature is the defaul tone. |
| 2024-12-05 17:51:44 +0100 | <enikar> | dminuoso: thanks, it begins to be clearer. |
| 2024-12-05 17:54:41 +0100 | <dminuoso> | enikar: Now, there's also the option for SPECIALISE for when you want to expose a polymorphic interface, but at the same time allow a specialized and optimized code that inlines across modules.. |
| 2024-12-05 17:54:58 +0100 | JuanDaugherty | (~juan@user/JuanDaugherty) JuanDaugherty |
| 2024-12-05 17:55:46 +0100 | <dminuoso> | (GHC will do this also automatically for types that top-level bindings are used within the same module, but not across modules) |
| 2024-12-05 17:55:58 +0100 | <dminuoso> | This kind of fits into the same theme here. |
| 2024-12-05 17:56:27 +0100 | <enikar> | I see |
| 2024-12-05 17:56:35 +0100 | <merijn> | enikar: Basically, if you always write type signatures for top-level definitions the MMR will never trigger, so you can forget it exists ;) |
| 2024-12-05 17:57:23 +0100 | youthlic | (~Thunderbi@user/youthlic) (Quit: youthlic) |
| 2024-12-05 17:57:23 +0100 | <enikar> | ok, this is a good news for me :) |
| 2024-12-05 17:58:41 +0100 | <dminuoso> | Well. That's not entirely true either. |
| 2024-12-05 17:58:43 +0100 | <enikar> | notice, sometimes we must write type signature for top-level bindings because ghc can't compute them. |
| 2024-12-05 17:58:46 +0100 | <dminuoso> | But true enough for most users. |
| 2024-12-05 17:59:04 +0100 | machinedgod | (~machinedg@d108-173-18-100.abhsia.telus.net) (Ping timeout: 272 seconds) |
| 2024-12-05 17:59:05 +0100 | <dminuoso> | MMR can trigger even with type signatures. :-) |
| 2024-12-05 17:59:18 +0100 | <lxsameer> | is there any atomic int type in haskell? |
| 2024-12-05 17:59:24 +0100 | <dminuoso> | lxsameer: What does "atomic" mean to you? |
| 2024-12-05 17:59:46 +0100 | <merijn> | enikar: The reasoning behind the MMR is: When you write top-level bindings that look like values (i.e. not a function) would you prefer: 1) it to blow up at compile time with an obvious easy to fix error, 2) have them *sometimes* turn into giant memory leaks, or 3) have them sometimes unpredictably slow down code. With the caveat that 2-3 will always be non-deterministic and hard to detect |
| 2024-12-05 17:59:53 +0100 | <merijn> | lxsameer: We have *at least* 4 |
| 2024-12-05 18:00:19 +0100 | <lxsameer> | dminuoso: atomic means any primitive operations on that is instance. nothing can interupt it |
| 2024-12-05 18:00:27 +0100 | <lxsameer> | merijn: like? |
| 2024-12-05 18:00:39 +0100 | <lxsameer> | *instant |
| 2024-12-05 18:00:40 +0100 | <merijn> | lxsameer: MVar, TVar, IOref, and then some obscure CAS primitives |
| 2024-12-05 18:00:56 +0100 | <lxsameer> | merijn: cheers |
| 2024-12-05 18:01:12 +0100 | <merijn> | lxsameer: MVar is effectively "locked" updates, TVar is software-transactional, IORef is just a mutable reference, but updating them is atomic |
| 2024-12-05 18:01:17 +0100 | <dminuoso> | "nothing can interrupt it", how much is "nothing" here? |
| 2024-12-05 18:01:58 +0100 | <merijn> | enikar: MMR enabled is option 1, MMR disabled is option 3 (option 2 is not implemented because it makes you sad) |
| 2024-12-05 18:02:40 +0100 | <geekosaur> | actually, how meaningful is this given immutability? |
| 2024-12-05 18:03:00 +0100 | <merijn> | enikar: In essence if you write a top level (typeclass) polymorphic value GHC wil silently compile it AS IF it is monomorphic (note how that's the opposite of polymorphic!) |
| 2024-12-05 18:03:06 +0100 | <enikar> | merijn: obviously I prefer the first choice, I have no hesitation on that. |
| 2024-12-05 18:03:15 +0100 | <merijn> | enikar: Which means it wil memoise, as dminuoso described |
| 2024-12-05 18:04:21 +0100 | <merijn> | enikar: By picking 1 specific type and compiling as if it has that type (i.e. it's monomorphic, not polymorphic). If you then use it as two different types (trying to use the polymorphic aspect) it will blow up with the "monomorphism restriction" (i.e. I made this monomorphic, but you're trying to use it polymorphic) |
| 2024-12-05 18:04:49 +0100 | <enikar> | then thank, I will never use NoMonomorphismRstriction :) |
| 2024-12-05 18:04:53 +0100 | <merijn> | enikar: However, this monomorphisation *only* happens in the absence of an explicit signature |
| 2024-12-05 18:04:59 +0100 | <dminuoso> | enikar: In general MMR is desirable, right. |
| 2024-12-05 18:05:50 +0100 | <merijn> | enikar: So if you write a type signature, GHC will just follow what the type signature says (monomorphic if just 'foo :: Int', polymorphic and re-computing at every use for "foo ::Num a => a") |
| 2024-12-05 18:06:29 +0100 | <merijn> | enikar: It's only if you write "foo = 5" (no type annotation) and *then* try to use it as both Int and Double that the MMR triggers |
| 2024-12-05 18:06:45 +0100 | <enikar> | That sounds well for me, some have told me the opposite. |
| 2024-12-05 18:06:59 +0100 | <merijn> | If you write "foo = 5" and only use it as Int, GHC will just silently rewrite foo to 'foo :: Int' vs 'foo :: Double' if you only use it as Double |
| 2024-12-05 18:07:42 +0100 | <merijn> | enikar: The MMR is a perfectly sensible solution to a tricky problem. But people who hate annotating types tend to complain that they have too, ignoring the (painful and subtle) problem it prevents |
| 2024-12-05 18:07:50 +0100 | <enikar> | well, now I understand this subject. |
| 2024-12-05 18:07:52 +0100 | <merijn> | So they'd rather disable |
| 2024-12-05 18:07:55 +0100 | <merijn> | +it |
| 2024-12-05 18:08:19 +0100 | <merijn> | enikar: the MMR, luckily, is nowhere near as hard to understand as the name makes it seem |
| 2024-12-05 18:08:50 +0100 | <dminuoso> | But its very desirable to save you from those two "did I just waste a day to debug this?" days a year. |
| 2024-12-05 18:09:13 +0100 | <enikar> | yes, the name is scary |
| 2024-12-05 18:13:41 +0100 | mari-estel | (~mari-este@user/mari-estel) mari-estel |
| 2024-12-05 18:15:44 +0100 | <hellwolf> | like many things in Haskell... |
| 2024-12-05 18:16:44 +0100 | <enikar> | :D |
| 2024-12-05 18:19:11 +0100 | JuanDaugherty | (~juan@user/JuanDaugherty) (Quit: JuanDaugherty) |
| 2024-12-05 18:19:44 +0100 | <hellwolf> | $ echo "list a few most scary concepts for Haskell the language" | chatgpt |
| 2024-12-05 18:19:44 +0100 | <hellwolf> | for your entertainment: https://paste.tomsmeding.com/fI7vGiak |
| 2024-12-05 18:19:52 +0100 | merijn | (~merijn@77.242.116.146) (Ping timeout: 252 seconds) |
| 2024-12-05 18:21:09 +0100 | <hellwolf> | Fair enough for ADT & GADT... but why would you name something differently just to appease people refuse to learn the abstract concepts? |
| 2024-12-05 18:21:48 +0100 | <hellwolf> | ppl do glaze their eyes over when you say monad, gadt, and sometimes they think you are intimidating them. it can be true in some case... |
| 2024-12-05 18:24:03 +0100 | vanishingideal | (~vanishing@user/vanishingideal) vanishingideal |
| 2024-12-05 18:27:45 +0100 | Digit | (~user@user/digit) Digit |
| 2024-12-05 18:29:22 +0100 | mari-estel | (~mari-este@user/mari-estel) (Quit: on the move) |
| 2024-12-05 18:29:40 +0100 | ystael | (~ystael@user/ystael) ystael |
| 2024-12-05 18:30:03 +0100 | <SrPx> | is this the right way to eval a list in parallel? foldr (\ x xs -> x `par` (x:xs)) list list |
| 2024-12-05 18:35:24 +0100 | <SrPx> | oh oops, that's silly |
| 2024-12-05 18:38:33 +0100 | lxsameer | (~lxsameer@Serene/lxsameer) (Ping timeout: 252 seconds) |
| 2024-12-05 18:38:55 +0100 | raym | (~ray@user/raym) raym |
| 2024-12-05 18:41:42 +0100 | vpan | (~vpan@212.117.1.172) (Quit: Leaving.) |
| 2024-12-05 18:44:25 +0100 | acidjnk_new3 | (~acidjnk@p200300d6e7283f313597cdba6c3bdfe2.dip0.t-ipconnect.de) (Ping timeout: 252 seconds) |
| 2024-12-05 18:48:48 +0100 | peterbecich | (~Thunderbi@syn-047-229-123-186.res.spectrum.com) peterbecich |
| 2024-12-05 18:49:41 +0100 | Smiles | (uid551636@id-551636.lymington.irccloud.com) (Quit: Connection closed for inactivity) |
| 2024-12-05 18:56:17 +0100 | sonolin | (~michael@174-26-31-216.phnx.qwest.net) |
| 2024-12-05 18:56:19 +0100 | sonolin | (~michael@174-26-31-216.phnx.qwest.net) (Changing host) |
| 2024-12-05 18:56:19 +0100 | sonolin | (~michael@user/sonolin) sonolin |
| 2024-12-05 18:58:16 +0100 | peterbecich | (~Thunderbi@syn-047-229-123-186.res.spectrum.com) (Ping timeout: 265 seconds) |
| 2024-12-05 19:02:08 +0100 | ft | (~ft@p508db9c7.dip0.t-ipconnect.de) ft |
| 2024-12-05 19:02:14 +0100 | acidjnk_new3 | (~acidjnk@p200300d6e7283f313597cdba6c3bdfe2.dip0.t-ipconnect.de) acidjnk |
| 2024-12-05 19:07:34 +0100 | tzh | (~tzh@c-76-115-131-146.hsd1.or.comcast.net) tzh |
| 2024-12-05 19:07:53 +0100 | alp | (~alp@128-79-174-146.hfc.dyn.abo.bbox.fr) (Ping timeout: 252 seconds) |
| 2024-12-05 19:08:25 +0100 | Lord_of_Life_ | (~Lord@user/lord-of-life/x-2819915) Lord_of_Life |
| 2024-12-05 19:08:39 +0100 | ljdarj | (~Thunderbi@user/ljdarj) ljdarj |
| 2024-12-05 19:08:45 +0100 | tnt1 | (~Thunderbi@user/tnt1) tnt1 |
| 2024-12-05 19:09:22 +0100 | Lord_of_Life | (~Lord@user/lord-of-life/x-2819915) (Ping timeout: 252 seconds) |
| 2024-12-05 19:11:22 +0100 | Lord_of_Life_ | Lord_of_Life |
| 2024-12-05 19:15:49 +0100 | ash3en | (~Thunderbi@2a03:7846:b6eb:101:93ac:a90a:da67:f207) ash3en |
| 2024-12-05 19:30:16 +0100 | tdammers | (~tdammers@82-150-212-87.ftth.glasoperator.nl) (Ping timeout: 252 seconds) |
| 2024-12-05 19:30:40 +0100 | tdammers | (~tdammers@82-150-212-87.ftth.glasoperator.nl) tdammers |
| 2024-12-05 19:33:03 +0100 | erty | (~user@user/aeroplane) (Ping timeout: 276 seconds) |
| 2024-12-05 19:34:49 +0100 | OftenFaded | (~OftenFade@user/tisktisk) OftenFaded |
| 2024-12-05 19:35:41 +0100 | KicksonButt | (~quassel@187.21.174.221) |
| 2024-12-05 19:38:13 +0100 | acidjnk_new3 | (~acidjnk@p200300d6e7283f313597cdba6c3bdfe2.dip0.t-ipconnect.de) (Ping timeout: 248 seconds) |
| 2024-12-05 19:42:06 +0100 | acidjnk_new3 | (~acidjnk@p200300d6e7283f313597cdba6c3bdfe2.dip0.t-ipconnect.de) acidjnk |
| 2024-12-05 19:53:20 +0100 | OftenFaded | (~OftenFade@user/tisktisk) (Quit: Client closed) |
| 2024-12-05 20:02:55 +0100 | OftenFaded | (~OftenFade@user/tisktisk) OftenFaded |
| 2024-12-05 20:04:35 +0100 | ham | (~ham@user/ham) (Read error: Connection reset by peer) |
| 2024-12-05 20:17:46 +0100 | lxsameer | (~lxsameer@Serene/lxsameer) lxsameer |
| 2024-12-05 20:21:25 +0100 | ash3en | (~Thunderbi@2a03:7846:b6eb:101:93ac:a90a:da67:f207) (Ping timeout: 265 seconds) |
| 2024-12-05 20:28:12 +0100 | ystael | (~ystael@user/ystael) (Ping timeout: 252 seconds) |
| 2024-12-05 20:29:19 +0100 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 2024-12-05 20:33:36 +0100 | sprotte24 | (~sprotte24@p200300d16f0cca009d8994f8fb036ac7.dip0.t-ipconnect.de) |
| 2024-12-05 20:36:07 +0100 | ystael | (~ystael@user/ystael) ystael |
| 2024-12-05 20:37:24 +0100 | Square | (~Square@user/square) (Ping timeout: 246 seconds) |
| 2024-12-05 20:41:18 +0100 | lxsameer | (~lxsameer@Serene/lxsameer) (Ping timeout: 276 seconds) |
| 2024-12-05 20:42:45 +0100 | machinedgod | (~machinedg@d108-173-18-100.abhsia.telus.net) machinedgod |
| 2024-12-05 20:44:34 +0100 | Buliarous | (~gypsydang@46.232.210.139) (Read error: Connection reset by peer) |
| 2024-12-05 20:47:42 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
| 2024-12-05 20:50:33 +0100 | hellwolf | (~user@47cb-a980-d8a8-4fad-0f00-4d40-07d0-2001.sta.estpak.ee) (Remote host closed the connection) |
| 2024-12-05 20:50:51 +0100 | weary-traveler | (~user@user/user363627) (Remote host closed the connection) |
| 2024-12-05 20:50:54 +0100 | hellwolf | (~user@b8a6-130a-d7ff-64a1-0f00-4d40-07d0-2001.sta.estpak.ee) hellwolf |
| 2024-12-05 20:52:49 +0100 | alp | (~alp@2001:861:8ca0:4940:9e8e:b300:b6f0:b48e) |
| 2024-12-05 20:54:43 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 264 seconds) |
| 2024-12-05 21:00:03 +0100 | caconym | (~caconym@user/caconym) (Quit: bye) |
| 2024-12-05 21:00:42 +0100 | caconym | (~caconym@user/caconym) caconym |
| 2024-12-05 21:05:45 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
| 2024-12-05 21:09:20 +0100 | wootehfoot | (~wootehfoo@user/wootehfoot) wootehfoot |
| 2024-12-05 21:09:58 +0100 | <SrPx> | I think sparks is really not working as it should |
| 2024-12-05 21:09:59 +0100 | <SrPx> | https://gist.github.com/VictorTaelin/748a60d8083daaaba10d0507540a7e3a |
| 2024-12-05 21:10:03 +0100 | <SrPx> | or am I doing something dumb |
| 2024-12-05 21:10:50 +0100 | <SrPx> | i converted the whole function to avoid using IO (using unsafePerformIO on the reduce, which is rine) so that it is just a normal recursive function. i'm sparking 4 threads on the arity-4 constructor for debugging. but it clearly is executing them in order, no speedup, the trace show it is sequential |
| 2024-12-05 21:10:57 +0100 | JuanDaugherty | (~juan@user/JuanDaugherty) JuanDaugherty |
| 2024-12-05 21:11:09 +0100 | <SrPx> | (see line 303) |
| 2024-12-05 21:15:07 +0100 | <kaol> | This is pretty much just guessing, but is using f0 `par` f1 `par` f2 `par` f3 `pseq` Ctr cid [f0,f1,f2,f3] on the next line any different? |
| 2024-12-05 21:15:52 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 252 seconds) |
| 2024-12-05 21:15:53 +0100 | <geekosaur> | make sure the results are forced or it will parallelize creating thunks and then force them serially |
| 2024-12-05 21:16:58 +0100 | CrunchyFlakes | (~CrunchyFl@ip1f13e94e.dynamic.kabel-deutschland.de) (Read error: Connection reset by peer) |
| 2024-12-05 21:17:11 +0100 | weary-traveler | (~user@user/user363627) user363627 |
| 2024-12-05 21:17:24 +0100 | TheCoffeMaker_ | (~TheCoffeM@186.136.173.70) (Ping timeout: 260 seconds) |
| 2024-12-05 21:17:25 +0100 | <kaol> | I've always found par confusing and I've had more luck with Control.Parallel.Strategies. |
| 2024-12-05 21:18:00 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
| 2024-12-05 21:18:30 +0100 | <kaol> | "[f0,f1,f2,f3] `using` parList rdeepseq" with it. |
| 2024-12-05 21:19:34 +0100 | CrunchyFlakes | (~CrunchyFl@ip1f13e94e.dynamic.kabel-deutschland.de) |
| 2024-12-05 21:19:43 +0100 | Buliarous | (~gypsydang@46.232.210.139) Buliarous |
| 2024-12-05 21:20:07 +0100 | TheCoffeMaker | (~TheCoffeM@user/thecoffemaker) TheCoffeMaker |
| 2024-12-05 21:25:17 +0100 | TheCoffeMaker | (~TheCoffeM@user/thecoffemaker) (Excess Flood) |
| 2024-12-05 21:25:30 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 276 seconds) |
| 2024-12-05 21:27:15 +0100 | TheCoffeMaker | (~TheCoffeM@user/thecoffemaker) TheCoffeMaker |
| 2024-12-05 21:28:23 +0100 | Tuplanolla | (~Tuplanoll@91-159-69-59.elisa-laajakaista.fi) Tuplanolla |
| 2024-12-05 21:32:09 +0100 | <monochrom> | "It can be intimidating at first" >:) |
| 2024-12-05 21:32:28 +0100 | Guest1 | (~Guest1@104.246.134.243) |
| 2024-12-05 21:32:39 +0100 | KicksonButt | (~quassel@187.21.174.221) (Ping timeout: 252 seconds) |
| 2024-12-05 21:32:41 +0100 | philopsos | (~caecilius@user/philopsos) (Ping timeout: 255 seconds) |
| 2024-12-05 21:33:50 +0100 | <SrPx> | "The new thread will be a lightweight, unbound thread. Foreign calls made by this thread are not guaranteed to be made by any particular OS thread; if you need foreign calls to be made by a particular OS thread, then use forkOS instead." |
| 2024-12-05 21:33:57 +0100 | <SrPx> | I think the issue is that FFI is serialized? |
| 2024-12-05 21:34:17 +0100 | <SrPx> | kaol: hmm |
| 2024-12-05 21:34:49 +0100 | <geekosaur> | unsafe calls aren't, but note their limitations |
| 2024-12-05 21:35:31 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
| 2024-12-05 21:35:37 +0100 | <geekosaur> | (in particular, if an unsafe call blocks, your whole program blocks) |
| 2024-12-05 21:36:18 +0100 | <SrPx> | what would cause it to block though? |
| 2024-12-05 21:40:26 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 252 seconds) |
| 2024-12-05 21:41:13 +0100 | <geekosaur> | I don't see the foreign call so I have no idea |
| 2024-12-05 21:41:29 +0100 | <geekosaur> | memory allocation is the one most people don't realize is a problem |
| 2024-12-05 21:41:53 +0100 | <geekosaur> | I/O calls in C are obviously an issue |
| 2024-12-05 21:42:23 +0100 | <geekosaur> | especially since even C doesn't know some of them block (spinning rust is slow, yo) |
| 2024-12-05 21:43:51 +0100 | Guest1 | (~Guest1@104.246.134.243) (Quit: Client closed) |
| 2024-12-05 21:43:57 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
| 2024-12-05 21:47:17 +0100 | <SrPx> | the IO function was just a busy loop in C |
| 2024-12-05 21:47:27 +0100 | peterbecich | (~Thunderbi@syn-047-229-123-186.res.spectrum.com) peterbecich |
| 2024-12-05 21:47:48 +0100 | <SrPx> | but turns out it was my fault, cabal wasn't installing with -N, only cabal run was /facepalm |
| 2024-12-05 21:47:49 +0100 | <SrPx> | sorry guys |
| 2024-12-05 21:48:04 +0100 | SrPx | was so confused |
| 2024-12-05 21:48:39 +0100 | KicksonButt | (~quassel@187.21.174.221) |
| 2024-12-05 21:48:51 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 252 seconds) |
| 2024-12-05 21:50:34 +0100 | <SrPx> | it works 🥳 |
| 2024-12-05 21:59:40 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
| 2024-12-05 22:01:11 +0100 | gmg | (~user@user/gehmehgeh) (Quit: Leaving) |
| 2024-12-05 22:04:34 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 245 seconds) |
| 2024-12-05 22:04:51 +0100 | gmg | (~user@user/gehmehgeh) gehmehgeh |
| 2024-12-05 22:10:02 +0100 | <geekosaur> | "busy loop in C" would block Haskell, though |
| 2024-12-05 22:11:36 +0100 | gmg | (~user@user/gehmehgeh) (Ping timeout: 264 seconds) |
| 2024-12-05 22:12:15 +0100 | gmg | (~user@user/gehmehgeh) gehmehgeh |
| 2024-12-05 22:12:26 +0100 | JuanDaugherty | (~juan@user/JuanDaugherty) (Quit: JuanDaugherty) |
| 2024-12-05 22:13:39 +0100 | tdammers | (~tdammers@82-150-212-87.ftth.glasoperator.nl) (Ping timeout: 246 seconds) |
| 2024-12-05 22:15:26 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
| 2024-12-05 22:18:05 +0100 | <SrPx> | how so? it worked fine with the correct arguments |
| 2024-12-05 22:18:27 +0100 | philopsos | (~caecilius@user/philopsos) philopsos |
| 2024-12-05 22:18:39 +0100 | <SrPx> | is there any way to signal from C side that a spark should sleep / give its turn to another spark? |
| 2024-12-05 22:19:25 +0100 | ystael | (~ystael@user/ystael) (Ping timeout: 252 seconds) |
| 2024-12-05 22:19:30 +0100 | <geekosaur> | if a GC doesn't happen you won't see a problem. all threads synchronize during a GC, and a thread in an unsafe foreign call can't synchronize so all threads block until the call returns |
| 2024-12-05 22:19:50 +0100 | michalz | (~michalz@185.246.207.222) (Remote host closed the connection) |
| 2024-12-05 22:20:04 +0100 | <geekosaur> | and no, C can't tell Haskell much of anything except by returning. (The one exception is there's an interface to tryPutMVar) |
| 2024-12-05 22:20:30 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 252 seconds) |
| 2024-12-05 22:20:42 +0100 | <SrPx> | the issue is, I'm using sparks to reduce a tree to normal form. to do so, I must call a C-side reduce function, that evaluates a pointer to whnf. the problem is that this function uses a stack, so I can only have <core_count> reduces running in parallel |
| 2024-12-05 22:21:26 +0100 | <SrPx> | so my idea is: when haskell calls reduce, it will pop a stack id from a pool of available stacks. if it gets it, it does the work. otherwise, it spinlocks(?) until a stack is available |
| 2024-12-05 22:21:42 +0100 | <SrPx> | but then I wonder what will happen to the haskell side spark when the C function it called is spinlocking |
| 2024-12-05 22:22:04 +0100 | <SrPx> | am I using the wrong abstraction? |
| 2024-12-05 22:22:19 +0100 | <SrPx> | perhaps I should avoid sparks and build my own scheduler haskell-side? |
| 2024-12-05 22:22:22 +0100 | <SrPx> | or will haskell handle that smoothly |
| 2024-12-05 22:24:09 +0100 | peterbecich | (~Thunderbi@syn-047-229-123-186.res.spectrum.com) (Ping timeout: 246 seconds) |
| 2024-12-05 22:27:40 +0100 | <SrPx> | oh I could just manage the available-stack pool haskell side with mvars i guess |
| 2024-12-05 22:31:15 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
| 2024-12-05 22:32:42 +0100 | r-sta | (~r-sta@sgyl-37-b2-v4wan-168528-cust2421.vm6.cable.virginm.net) |
| 2024-12-05 22:36:28 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 272 seconds) |
| 2024-12-05 22:37:24 +0100 | <geekosaur> | usually haskell will just handle it |
| 2024-12-05 22:38:05 +0100 | <geekosaur> | the only reason I raised the issue of unsafe foreign calls was that you were worried about OS threads ("The new thread will be a lightweight, unbound thread. Foreign calls made by this thread are not guaranteed to be made by any particular OS thread") |
| 2024-12-05 22:38:12 +0100 | <geekosaur> | this has nothing to do with serialization |
| 2024-12-05 22:38:33 +0100 | <geekosaur> | it has to do with thread-local state, which is not used often because it's very limited and expensive |
| 2024-12-05 22:41:36 +0100 | califax | (~califax@user/califx) (Ping timeout: 264 seconds) |
| 2024-12-05 22:42:10 +0100 | <r-sta> | im upset because there is something similar happening in 2 places in my code, and i cant seem to unify them |
| 2024-12-05 22:42:34 +0100 | califax | (~califax@user/califx) califx |
| 2024-12-05 22:43:30 +0100 | <r-sta> | one is a buffer on streaming machines, which enter an ensemble, are updated, and saved. the other is not a buffer, and is of traders, and is also updated and saved. how is the buffer and the collection supposed to be captured by the same abstraction supporting editing and saving? |
| 2024-12-05 22:44:58 +0100 | <r-sta> | i can make, 2 objects, one buffering, one not. but im not sure how to get an abstraction presumably in the form of a class, that they can both use |
| 2024-12-05 22:44:59 +0100 | ljdarj | (~Thunderbi@user/ljdarj) (Ping timeout: 245 seconds) |
| 2024-12-05 22:45:32 +0100 | <r-sta> | i can say at the constraint, that the objects in the ensemble have to have Store instances, so they can be loaded and saved |
| 2024-12-05 22:45:44 +0100 | <r-sta> | but nothing to say that when they are edited that they should be saved |
| 2024-12-05 22:46:00 +0100 | <r-sta> | the user is just expected to ensure the store instance is actually used in the implementation |
| 2024-12-05 22:46:07 +0100 | <r-sta> | im not sure how i can ensure they do so |
| 2024-12-05 22:46:47 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
| 2024-12-05 22:46:54 +0100 | <SrPx> | hmmm ok thanks, lets see what happens |
| 2024-12-05 22:47:00 +0100 | <r-sta> | its like, i can have 2 objects containing things that *can* be saved, but no way to say they actually are! |
| 2024-12-05 22:48:03 +0100 | <r-sta> | otherwise its just; Store a => f a |
| 2024-12-05 22:48:31 +0100 | <geekosaur> | this is kinda classic type level area, I think? |
| 2024-12-05 22:48:55 +0100 | <r-sta> | yeah, kind of |
| 2024-12-05 22:49:29 +0100 | <r-sta> | i can have eg; data Ensemble f a where Ensemble :: Store a => f a -> Ensemble f a |
| 2024-12-05 22:49:37 +0100 | <r-sta> | it ends up looking like a kind of dictionary |
| 2024-12-05 22:49:52 +0100 | briandaed | (~root@user/briandaed) (Remote host closed the connection) |
| 2024-12-05 22:50:35 +0100 | <geekosaur> | although even in that case you can only guarantee it if the only way to generate the "used" type tag is for a Store instance to use some function/method you provide |
| 2024-12-05 22:51:15 +0100 | <geekosaur> | otherwise, I think you're just running into the problem that you can generally guide against accidental misuse but not malicious misuse |
| 2024-12-05 22:51:34 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 252 seconds) |
| 2024-12-05 22:51:35 +0100 | <r-sta> | class Store a is just save :: a -> IO (); load :: IO a |
| 2024-12-05 22:51:55 +0100 | <geekosaur> | (and no matter what, someone can unsafeCoerce on you to escape the type issue) |
| 2024-12-05 22:52:05 +0100 | <r-sta> | hmm. |
| 2024-12-05 22:52:11 +0100 | <r-sta> | im not sure about the idea |
| 2024-12-05 22:52:15 +0100 | <r-sta> | im not sure i understand |
| 2024-12-05 22:52:17 +0100 | <r-sta> | a tag? |
| 2024-12-05 22:52:45 +0100 | <geekosaur> | the idea is you have a type level tag indicating that the store has been used, that can only be acquired by actual use |
| 2024-12-05 22:53:24 +0100 | <geekosaur> | except that unsafeCoerce can still generate it, so someone deliberately trying to evade your safety would be able to do so (well, absent Safe Haskell) |
| 2024-12-05 22:53:28 +0100 | <r-sta> | like, `a' would have some kind of type level Bool saying if it is before or after a save, with an edit |
| 2024-12-05 22:54:04 +0100 | <r-sta> | and then the function type could ensure the update also changed the `a' to have the Saved label |
| 2024-12-05 22:54:13 +0100 | <r-sta> | actually might be a very good solution. thanks |
| 2024-12-05 22:54:27 +0100 | <geekosaur> | f (Unsaved a) -> f (Saved a) where the only way to get Saved is to invoke your saver |
| 2024-12-05 22:54:53 +0100 | <r-sta> | i guess thats something i just do, and not something i express |
| 2024-12-05 22:55:06 +0100 | <r-sta> | "the only way" |
| 2024-12-05 22:55:12 +0100 | wootehfoot | (~wootehfoo@user/wootehfoot) (Read error: Connection reset by peer) |
| 2024-12-05 22:55:15 +0100 | <r-sta> | is that something linear types could do? |
| 2024-12-05 22:55:32 +0100 | <geekosaur> | https://blog.jle.im/entry/introduction-to-singletons-1.html |
| 2024-12-05 22:55:57 +0100 | <r-sta> | i know all these things from ages ago |
| 2024-12-05 22:56:07 +0100 | <geekosaur> | no, linear types express "used only once as opposed to many times" but they don't help with "not used at all" |
| 2024-12-05 22:56:10 +0100 | tdammers | (~tdammers@82-150-212-87.ftth.glasoperator.nl) tdammers |
| 2024-12-05 22:56:11 +0100 | <r-sta> | though i cant quite see the relavence |
| 2024-12-05 22:57:03 +0100 | <r-sta> | i think ill just go with these wrappers you suggest |
| 2024-12-05 22:57:10 +0100 | <geekosaur> | jle's example is a door where you can't lock the door unless it's closed first, but it shows the basic idea of controlling the state of a value (in your case it's simpler: is it saved, or not?) |
| 2024-12-05 22:57:57 +0100 | <geekosaur> | I'm not especially fond of it because singletons needs to be burned with fire, but it does get the job done (somewhat painfully because Haskell isn't actually dependently typed) |
| 2024-12-05 22:58:17 +0100 | <r-sta> | tyfun! |
| 2024-12-05 22:58:57 +0100 | <r-sta> | partially applied type families. horrible! |
| 2024-12-05 22:59:13 +0100 | <r-sta> | i used to do stencil convolutions at type level. i quit |
| 2024-12-05 23:02:33 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
| 2024-12-05 23:07:17 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 248 seconds) |
| 2024-12-05 23:08:08 +0100 | <r-sta> | so basically, i end up with a class that can return the state of the object in terms of being saved |
| 2024-12-05 23:08:23 +0100 | <r-sta> | i guess i need to make my edit function ensure that it returns the unsaved version |
| 2024-12-05 23:08:35 +0100 | <geekosaur> | right |
| 2024-12-05 23:09:43 +0100 | <r-sta> | and this class, associates a "singleton" term to each value the phantom takes |
| 2024-12-05 23:10:15 +0100 | <r-sta> | so i can read and pattern match at term level, differently depending on the type |
| 2024-12-05 23:10:51 +0100 | <r-sta> | weird. singletons allow to do exactly what i want |
| 2024-12-05 23:11:21 +0100 | ljdarj | (~Thunderbi@user/ljdarj) ljdarj |
| 2024-12-05 23:11:30 +0100 | <r-sta> | but kinda clunky how my objects now have to sit in these saved or not wrappers |
| 2024-12-05 23:12:12 +0100 | <geekosaur> | well, there has to be some way to indicate saved vs. unsaved, and in Haskell that way is types |
| 2024-12-05 23:12:38 +0100 | <r-sta> | i mean, normally i would just have a collection of objects, but now my objects always have these wrappers |
| 2024-12-05 23:12:42 +0100 | <r-sta> | but your right its fine |
| 2024-12-05 23:12:48 +0100 | <r-sta> | thats just how its indicating the functionality |
| 2024-12-05 23:13:16 +0100 | <r-sta> | i guess then i can write the edit class? |
| 2024-12-05 23:13:22 +0100 | takuan | (~takuan@178-116-218-225.access.telenet.be) (Remote host closed the connection) |
| 2024-12-05 23:13:58 +0100 | mud | (~mud@user/kadoban) (Remote host closed the connection) |
| 2024-12-05 23:14:27 +0100 | <r-sta> | that says the user, for some container, has to implement a function that does an edit, casing from f (Saved a) to f (Unsaved a). and a function that does the save with the types the other way round in the function |
| 2024-12-05 23:14:36 +0100 | <geekosaur> | (alternately you have one type and associate it with a tag, e.g. Val a st where st is Saved or Unsaved, which makes it easier to be polymorphic over it when you don't care) |
| 2024-12-05 23:15:34 +0100 | <r-sta> | alternately? |
| 2024-12-05 23:15:40 +0100 | <r-sta> | thats not what we were just doing? |
| 2024-12-05 23:16:03 +0100 | <geekosaur> | the first verion I brought up was Saved a vs. Unsaved a |
| 2024-12-05 23:16:08 +0100 | mud | (~mud@user/kadoban) kadoban |
| 2024-12-05 23:16:13 +0100 | <geekosaur> | Val a Saved/Unsaved is a little more flexible |
| 2024-12-05 23:16:50 +0100 | <r-sta> | yeah, id go with that |
| 2024-12-05 23:17:18 +0100 | <r-sta> | and i can write; f (Val a st) |
| 2024-12-05 23:17:46 +0100 | supercode | (~supercode@user/supercode) supercode |
| 2024-12-05 23:17:52 +0100 | <r-sta> | yo i joined in 2007, this is 17 years on |
| 2024-12-05 23:18:09 +0100 | <r-sta> | feel like iv seen the name geekosaur the whole time |
| 2024-12-05 23:18:17 +0100 | r-sta | (~r-sta@sgyl-37-b2-v4wan-168528-cust2421.vm6.cable.virginm.net) (Quit: Client closed) |
| 2024-12-05 23:18:20 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
| 2024-12-05 23:18:31 +0100 | <geekosaur> | you're not wrong, I joined in lateish 2006 |
| 2024-12-05 23:19:00 +0100 | r-sta | (~r-sta@sgyl-37-b2-v4wan-168528-cust2421.vm6.cable.virginm.net) |
| 2024-12-05 23:19:09 +0100 | <r-sta> | im also really happy that describing my problem led to a solution |
| 2024-12-05 23:19:14 +0100 | <r-sta> | its awesome when that happens |
| 2024-12-05 23:21:39 +0100 | weary-traveler | (~user@user/user363627) (Remote host closed the connection) |
| 2024-12-05 23:23:05 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 252 seconds) |
| 2024-12-05 23:26:30 +0100 | Tuplanolla | (~Tuplanoll@91-159-69-59.elisa-laajakaista.fi) (Quit: Leaving.) |
| 2024-12-05 23:30:08 +0100 | <haskellbridge> | <zwro> rubber ducking |
| 2024-12-05 23:30:21 +0100 | <r-sta> | chatGPT seems to excell in this case |
| 2024-12-05 23:30:21 +0100 | <r-sta> | https://chatgpt.com/share/67522966-b920-800b-b345-eedb795923e3 |
| 2024-12-05 23:31:06 +0100 | <r-sta> | combination of expert input and automated code generation working amazingly! |
| 2024-12-05 23:31:15 +0100 | <r-sta> | it makes some errors still tho |
| 2024-12-05 23:31:21 +0100 | <r-sta> | (Item) |
| 2024-12-05 23:31:53 +0100 | r-sta | (~r-sta@sgyl-37-b2-v4wan-168528-cust2421.vm6.cable.virginm.net) (Quit: Client closed) |
| 2024-12-05 23:33:56 +0100 | mange | (~user@user/mange) mange |
| 2024-12-05 23:34:08 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
| 2024-12-05 23:38:13 +0100 | tdammers | (~tdammers@82-150-212-87.ftth.glasoperator.nl) (Ping timeout: 248 seconds) |
| 2024-12-05 23:40:48 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 246 seconds) |
| 2024-12-05 23:43:08 +0100 | falafel | (~falafel@2603:8000:b4f0:62a0:e8b3:b69f:e70f:bca9) falafel |
| 2024-12-05 23:44:00 +0100 | szkl | (uid110435@id-110435.uxbridge.irccloud.com) (Quit: Connection closed for inactivity) |
| 2024-12-05 23:47:56 +0100 | sindu | (~sindu@176.75.224.1) |
| 2024-12-05 23:49:13 +0100 | supercode | (~supercode@user/supercode) (Quit: Client closed) |
| 2024-12-05 23:52:10 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
| 2024-12-05 23:52:52 +0100 | supercode | (~supercode@user/supercode) supercode |
| 2024-12-05 23:57:12 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 252 seconds) |