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