| 2022-11-22 00:00:13 +0100 | <monochrom> | But I am not sure what to do with two type variables |
| 2022-11-22 00:00:57 +0100 | <monochrom> | Oh! There is only one type variable, the one for the Alternative instance! |
| 2022-11-22 00:01:10 +0100 | <monochrom> | @src IO asum |
| 2022-11-22 00:01:10 +0100 | <lambdabot> | Source not found. Where did you learn to type? |
| 2022-11-22 00:01:51 +0100 | <monochrom> | But it probably really doesn't have asum. |
| 2022-11-22 00:04:42 +0100 | bitdex | (~bitdex@gateway/tor-sasl/bitdex) (Remote host closed the connection) |
| 2022-11-22 00:04:50 +0100 | sammelweis | (~quassel@2601:401:8200:2d4c:bd9:d04c:7f69:eb10) (Quit: No Ping reply in 180 seconds.) |
| 2022-11-22 00:04:58 +0100 | troydm | (~troydm@host-176-37-124-197.b025.la.net.ua) |
| 2022-11-22 00:05:35 +0100 | chexum | (~quassel@gateway/tor-sasl/chexum) (Ping timeout: 255 seconds) |
| 2022-11-22 00:05:55 +0100 | bitdex | (~bitdex@gateway/tor-sasl/bitdex) |
| 2022-11-22 00:06:18 +0100 | sammelweis | (~quassel@2601:401:8200:2d4c:bd9:d04c:7f69:eb10) |
| 2022-11-22 00:06:49 +0100 | chexum | (~quassel@gateway/tor-sasl/chexum) |
| 2022-11-22 00:07:46 +0100 | euandreh | (~Thunderbi@179.214.113.107) (Remote host closed the connection) |
| 2022-11-22 00:08:00 +0100 | <xerox> | yeah https://github.com/lambdabot/lambdabot/blob/master/lambdabot/State/source |
| 2022-11-22 00:09:39 +0100 | euandreh | (~Thunderbi@179.214.113.107) |
| 2022-11-22 00:12:23 +0100 | kayvank | (~user@52-119-115-185.PUBLIC.monkeybrains.net) (Remote host closed the connection) |
| 2022-11-22 00:14:27 +0100 | euandreh | (~Thunderbi@179.214.113.107) (Client Quit) |
| 2022-11-22 00:16:44 +0100 | troydm | (~troydm@host-176-37-124-197.b025.la.net.ua) (Ping timeout: 268 seconds) |
| 2022-11-22 00:18:18 +0100 | euandreh | (~Thunderbi@179.214.113.107) |
| 2022-11-22 00:22:43 +0100 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) |
| 2022-11-22 00:28:16 +0100 | aliosablack | (~chomwitt@2a02:587:7a08:f700:1ac0:4dff:fedb:a3f1) (Ping timeout: 252 seconds) |
| 2022-11-22 00:28:51 +0100 | sammelweis | (~quassel@2601:401:8200:2d4c:bd9:d04c:7f69:eb10) (Quit: No Ping reply in 180 seconds.) |
| 2022-11-22 00:31:01 +0100 | ubert | (~Thunderbi@91.141.78.146.wireless.dyn.drei.com) (Ping timeout: 252 seconds) |
| 2022-11-22 00:31:01 +0100 | ub | ubert |
| 2022-11-22 00:37:04 +0100 | c209e6dc-4d76-47 | (~aditya@2601:249:4300:1296:195:dac6:592c:a55a) |
| 2022-11-22 00:37:26 +0100 | <c209e6dc-4d76-47> | Is there a way to know the stack trace for when ExceptT fails? |
| 2022-11-22 00:38:47 +0100 | mikoto-chan | (~mikoto-ch@164.5.249.78) (Ping timeout: 260 seconds) |
| 2022-11-22 00:39:16 +0100 | merijn | (~merijn@c-001-001-017.client.esciencecenter.eduvpn.nl) |
| 2022-11-22 00:42:06 +0100 | sammelweis | (~quassel@2601:401:8200:2d4c:bd9:d04c:7f69:eb10) |
| 2022-11-22 00:43:15 +0100 | freeside | (~mengwong@103.252.202.193) (Ping timeout: 268 seconds) |
| 2022-11-22 00:52:14 +0100 | fserucas | (~fserucas@2001:818:e376:a400:fb92:70c1:dd88:c7d7) |
| 2022-11-22 00:52:20 +0100 | Kaiepi | (~Kaiepi@108.175.84.104) (Ping timeout: 248 seconds) |
| 2022-11-22 00:52:58 +0100 | nate4 | (~nate@98.45.169.16) |
| 2022-11-22 00:54:44 +0100 | freeside | (~mengwong@103.252.202.193) |
| 2022-11-22 00:55:51 +0100 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 2022-11-22 00:56:04 +0100 | caryhartline | (~caryhartl@2603-8080-6a0e-8d88-d0ec-e190-f31a-ff70.res6.spectrum.com) (Quit: caryhartline) |
| 2022-11-22 00:58:10 +0100 | nate4 | (~nate@98.45.169.16) (Ping timeout: 260 seconds) |
| 2022-11-22 00:58:15 +0100 | k8yun | (~k8yun@user/k8yun) |
| 2022-11-22 01:00:10 +0100 | freeside | (~mengwong@103.252.202.193) (Ping timeout: 252 seconds) |
| 2022-11-22 01:00:25 +0100 | troydm | (~troydm@host-176-37-124-197.b025.la.net.ua) |
| 2022-11-22 01:00:53 +0100 | fserucas | (~fserucas@2001:818:e376:a400:fb92:70c1:dd88:c7d7) (Quit: Leaving) |
| 2022-11-22 01:01:16 +0100 | srz_ | (~srz@179.36.104.57) |
| 2022-11-22 01:01:50 +0100 | bitdex | (~bitdex@gateway/tor-sasl/bitdex) (Ping timeout: 255 seconds) |
| 2022-11-22 01:02:52 +0100 | srz_ | (~srz@179.36.104.57) (Remote host closed the connection) |
| 2022-11-22 01:03:13 +0100 | eggplantade | (~Eggplanta@2600:1700:38c5:d800:5866:96fb:16f6:58d1) |
| 2022-11-22 01:03:18 +0100 | bitdex | (~bitdex@gateway/tor-sasl/bitdex) |
| 2022-11-22 01:03:24 +0100 | srz_ | (~srz@179.36.104.57) |
| 2022-11-22 01:03:36 +0100 | srz | (~srz@181.228.49.93) (Ping timeout: 268 seconds) |
| 2022-11-22 01:06:53 +0100 | dsrt^ | (~dsrt@76.145.185.103) |
| 2022-11-22 01:07:29 +0100 | sammelweis | (~quassel@2601:401:8200:2d4c:bd9:d04c:7f69:eb10) (Quit: No Ping reply in 180 seconds.) |
| 2022-11-22 01:07:36 +0100 | eggplantade | (~Eggplanta@2600:1700:38c5:d800:5866:96fb:16f6:58d1) (Ping timeout: 255 seconds) |
| 2022-11-22 01:07:58 +0100 | ddellacosta | (~ddellacos@89.45.224.71) (Quit: WeeChat 3.7.1) |
| 2022-11-22 01:08:24 +0100 | ddellacosta | (~ddellacos@89.45.224.71) |
| 2022-11-22 01:08:46 +0100 | sammelweis | (~quassel@2601:401:8200:2d4c:bd9:d04c:7f69:eb10) |
| 2022-11-22 01:08:50 +0100 | merijn | (~merijn@c-001-001-017.client.esciencecenter.eduvpn.nl) (Ping timeout: 256 seconds) |
| 2022-11-22 01:09:29 +0100 | srz_ | (~srz@179.36.104.57) (Ping timeout: 260 seconds) |
| 2022-11-22 01:10:02 +0100 | azimut | (~azimut@gateway/tor-sasl/azimut) |
| 2022-11-22 01:11:18 +0100 | <Axman6> | c209e6dc-4d76-47: not really, if you think about it, it's not a super helpful thing to have in a language where nearly everything is a function. There are ways to build stack traces though, you might find this useful: https://www.parsonsmatt.org/2022/08/16/dynamic_exception_reporting_in_haskell.html |
| 2022-11-22 01:14:01 +0100 | freeside | (~mengwong@103.252.202.193) |
| 2022-11-22 01:15:32 +0100 | <c209e6dc-4d76-47> | so I am writing a typechecker for my toy language and using ExceptT to throw various kinds of errors |
| 2022-11-22 01:15:51 +0100 | azimut | (~azimut@gateway/tor-sasl/azimut) (Remote host closed the connection) |
| 2022-11-22 01:15:52 +0100 | <c209e6dc-4d76-47> | but I am having difficulty finding out where a specific error has been thrown in from the compiler code |
| 2022-11-22 01:16:03 +0100 | <c209e6dc-4d76-47> | to debug if it is a problem with compiler itself |
| 2022-11-22 01:16:26 +0100 | wroathe | (~wroathe@207-153-38-140.fttp.usinternet.com) |
| 2022-11-22 01:16:26 +0100 | wroathe | (~wroathe@207-153-38-140.fttp.usinternet.com) (Changing host) |
| 2022-11-22 01:16:26 +0100 | wroathe | (~wroathe@user/wroathe) |
| 2022-11-22 01:16:28 +0100 | <Axman6> | You can safely add HasCallstack constraints to your functions to make that easier, like in that post |
| 2022-11-22 01:16:40 +0100 | azimut | (~azimut@gateway/tor-sasl/azimut) |
| 2022-11-22 01:28:24 +0100 | chexum | (~quassel@gateway/tor-sasl/chexum) (Quit: No Ping reply in 180 seconds.) |
| 2022-11-22 01:29:34 +0100 | chromoblob | (~user@37.113.164.122) |
| 2022-11-22 01:30:25 +0100 | <c209e6dc-4d76-47> | hmm, I see, but I'll have to switch out the ExceptT for error calls, right? |
| 2022-11-22 01:30:41 +0100 | chexum | (~quassel@gateway/tor-sasl/chexum) |
| 2022-11-22 01:31:26 +0100 | lucerne | (~lucerne@5.116.75.203) |
| 2022-11-22 01:32:04 +0100 | <jackdk> | Your `e` in your `ExceptT e m` monad could capture a call stack? |
| 2022-11-22 01:32:25 +0100 | <Axman6> | you could include the call stack in the ExceptT errors - throw' :: HasCallstack => e -> ExceptT (Callstack, e) m a |
| 2022-11-22 01:32:40 +0100 | Axman6 | high fives jackdk |
| 2022-11-22 01:33:41 +0100 | <monochrom> | I am not sure which "error" you mean: 1. Toy typechecker finds a type error in the input, want to track location? 2. Toy typechecker has a bug, want GHC to report location? |
| 2022-11-22 01:34:02 +0100 | <monochrom> | Because "clearly" the former requires you to implement location tracking yourself. |
| 2022-11-22 01:36:52 +0100 | <monochrom> | Ironically I am preparing a talk on logics, and I need to clarify how my audience can tell whether I am speaking in the meta-logic or speaking about the target logic. |
| 2022-11-22 01:37:15 +0100 | chromoblob | (~user@37.113.164.122) (Ping timeout: 260 seconds) |
| 2022-11-22 01:37:21 +0100 | <monochrom> | And I was thinking "oh but programmers don't find it confusing because they are already used to using GHC to compile GHC!" |
| 2022-11-22 01:37:49 +0100 | <monochrom> | But I guess we see that it is still confusing to programmers. |
| 2022-11-22 01:38:21 +0100 | <hpc> | they're just not meta-meta |
| 2022-11-22 01:38:23 +0100 | <c209e6dc-4d76-47> | more on the lines of 2. toy typechecker has a bug, want GHC to report when toy typechecker report error in the toy program. |
| 2022-11-22 01:38:49 +0100 | <c209e6dc-4d76-47> | *location in toy typechecker from where toy typechecker found an error in program |
| 2022-11-22 01:38:51 +0100 | <Axman6> | that sounds like something for your parser then |
| 2022-11-22 01:38:56 +0100 | <monochrom> | Then ExceptT is totally not for that. |
| 2022-11-22 01:38:59 +0100 | <Axman6> | or not? |
| 2022-11-22 01:39:25 +0100 | <hpc> | yeah, it's the parser's job |
| 2022-11-22 01:39:26 +0100 | <c209e6dc-4d76-47> | parser would have locations from programs not the compiler itself afaik |
| 2022-11-22 01:39:35 +0100 | <hpc> | it's like asking for a gcc error when a webpage 404s |
| 2022-11-22 01:43:23 +0100 | <probie> | monochrom: On slides, I find it's helpful to use different symbols (e.g. wedge and thick arrows for one, & and thin arrows for the other). e.g. (p |- q) -> |- (p => q) for something like "if p entails q, then empty entails p implies q" |
| 2022-11-22 01:43:27 +0100 | Lumia | (~Lumia@user/Lumia) |
| 2022-11-22 01:43:33 +0100 | <monochrom> | To debug bugs, I would use Debug.Trace instead. |
| 2022-11-22 01:43:54 +0100 | <hpc> | c209e6dc-4d76-47: to pre-empt another common issue, unless your code does some really fancy guesswork the location info is going to point to the first point of surprise, not the actual first point of error |
| 2022-11-22 01:43:56 +0100 | <Axman6> | c209e6dc-4d76-47: an alternative, if you have a program you're parsing which causes a problem is to log things instead - log the arguments to each function with its name and any other relevant values |
| 2022-11-22 01:44:03 +0100 | <monochrom> | Yeah I'll use English for the meta-logic, symbols for the target logic. |
| 2022-11-22 01:44:37 +0100 | <hpc> | or some kind of intermediate language, depending on how you have it set up? |
| 2022-11-22 01:44:39 +0100 | <Axman6> | depending on what your app's monad is, Debug.Trace or print are both food ways to hack this |
| 2022-11-22 01:44:56 +0100 | <hpc> | even if the language isn't actually a real language but just a vaguely nice-ish representation of a data structure |
| 2022-11-22 01:45:08 +0100 | <monochrom> | yum, food ways :) |
| 2022-11-22 01:45:25 +0100 | <hpc> | *depending on what your app's burrito is |
| 2022-11-22 01:46:12 +0100 | <monochrom> | "your labour bears fruit" -> "your labour beer food" >:) |
| 2022-11-22 01:46:13 +0100 | <Axman6> | good too |
| 2022-11-22 01:47:09 +0100 | <Axman6> | monochrom: the Australian Labor Party (yes it is actually spelt like that) owns a bunch of clubs, so labor beer food isn;t a particularly surprising sentense here |
| 2022-11-22 01:47:17 +0100 | <hpc> | i eat my bear fruit with my bear hands |
| 2022-11-22 01:47:24 +0100 | <probie> | monochrom: out of curiosity, what is the target logic? |
| 2022-11-22 01:47:42 +0100 | <monochrom> | intuitionistic logic |
| 2022-11-22 01:50:44 +0100 | <maerwald> | sm: correct |
| 2022-11-22 01:52:39 +0100 | gurkenglas | (~gurkengla@p548ac72e.dip0.t-ipconnect.de) (Ping timeout: 260 seconds) |
| 2022-11-22 01:58:49 +0100 | sammelweis | (~quassel@2601:401:8200:2d4c:bd9:d04c:7f69:eb10) (Quit: No Ping reply in 180 seconds.) |
| 2022-11-22 02:02:57 +0100 | srz | (~srz@179.36.104.57) |
| 2022-11-22 02:06:04 +0100 | marc___ | (~marc@5.83.191.225) (Ping timeout: 256 seconds) |
| 2022-11-22 02:06:13 +0100 | merijn | (~merijn@c-001-001-017.client.esciencecenter.eduvpn.nl) |
| 2022-11-22 02:06:38 +0100 | Lumia | (~Lumia@user/Lumia) (Remote host closed the connection) |
| 2022-11-22 02:06:39 +0100 | ubert | (~Thunderbi@91.141.78.146.wireless.dyn.drei.com) (Ping timeout: 260 seconds) |
| 2022-11-22 02:06:53 +0100 | ubert | (~Thunderbi@178.165.183.156.wireless.dyn.drei.com) |
| 2022-11-22 02:07:01 +0100 | acidjnk | (~acidjnk@p200300d6e7137a84584e92a62d782504.dip0.t-ipconnect.de) (Ping timeout: 256 seconds) |
| 2022-11-22 02:07:35 +0100 | marc__ | (~marc@46.167.25.184) |
| 2022-11-22 02:09:06 +0100 | c209e6dc-4d76-47 | (~aditya@2601:249:4300:1296:195:dac6:592c:a55a) (Quit: Konversation terminated!) |
| 2022-11-22 02:09:29 +0100 | kaol | (~kaol@94-237-42-30.nl-ams1.upcloud.host) (Ping timeout: 246 seconds) |
| 2022-11-22 02:11:48 +0100 | xff0x | (~xff0x@ai071162.d.east.v6connect.net) (Ping timeout: 248 seconds) |
| 2022-11-22 02:12:02 +0100 | zeenk | (~zeenk@2a02:2f04:a208:3600::7fe) (Quit: Konversation terminated!) |
| 2022-11-22 02:13:38 +0100 | mud | (~mud@user/kadoban) (Quit: quit) |
| 2022-11-22 02:14:42 +0100 | sammelweis | (~quassel@2601:401:8200:2d4c:bd9:d04c:7f69:eb10) |
| 2022-11-22 02:15:27 +0100 | kaol | (~kaol@94-237-42-30.nl-ams1.upcloud.host) |
| 2022-11-22 02:15:34 +0100 | <maerwald[m]> | Available binaries are here https://github.com/haskell/ghcup-metadata/blob/develop/hls-metadata-0.0.1.json |
| 2022-11-22 02:16:01 +0100 | <maerwald[m]> | But only vscode haskell extension makes use of it |
| 2022-11-22 02:16:29 +0100 | mud | (~mud@user/kadoban) |
| 2022-11-22 02:16:34 +0100 | freeside | (~mengwong@103.252.202.193) (Ping timeout: 260 seconds) |
| 2022-11-22 02:17:26 +0100 | freeside | (~mengwong@103.252.202.193) |
| 2022-11-22 02:21:35 +0100 | accord | (uid568320@id-568320.hampstead.irccloud.com) |
| 2022-11-22 02:24:56 +0100 | marc___ | (~marc@5.83.191.235) |
| 2022-11-22 02:26:14 +0100 | freeside | (~mengwong@103.252.202.193) (Ping timeout: 268 seconds) |
| 2022-11-22 02:26:29 +0100 | Tuplanolla | (~Tuplanoll@91-159-68-152.elisa-laajakaista.fi) (Quit: Leaving.) |
| 2022-11-22 02:28:06 +0100 | sammelweis | (~quassel@2601:401:8200:2d4c:bd9:d04c:7f69:eb10) (Quit: No Ping reply in 180 seconds.) |
| 2022-11-22 02:28:14 +0100 | marc__ | (~marc@46.167.25.184) (Ping timeout: 260 seconds) |
| 2022-11-22 02:28:51 +0100 | razetime | (~quassel@117.193.5.30) |
| 2022-11-22 02:29:21 +0100 | azimut | (~azimut@gateway/tor-sasl/azimut) (Remote host closed the connection) |
| 2022-11-22 02:29:21 +0100 | califax | (~califax@user/califx) (Remote host closed the connection) |
| 2022-11-22 02:29:21 +0100 | bitdex | (~bitdex@gateway/tor-sasl/bitdex) (Remote host closed the connection) |
| 2022-11-22 02:29:21 +0100 | FinnElija | (~finn_elij@user/finn-elija/x-0085643) (Remote host closed the connection) |
| 2022-11-22 02:29:21 +0100 | ChaiTRex | (~ChaiTRex@user/chaitrex) (Remote host closed the connection) |
| 2022-11-22 02:29:59 +0100 | ChaiTRex | (~ChaiTRex@user/chaitrex) |
| 2022-11-22 02:30:23 +0100 | sammelweis | (~quassel@2601:401:8200:2d4c:bd9:d04c:7f69:eb10) |
| 2022-11-22 02:30:38 +0100 | bitdex | (~bitdex@gateway/tor-sasl/bitdex) |
| 2022-11-22 02:30:45 +0100 | FinnElija | (~finn_elij@user/finn-elija/x-0085643) |
| 2022-11-22 02:31:04 +0100 | califax | (~califax@user/califx) |
| 2022-11-22 02:31:25 +0100 | FinnElija | (~finn_elij@user/finn-elija/x-0085643) (Remote host closed the connection) |
| 2022-11-22 02:31:42 +0100 | FinnElija | (~finn_elij@user/finn-elija/x-0085643) |
| 2022-11-22 02:33:55 +0100 | azimut | (~azimut@gateway/tor-sasl/azimut) |
| 2022-11-22 02:36:59 +0100 | razetime | (~quassel@117.193.5.30) (Ping timeout: 260 seconds) |
| 2022-11-22 02:37:36 +0100 | razetime | (~quassel@117.193.5.4) |
| 2022-11-22 02:38:46 +0100 | sammelweis | (~quassel@2601:401:8200:2d4c:bd9:d04c:7f69:eb10) (Quit: No Ping reply in 180 seconds.) |
| 2022-11-22 02:38:54 +0100 | freeside | (~mengwong@103.252.202.193) |
| 2022-11-22 02:38:56 +0100 | merijn | (~merijn@c-001-001-017.client.esciencecenter.eduvpn.nl) (Ping timeout: 256 seconds) |
| 2022-11-22 02:39:36 +0100 | ChaiTRex | (~ChaiTRex@user/chaitrex) (Remote host closed the connection) |
| 2022-11-22 02:40:03 +0100 | sammelweis | (~quassel@2601:401:8200:2d4c:bd9:d04c:7f69:eb10) |
| 2022-11-22 02:40:13 +0100 | ChaiTRex | (~ChaiTRex@user/chaitrex) |
| 2022-11-22 02:40:40 +0100 | ec | (~ec@gateway/tor-sasl/ec) (Remote host closed the connection) |
| 2022-11-22 02:41:29 +0100 | ec | (~ec@gateway/tor-sasl/ec) |
| 2022-11-22 02:42:20 +0100 | razetime | (~quassel@117.193.5.4) (Ping timeout: 256 seconds) |
| 2022-11-22 02:43:30 +0100 | freeside | (~mengwong@103.252.202.193) (Ping timeout: 268 seconds) |
| 2022-11-22 02:44:06 +0100 | srz_ | (~srz@181.228.49.93) |
| 2022-11-22 02:45:43 +0100 | razetime | (~quassel@117.254.34.122) |
| 2022-11-22 02:46:28 +0100 | machinedgod | (~machinedg@d198-53-218-113.abhsia.telus.net) (Ping timeout: 248 seconds) |
| 2022-11-22 02:46:39 +0100 | srz | (~srz@179.36.104.57) (Ping timeout: 260 seconds) |
| 2022-11-22 02:49:40 +0100 | sawilagar | (~sawilagar@user/sawilagar) (Ping timeout: 268 seconds) |
| 2022-11-22 02:50:41 +0100 | razetime_ | (~quassel@117.193.0.209) |
| 2022-11-22 02:50:50 +0100 | razetime | (~quassel@117.254.34.122) (Ping timeout: 256 seconds) |
| 2022-11-22 02:51:19 +0100 | c209e6dc-4d76-47 | (~aditya@2601:249:4300:1296:195:dac6:592c:a55a) |
| 2022-11-22 02:52:18 +0100 | <c209e6dc-4d76-47> | what is this wierd syntax `[] <- locs` at https://github.com/iu-parfunc/gibbon/blob/3e4599346770fb97c4e02569246269e1885c7d30/gibbon-compiler… |
| 2022-11-22 02:55:36 +0100 | freeside | (~mengwong@103.252.202.193) |
| 2022-11-22 02:57:45 +0100 | wroathe | (~wroathe@user/wroathe) (Ping timeout: 260 seconds) |
| 2022-11-22 02:57:49 +0100 | <Axman6> | it's a pattern guard, it constrains LetE (vr,locs,bty,rhs) bod to only match whern locs is [] |
| 2022-11-22 02:58:12 +0100 | <Axman6> | it could have been written as LetE (vr,[],bty,rhs) bod |
| 2022-11-22 02:58:48 +0100 | <Axman6> | usually you'd use a function there, like LetE (vr,locs,bty,rhs) bod | [] <- filter onlyValid locs -> ... |
| 2022-11-22 02:59:03 +0100 | <jackdk> | That was going to be my next question |
| 2022-11-22 03:00:37 +0100 | beteigeuze | (~Thunderbi@a79-169-109-107.cpe.netcabo.pt) (Ping timeout: 252 seconds) |
| 2022-11-22 03:00:39 +0100 | <Axman6> | https://www.haskell.org/onlinereport/haskell2010/haskellch3.html#x8-460003.13 explains them, but it's not a nice to read as I was hoping |
| 2022-11-22 03:00:58 +0100 | xff0x | (~xff0x@125x103x176x34.ap125.ftth.ucom.ne.jp) |
| 2022-11-22 03:02:01 +0100 | andreinovitcho | (~a@modemcable068.162-80-70.mc.videotron.ca) |
| 2022-11-22 03:03:53 +0100 | <c209e6dc-4d76-47> | oh, never saw pattern guards, or boolean guards before, thanks! |
| 2022-11-22 03:04:34 +0100 | bitdex | (~bitdex@gateway/tor-sasl/bitdex) (Remote host closed the connection) |
| 2022-11-22 03:05:52 +0100 | bitdex | (~bitdex@gateway/tor-sasl/bitdex) |
| 2022-11-22 03:10:10 +0100 | srz_ | (~srz@181.228.49.93) (Quit: Leaving) |
| 2022-11-22 03:10:27 +0100 | waleee | (~waleee@2001:9b0:213:7200:cc36:a556:b1e8:b340) (Ping timeout: 255 seconds) |
| 2022-11-22 03:11:39 +0100 | c209e6dc-4d76-47 | (~aditya@2601:249:4300:1296:195:dac6:592c:a55a) (Quit: Konversation terminated!) |
| 2022-11-22 03:14:30 +0100 | lyxia | (~lyxia@poisson.chat) (Ping timeout: 240 seconds) |
| 2022-11-22 03:14:41 +0100 | chexum | (~quassel@gateway/tor-sasl/chexum) (Remote host closed the connection) |
| 2022-11-22 03:14:46 +0100 | lyxia | (~lyxia@poisson.chat) |
| 2022-11-22 03:15:49 +0100 | andreinovitcho | (~a@modemcable068.162-80-70.mc.videotron.ca) (Quit: Leaving) |
| 2022-11-22 03:15:56 +0100 | bitdex | (~bitdex@gateway/tor-sasl/bitdex) (Ping timeout: 255 seconds) |
| 2022-11-22 03:15:56 +0100 | FinnElija | (~finn_elij@user/finn-elija/x-0085643) (Ping timeout: 255 seconds) |
| 2022-11-22 03:16:48 +0100 | Inoperable | (~PLAYER_1@fancydata.science) (Ping timeout: 268 seconds) |
| 2022-11-22 03:16:51 +0100 | chexum | (~quassel@gateway/tor-sasl/chexum) |
| 2022-11-22 03:17:13 +0100 | In0perable | (~PLAYER_1@fancydata.science) |
| 2022-11-22 03:18:14 +0100 | FinnElija | (~finn_elij@user/finn-elija/x-0085643) |
| 2022-11-22 03:18:34 +0100 | bitdex | (~bitdex@gateway/tor-sasl/bitdex) |
| 2022-11-22 03:31:25 +0100 | thyriaen | (~thyriaen@2a01:aea0:dd4:470d:6245:cbff:fe9f:48b1) |
| 2022-11-22 03:35:39 +0100 | merijn | (~merijn@c-001-001-017.client.esciencecenter.eduvpn.nl) |
| 2022-11-22 03:36:06 +0100 | sammelweis | (~quassel@2601:401:8200:2d4c:bd9:d04c:7f69:eb10) (Quit: No Ping reply in 180 seconds.) |
| 2022-11-22 03:37:13 +0100 | sammelweis | (~quassel@2601:401:8200:2d4c:bd9:d04c:7f69:eb10) |
| 2022-11-22 03:44:39 +0100 | gentauro | (~gentauro@user/gentauro) (Ping timeout: 255 seconds) |
| 2022-11-22 03:52:50 +0100 | causal | (~user@50.35.83.177) (Quit: WeeChat 3.7.1) |
| 2022-11-22 03:55:04 +0100 | gentauro | (~gentauro@user/gentauro) |
| 2022-11-22 03:55:17 +0100 | wroathe | (~wroathe@207-153-38-140.fttp.usinternet.com) |
| 2022-11-22 03:55:17 +0100 | wroathe | (~wroathe@207-153-38-140.fttp.usinternet.com) (Changing host) |
| 2022-11-22 03:55:17 +0100 | wroathe | (~wroathe@user/wroathe) |
| 2022-11-22 03:59:58 +0100 | freeside | (~mengwong@103.252.202.193) (Ping timeout: 256 seconds) |
| 2022-11-22 04:01:03 +0100 | freeside | (~mengwong@103.252.202.193) |
| 2022-11-22 04:01:49 +0100 | wroathe | (~wroathe@user/wroathe) (Ping timeout: 268 seconds) |
| 2022-11-22 04:05:46 +0100 | eggplantade | (~Eggplanta@2600:1700:38c5:d800:5866:96fb:16f6:58d1) |
| 2022-11-22 04:06:50 +0100 | wroathe | (~wroathe@207-153-38-140.fttp.usinternet.com) |
| 2022-11-22 04:06:50 +0100 | wroathe | (~wroathe@207-153-38-140.fttp.usinternet.com) (Changing host) |
| 2022-11-22 04:06:50 +0100 | wroathe | (~wroathe@user/wroathe) |
| 2022-11-22 04:06:54 +0100 | lisbeths | (uid135845@id-135845.lymington.irccloud.com) (Quit: Connection closed for inactivity) |
| 2022-11-22 04:07:22 +0100 | freeside | (~mengwong@103.252.202.193) (Ping timeout: 268 seconds) |
| 2022-11-22 04:09:02 +0100 | merijn | (~merijn@c-001-001-017.client.esciencecenter.eduvpn.nl) (Ping timeout: 256 seconds) |
| 2022-11-22 04:09:20 +0100 | notzmv | (~zmv@user/notzmv) |
| 2022-11-22 04:09:25 +0100 | zebrag | (~chris@user/zebrag) |
| 2022-11-22 04:10:11 +0100 | eggplantade | (~Eggplanta@2600:1700:38c5:d800:5866:96fb:16f6:58d1) (Ping timeout: 260 seconds) |
| 2022-11-22 04:10:18 +0100 | TonyStone | (~TonyStone@cpe-74-76-57-186.nycap.res.rr.com) (Quit: Leaving) |
| 2022-11-22 04:14:20 +0100 | eggplantade | (~Eggplanta@2600:1700:38c5:d800:5866:96fb:16f6:58d1) |
| 2022-11-22 04:14:47 +0100 | marc__ | (~marc@5.83.191.246) |
| 2022-11-22 04:18:28 +0100 | marc___ | (~marc@5.83.191.235) (Ping timeout: 268 seconds) |
| 2022-11-22 04:21:17 +0100 | freeside | (~mengwong@103.252.202.193) |
| 2022-11-22 04:32:53 +0100 | azimut | (~azimut@gateway/tor-sasl/azimut) (Ping timeout: 255 seconds) |
| 2022-11-22 04:34:00 +0100 | Erutuon | (~Erutuon@user/erutuon) (Ping timeout: 260 seconds) |
| 2022-11-22 04:41:03 +0100 | berberman | (~berberman@user/berberman) |
| 2022-11-22 04:41:25 +0100 | nek0 | (~nek0@2a01:4f8:222:2b41::12) (Quit: The Lounge - https://thelounge.chat) |
| 2022-11-22 04:42:08 +0100 | berberman_ | (~berberman@user/berberman) (Ping timeout: 252 seconds) |
| 2022-11-22 04:42:58 +0100 | bilegeek | (~bilegeek@2600:1008:b049:5f3c:af56:db8d:9abf:ed4b) |
| 2022-11-22 04:43:52 +0100 | FinnElija | (~finn_elij@user/finn-elija/x-0085643) (Remote host closed the connection) |
| 2022-11-22 04:44:30 +0100 | ridcully | (~ridcully@p57b52925.dip0.t-ipconnect.de) (Ping timeout: 240 seconds) |
| 2022-11-22 04:44:31 +0100 | ridcully_ | (~ridcully@p57b52404.dip0.t-ipconnect.de) |
| 2022-11-22 04:46:23 +0100 | cafkafk | (~cafkafk@fsf/member/cafkafk) (Ping timeout: 255 seconds) |
| 2022-11-22 04:47:00 +0100 | terrorjack | (~terrorjac@2a01:4f8:1c1e:509a::1) (Ping timeout: 256 seconds) |
| 2022-11-22 04:47:23 +0100 | FinnElija | (~finn_elij@user/finn-elija/x-0085643) |
| 2022-11-22 04:49:59 +0100 | terrorjack | (~terrorjac@2a01:4f8:1c1e:509a::1) |
| 2022-11-22 04:53:44 +0100 | nek0 | (~nek0@2a01:4f8:222:2b41::12) |
| 2022-11-22 04:53:55 +0100 | bilegeek | (~bilegeek@2600:1008:b049:5f3c:af56:db8d:9abf:ed4b) (Quit: Leaving) |
| 2022-11-22 04:54:28 +0100 | nate4 | (~nate@98.45.169.16) |
| 2022-11-22 04:56:07 +0100 | k8yun | (~k8yun@user/k8yun) (Ping timeout: 252 seconds) |
| 2022-11-22 04:57:22 +0100 | talismanick | (~talismani@76.133.152.122) |
| 2022-11-22 04:59:28 +0100 | nate4 | (~nate@98.45.169.16) (Ping timeout: 256 seconds) |
| 2022-11-22 05:02:18 +0100 | td_ | (~td@83.135.9.7) (Ping timeout: 256 seconds) |
| 2022-11-22 05:03:59 +0100 | td_ | (~td@83.135.9.38) |
| 2022-11-22 05:04:01 +0100 | cafkafk | (~cafkafk@fsf/member/cafkafk) |
| 2022-11-22 05:06:28 +0100 | merijn | (~merijn@c-001-001-017.client.esciencecenter.eduvpn.nl) |
| 2022-11-22 05:13:02 +0100 | opticblast | (~Thunderbi@secure-165.caltech.edu) |
| 2022-11-22 05:17:24 +0100 | opticblast | (~Thunderbi@secure-165.caltech.edu) (Ping timeout: 248 seconds) |
| 2022-11-22 05:21:33 +0100 | opticblast | (~Thunderbi@secure-165.caltech.edu) |
| 2022-11-22 05:22:20 +0100 | bilegeek | (~bilegeek@2600:1008:b049:5f3c:af56:db8d:9abf:ed4b) |
| 2022-11-22 05:22:53 +0100 | zebrag | (~chris@user/zebrag) (Quit: Konversation terminated!) |
| 2022-11-22 05:28:04 +0100 | freeside | (~mengwong@103.252.202.193) (Ping timeout: 248 seconds) |
| 2022-11-22 05:28:11 +0100 | opticblast | (~Thunderbi@secure-165.caltech.edu) (Ping timeout: 256 seconds) |
| 2022-11-22 05:28:16 +0100 | thyriaen | (~thyriaen@2a01:aea0:dd4:470d:6245:cbff:fe9f:48b1) (Remote host closed the connection) |
| 2022-11-22 05:28:28 +0100 | freeside | (~mengwong@103.252.202.193) |
| 2022-11-22 05:33:09 +0100 | freeside | (~mengwong@103.252.202.193) (Ping timeout: 260 seconds) |
| 2022-11-22 05:39:48 +0100 | merijn | (~merijn@c-001-001-017.client.esciencecenter.eduvpn.nl) (Ping timeout: 248 seconds) |
| 2022-11-22 05:40:54 +0100 | monochrom | (trebla@216.138.220.146) (Quit: NO CARRIER) |
| 2022-11-22 05:43:52 +0100 | opticblast | (~Thunderbi@secure-165.caltech.edu) |
| 2022-11-22 05:46:07 +0100 | k8yun | (~k8yun@user/k8yun) |
| 2022-11-22 05:47:19 +0100 | freeside | (~mengwong@103.252.202.193) |
| 2022-11-22 05:48:19 +0100 | euandreh | (~Thunderbi@179.214.113.107) (Ping timeout: 260 seconds) |
| 2022-11-22 05:50:28 +0100 | k8yun | (~k8yun@user/k8yun) (Ping timeout: 248 seconds) |
| 2022-11-22 05:52:44 +0100 | Vajb | (~Vajb@2001:999:504:3ad6:52a4:a3b5:32d8:e74d) (Read error: Connection reset by peer) |
| 2022-11-22 05:53:49 +0100 | Vajb | (~Vajb@hag-jnsbng11-58c3a5-27.dhcp.inet.fi) |
| 2022-11-22 05:59:59 +0100 | ddellacosta | (~ddellacos@89.45.224.71) (Ping timeout: 260 seconds) |
| 2022-11-22 06:08:51 +0100 | Guest60 | (~Guest60@149.159.207.218) |
| 2022-11-22 06:10:11 +0100 | <Guest60> | Hello, what is the best way to cancel async tasks? I would like to have a coordinator launch bunch of helper tasks, but I want the worker tasks to be cancelled when the coordinator is cancelled. |
| 2022-11-22 06:11:42 +0100 | yella | (~yell@2607:fb90:80c4:d3a9:a406:e932:6bb2:44ac) |
| 2022-11-22 06:13:11 +0100 | yella | (~yell@2607:fb90:80c4:d3a9:a406:e932:6bb2:44ac) (Remote host closed the connection) |
| 2022-11-22 06:14:42 +0100 | <davean> | Are you using something like the 'async' package? |
| 2022-11-22 06:15:42 +0100 | <Guest60> | I would like to use something like the 'async' package, but it doesn't have anything that does what I want (at least not as directly as I described it). |
| 2022-11-22 06:17:12 +0100 | <davean> | Sure it does, withAsync |
| 2022-11-22 06:17:59 +0100 | <davean> | also cancel |
| 2022-11-22 06:18:17 +0100 | wroathe | (~wroathe@user/wroathe) (Quit: leaving) |
| 2022-11-22 06:19:47 +0100 | Vajb | (~Vajb@hag-jnsbng11-58c3a5-27.dhcp.inet.fi) (Read error: Connection reset by peer) |
| 2022-11-22 06:19:54 +0100 | <Guest60> | hmm, can you please tell me how to use it exactly to do what I want. If I understand correctly, withAsync does it for an IO action and a function. |
| 2022-11-22 06:20:05 +0100 | Vajb | (~Vajb@2001:999:504:3ad6:52a4:a3b5:32d8:e74d) |
| 2022-11-22 06:20:20 +0100 | <Guest60> | I want to have a whole bunch of tasks to run concurrently and be cancelled automatically when the coordinator is cancelled |
| 2022-11-22 06:22:17 +0100 | <Guest60> | Also, I don't want to use cancel. If I use cancel, I should keep track of which asyncs were spawned off, and cancel them individually. What I want is something like withAsync but it should take multiple arguments, and all of them should be cancelled when the parent thread (the thread that initiated all those asyncs) is cancelled. |
| 2022-11-22 06:25:17 +0100 | <davean> | ou might prefer working with 'async-pool', if it makes more sense to you |
| 2022-11-22 06:27:34 +0100 | yl53[m] | (~yl53matri@2001:470:69fc:105::85b) |
| 2022-11-22 06:30:22 +0100 | sclv | (sid39734@haskell/developer/sclv) (Read error: Software caused connection abort) |
| 2022-11-22 06:30:31 +0100 | sclv | (sid39734@haskell/developer/sclv) |
| 2022-11-22 06:32:55 +0100 | <Guest60> | hmm, just took a look at it. Doesn't seem to do what I want. I guess for now I'll just launch the tasks by chaining calls to withAsync. |
| 2022-11-22 06:33:21 +0100 | <dsal> | It has a lot of ways to do what you want. |
| 2022-11-22 06:34:07 +0100 | <Guest60> | Can you please describe at least one way to me? I am new to all this and pretty much clueless. |
| 2022-11-22 06:34:09 +0100 | <c_wraith> | Guest60: mapRace in async-pool does exactly what you want |
| 2022-11-22 06:34:10 +0100 | Lord_of_Life | (~Lord@user/lord-of-life/x-2819915) (Ping timeout: 260 seconds) |
| 2022-11-22 06:34:28 +0100 | <Guest60> | Thanks. I'll take a look at it. |
| 2022-11-22 06:35:44 +0100 | Lord_of_Life | (~Lord@user/lord-of-life/x-2819915) |
| 2022-11-22 06:36:02 +0100 | <Guest60> | mapRace doesn't do what I want. mapRace gets the first result and cancels the rest of the tasks. I don't want that behavior. |
| 2022-11-22 06:36:38 +0100 | merijn | (~merijn@c-001-001-017.client.esciencecenter.eduvpn.nl) |
| 2022-11-22 06:36:51 +0100 | <Guest60> | The spawned async tasks are all independent running entities. They should only be cancelled when the parent thread (the one who launched all these asyncs) is cancelled. |
| 2022-11-22 06:36:52 +0100 | <dsal> | So, if you just run a bunch of tasks concurrently, you'll get a bunch of Asyncs. You can cancel all those Asyncs when your supervisor is finished. |
| 2022-11-22 06:37:55 +0100 | <Guest60> | yup, I know that I can do it by calling cancel on each of the asyncs, but I was hoping to find withAsync style of cancelling those tasks automatically. |
| 2022-11-22 06:38:05 +0100 | <dsal> | Another easy path is using link which is easy linkage if the supervisor should also fail if one of the workers fails. |
| 2022-11-22 06:38:28 +0100 | <dsal> | There's no "automatically." Things happen that are programmed to happen. |
| 2022-11-22 06:38:45 +0100 | hgolden | (~hgolden@cpe-172-251-233-141.socal.res.rr.com) (Remote host closed the connection) |
| 2022-11-22 06:39:04 +0100 | <dsal> | It'd be easy to build an abstraction like `withAsyncs` that will spawn and cancel. |
| 2022-11-22 06:39:57 +0100 | <Guest60> | yup, I actually want something like `withAsyncs` but I don't think it's in the library. I guess I can code it up myself by chaining multiple `withAsync`s |
| 2022-11-22 06:42:09 +0100 | merijn | (~merijn@c-001-001-017.client.esciencecenter.eduvpn.nl) (Ping timeout: 268 seconds) |
| 2022-11-22 06:43:34 +0100 | <Guest60> | would something like this work? `foldr withAsync [t1, t2, t3, ..., supervisor]`. |
| 2022-11-22 06:44:09 +0100 | hgolden | (~hgolden@cpe-172-251-233-141.socal.res.rr.com) |
| 2022-11-22 06:44:33 +0100 | <dsal> | That doesn't make much sense to me. You could certainly use fold for that, but I'd probably not do it that way. Let me look at the docs real quick… |
| 2022-11-22 06:47:04 +0100 | <dsal> | I'd probably just do something like `traverse . async` and then bracket a `traverse cancel as` around the supervisor action. |
| 2022-11-22 06:47:18 +0100 | <Guest60> | oh, my bad, I meant to write `foldr withAsync [t1, t2, t3, ..., tn] supervisor` |
| 2022-11-22 06:48:05 +0100 | titibandit | (~titibandi@xdsl-78-34-153-165.nc.de) |
| 2022-11-22 06:48:36 +0100 | <Guest60> | dsal, ah that is good. Thanks. |
| 2022-11-22 06:48:58 +0100 | <dsal> | You could implement it that way, but I'd want an abstraction that I could feed work and a supervisor action into. |
| 2022-11-22 06:49:45 +0100 | chromoblob | (~user@37.113.164.122) |
| 2022-11-22 06:50:35 +0100 | <dsal> | Partially because it's not clear to me what the types are supposed to be. |
| 2022-11-22 06:50:48 +0100 | <davean> | Guest60: "withAsync is like async, except that the Async is automatically killed (or unscheduled, using cancel) if the enclosing IO operation returns before it has completed." |
| 2022-11-22 06:52:19 +0100 | <davean> | Guest60: "Leaving the block cancels every task still executing in the group." |
| 2022-11-22 06:52:31 +0100 | <davean> | Guest60: I'm confused why you think this doesn't do the thing you're asking |
| 2022-11-22 06:52:50 +0100 | ChaiTRex | (~ChaiTRex@user/chaitrex) (Ping timeout: 255 seconds) |
| 2022-11-22 06:53:07 +0100 | mxs | (~mxs@user/mxs) (Read error: Software caused connection abort) |
| 2022-11-22 06:53:15 +0100 | mxs | (~mxs@user/mxs) |
| 2022-11-22 06:54:10 +0100 | <davean> | Guest60: it seems to me to litterly quote the guarrentee you are looking for |
| 2022-11-22 06:54:35 +0100 | chromoblob | (~user@37.113.164.122) (Ping timeout: 260 seconds) |
| 2022-11-22 06:55:11 +0100 | ChaiTRex | (~ChaiTRex@user/chaitrex) |
| 2022-11-22 06:55:41 +0100 | <dsal> | I think it's the "lots of workers" thing. |
| 2022-11-22 06:55:58 +0100 | <davean> | dsal: Yes? That specificly handles lots of workers |
| 2022-11-22 06:56:18 +0100 | <davean> | Thats the ONLY thing that function does, let you launch an arbitrary number of workers and have them canceled when you leave |
| 2022-11-22 06:56:25 +0100 | <Guest60> | davean, I am taking a look at async-pool agian. That quote does seem to guarantee what I want. |
| 2022-11-22 06:57:17 +0100 | <davean> | Note "withTaskGroup n f = createPool >>= \p -> withTaskGroupIn p n f" so withTaskGroup also has that property, though the documentation fails to say it exactly. |
| 2022-11-22 06:57:48 +0100 | <dsal> | davean: well, "one" isn't really arbitrary. I guess you could start a bunch of workers and link them from within the spawned async. |
| 2022-11-22 06:58:47 +0100 | <davean> | dsal: uh, where did "one" come from? None of the text suggests singular. |
| 2022-11-22 06:59:01 +0100 | <davean> | dsal: it specificly takes a parameter of how many to allow to run at once. |
| 2022-11-22 06:59:31 +0100 | <dsal> | `withAsync :: IO a -> (Async a -> IO b) -> IO b` -- ? |
| 2022-11-22 07:00:24 +0100 | <davean> | That particular function does one at a time, it allows building arbitrary, but it also isn't what we're talking about. |
| 2022-11-22 07:00:39 +0100 | <davean> | Did you see the code I litterly pasted above? |
| 2022-11-22 07:00:52 +0100 | <davean> | Or the citations above that |
| 2022-11-22 07:01:10 +0100 | <dsal> | Yeah, you pasted "withAsync is like async, except that the Async is automatically killed (or unscheduled, using cancel) if the enclosing IO operation returns before it has completed." |
| 2022-11-22 07:01:17 +0100 | <Guest60> | Oh, I think I there's a communication gap here. davean wrote `withAsync` , but quoted `withTaskGroupIn` |
| 2022-11-22 07:01:20 +0100 | <dsal> | If "the Async" doesn't imply "one" then I'm confused. |
| 2022-11-22 07:01:58 +0100 | <davean> | Guest60: I've talked about both, you can build it with withAsync |
| 2022-11-22 07:02:28 +0100 | <davean> | its not super efficient to, but it is a sufficient combinator |
| 2022-11-22 07:02:50 +0100 | <davean> | withTaskGroup, which I mentioned specificly, is a more efficient way |
| 2022-11-22 07:03:01 +0100 | <davean> | (Since it doesn't need as many enclosures) |
| 2022-11-22 07:03:32 +0100 | Erutuon | (~Erutuon@23-88-131-243.fttp.usinternet.com) |
| 2022-11-22 07:04:17 +0100 | hgolden | (~hgolden@cpe-172-251-233-141.socal.res.rr.com) (Remote host closed the connection) |
| 2022-11-22 07:05:00 +0100 | <Guest60> | Okay. "Create a task group within the given pool having a specified number of execution slots, but with a bounded lifetime. Leaving the block cancels every task still executing in the group." |
| 2022-11-22 07:05:08 +0100 | <Guest60> | What does "block" mean here? |
| 2022-11-22 07:05:41 +0100 | <davean> | lexical scope |
| 2022-11-22 07:05:57 +0100 | <davean> | well |
| 2022-11-22 07:05:59 +0100 | <davean> | not actually |
| 2022-11-22 07:06:04 +0100 | <dsal> | I assume it's the `TaskGroup -> IO b` action. |
| 2022-11-22 07:06:05 +0100 | <davean> | but thats where the term is pointing you at |
| 2022-11-22 07:06:13 +0100 | jao | (~jao@cpc103048-sgyl39-2-0-cust502.18-2.cable.virginm.net) (Ping timeout: 256 seconds) |
| 2022-11-22 07:06:24 +0100 | <davean> | but yah, when (TaskGroup -> IO b) returns, you've left "the block" |
| 2022-11-22 07:06:36 +0100 | <mauke> | so I've looked at the async docs. isn't this just forConcurrently? |
| 2022-11-22 07:06:49 +0100 | <davean> | withTaskGroupIn :: Pool -> Int -> (TaskGroup -> IO b) -> IO b |
| 2022-11-22 07:06:51 +0100 | <davean> | withTaskGroupIn p n f = createTaskGroup p n >>= \g -> |
| 2022-11-22 07:06:53 +0100 | <davean> | Async.withAsync (runTaskGroup g) $ const $ f g `finally` cancelAll g |
| 2022-11-22 07:07:10 +0100 | <davean> | see the `finally`? |
| 2022-11-22 07:07:44 +0100 | <Guest60> | yup. Thanks. |
| 2022-11-22 07:08:00 +0100 | hgolden | (~hgolden@cpe-172-251-233-141.socal.res.rr.com) |
| 2022-11-22 07:08:42 +0100 | <dsal> | mauke: I think it's more like if you have `actions :: [IO ()]` and you do something like `bracket_ (traverse async) (traverse cancel) $ superviseStuff` |
| 2022-11-22 07:10:03 +0100 | <dsal> | Er, I left the actions out of that traverse async. But basically the idea is that you want to automatically cancel all the launched things when your supervisor is done. |
| 2022-11-22 07:10:06 +0100 | accord | (uid568320@id-568320.hampstead.irccloud.com) (Quit: Connection closed for inactivity) |
| 2022-11-22 07:13:48 +0100 | haveo_ | (~haveo@sl35.iuwt.fr) (Read error: Software caused connection abort) |
| 2022-11-22 07:13:51 +0100 | MironZ | (~MironZ@nat-infra.ehlab.uk) (Read error: Software caused connection abort) |
| 2022-11-22 07:13:56 +0100 | haveo | (~haveo@sl35.iuwt.fr) |
| 2022-11-22 07:14:10 +0100 | MironZ | (~MironZ@nat-infra.ehlab.uk) |
| 2022-11-22 07:16:14 +0100 | FinnElija | (~finn_elij@user/finn-elija/x-0085643) (Ping timeout: 255 seconds) |
| 2022-11-22 07:17:48 +0100 | FinnElija | (~finn_elij@user/finn-elija/x-0085643) |
| 2022-11-22 07:17:57 +0100 | king_gs | (~Thunderbi@2806:103e:29:bfeb:c988:bbd5:2586:4924) |
| 2022-11-22 07:20:33 +0100 | <Guest60> | Thanks, people. I'll try to work with this async-pool stuff. |
| 2022-11-22 07:21:33 +0100 | T_S_ | (sid501726@id-501726.uxbridge.irccloud.com) (Read error: Software caused connection abort) |
| 2022-11-22 07:21:46 +0100 | T_S_ | (sid501726@id-501726.uxbridge.irccloud.com) |
| 2022-11-22 07:22:36 +0100 | wafflepirate | (sid467876@2a03:5180:f:3::7:23a4) (Read error: Software caused connection abort) |
| 2022-11-22 07:22:45 +0100 | wafflepirate | (sid467876@id-467876.ilkley.irccloud.com) |
| 2022-11-22 07:23:42 +0100 | bilegeek_ | (~bilegeek@16.sub-174-209-37.myvzw.com) |
| 2022-11-22 07:26:06 +0100 | <dsal> | Finally got a ghci to come up. |
| 2022-11-22 07:26:40 +0100 | bilegeek | (~bilegeek@2600:1008:b049:5f3c:af56:db8d:9abf:ed4b) (Ping timeout: 260 seconds) |
| 2022-11-22 07:27:00 +0100 | <dsal> | I'd just do: `:t \ws s -> bracket (traverse async ws) (traverse cancel) $ \_ -> s :: Traversable t => t (IO a) -> IO c -> IO c` based on my understanding. |
| 2022-11-22 07:27:53 +0100 | <dsal> | But it's not clear what it means for a worker to exit/abort. |
| 2022-11-22 07:30:45 +0100 | coot | (~coot@213.134.171.3) |
| 2022-11-22 07:34:17 +0100 | jakalx | (~jakalx@base.jakalx.net) (Error from remote client) |
| 2022-11-22 07:37:59 +0100 | merijn | (~merijn@c-001-001-017.client.esciencecenter.eduvpn.nl) |
| 2022-11-22 07:42:28 +0100 | ft | (~ft@p508dbd59.dip0.t-ipconnect.de) (Quit: leaving) |
| 2022-11-22 07:42:44 +0100 | chomwitt | (~chomwitt@2a02:587:7a0d:dd00:1ac0:4dff:fedb:a3f1) |
| 2022-11-22 07:43:05 +0100 | monochrom | (trebla@216.138.220.146) |
| 2022-11-22 07:43:58 +0100 | jean-paul[m] | (~jean-paul@2001:470:69fc:105::d1ab) (Read error: Software caused connection abort) |
| 2022-11-22 07:44:11 +0100 | jean-paul[m] | (~jean-paul@2001:470:69fc:105::d1ab) |
| 2022-11-22 07:47:06 +0100 | yella | (~yell@2607:fb90:80c9:e326:6468:b483:c07e:90c8) |
| 2022-11-22 07:48:42 +0100 | king_gs | (~Thunderbi@2806:103e:29:bfeb:c988:bbd5:2586:4924) (Remote host closed the connection) |
| 2022-11-22 07:49:02 +0100 | king_gs | (~Thunderbi@2806:103e:29:bfeb:c988:bbd5:2586:4924) |
| 2022-11-22 07:52:50 +0100 | Kaiepi | (~Kaiepi@108.175.84.104) |
| 2022-11-22 07:54:22 +0100 | jakalx | (~jakalx@base.jakalx.net) |
| 2022-11-22 07:55:11 +0100 | michalz | (~michalz@185.246.207.197) |
| 2022-11-22 07:56:12 +0100 | mei__ | (~mei@user/mei) |
| 2022-11-22 07:56:16 +0100 | merijn | (~merijn@c-001-001-017.client.esciencecenter.eduvpn.nl) (Ping timeout: 256 seconds) |
| 2022-11-22 08:01:59 +0100 | emmanuelux | (~emmanuelu@user/emmanuelux) (Quit: au revoir) |
| 2022-11-22 08:03:19 +0100 | kenran | (~user@user/kenran) |
| 2022-11-22 08:03:22 +0100 | kenran | (~user@user/kenran) (Remote host closed the connection) |
| 2022-11-22 08:08:31 +0100 | jmorris | (uid537181@id-537181.uxbridge.irccloud.com) (Quit: Connection closed for inactivity) |
| 2022-11-22 08:08:35 +0100 | <talismanick> | What might cause HLS to segfault? Anything that I can fix myself? |
| 2022-11-22 08:11:00 +0100 | opticblast | (~Thunderbi@secure-165.caltech.edu) (Ping timeout: 256 seconds) |
| 2022-11-22 08:17:50 +0100 | lisbeths | (uid135845@id-135845.lymington.irccloud.com) |
| 2022-11-22 08:18:29 +0100 | opticblast | (~Thunderbi@secure-165.caltech.edu) |
| 2022-11-22 08:20:50 +0100 | nckx | (~nckx@tobias.gr) (Ping timeout: 268 seconds) |
| 2022-11-22 08:24:59 +0100 | shriekingnoise | (~shrieking@186.137.167.202) (Quit: Quit) |
| 2022-11-22 08:26:45 +0100 | dolio | (~dolio@130.44.134.54) (Ping timeout: 260 seconds) |
| 2022-11-22 08:27:21 +0100 | califax | (~califax@user/califx) (Quit: ZNC 1.8.2 - https://znc.in) |
| 2022-11-22 08:28:23 +0100 | Guest60 | (~Guest60@149.159.207.218) (Ping timeout: 260 seconds) |
| 2022-11-22 08:28:44 +0100 | troydm | (~troydm@host-176-37-124-197.b025.la.net.ua) (Ping timeout: 260 seconds) |
| 2022-11-22 08:29:12 +0100 | califax | (~califax@user/califx) |
| 2022-11-22 08:29:33 +0100 | k8yun | (~k8yun@user/k8yun) |
| 2022-11-22 08:29:56 +0100 | king_gs | (~Thunderbi@2806:103e:29:bfeb:c988:bbd5:2586:4924) (Ping timeout: 255 seconds) |
| 2022-11-22 08:29:58 +0100 | califax | (~califax@user/califx) (Remote host closed the connection) |
| 2022-11-22 08:31:14 +0100 | use-value | (~Thunderbi@2a00:23c6:8a03:2f01:38e4:6025:87e4:a8aa) (Remote host closed the connection) |
| 2022-11-22 08:31:18 +0100 | ystael | (~ystael@user/ystael) (Ping timeout: 268 seconds) |
| 2022-11-22 08:31:34 +0100 | use-value | (~Thunderbi@2a00:23c6:8a03:2f01:38e4:6025:87e4:a8aa) |
| 2022-11-22 08:32:01 +0100 | califax | (~califax@user/califx) |
| 2022-11-22 08:35:03 +0100 | k8yun | (~k8yun@user/k8yun) (Quit: Leaving) |
| 2022-11-22 08:36:41 +0100 | akegalj | (~akegalj@89-172-58-90.adsl.net.t-com.hr) |
| 2022-11-22 08:37:58 +0100 | ystael | (~ystael@user/ystael) |
| 2022-11-22 08:38:40 +0100 | nckx | (~nckx@tobias.gr) |
| 2022-11-22 08:39:12 +0100 | dolio | (~dolio@130.44.134.54) |
| 2022-11-22 08:42:43 +0100 | jonathanx | (~jonathan@h-178-174-176-109.A357.priv.bahnhof.se) (Ping timeout: 252 seconds) |
| 2022-11-22 08:46:30 +0100 | mrvdb- | (~mrvdb@2001:19f0:5000:8582:5400:ff:fe07:3df5) (Read error: Software caused connection abort) |
| 2022-11-22 08:46:47 +0100 | mrvdb | (~mrvdb@2001:19f0:5000:8582:5400:ff:fe07:3df5) |
| 2022-11-22 08:50:48 +0100 | ccapndave | (~ccapndave@xcpe-62-167-164-99.cgn.res.adslplus.ch) |
| 2022-11-22 08:53:13 +0100 | merijn | (~merijn@c-001-001-017.client.esciencecenter.eduvpn.nl) |
| 2022-11-22 08:55:57 +0100 | nate4 | (~nate@98.45.169.16) |
| 2022-11-22 08:57:12 +0100 | jonathanx | (~jonathan@h-98-128-168-222.NA.cust.bahnhof.se) |
| 2022-11-22 09:00:41 +0100 | nate4 | (~nate@98.45.169.16) (Ping timeout: 256 seconds) |
| 2022-11-22 09:02:01 +0100 | Putonlalla | (~Putonlall@it-cyan.it.jyu.fi) (Read error: Software caused connection abort) |
| 2022-11-22 09:02:31 +0100 | peddie | (~peddie@2001:470:69fc:105::25d) (Read error: Software caused connection abort) |
| 2022-11-22 09:02:50 +0100 | peddie | (~peddie@2001:470:69fc:105::25d) |
| 2022-11-22 09:02:51 +0100 | Putonlalla | (~Putonlall@it-cyan.it.jyu.fi) |
| 2022-11-22 09:03:27 +0100 | lortabac | (~lortabac@2a01:e0a:541:b8f0:77f5:99bc:10c3:3c4c) |
| 2022-11-22 09:06:17 +0100 | madjestic | (~madjestic@77-63-78-129.mobile.kpn.net) |
| 2022-11-22 09:06:55 +0100 | mmhat | (~mmh@p200300f1c72dc6ddee086bfffe095315.dip0.t-ipconnect.de) |
| 2022-11-22 09:07:02 +0100 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) |
| 2022-11-22 09:07:13 +0100 | sammelweis | (~quassel@2601:401:8200:2d4c:bd9:d04c:7f69:eb10) (Quit: No Ping reply in 180 seconds.) |
| 2022-11-22 09:07:14 +0100 | coot | (~coot@213.134.171.3) (Quit: coot) |
| 2022-11-22 09:07:21 +0100 | sammelweis | (~quassel@2601:401:8200:2d4c:bd9:d04c:7f69:eb10) |
| 2022-11-22 09:10:42 +0100 | FinnElija | (~finn_elij@user/finn-elija/x-0085643) (Remote host closed the connection) |
| 2022-11-22 09:10:42 +0100 | califax | (~califax@user/califx) (Remote host closed the connection) |
| 2022-11-22 09:10:42 +0100 | cafkafk | (~cafkafk@fsf/member/cafkafk) (Remote host closed the connection) |
| 2022-11-22 09:10:42 +0100 | chexum | (~quassel@gateway/tor-sasl/chexum) (Remote host closed the connection) |
| 2022-11-22 09:10:42 +0100 | ChaiTRex | (~ChaiTRex@user/chaitrex) (Remote host closed the connection) |
| 2022-11-22 09:11:31 +0100 | cafkafk | (~cafkafk@fsf/member/cafkafk) |
| 2022-11-22 09:11:32 +0100 | FinnElija | (~finn_elij@user/finn-elija/x-0085643) |
| 2022-11-22 09:12:43 +0100 | bilegeek_ | (~bilegeek@16.sub-174-209-37.myvzw.com) (Quit: Leaving) |
| 2022-11-22 09:13:36 +0100 | ChaiTRex | (~ChaiTRex@user/chaitrex) |
| 2022-11-22 09:14:03 +0100 | chexum | (~quassel@gateway/tor-sasl/chexum) |
| 2022-11-22 09:14:10 +0100 | califax | (~califax@user/califx) |
| 2022-11-22 09:15:50 +0100 | nschoe | (~q@2a01:e0a:8e:a190:13d9:919d:218e:b9d2) |
| 2022-11-22 09:19:50 +0100 | razetime_ | (~quassel@117.193.0.209) (Ping timeout: 260 seconds) |
| 2022-11-22 09:19:51 +0100 | razetime | (~quassel@117.193.4.165) |
| 2022-11-22 09:20:23 +0100 | stiell | (~stiell@gateway/tor-sasl/stiell) (Remote host closed the connection) |
| 2022-11-22 09:20:49 +0100 | madjestic | (~madjestic@77-63-78-129.mobile.kpn.net) (Read error: Connection reset by peer) |
| 2022-11-22 09:21:03 +0100 | stiell | (~stiell@gateway/tor-sasl/stiell) |
| 2022-11-22 09:21:03 +0100 | Axman6 | (~Axman6@user/axman6) (Ping timeout: 268 seconds) |
| 2022-11-22 09:21:08 +0100 | edm | (sid147314@id-147314.hampstead.irccloud.com) (Read error: Software caused connection abort) |
| 2022-11-22 09:21:21 +0100 | edm | (sid147314@id-147314.hampstead.irccloud.com) |
| 2022-11-22 09:21:59 +0100 | aweinstock | (~aweinstoc@cpe-74-76-189-75.nycap.res.rr.com) (Read error: Software caused connection abort) |
| 2022-11-22 09:22:50 +0100 | Sgeo | (~Sgeo@user/sgeo) (Read error: Connection reset by peer) |
| 2022-11-22 09:25:16 +0100 | cjay | (cjay@nerdbox.nerd2nerd.org) (Read error: Software caused connection abort) |
| 2022-11-22 09:25:27 +0100 | cjay | (cjay@nerdbox.nerd2nerd.org) |
| 2022-11-22 09:25:41 +0100 | coot | (~coot@2a02:a310:e241:1b00:ec1a:e9df:79ac:66ba) |
| 2022-11-22 09:27:00 +0100 | opticblast | (~Thunderbi@secure-165.caltech.edu) (Ping timeout: 248 seconds) |
| 2022-11-22 09:28:09 +0100 | aweinstock | (~aweinstoc@cpe-74-76-189-75.nycap.res.rr.com) |
| 2022-11-22 09:28:38 +0100 | razetime | (~quassel@117.193.4.165) (Ping timeout: 256 seconds) |
| 2022-11-22 09:30:31 +0100 | razetime | (~quassel@117.254.34.53) |
| 2022-11-22 09:33:12 +0100 | chexum | (~quassel@gateway/tor-sasl/chexum) (Quit: No Ping reply in 180 seconds.) |
| 2022-11-22 09:33:24 +0100 | acidjnk | (~acidjnk@p200300d6e7137a84847a35f477003ced.dip0.t-ipconnect.de) |
| 2022-11-22 09:35:35 +0100 | mei__ | (~mei@user/mei) (Ping timeout: 260 seconds) |
| 2022-11-22 09:35:43 +0100 | chexum | (~quassel@gateway/tor-sasl/chexum) |
| 2022-11-22 09:39:47 +0100 | acidjnk | (~acidjnk@p200300d6e7137a84847a35f477003ced.dip0.t-ipconnect.de) (Ping timeout: 256 seconds) |
| 2022-11-22 09:39:51 +0100 | dmj` | (sid72307@id-72307.hampstead.irccloud.com) (Read error: Software caused connection abort) |
| 2022-11-22 09:40:18 +0100 | dmj` | (sid72307@id-72307.hampstead.irccloud.com) |
| 2022-11-22 09:40:20 +0100 | opticblast | (~Thunderbi@secure-165.caltech.edu) |
| 2022-11-22 09:41:46 +0100 | fserucas | (~fserucas@2001:818:e376:a400:fb92:70c1:dd88:c7d7) |
| 2022-11-22 09:41:49 +0100 | m1dnight | (~christoph@78-22-0-121.access.telenet.be) (Quit: WeeChat 3.7.1) |
| 2022-11-22 09:42:17 +0100 | m1dnight | (~christoph@78-22-0-121.access.telenet.be) |
| 2022-11-22 09:44:20 +0100 | jonathanx | (~jonathan@h-98-128-168-222.NA.cust.bahnhof.se) (Ping timeout: 260 seconds) |
| 2022-11-22 09:45:00 +0100 | ccapndave | (~ccapndave@xcpe-62-167-164-99.cgn.res.adslplus.ch) (Quit: My MacBook has gone to sleep. ZZZzzz…) |
| 2022-11-22 09:45:57 +0100 | zeenk | (~zeenk@2a02:2f04:a208:3600::7fe) |
| 2022-11-22 09:48:35 +0100 | karolis | (~karolis@78.157.77.235) |
| 2022-11-22 09:50:46 +0100 | machinedgod | (~machinedg@d198-53-218-113.abhsia.telus.net) |
| 2022-11-22 09:51:29 +0100 | chexum | (~quassel@gateway/tor-sasl/chexum) (Ping timeout: 255 seconds) |
| 2022-11-22 09:51:41 +0100 | MajorBiscuit | (~MajorBisc@2a02-a461-129d-1-193d-75d8-745d-e91e.fixed6.kpn.net) |
| 2022-11-22 09:52:07 +0100 | chexum | (~quassel@gateway/tor-sasl/chexum) |
| 2022-11-22 09:54:55 +0100 | juri_ | (~juri@84.19.175.179) (Read error: Software caused connection abort) |
| 2022-11-22 09:55:08 +0100 | juri_ | (~juri@84-19-175-179.pool.ovpn.com) |
| 2022-11-22 09:55:16 +0100 | MajorBiscuit | (~MajorBisc@2a02-a461-129d-1-193d-75d8-745d-e91e.fixed6.kpn.net) (Client Quit) |
| 2022-11-22 10:00:52 +0100 | MajorBiscuit | (~MajorBisc@86-88-79-148.fixed.kpn.net) |
| 2022-11-22 10:02:27 +0100 | ubert1 | (~Thunderbi@178.165.183.156.wireless.dyn.drei.com) |
| 2022-11-22 10:02:58 +0100 | Matthew|m | (~arathorn@2001:470:69fc:105::1f) (Read error: Software caused connection abort) |
| 2022-11-22 10:03:19 +0100 | Matthew|m | (~arathorn@2001:470:69fc:105::1f) |
| 2022-11-22 10:04:35 +0100 | euandreh | (~Thunderbi@179.214.113.107) |
| 2022-11-22 10:08:35 +0100 | sammelweis | (~quassel@2601:401:8200:2d4c:bd9:d04c:7f69:eb10) (Ping timeout: 260 seconds) |
| 2022-11-22 10:08:43 +0100 | sammelweis | (~quassel@2601:401:8200:2d4c:bd9:d04c:7f69:eb10) |
| 2022-11-22 10:08:51 +0100 | euandreh | (~Thunderbi@179.214.113.107) (Remote host closed the connection) |
| 2022-11-22 10:11:04 +0100 | euandreh | (~Thunderbi@179.214.113.107) |
| 2022-11-22 10:14:02 +0100 | ThePlayer | (~ThePlayer@94-21-96-104.pool.digikabel.hu) |
| 2022-11-22 10:16:00 +0100 | cfricke | (~cfricke@user/cfricke) |
| 2022-11-22 10:18:16 +0100 | jonathanx | (~jonathan@h-98-128-168-222.NA.cust.bahnhof.se) |
| 2022-11-22 10:19:26 +0100 | teehemkay | (sid14792@id-14792.lymington.irccloud.com) (Read error: Software caused connection abort) |
| 2022-11-22 10:19:33 +0100 | teehemkay | (sid14792@id-14792.lymington.irccloud.com) |
| 2022-11-22 10:19:37 +0100 | eggplantade | (~Eggplanta@2600:1700:38c5:d800:5866:96fb:16f6:58d1) (Remote host closed the connection) |
| 2022-11-22 10:19:50 +0100 | karolis | (~karolis@78.157.77.235) (Ping timeout: 268 seconds) |
| 2022-11-22 10:21:32 +0100 | gaze___ | (sid387101@id-387101.helmsley.irccloud.com) (Read error: Software caused connection abort) |
| 2022-11-22 10:21:42 +0100 | gaze___ | (sid387101@id-387101.helmsley.irccloud.com) |
| 2022-11-22 10:22:55 +0100 | jonathanx | (~jonathan@h-98-128-168-222.NA.cust.bahnhof.se) (Ping timeout: 268 seconds) |
| 2022-11-22 10:23:39 +0100 | SanchayanMaity | (sid478177@id-478177.hampstead.irccloud.com) (Read error: Software caused connection abort) |
| 2022-11-22 10:23:48 +0100 | SanchayanMaity | (sid478177@id-478177.hampstead.irccloud.com) |
| 2022-11-22 10:24:14 +0100 | razetime | (~quassel@117.254.34.53) (Ping timeout: 255 seconds) |
| 2022-11-22 10:24:40 +0100 | razetime | (~quassel@117.254.35.120) |
| 2022-11-22 10:25:29 +0100 | atocanist | (~atocanist@2a01:e34:ec22:3040:260e:115e:44a8:9bee) |
| 2022-11-22 10:27:23 +0100 | lisbeths | (uid135845@id-135845.lymington.irccloud.com) (Quit: Connection closed for inactivity) |
| 2022-11-22 10:29:55 +0100 | Robert11 | (~Robert@ext-1-087.eduroam.chalmers.se) |
| 2022-11-22 10:30:28 +0100 | <Robert11> | Hi! `fixm f` where `f` is an IO computations makes little sense, right, since IO is strict? |
| 2022-11-22 10:30:47 +0100 | merijn | (~merijn@c-001-001-017.client.esciencecenter.eduvpn.nl) (Ping timeout: 256 seconds) |
| 2022-11-22 10:31:04 +0100 | madjestic | (~madjestic@213.208.229.226) |
| 2022-11-22 10:31:39 +0100 | econo | (uid147250@user/econo) (Quit: Connection closed for inactivity) |
| 2022-11-22 10:31:53 +0100 | <opqdonut> | Robert11: you mean mfix? yeah. even the docs say it should'nt be strinct |
| 2022-11-22 10:32:32 +0100 | <opqdonut> | there is an MonadFix IO instance though... I wonder if it can be used with lazy IO or something |
| 2022-11-22 10:32:53 +0100 | <dminuoso> | opqdonut: it indoces lazy io via fixIO yes |
| 2022-11-22 10:32:57 +0100 | <dminuoso> | induces, even |
| 2022-11-22 10:33:00 +0100 | <dminuoso> | https://hackage.haskell.org/package/base-4.17.0.0/docs/src/System.IO.html#fixIO |
| 2022-11-22 10:33:07 +0100 | <c_wraith> | the source is frightening |
| 2022-11-22 10:33:22 +0100 | <c_wraith> | It only works because IO can create reference types |
| 2022-11-22 10:33:46 +0100 | titibandit | (~titibandi@xdsl-78-34-153-165.nc.de) (Remote host closed the connection) |
| 2022-11-22 10:34:00 +0100 | <dminuoso> | If you fall in love with fixIO too deeply, you end up building nix. |
| 2022-11-22 10:34:07 +0100 | <c_wraith> | Same reason ST has a MonadFix instance |
| 2022-11-22 10:34:28 +0100 | jonathanx | (~jonathan@h-98-128-168-222.NA.cust.bahnhof.se) |
| 2022-11-22 10:35:09 +0100 | <Robert11> | Kind off thinking about something |
| 2022-11-22 10:35:42 +0100 | <Robert11> | `f :: IO [ThreadID]`, preferably I'd like to access these id's inside `f` |
| 2022-11-22 10:36:00 +0100 | bjourne | (~bjourne@2001:6b0:1:1140:42bf:ff4:f8fa:50e5) |
| 2022-11-22 10:37:00 +0100 | <dminuoso> | Keep in mind that holding a reference to a ThreadId will prevent the GC from reclaiming the thread itself. |
| 2022-11-22 10:37:19 +0100 | <dminuoso> | So even if the thread is done, it cant be freed. |
| 2022-11-22 10:37:29 +0100 | <Robert11> | This is OK, I don't have many, and they are cleaned up OK |
| 2022-11-22 10:37:58 +0100 | <Robert11> | I believe... I will have to investigate this if I end up going this route |
| 2022-11-22 10:38:25 +0100 | <Robert11> | I want some sibling threads to be able to communicate to each other |
| 2022-11-22 10:39:14 +0100 | <dminuoso> | The ThreadId is not going to help you much, unless you intend to use async exceptions to that effect. |
| 2022-11-22 10:39:23 +0100 | <dminuoso> | It is probably better to just use STM to that end. |
| 2022-11-22 10:41:44 +0100 | talismanick | (~talismani@76.133.152.122) (Ping timeout: 256 seconds) |
| 2022-11-22 10:42:11 +0100 | <Robert11> | Well yes, the siblings need to be able to kill each other |
| 2022-11-22 10:42:17 +0100 | <Robert11> | "I did the thing, please stop trying to do the thing" |
| 2022-11-22 10:42:43 +0100 | <c_wraith> | in that case, are you more looking for something like race from async? |
| 2022-11-22 10:43:07 +0100 | razetime | (~quassel@117.254.35.120) (Ping timeout: 260 seconds) |
| 2022-11-22 10:43:25 +0100 | razetime | (~quassel@117.254.35.71) |
| 2022-11-22 10:44:39 +0100 | <bjourne> | suppose i have a binary tree. in another data structure i want to store names of nodes in the tree. how can this be done without reference equality? |
| 2022-11-22 10:44:57 +0100 | <dminuoso> | bjourne: What do you mean by "reference" equality? |
| 2022-11-22 10:45:00 +0100 | son0p | (~ff@2604:3d08:5b7f:5540::6bfc) (Ping timeout: 260 seconds) |
| 2022-11-22 10:45:10 +0100 | <Robert11> | is async a separate package? I don't want to pull in too many dependencies |
| 2022-11-22 10:45:11 +0100 | jespada_ | (~jespada@nmal-24-b2-v4wan-166357-cust1764.vm24.cable.virginm.net) (Quit: My MacBook has gone to sleep. ZZZzzz…) |
| 2022-11-22 10:45:17 +0100 | <Robert11> | I'd like to stick to control.concurrent if possible |
| 2022-11-22 10:45:50 +0100 | <bjourne> | "Reference equality is an equality relationship that does not only guarantee that two values are equal, but also that they are, in fact, the same value." |
| 2022-11-22 10:46:12 +0100 | <dminuoso> | bjourne: Yes, that is a mode of operation for an Eq implementation. |
| 2022-11-22 10:46:42 +0100 | <dminuoso> | Im really not sure what it is you are asking for. |
| 2022-11-22 10:47:04 +0100 | <c_wraith> | You're not meant to think of references in Haskell. Just values. |
| 2022-11-22 10:47:37 +0100 | <dminuoso> | I have a vague idea of what you might be asking. Is your question how to keep a copy of a string, rather than a reference? |
| 2022-11-22 10:48:07 +0100 | madjestic | (~madjestic@213.208.229.226) (Ping timeout: 252 seconds) |
| 2022-11-22 10:48:14 +0100 | jespada | (~jespada@nmal-24-b2-v4wan-166357-cust1764.vm24.cable.virginm.net) |
| 2022-11-22 10:48:39 +0100 | <mauke> | Robert11: you can, but ... writing code with manual resource management that is safe in the presence of asynchronous exceptions is fiddly and annoying |
| 2022-11-22 10:48:54 +0100 | <mauke> | async gives you safer building blocks |
| 2022-11-22 10:49:05 +0100 | madjestic | (~madjestic@213.208.229.226) |
| 2022-11-22 10:49:12 +0100 | <Robert11> | This is the cross I carry |
| 2022-11-22 10:49:12 +0100 | <bjourne> | c_wraith: it doesnt work for graphs |
| 2022-11-22 10:49:21 +0100 | <Robert11> | It is my burden, as the package developer |
| 2022-11-22 10:50:21 +0100 | <mauke> | yeah, but async was written by Simon Marlow, one of the core developers of ghc |
| 2022-11-22 10:50:31 +0100 | <mauke> | so I kind of trust it more than anything I could come up with myself |
| 2022-11-22 10:50:46 +0100 | <c_wraith> | bjourne: you'll note that any sort of real-world graph package in haskell does not represent graphs with pointers. They use explicit indices into some backing structure. (Usually an array) |
| 2022-11-22 10:50:48 +0100 | razetime | (~quassel@117.254.35.71) (Ping timeout: 256 seconds) |
| 2022-11-22 10:52:24 +0100 | <Robert11> | I did not critique async in any way, I just meant that I'd rather spend some time getting it to work than pull in another dependency |
| 2022-11-22 10:52:35 +0100 | zmt00 | (~zmt00@user/zmt00) (Ping timeout: 260 seconds) |
| 2022-11-22 10:52:54 +0100 | tzh | (~tzh@c-24-21-73-154.hsd1.or.comcast.net) (Quit: zzz) |
| 2022-11-22 10:52:59 +0100 | <c_wraith> | how do you feel about spending some time making yourself think it works, then spending a lot more time debugging issues it causes? |
| 2022-11-22 10:53:05 +0100 | <geekosaur> | that's generally considered a bad decision: as many things as possible are split off into dependencies |
| 2022-11-22 10:53:27 +0100 | <geekosaur> | \they're getting ready to split base again, if I'm reading discussion elsewhere correctly |
| 2022-11-22 10:53:29 +0100 | razetime | (~quassel@117.193.7.206) |
| 2022-11-22 10:53:47 +0100 | <dminuoso> | geekosaur: Really? What is going to be split off? |
| 2022-11-22 10:54:30 +0100 | <geekosaur> | actually that part isn't happening yet. first phase is to split the stuff that needs to be wired-in or etc. into a separate ghc-base, which is the one that will be pinned |
| 2022-11-22 10:54:48 +0100 | <geekosaur> | then the rest of base can be split, upgraded separately, whatever |
| 2022-11-22 10:55:03 +0100 | <c_wraith> | makes sense. there's a lot more in base than needs to be wired in. |
| 2022-11-22 10:55:12 +0100 | <Robert11> | Man this discussion is starting to feel like something I'd read on stackoverflow. Rather than answering the question / not answering at all, you're trying to tell me why my desired approach is wrong (not knowing anything of the overall project I am working on) |
| 2022-11-22 10:55:14 +0100 | zmt00 | (~zmt00@user/zmt00) |
| 2022-11-22 10:55:31 +0100 | Robert11 | (~Robert@ext-1-087.eduroam.chalmers.se) (Quit: Connection closed) |
| 2022-11-22 10:55:43 +0100 | <c_wraith> | Robert11: perhaps that's because your desired approach has problems that you're not communicating that you understand |
| 2022-11-22 10:56:05 +0100 | <dminuoso> | They have just left |
| 2022-11-22 10:56:07 +0100 | <mauke> | I thought Robert11's original question was already answered a while ago |
| 2022-11-22 10:56:12 +0100 | <mauke> | was there another one? |
| 2022-11-22 10:56:24 +0100 | <geekosaur> | also, wishing for access to references won't get you them. the language design gores out of its way to *not give you that* |
| 2022-11-22 10:56:28 +0100 | <geekosaur> | *goes |
| 2022-11-22 10:56:34 +0100 | <c_wraith> | They wanted to run several IO actions and cancel the others when one finishes. |
| 2022-11-22 10:56:40 +0100 | <dminuoso> | And if you do uncover the references, they are evil and treacherous. |
| 2022-11-22 10:56:45 +0100 | <c_wraith> | And they wanted to not use the async package |
| 2022-11-22 10:56:46 +0100 | <bjourne> | c_wraith: yes, i call that reference equality-- since, practically speaking, it is not type safe |
| 2022-11-22 10:56:58 +0100 | <dminuoso> | We have this thing called reallyUnsafePtrEquality# which is a simple pointer address equality |
| 2022-11-22 10:57:05 +0100 | <dminuoso> | And it will *not* behave like you expect it, it is truly evil. |
| 2022-11-22 10:57:14 +0100 | <mauke> | c_wraith: sure, but that's not a question |
| 2022-11-22 10:57:17 +0100 | <dminuoso> | This is due to how the runtime model is built |
| 2022-11-22 10:57:51 +0100 | <c_wraith> | mauke: eh. request for help or question, does the difference matter that much? |
| 2022-11-22 10:58:06 +0100 | <dminuoso> | bjourne: That thing can give false positives, false negatives |
| 2022-11-22 10:58:16 +0100 | <dminuoso> | bjourne: with that in mind, do you think talking about references is generally a useful thing? |
| 2022-11-22 10:58:19 +0100 | merijn | (~merijn@c-001-001-017.client.esciencecenter.eduvpn.nl) |
| 2022-11-22 10:58:47 +0100 | <c_wraith> | dminuoso: I think it can't actually give false positives. It can't be interrupted by GC, so things can't be moved around in the middle of it. |
| 2022-11-22 10:59:41 +0100 | <mauke> | c_wraith: "<Robert11> I believe... I will have to investigate this if I end up going this route" <- I didn't parse it as a request for help, more like "this is how I'm planning to go about it" |
| 2022-11-22 10:59:50 +0100 | <dminuoso> | c_wraith: let me rephrase what Im thinking off then. |
| 2022-11-22 11:00:06 +0100 | <geekosaur> | Robert11 gave up and left |
| 2022-11-22 11:00:09 +0100 | <dminuoso> | You can have a situation where `reallyUnsafePtrEquality# a b` starts off as true, and then if you reevaluate that same expression becomes false. |
| 2022-11-22 11:00:24 +0100 | <geekosaur> | apparently it's "write and debug from scratch hiimself" or we're all mean playmates |
| 2022-11-22 11:00:32 +0100 | <dminuoso> | Thats just one of the many evil traps thinking about references holds |
| 2022-11-22 11:00:37 +0100 | teo | (~teo@user/teo) |
| 2022-11-22 11:00:47 +0100 | <bjourne> | dminuoso: "They use explicit indices into some backing structure." <- this is references implemented "by hand". |
| 2022-11-22 11:00:57 +0100 | <c_wraith> | dminuoso: I don't see how that could happen. |
| 2022-11-22 11:01:06 +0100 | __monty__ | (~toonn@user/toonn) |
| 2022-11-22 11:01:06 +0100 | <geekosaur> | and that's pretty much how you have to do it, in Haskell |
| 2022-11-22 11:02:14 +0100 | <dminuoso> | c_wraith: imagine some shared impure (unsafePerformIO) thunk |
| 2022-11-22 11:02:16 +0100 | chromoblob | (~user@37.113.164.122) |
| 2022-11-22 11:02:17 +0100 | <c_wraith> | bjourne: I said at the start that haskell wants you to work with values, not pointers. If you want to work with indirect access to data, you need to implement it. |
| 2022-11-22 11:02:30 +0100 | yella | (~yell@2607:fb90:80c9:e326:6468:b483:c07e:90c8) (Ping timeout: 255 seconds) |
| 2022-11-22 11:02:54 +0100 | <dminuoso> | though mmm |
| 2022-11-22 11:03:04 +0100 | <dminuoso> | you wouldnt get a false on the intiail pointer comparison |
| 2022-11-22 11:03:06 +0100 | merijn | glances at the 15 different reference types in base |
| 2022-11-22 11:03:16 +0100 | <merijn> | I don't think I have to implement references myself ;) |
| 2022-11-22 11:03:30 +0100 | chele | (~chele@user/chele) |
| 2022-11-22 11:03:41 +0100 | <c_wraith> | Sure, but then you give up all the good points of having your graph nodes in an array |
| 2022-11-22 11:04:26 +0100 | <c_wraith> | dminuoso: oh, I see. If a and b are pointers to an unevaluated thunk, evaluating it will rewrite *one* of the pointers, not both. |
| 2022-11-22 11:04:47 +0100 | <dminuoso> | c_wraith yeah |
| 2022-11-22 11:05:17 +0100 | <dminuoso> | bjourne: maybe this is a confused discussion that has its root in an XY problem. |
| 2022-11-22 11:05:25 +0100 | <dminuoso> | care to explain the problem you are facing? |
| 2022-11-22 11:06:55 +0100 | <bjourne> | c_wraith: ok so you have type Graph = ([Vertex], Map Int [Int]), now you want to delete a vertex |
| 2022-11-22 11:07:14 +0100 | jonathanx | (~jonathan@h-98-128-168-222.NA.cust.bahnhof.se) (Ping timeout: 256 seconds) |
| 2022-11-22 11:07:24 +0100 | <merijn> | Why the list of vertices? Isn't that implicit in the Map? |
| 2022-11-22 11:07:38 +0100 | <c_wraith> | maybe it's storing data other than the index. |
| 2022-11-22 11:07:44 +0100 | <c_wraith> | It makes sense to me |
| 2022-11-22 11:07:59 +0100 | <merijn> | c_wraith: Wouldn't that make more sense as "Map Int (VertexData, [Int])"? |
| 2022-11-22 11:08:28 +0100 | <c_wraith> | Well, ok. that would make more sense. |
| 2022-11-22 11:08:47 +0100 | <merijn> | Make illegal states irrepresentible and all that ;) |
| 2022-11-22 11:08:54 +0100 | <c_wraith> | yeah |
| 2022-11-22 11:09:17 +0100 | <c_wraith> | also, updating it is faster than updating the list if the vertex data changes, but let's ignore that. |
| 2022-11-22 11:09:58 +0100 | atocanist | (~atocanist@2a01:e34:ec22:3040:260e:115e:44a8:9bee) (Ping timeout: 260 seconds) |
| 2022-11-22 11:11:17 +0100 | nek0 | (~nek0@2a01:4f8:222:2b41::12) (Quit: Ping timeout (120 seconds)) |
| 2022-11-22 11:11:32 +0100 | nek0 | (~nek0@2a01:4f8:222:2b41::12) |
| 2022-11-22 11:11:34 +0100 | <bjourne> | so type Graph = Map Int (VertexData, [Int]), you want to add a node, what do you do? |
| 2022-11-22 11:12:16 +0100 | <c_wraith> | what's interesting is that Data.Graph doesn't even have that operation |
| 2022-11-22 11:12:20 +0100 | <c_wraith> | and... I never noticed. |
| 2022-11-22 11:12:25 +0100 | xff0x | (~xff0x@125x103x176x34.ap125.ftth.ucom.ne.jp) (Ping timeout: 260 seconds) |
| 2022-11-22 11:12:39 +0100 | <c_wraith> | Admittedly, Data.Graph is intentionally quite limited. But it's sort of rare to add nodes to a graph online. |
| 2022-11-22 11:13:59 +0100 | <c_wraith> | to do it efficiently, your representation is actually (Int, Map Int ...) |
| 2022-11-22 11:14:12 +0100 | <c_wraith> | where the first value is the next node index to add. |
| 2022-11-22 11:14:29 +0100 | <merijn> | c_wraith: Map has a cheap max value lookup anyway? |
| 2022-11-22 11:14:39 +0100 | <c_wraith> | well. max key. yes. |
| 2022-11-22 11:15:03 +0100 | stiell | (~stiell@gateway/tor-sasl/stiell) (Remote host closed the connection) |
| 2022-11-22 11:15:37 +0100 | <bjourne> | so it's now type Graph = (Int, Map Int (VertexData, [Int])) |
| 2022-11-22 11:15:44 +0100 | <merijn> | I mean, either way this isn't gonna be a super high performance implementation |
| 2022-11-22 11:16:03 +0100 | <c_wraith> | bjourne: or just use lookupMax on the map, whatever |
| 2022-11-22 11:16:08 +0100 | stiell | (~stiell@gateway/tor-sasl/stiell) |
| 2022-11-22 11:16:19 +0100 | karolis | (~karolis@78.157.77.235) |
| 2022-11-22 11:16:33 +0100 | <bjourne> | i want O(1) insert |
| 2022-11-22 11:16:34 +0100 | madjestic | (~madjestic@213.208.229.226) (Ping timeout: 268 seconds) |
| 2022-11-22 11:16:48 +0100 | <c_wraith> | why? |
| 2022-11-22 11:16:53 +0100 | <probie> | O(log n) is pretty much O(1) |
| 2022-11-22 11:17:00 +0100 | jonathanx | (~jonathan@h-98-128-168-222.NA.cust.bahnhof.se) |
| 2022-11-22 11:17:12 +0100 | <merijn> | Could even use IntMap and get even better asymptotics |
| 2022-11-22 11:17:19 +0100 | chromoblob | (~user@37.113.164.122) (Ping timeout: 260 seconds) |
| 2022-11-22 11:17:25 +0100 | <c_wraith> | I can't imagine any graph algorithm where you insert more nodes than edges. |
| 2022-11-22 11:18:35 +0100 | <merijn> | Not to mention any representation that has O(1) insert is gonna have shit performance on queries |
| 2022-11-22 11:19:05 +0100 | <c_wraith> | including queries like finding the node to put on the other sides of the edge |
| 2022-11-22 11:19:24 +0100 | <probie> | If you keep the graph lazy, "insertion" is always O(1) :p |
| 2022-11-22 11:20:07 +0100 | eggplantade | (~Eggplanta@2600:1700:38c5:d800:5866:96fb:16f6:58d1) |
| 2022-11-22 11:21:05 +0100 | <bjourne> | it's odd that you dont understand why O(1) amortized complexity is important but it's beside the point |
| 2022-11-22 11:21:55 +0100 | <c_wraith> | I mean, you can go make an IORef graph if you want, but performance is going to be a lot worse on almost every algorithm. |
| 2022-11-22 11:21:55 +0100 | <merijn> | bjourne: Your graph is not going to be big enough to for O(log n) to be noticably different from O(1). And if your graph IS going to be big enough, the Map and List approach is fundamentally the wrong approach anyway |
| 2022-11-22 11:22:17 +0100 | <merijn> | You'd want a mutable vector based CSR or something |
| 2022-11-22 11:24:10 +0100 | eggplantade | (~Eggplanta@2600:1700:38c5:d800:5866:96fb:16f6:58d1) (Ping timeout: 240 seconds) |
| 2022-11-22 11:24:11 +0100 | FinnElija | (~finn_elij@user/finn-elija/x-0085643) (Ping timeout: 255 seconds) |
| 2022-11-22 11:25:18 +0100 | mei__ | (~mei@user/mei) |
| 2022-11-22 11:25:52 +0100 | <c_wraith> | ooh, CSR is neat. I never looked into what actually-efficient graph representation use. |
| 2022-11-22 11:26:31 +0100 | FinnElija | (~finn_elij@user/finn-elija/x-0085643) |
| 2022-11-22 11:27:50 +0100 | <c_wraith> | hey, and there are variants like PCSR intended for use cases with lots of node insertion/deletion |
| 2022-11-22 11:28:14 +0100 | <bjourne> | merijn: if it is the wrong approach, why did you suggest it? |
| 2022-11-22 11:28:23 +0100 | azimut | (~azimut@gateway/tor-sasl/azimut) |
| 2022-11-22 11:28:32 +0100 | <c_wraith> | because it works fine up to a couple million nodes |
| 2022-11-22 11:28:46 +0100 | <c_wraith> | most graphs aren't that big. |
| 2022-11-22 11:29:21 +0100 | <c_wraith> | and honestly, memory use becomes an issue before speed does. |
| 2022-11-22 11:30:13 +0100 | <merijn> | bjourne: Because you haven't specified what you're doing so we're all just randomly guessing based on your initial suggestion/idea |
| 2022-11-22 11:30:52 +0100 | gurkenglas | (~gurkengla@p548ac72e.dip0.t-ipconnect.de) |
| 2022-11-22 11:31:08 +0100 | <dminuoso> | Okay, I think I've done it. I realized I started writing unsafeCoerce without the slightest hesitation. |
| 2022-11-22 11:31:13 +0100 | <merijn> | c_wraith: CSR is gonna be painfully expensive to update, though. But for querying operation you can't beat "dense arrasy" as universal HPC datastructur |
| 2022-11-22 11:31:16 +0100 | <dminuoso> | Have I gone too far? :) |
| 2022-11-22 11:32:20 +0100 | razetime | (~quassel@117.193.7.206) (Ping timeout: 248 seconds) |
| 2022-11-22 11:33:01 +0100 | razetime | (~quassel@117.254.34.208) |
| 2022-11-22 11:33:37 +0100 | troydm | (~troydm@host-176-37-124-197.b025.la.net.ua) |
| 2022-11-22 11:33:45 +0100 | <c_wraith> | dminuoso: hmm. probably. Even when I know it's safe, I still hesitate to ask if I can possibly do it another way. |
| 2022-11-22 11:35:02 +0100 | acidjnk | (~acidjnk@p200300d6e7137a84847a35f477003ced.dip0.t-ipconnect.de) |
| 2022-11-22 11:35:11 +0100 | smichel17[m] | (~smichel17@2001:470:69fc:105::2d32) (Quit: Bridge terminating on SIGTERM) |
| 2022-11-22 11:35:11 +0100 | elvishjerricco | (~elvishjer@2001:470:69fc:105::6172) (Quit: Bridge terminating on SIGTERM) |
| 2022-11-22 11:35:11 +0100 | Tisoxin | (~ikosit@user/ikosit) (Quit: Bridge terminating on SIGTERM) |
| 2022-11-22 11:35:11 +0100 | geekosaur[m] | (~geekosaur@xmonad/geekosaur) (Quit: Bridge terminating on SIGTERM) |
| 2022-11-22 11:35:11 +0100 | jbggs[m] | (~jbggsmatr@2001:470:69fc:105::2:995f) (Quit: Bridge terminating on SIGTERM) |
| 2022-11-22 11:35:11 +0100 | adziahel[m] | (~adziahelm@2001:470:69fc:105::b4d) (Quit: Bridge terminating on SIGTERM) |
| 2022-11-22 11:35:11 +0100 | inkbottle[m] | (~inkbottle@2001:470:69fc:105::2ff5) (Quit: Bridge terminating on SIGTERM) |
| 2022-11-22 11:35:11 +0100 | aaronv | (~aaronv@user/aaronv) (Quit: Bridge terminating on SIGTERM) |
| 2022-11-22 11:35:11 +0100 | kfiz[m] | (~louismatr@2001:470:69fc:105::2:aee0) (Quit: Bridge terminating on SIGTERM) |
| 2022-11-22 11:35:11 +0100 | psydroid | (~psydroid@user/psydroid) (Quit: Bridge terminating on SIGTERM) |
| 2022-11-22 11:35:12 +0100 | M0rphee[m] | (~M0rpheema@2001:470:69fc:105::2:b1ce) (Quit: Bridge terminating on SIGTERM) |
| 2022-11-22 11:35:12 +0100 | maralorn | (~maralorn@2001:470:69fc:105::251) (Quit: Bridge terminating on SIGTERM) |
| 2022-11-22 11:35:12 +0100 | srid[m] | (~sridmatri@2001:470:69fc:105::1c2) (Quit: Bridge terminating on SIGTERM) |
| 2022-11-22 11:35:12 +0100 | lawt | (~lawtonmat@2001:470:69fc:105::2:97b8) (Quit: Bridge terminating on SIGTERM) |
| 2022-11-22 11:35:12 +0100 | cafkafk[m] | (~cafkafkma@2001:470:69fc:105::1:cea8) (Quit: Bridge terminating on SIGTERM) |
| 2022-11-22 11:35:12 +0100 | Clinton[m] | (~clintonme@2001:470:69fc:105::2:31d4) (Quit: Bridge terminating on SIGTERM) |
| 2022-11-22 11:35:12 +0100 | afotgkmnzj7asv3r | (~afotgkmnz@2001:470:69fc:105::c24b) (Quit: Bridge terminating on SIGTERM) |
| 2022-11-22 11:35:12 +0100 | steve[m]12 | (~stevetrou@2001:470:69fc:105::e0b) (Quit: Bridge terminating on SIGTERM) |
| 2022-11-22 11:35:12 +0100 | schuelermine[m] | (~schuelerm@user/schuelermine) (Quit: Bridge terminating on SIGTERM) |
| 2022-11-22 11:35:12 +0100 | Artem[m] | (~artemtype@2001:470:69fc:105::75b) (Quit: Bridge terminating on SIGTERM) |
| 2022-11-22 11:35:12 +0100 | olivermead[m] | (~olivermea@2001:470:69fc:105::2:4289) (Quit: Bridge terminating on SIGTERM) |
| 2022-11-22 11:35:12 +0100 | sm | (~sm@plaintextaccounting/sm) (Quit: Bridge terminating on SIGTERM) |
| 2022-11-22 11:35:12 +0100 | ManofLetters[m] | (~manoflett@2001:470:69fc:105::3be) (Quit: Bridge terminating on SIGTERM) |
| 2022-11-22 11:35:13 +0100 | ongy[m] | (~ongymatri@2001:470:69fc:105::5018) (Quit: Bridge terminating on SIGTERM) |
| 2022-11-22 11:35:13 +0100 | fgaz | (~fgaz@2001:470:69fc:105::842) (Quit: Bridge terminating on SIGTERM) |
| 2022-11-22 11:35:13 +0100 | silky[m] | (~noonvande@2001:470:69fc:105::2:943c) (Quit: Bridge terminating on SIGTERM) |
| 2022-11-22 11:35:13 +0100 | famubu[m] | (~famubumat@2001:470:69fc:105::1081) (Quit: Bridge terminating on SIGTERM) |
| 2022-11-22 11:35:13 +0100 | Deide | (~deide@user/deide) (Quit: Bridge terminating on SIGTERM) |
| 2022-11-22 11:35:13 +0100 | unclechu | (~unclechu@2001:470:69fc:105::354) (Quit: Bridge terminating on SIGTERM) |
| 2022-11-22 11:35:13 +0100 | VanceIsM7[m] | (~vanceism7@2001:470:69fc:105::3ad) (Quit: Bridge terminating on SIGTERM) |
| 2022-11-22 11:35:13 +0100 | VarikValefor[m] | (~varikvale@2001:470:69fc:105::a5d) (Quit: Bridge terminating on SIGTERM) |
| 2022-11-22 11:35:13 +0100 | fendor[m] | (~fendormat@2001:470:69fc:105::fcbd) (Quit: Bridge terminating on SIGTERM) |
| 2022-11-22 11:35:14 +0100 | ormaaj | (~ormaaj@user/ormaaj) (Quit: Bridge terminating on SIGTERM) |
| 2022-11-22 11:35:14 +0100 | crazazy[m] | (~crazazyut@2001:470:69fc:105::2:ba2a) (Quit: Bridge terminating on SIGTERM) |
| 2022-11-22 11:35:14 +0100 | vladan[m] | (~vladanmat@2001:470:69fc:105::2:24df) (Quit: Bridge terminating on SIGTERM) |
| 2022-11-22 11:35:14 +0100 | Las[m] | (~lasmatrix@2001:470:69fc:105::74e) (Quit: Bridge terminating on SIGTERM) |
| 2022-11-22 11:35:14 +0100 | SeanKing[m] | (~seankingm@2001:470:69fc:105::cf9c) (Quit: Bridge terminating on SIGTERM) |
| 2022-11-22 11:35:14 +0100 | nomagno | (~nomagno@2001:470:69fc:105::c1f0) (Quit: Bridge terminating on SIGTERM) |
| 2022-11-22 11:35:14 +0100 | maerwald[m] | (~maerwaldm@2001:470:69fc:105::1ee) (Quit: Bridge terminating on SIGTERM) |
| 2022-11-22 11:35:14 +0100 | Guillaum[m] | (~guiboumat@2001:470:69fc:105::1:72ac) (Quit: Bridge terminating on SIGTERM) |
| 2022-11-22 11:35:14 +0100 | jneira[m] | (~jneiramat@2001:470:69fc:105::d729) (Quit: Bridge terminating on SIGTERM) |
| 2022-11-22 11:35:14 +0100 | jinsun_ | (~jinsun@user/jinsun) (Quit: Bridge terminating on SIGTERM) |
| 2022-11-22 11:35:14 +0100 | chreekat | (~chreekat@2001:470:69fc:105::16b5) (Quit: Bridge terminating on SIGTERM) |
| 2022-11-22 11:35:14 +0100 | drsooch[m] | (~drsoochma@2001:470:69fc:105::1:c8a1) (Quit: Bridge terminating on SIGTERM) |
| 2022-11-22 11:35:14 +0100 | oak- | (~oak-@2001:470:69fc:105::fcd) (Quit: Bridge terminating on SIGTERM) |
| 2022-11-22 11:35:15 +0100 | Dominik[m]1 | (~dschrempf@2001:470:69fc:105::2:bbb6) (Quit: Bridge terminating on SIGTERM) |
| 2022-11-22 11:35:15 +0100 | czuberion[m] | (~czuberion@2001:470:69fc:105::2:bc47) (Quit: Bridge terminating on SIGTERM) |
| 2022-11-22 11:35:15 +0100 | zarel[m] | (~zarelitma@2001:470:69fc:105::1:fcfb) (Quit: Bridge terminating on SIGTERM) |
| 2022-11-22 11:35:15 +0100 | AdamConner-Sax[m | (~adamcsmat@2001:470:69fc:105::1:e2c8) (Quit: Bridge terminating on SIGTERM) |
| 2022-11-22 11:35:15 +0100 | ted[m] | (~tedmatrix@2001:470:69fc:105::2:bf60) (Quit: Bridge terminating on SIGTERM) |
| 2022-11-22 11:35:16 +0100 | alexfmpe[m] | (~alexfmpem@2001:470:69fc:105::38ba) (Quit: Bridge terminating on SIGTERM) |
| 2022-11-22 11:35:16 +0100 | ericson2314 | (~ericson23@2001:470:69fc:105::70c) (Quit: Bridge terminating on SIGTERM) |
| 2022-11-22 11:35:16 +0100 | Player-205[m] | (~sashaserp@2001:470:69fc:105::2:30b8) (Quit: Bridge terminating on SIGTERM) |
| 2022-11-22 11:35:16 +0100 | yl53[m] | (~yl53matri@2001:470:69fc:105::85b) (Quit: Bridge terminating on SIGTERM) |
| 2022-11-22 11:35:16 +0100 | jean-paul[m] | (~jean-paul@2001:470:69fc:105::d1ab) (Quit: Bridge terminating on SIGTERM) |
| 2022-11-22 11:35:16 +0100 | peddie | (~peddie@2001:470:69fc:105::25d) (Quit: Bridge terminating on SIGTERM) |
| 2022-11-22 11:35:16 +0100 | Matthew|m | (~arathorn@2001:470:69fc:105::1f) (Quit: Bridge terminating on SIGTERM) |
| 2022-11-22 11:35:19 +0100 | Christoph[m] | (~hpotsirhc@2001:470:69fc:105::2ff8) (Quit: Bridge terminating on SIGTERM) |
| 2022-11-22 11:35:19 +0100 | nicm[m] | (~nicmollel@2001:470:69fc:105::1:feeb) (Quit: Bridge terminating on SIGTERM) |
| 2022-11-22 11:35:19 +0100 | romes[m] | (~romesmatr@2001:470:69fc:105::2:1660) (Quit: Bridge terminating on SIGTERM) |
| 2022-11-22 11:35:19 +0100 | MangoIV[m] | (~mangoivma@2001:470:69fc:105::2:8417) (Quit: Bridge terminating on SIGTERM) |
| 2022-11-22 11:35:19 +0100 | JensPetersen[m] | (~juhp@2001:470:69fc:105::6e9) (Quit: Bridge terminating on SIGTERM) |
| 2022-11-22 11:35:19 +0100 | tiziodcaio | (~tiziodcai@2001:470:69fc:105::1:2bf8) (Quit: Bridge terminating on SIGTERM) |
| 2022-11-22 11:35:20 +0100 | UdayKiran[m] | (~neoatnebu@2001:470:69fc:105::2:bae0) (Quit: Bridge terminating on SIGTERM) |
| 2022-11-22 11:35:20 +0100 | mimi1vx[m] | (~osukupmat@2001:470:69fc:105::2:418d) (Quit: Bridge terminating on SIGTERM) |
| 2022-11-22 11:35:20 +0100 | ozkutuk[m] | (~ozkutuk@2001:470:69fc:105::2:9af8) (Quit: Bridge terminating on SIGTERM) |
| 2022-11-22 11:35:20 +0100 | JonathanWatson[m | (~jjwmatrix@2001:470:69fc:105::2:a544) (Quit: Bridge terminating on SIGTERM) |
| 2022-11-22 11:35:20 +0100 | sektor[m] | (~sektor@2001:470:69fc:105::2:3f60) (Quit: Bridge terminating on SIGTERM) |
| 2022-11-22 11:35:20 +0100 | oo_miguel[m] | (~oomiguelm@2001:470:69fc:105::1:5ab0) (Quit: Bridge terminating on SIGTERM) |
| 2022-11-22 11:35:21 +0100 | jecxjo[m] | (~jecxjomat@2001:470:69fc:105::2:bd7c) (Quit: Bridge terminating on SIGTERM) |
| 2022-11-22 11:35:21 +0100 | jmcantrell | (~jmcantrel@user/jmcantrell) (Quit: Bridge terminating on SIGTERM) |
| 2022-11-22 11:35:21 +0100 | kjlid[m] | (~kjlidmatr@2001:470:69fc:105::2:c193) (Quit: Bridge terminating on SIGTERM) |
| 2022-11-22 11:35:22 +0100 | <c_wraith> | wow, it's late. That sure is ambiguously phrase. I still hesitate *to give myself time* to ask.... |
| 2022-11-22 11:35:45 +0100 | <dminuoso> | c_wraith: Given what Im doing, there is little way around it. |
| 2022-11-22 11:35:55 +0100 | <c_wraith> | sometimes that happens. |
| 2022-11-22 11:36:07 +0100 | <c_wraith> | But I still spend some time hesitating. :) |
| 2022-11-22 11:36:20 +0100 | <bjourne> | merijn: this expression in haskell: Map<T, List<T> > map = new HashMap<>(); |
| 2022-11-22 11:36:27 +0100 | <dminuoso> | Im essentially doing things like turning `newtype ST s a = ST (State# s -> (# State# s, a #)) into `Proxy# s -> (# Proxy# s, a #)` and back |
| 2022-11-22 11:36:37 +0100 | <dminuoso> | For some a bunch of convoluted reasons |
| 2022-11-22 11:37:03 +0100 | <c_wraith> | huh. I thought Proxy# arguments were elided at runtime |
| 2022-11-22 11:37:12 +0100 | <dminuoso> | Yes, so are State# |
| 2022-11-22 11:37:15 +0100 | <c_wraith> | ah, ok |
| 2022-11-22 11:37:39 +0100 | fgaz | (~fgaz@2001:470:69fc:105::842) |
| 2022-11-22 11:37:44 +0100 | <merijn> | bjourne: That's not a description of the problem you want to solve, nor the scale of your data, or really anything useful beyond "I have this exact code in another language that I try to mimic", which may or may not make sense, given that Haskell is lazy and immutable |
| 2022-11-22 11:37:46 +0100 | peddie | (~peddie@2001:470:69fc:105::25d) |
| 2022-11-22 11:37:46 +0100 | ericson2314 | (~ericson23@2001:470:69fc:105::70c) |
| 2022-11-22 11:37:46 +0100 | famubu[m] | (~famubumat@2001:470:69fc:105::1081) |
| 2022-11-22 11:38:00 +0100 | aaronv | (~aaronv@user/aaronv) |
| 2022-11-22 11:38:00 +0100 | maralorn | (~maralorn@2001:470:69fc:105::251) |
| 2022-11-22 11:38:00 +0100 | sm | (~sm@plaintextaccounting/sm) |
| 2022-11-22 11:38:01 +0100 | tiziodcaio | (~tiziodcai@2001:470:69fc:105::1:2bf8) |
| 2022-11-22 11:38:13 +0100 | Christoph[m] | (~hpotsirhc@2001:470:69fc:105::2ff8) |
| 2022-11-22 11:38:13 +0100 | ongy[m] | (~ongymatri@2001:470:69fc:105::5018) |
| 2022-11-22 11:38:28 +0100 | Las[m] | (~lasmatrix@2001:470:69fc:105::74e) |
| 2022-11-22 11:38:30 +0100 | <dminuoso> | https://github.com/dminuoso/flatparse-state/blob/main/app/Main.hs nearly 10% of lines have an unsafeCoerce in them heh |
| 2022-11-22 11:38:42 +0100 | smichel17[m] | (~smichel17@2001:470:69fc:105::2d32) |
| 2022-11-22 11:38:56 +0100 | chreekat | (~chreekat@2001:470:69fc:105::16b5) |
| 2022-11-22 11:39:09 +0100 | ManofLetters[m] | (~manoflett@2001:470:69fc:105::3be) |
| 2022-11-22 11:39:09 +0100 | fendor[m] | (~fendormat@2001:470:69fc:105::fcbd) |
| 2022-11-22 11:39:16 +0100 | inversed | (~inversed@bcdcac82.skybroadband.com) (Ping timeout: 248 seconds) |
| 2022-11-22 11:39:24 +0100 | oak- | (~oak-@2001:470:69fc:105::fcd) |
| 2022-11-22 11:39:32 +0100 | <probie> | bjourne: import Data.HashMap qualified as HM; map = HM.empty |
| 2022-11-22 11:39:37 +0100 | kfiz[m] | (~louismatr@2001:470:69fc:105::2:aee0) |
| 2022-11-22 11:39:37 +0100 | jmcantrell | (~jmcantrel@user/jmcantrell) |
| 2022-11-22 11:39:37 +0100 | jinsun_ | (~jinsun@user/jinsun) |
| 2022-11-22 11:39:50 +0100 | romes[m] | (~romesmatr@2001:470:69fc:105::2:1660) |
| 2022-11-22 11:40:05 +0100 | JensPetersen[m] | (~juhp@2001:470:69fc:105::6e9) |
| 2022-11-22 11:40:06 +0100 | ormaaj | (~ormaaj@user/ormaaj) |
| 2022-11-22 11:40:06 +0100 | Guillaum[m] | (~guiboumat@2001:470:69fc:105::1:72ac) |
| 2022-11-22 11:40:12 +0100 | inversed | (~inversed@bcdcac82.skybroadband.com) |
| 2022-11-22 11:40:19 +0100 | silky[m] | (~noonvande@2001:470:69fc:105::2:943c) |
| 2022-11-22 11:40:32 +0100 | jneira[m] | (~jneiramat@2001:470:69fc:105::d729) |
| 2022-11-22 11:40:32 +0100 | alexfmpe[m] | (~alexfmpem@2001:470:69fc:105::38ba) |
| 2022-11-22 11:40:32 +0100 | Matthew|m | (~arathorn@2001:470:69fc:105::1f) |
| 2022-11-22 11:40:33 +0100 | JonathanWatson[m | (~jjwmatrix@2001:470:69fc:105::2:a544) |
| 2022-11-22 11:40:42 +0100 | <dminuoso> | bjourne: What operations do you do with the graph mainly? |
| 2022-11-22 11:40:44 +0100 | <probie> | with a type signature of "map :: HM.Map T [T]". It's probably not what you want though |
| 2022-11-22 11:40:45 +0100 | srid[m] | (~sridmatri@2001:470:69fc:105::1c2) |
| 2022-11-22 11:40:46 +0100 | lawt | (~lawtonmat@2001:470:69fc:105::2:97b8) |
| 2022-11-22 11:40:59 +0100 | M0rphee[m] | (~M0rpheema@2001:470:69fc:105::2:b1ce) |
| 2022-11-22 11:40:59 +0100 | nicm[m] | (~nicmollel@2001:470:69fc:105::1:feeb) |
| 2022-11-22 11:41:06 +0100 | <bjourne> | merijn: i disagree. Map<T, List<T> > map = new HashMap<>(); instantiates a graph with capacity for many millions of nodes |
| 2022-11-22 11:41:12 +0100 | drsooch[m] | (~drsoochma@2001:470:69fc:105::1:c8a1) |
| 2022-11-22 11:41:25 +0100 | olivermead[m] | (~olivermea@2001:470:69fc:105::2:4289) |
| 2022-11-22 11:41:37 +0100 | jbggs[m] | (~jbggsmatr@2001:470:69fc:105::2:995f) |
| 2022-11-22 11:41:52 +0100 | oo_miguel[m] | (~oomiguelm@2001:470:69fc:105::1:5ab0) |
| 2022-11-22 11:41:53 +0100 | Tisoxin | (~ikosit@user/ikosit) |
| 2022-11-22 11:42:06 +0100 | <dminuoso> | Either way, is there any graph representation in which vertex removal is actually cheap? |
| 2022-11-22 11:42:08 +0100 | ozkutuk[m] | (~ozkutuk@2001:470:69fc:105::2:9af8) |
| 2022-11-22 11:42:08 +0100 | Artem[m] | (~artemtype@2001:470:69fc:105::75b) |
| 2022-11-22 11:42:08 +0100 | unclechu | (~unclechu@2001:470:69fc:105::354) |
| 2022-11-22 11:42:09 +0100 | sektor[m] | (~sektor@2001:470:69fc:105::2:3f60) |
| 2022-11-22 11:42:21 +0100 | Clinton[m] | (~clintonme@2001:470:69fc:105::2:31d4) |
| 2022-11-22 11:42:21 +0100 | maerwald[m] | (~maerwaldm@2001:470:69fc:105::1ee) |
| 2022-11-22 11:42:21 +0100 | vladan[m] | (~vladanmat@2001:470:69fc:105::2:24df) |
| 2022-11-22 11:42:36 +0100 | <dminuoso> | Adjacency list is the cheapest for that type of operation that I know of |
| 2022-11-22 11:42:37 +0100 | elvishjerricco | (~elvishjer@2001:470:69fc:105::6172) |
| 2022-11-22 11:42:37 +0100 | VarikValefor[m] | (~varikvale@2001:470:69fc:105::a5d) |
| 2022-11-22 11:42:38 +0100 | geekosaur[m] | (~geekosaur@xmonad/geekosaur) |
| 2022-11-22 11:42:38 +0100 | nomagno | (~nomagno@2001:470:69fc:105::c1f0) |
| 2022-11-22 11:42:51 +0100 | jean-paul[m] | (~jean-paul@2001:470:69fc:105::d1ab) |
| 2022-11-22 11:43:03 +0100 | afotgkmnzj7asv3r | (~afotgkmnz@2001:470:69fc:105::c24b) |
| 2022-11-22 11:43:17 +0100 | cafkafk[m] | (~cafkafkma@2001:470:69fc:105::1:cea8) |
| 2022-11-22 11:43:29 +0100 | VanceIsM7[m] | (~vanceism7@2001:470:69fc:105::3ad) |
| 2022-11-22 11:43:29 +0100 | Deide | (~deide@user/deide) |
| 2022-11-22 11:43:29 +0100 | SeanKing[m] | (~seankingm@2001:470:69fc:105::cf9c) |
| 2022-11-22 11:43:43 +0100 | Player-205[m] | (~sashaserp@2001:470:69fc:105::2:30b8) |
| 2022-11-22 11:43:43 +0100 | MangoIV[m] | (~mangoivma@2001:470:69fc:105::2:8417) |
| 2022-11-22 11:43:43 +0100 | psydroid | (~psydroid@user/psydroid) |
| 2022-11-22 11:43:43 +0100 | schuelermine[m] | (~schuelerm@user/schuelermine) |
| 2022-11-22 11:43:43 +0100 | yl53[m] | (~yl53matri@2001:470:69fc:105::85b) |
| 2022-11-22 11:43:57 +0100 | crazazy[m] | (~crazazyut@2001:470:69fc:105::2:ba2a) |
| 2022-11-22 11:44:09 +0100 | UdayKiran[m] | (~neoatnebu@2001:470:69fc:105::2:bae0) |
| 2022-11-22 11:44:22 +0100 | czuberion[m] | (~czuberion@2001:470:69fc:105::2:bc47) |
| 2022-11-22 11:44:35 +0100 | zarel[m] | (~zarelitma@2001:470:69fc:105::1:fcfb) |
| 2022-11-22 11:44:44 +0100 | <bjourne> | it's O(1) if you allow for tombstoning |
| 2022-11-22 11:44:47 +0100 | accord | (uid568320@id-568320.hampstead.irccloud.com) |
| 2022-11-22 11:44:48 +0100 | Dominik[m]1 | (~dschrempf@2001:470:69fc:105::2:bbb6) |
| 2022-11-22 11:44:49 +0100 | AdamConner-Sax[m | (~adamcsmat@2001:470:69fc:105::1:e2c8) |
| 2022-11-22 11:44:54 +0100 | <probie> | dminuoso: You can use `Map Node (Set Node)` where deletion is just removing a Node from the Map. It just makes querying more expensive since garbage isn't collected (but this might be acceptable) |
| 2022-11-22 11:45:04 +0100 | mimi1vx[m] | (~osukupmat@2001:470:69fc:105::2:418d) |
| 2022-11-22 11:45:22 +0100 | ted[m] | (~tedmatrix@2001:470:69fc:105::2:bf60) |
| 2022-11-22 11:45:23 +0100 | adziahel[m] | (~adziahelm@2001:470:69fc:105::b4d) |
| 2022-11-22 11:45:36 +0100 | steve[m] | (~stevetrou@2001:470:69fc:105::e0b) |
| 2022-11-22 11:45:36 +0100 | inkbottle[m] | (~inkbottle@2001:470:69fc:105::2ff5) |
| 2022-11-22 11:45:52 +0100 | jecxjo[m] | (~jecxjomat@2001:470:69fc:105::2:bd7c) |
| 2022-11-22 11:45:57 +0100 | <[Leary]> | If you're clever with a reference-style graph, you can probably build cheap clean-up actions alongside each vertex. |
| 2022-11-22 11:46:13 +0100 | kjlid[m] | (~kjlidmatr@2001:470:69fc:105::2:c193) |
| 2022-11-22 11:46:17 +0100 | <dminuoso> | If performance was relevant, I guess I would generally favour CSR on mutable buffers. |
| 2022-11-22 11:46:31 +0100 | <dminuoso> | Much improved locality of reference |
| 2022-11-22 11:46:31 +0100 | <merijn> | I mean, this is all just random guess work and fairly pointless |
| 2022-11-22 11:48:29 +0100 | <mauke> | let graph = (); insert vertex graph = () |
| 2022-11-22 11:48:32 +0100 | <mauke> | technically O(1) |
| 2022-11-22 11:49:53 +0100 | Guest7579 | (~Guest75@178.141.130.118) |
| 2022-11-22 11:50:33 +0100 | <Guest7579> | Hello. On Hoogle, is it possible to find usage examples of a particular function, provided name and signature? e.g. runParser :: DynFlags -> Parser a -> String -> ParseOutput a |
| 2022-11-22 11:50:58 +0100 | <mauke> | I don't think so |
| 2022-11-22 11:51:06 +0100 | <merijn> | Depends if the author wrote any :p |
| 2022-11-22 11:51:18 +0100 | <merijn> | Oh, wait, you mean like packages that use that code? |
| 2022-11-22 11:51:25 +0100 | <Guest7579> | say yes |
| 2022-11-22 11:51:26 +0100 | karolis | (~karolis@78.157.77.235) (Ping timeout: 256 seconds) |
| 2022-11-22 11:51:32 +0100 | <geekosaur> | sounds more like google code search |
| 2022-11-22 11:51:39 +0100 | <merijn> | Probably better luck searching on github |
| 2022-11-22 11:51:40 +0100 | <Guest7579> | aha |
| 2022-11-22 11:51:44 +0100 | Ranhir | (~Ranhir@157.97.53.139) (Ping timeout: 260 seconds) |
| 2022-11-22 11:51:56 +0100 | <geekosaur> | or yes, github |
| 2022-11-22 11:52:23 +0100 | <geekosaur> | hoogle's bvetter at looking for definitions, not so much uses or examples |
| 2022-11-22 11:52:33 +0100 | <geekosaur> | unless the function docs include useful examples |
| 2022-11-22 11:52:49 +0100 | <Guest7579> | Wonder if https://about.sourcegraph.com/ should help |
| 2022-11-22 11:55:02 +0100 | <probie> | But seriously, if you're going to be adding and removing nodes all over the place, `data Graph = Graph { nodes :: Map Node Int, edges :: IntMap IntSet }` is almost certainly adequate if Map<T, List<T> > map = new HashMap<>(); was adequate |
| 2022-11-22 11:56:36 +0100 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 2022-11-22 11:57:06 +0100 | karolis | (~karolis@78.157.77.235) |
| 2022-11-22 11:57:27 +0100 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) |
| 2022-11-22 11:59:54 +0100 | jonathanx | (~jonathan@h-98-128-168-222.NA.cust.bahnhof.se) (Ping timeout: 260 seconds) |
| 2022-11-22 12:03:02 +0100 | sawilagar | (~sawilagar@user/sawilagar) |
| 2022-11-22 12:07:11 +0100 | Ranhir | (~Ranhir@157.97.53.139) |
| 2022-11-22 12:08:06 +0100 | xff0x | (~xff0x@2405:6580:b080:900:9ba0:81b0:6475:533a) |
| 2022-11-22 12:09:24 +0100 | madjestic | (~madjestic@213.208.229.226) |
| 2022-11-22 12:11:09 +0100 | jespada | (~jespada@nmal-24-b2-v4wan-166357-cust1764.vm24.cable.virginm.net) (Quit: My MacBook has gone to sleep. ZZZzzz…) |
| 2022-11-22 12:11:17 +0100 | jinsun | Guest3604 |
| 2022-11-22 12:11:17 +0100 | jinsun__ | (~jinsun@user/jinsun) |
| 2022-11-22 12:11:17 +0100 | Guest3604 | (~jinsun@user/jinsun) (Killed (zirconium.libera.chat (Nickname regained by services))) |
| 2022-11-22 12:11:17 +0100 | jinsun__ | jinsun |
| 2022-11-22 12:11:41 +0100 | jespada | (~jespada@82.36.38.229) |
| 2022-11-22 12:13:21 +0100 | nckx | (~nckx@tobias.gr) (Ping timeout: 256 seconds) |
| 2022-11-22 12:23:23 +0100 | madjestic | (~madjestic@213.208.229.226) (Ping timeout: 246 seconds) |
| 2022-11-22 12:24:23 +0100 | razetime | (~quassel@117.254.34.208) (Ping timeout: 260 seconds) |
| 2022-11-22 12:24:41 +0100 | razetime | (~quassel@117.254.35.248) |
| 2022-11-22 12:25:26 +0100 | Erutuon | (~Erutuon@23-88-131-243.fttp.usinternet.com) (Ping timeout: 256 seconds) |
| 2022-11-22 12:27:36 +0100 | phma | (~phma@2001:5b0:215d:aad8:20ab:f617:f484:4a0d) (Read error: Connection reset by peer) |
| 2022-11-22 12:28:25 +0100 | phma | (phma@2001:5b0:211f:4b08:4055:ac0:eabe:4279) |
| 2022-11-22 12:31:58 +0100 | <Square> | Glad to hear GHC got a wasm backend today. |
| 2022-11-22 12:32:25 +0100 | <Square> | https://www.tweag.io/blog/2022-11-22-wasm-backend-merged-in-ghc/ |
| 2022-11-22 12:32:37 +0100 | ThePlayer | (~ThePlayer@94-21-96-104.pool.digikabel.hu) (Ping timeout: 256 seconds) |
| 2022-11-22 12:33:25 +0100 | <Franciman> | major achievement! |
| 2022-11-22 12:37:49 +0100 | yaroot_ | (~yaroot@p2790051-ipngn7801souka.saitama.ocn.ne.jp) |
| 2022-11-22 12:37:54 +0100 | yaroot | (~yaroot@2400:4052:ac0:d900:1cf4:2aff:fe51:c04c) (Ping timeout: 255 seconds) |
| 2022-11-22 12:37:55 +0100 | yaroot_ | yaroot |
| 2022-11-22 12:41:49 +0100 | yoneda | (~mike@193.206.102.122) |
| 2022-11-22 12:43:19 +0100 | razetime | (~quassel@117.254.35.248) (Ping timeout: 252 seconds) |
| 2022-11-22 12:43:50 +0100 | razetime | (~quassel@117.254.34.137) |
| 2022-11-22 12:48:34 +0100 | zmt01 | (~zmt00@user/zmt00) |
| 2022-11-22 12:50:04 +0100 | chromoblob | (~user@37.113.164.122) |
| 2022-11-22 12:50:25 +0100 | zmt00 | (~zmt00@user/zmt00) (Ping timeout: 260 seconds) |
| 2022-11-22 12:50:34 +0100 | mikoto-chan | (~mikoto-ch@164.5.249.78) |
| 2022-11-22 12:51:25 +0100 | <chreekat> | hell yeah |
| 2022-11-22 12:52:51 +0100 | jespada | (~jespada@82.36.38.229) (Quit: My MacBook has gone to sleep. ZZZzzz…) |
| 2022-11-22 12:54:23 +0100 | son0p | (~ff@2604:3d08:5b7f:5540::604) |
| 2022-11-22 12:54:29 +0100 | karolis | (~karolis@78.157.77.235) (Ping timeout: 246 seconds) |
| 2022-11-22 12:57:28 +0100 | nate4 | (~nate@98.45.169.16) |
| 2022-11-22 12:57:42 +0100 | <dminuoso> | I do wonder, what limitations does the wasm backend impose? Can I use all of ghc-prim with it? |
| 2022-11-22 13:00:05 +0100 | ec | (~ec@gateway/tor-sasl/ec) (Remote host closed the connection) |
| 2022-11-22 13:02:16 +0100 | nate4 | (~nate@98.45.169.16) (Ping timeout: 256 seconds) |
| 2022-11-22 13:02:41 +0100 | Unicorn_Princess | (~Unicorn_P@user/Unicorn-Princess/x-3540542) (Quit: Leaving) |
| 2022-11-22 13:02:44 +0100 | califax | (~califax@user/califx) (Ping timeout: 255 seconds) |
| 2022-11-22 13:04:47 +0100 | jespada | (~jespada@nmal-24-b2-v4wan-166357-cust1764.vm24.cable.virginm.net) |
| 2022-11-22 13:05:45 +0100 | Guest7579 | (~Guest75@178.141.130.118) (Quit: Client closed) |
| 2022-11-22 13:05:55 +0100 | ec | (~ec@gateway/tor-sasl/ec) |
| 2022-11-22 13:08:07 +0100 | califax | (~califax@user/califx) |
| 2022-11-22 13:09:25 +0100 | chromoblob | (~user@37.113.164.122) (Ping timeout: 268 seconds) |
| 2022-11-22 13:14:27 +0100 | califax | (~califax@user/califx) (Remote host closed the connection) |
| 2022-11-22 13:15:00 +0100 | califax | (~califax@user/califx) |
| 2022-11-22 13:18:23 +0100 | jonathanx | (~jonathan@h-98-128-168-222.NA.cust.bahnhof.se) |
| 2022-11-22 13:22:32 +0100 | razetime | (~quassel@117.254.34.137) (Ping timeout: 246 seconds) |
| 2022-11-22 13:23:00 +0100 | razetime | (~quassel@117.193.3.102) |
| 2022-11-22 13:27:05 +0100 | acidjnk_new | (~acidjnk@p200300d6e7137a845929a180a95a2c61.dip0.t-ipconnect.de) |
| 2022-11-22 13:28:12 +0100 | razetime_ | (~quassel@117.193.6.246) |
| 2022-11-22 13:28:20 +0100 | razetime | (~quassel@117.193.3.102) (Ping timeout: 260 seconds) |
| 2022-11-22 13:29:17 +0100 | acidjnk | (~acidjnk@p200300d6e7137a84847a35f477003ced.dip0.t-ipconnect.de) (Ping timeout: 256 seconds) |
| 2022-11-22 13:33:42 +0100 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 2022-11-22 13:33:48 +0100 | <merijn> | dminuoso: "whatever asterius supported", presumably? |
| 2022-11-22 13:34:27 +0100 | <Hecate> | you fools, just ask terrorjack |
| 2022-11-22 13:34:36 +0100 | <Hecate> | we literally have the creator of the backend in our ranks |
| 2022-11-22 13:34:49 +0100 | <geekosaur> | ^ |
| 2022-11-22 13:34:52 +0100 | <dminuoso> | Ah, terrorhack is Cheng Shao? |
| 2022-11-22 13:35:00 +0100 | <Hecate> | aye |
| 2022-11-22 13:36:30 +0100 | <maerwald> | terrorjack is on vacation or so |
| 2022-11-22 13:37:09 +0100 | <dminuoso> | I did talk to him yesterday |
| 2022-11-22 13:38:10 +0100 | pavonia | (~user@user/siracusa) (Read error: Connection reset by peer) |
| 2022-11-22 13:39:01 +0100 | azimut | (~azimut@gateway/tor-sasl/azimut) (Quit: ZNC - https://znc.in) |
| 2022-11-22 13:39:16 +0100 | sammelweis | (~quassel@2601:401:8200:2d4c:bd9:d04c:7f69:eb10) (Quit: No Ping reply in 180 seconds.) |
| 2022-11-22 13:40:14 +0100 | akegalj | (~akegalj@89-172-58-90.adsl.net.t-com.hr) (Ping timeout: 256 seconds) |
| 2022-11-22 13:40:18 +0100 | azimut | (~azimut@gateway/tor-sasl/azimut) |
| 2022-11-22 13:41:12 +0100 | madjestic | (~madjestic@213.208.229.226) |
| 2022-11-22 13:42:24 +0100 | sammelweis | (~quassel@2601:401:8200:2d4c:bd9:d04c:7f69:eb10) |
| 2022-11-22 13:44:02 +0100 | karolis | (~karolis@78.157.77.235) |
| 2022-11-22 13:45:24 +0100 | stiell | (~stiell@gateway/tor-sasl/stiell) (Remote host closed the connection) |
| 2022-11-22 13:46:25 +0100 | madjestic | (~madjestic@213.208.229.226) (Ping timeout: 268 seconds) |
| 2022-11-22 13:47:30 +0100 | stiell | (~stiell@gateway/tor-sasl/stiell) |
| 2022-11-22 13:49:49 +0100 | nckx | (~nckx@tobias.gr) |
| 2022-11-22 13:50:52 +0100 | bitdex | (~bitdex@gateway/tor-sasl/bitdex) (Quit: = "") |
| 2022-11-22 13:53:57 +0100 | CAT_S | (apic@brezn3.muc.ccc.de) (Read error: Connection reset by peer) |
| 2022-11-22 13:54:00 +0100 | jmdaemon | (~jmdaemon@user/jmdaemon) (Ping timeout: 260 seconds) |
| 2022-11-22 13:54:10 +0100 | pavonia | (~user@user/siracusa) |
| 2022-11-22 13:57:04 +0100 | karolis | (~karolis@78.157.77.235) (Remote host closed the connection) |
| 2022-11-22 13:58:00 +0100 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) |
| 2022-11-22 14:01:29 +0100 | stiell | (~stiell@gateway/tor-sasl/stiell) (Remote host closed the connection) |
| 2022-11-22 14:03:53 +0100 | stiell | (~stiell@gateway/tor-sasl/stiell) |
| 2022-11-22 14:06:50 +0100 | stiell | (~stiell@gateway/tor-sasl/stiell) (Remote host closed the connection) |
| 2022-11-22 14:07:28 +0100 | stiell | (~stiell@gateway/tor-sasl/stiell) |
| 2022-11-22 14:09:23 +0100 | chromoblob | (~user@37.113.164.122) |
| 2022-11-22 14:10:36 +0100 | CAT_S | (apic@brezn3.muc.ccc.de) |
| 2022-11-22 14:11:52 +0100 | ec | (~ec@gateway/tor-sasl/ec) (Write error: Connection reset by peer) |
| 2022-11-22 14:11:52 +0100 | FinnElija | (~finn_elij@user/finn-elija/x-0085643) (Write error: Connection reset by peer) |
| 2022-11-22 14:11:52 +0100 | chexum | (~quassel@gateway/tor-sasl/chexum) (Read error: Connection reset by peer) |
| 2022-11-22 14:12:02 +0100 | stiell | (~stiell@gateway/tor-sasl/stiell) (Ping timeout: 255 seconds) |
| 2022-11-22 14:13:41 +0100 | FinnElija | (~finn_elij@user/finn-elija/x-0085643) |
| 2022-11-22 14:13:53 +0100 | chexum | (~quassel@gateway/tor-sasl/chexum) |
| 2022-11-22 14:14:49 +0100 | stiell | (~stiell@gateway/tor-sasl/stiell) |
| 2022-11-22 14:15:17 +0100 | jinsun__ | (~jinsun@user/jinsun) |
| 2022-11-22 14:15:17 +0100 | jinsun | Guest1009 |
| 2022-11-22 14:15:17 +0100 | Guest1009 | (~jinsun@user/jinsun) (Killed (sodium.libera.chat (Nickname regained by services))) |
| 2022-11-22 14:15:17 +0100 | jinsun__ | jinsun |
| 2022-11-22 14:21:24 +0100 | ec | (~ec@gateway/tor-sasl/ec) |
| 2022-11-22 14:21:25 +0100 | jrm | (~jrm@user/jrm) (Read error: Connection reset by peer) |
| 2022-11-22 14:21:44 +0100 | jrm | (~jrm@user/jrm) |
| 2022-11-22 14:24:08 +0100 | shriekingnoise | (~shrieking@186.137.167.202) |
| 2022-11-22 14:28:56 +0100 | ec | (~ec@gateway/tor-sasl/ec) (Remote host closed the connection) |
| 2022-11-22 14:29:47 +0100 | ec | (~ec@gateway/tor-sasl/ec) |
| 2022-11-22 14:34:18 +0100 | use-value | (~Thunderbi@2a00:23c6:8a03:2f01:38e4:6025:87e4:a8aa) (Remote host closed the connection) |
| 2022-11-22 14:34:37 +0100 | use-value | (~Thunderbi@2a00:23c6:8a03:2f01:38e4:6025:87e4:a8aa) |
| 2022-11-22 14:35:02 +0100 | <accord> | Is the link between lazy evaluation and copy-on-write mutation well known? |
| 2022-11-22 14:36:54 +0100 | InstX1 | (~Liam@2601:6c4:4081:54f0:148c:5793:51b7:46e1) (Ping timeout: 256 seconds) |
| 2022-11-22 14:37:59 +0100 | <dminuoso> | What link are you referring to, accord? |
| 2022-11-22 14:38:20 +0100 | <accord> | dminuoso: it's basically part of the same model, it seems to me. |
| 2022-11-22 14:38:27 +0100 | <accord> | dminuoso: compute-on-read and copy-on-write |
| 2022-11-22 14:38:29 +0100 | <dminuoso> | I do not see how. Can you explain? |
| 2022-11-22 14:38:40 +0100 | <accord> | modify-on-read, and replicate-on-write |
| 2022-11-22 14:38:49 +0100 | <accord> | Read and Write are mirror operations. |
| 2022-11-22 14:39:07 +0100 | <accord> | Reading modifies the reader, the thing they read is written to them |
| 2022-11-22 14:39:23 +0100 | <accord> | Reading is also copying. You copy a book you read in your memory basically |
| 2022-11-22 14:39:54 +0100 | <accord> | Systems of lazy evaluation naturally are capable of deferring commands. |
| 2022-11-22 14:40:03 +0100 | <accord> | Including to copy physically a result in memory for example |
| 2022-11-22 14:40:16 +0100 | <dminuoso> | The only thing I had to think of when you mentioned it, is that Clean does a kind of inverted copy-on-write. |
| 2022-11-22 14:40:28 +0100 | <dminuoso> | But it is not necessarily related to lazyness |
| 2022-11-22 14:40:41 +0100 | <accord> | dminuoso: Clean deduplicates and interns data yes? |
| 2022-11-22 14:41:04 +0100 | <dminuoso> | No rather, when clean detects there are no duplicate references, it will switch to in-place mutations. |
| 2022-11-22 14:41:14 +0100 | <dminuoso> | It uses its type system to guarantee this is safe |
| 2022-11-22 14:42:14 +0100 | <accord> | Ah |
| 2022-11-22 14:42:31 +0100 | <dminuoso> | So it is a kind of inversion of copy-on-write. |
| 2022-11-22 14:42:33 +0100 | opticblast | (~Thunderbi@secure-165.caltech.edu) (Read error: Connection reset by peer) |
| 2022-11-22 14:42:52 +0100 | opticblast | (~Thunderbi@secure-165.caltech.edu) |
| 2022-11-22 14:43:09 +0100 | <dminuoso> | accord: I just dont see any connection between call-by-name and copy-on-write. |
| 2022-11-22 14:43:28 +0100 | <dminuoso> | Other than some vague similarity if you squint really hard |
| 2022-11-22 14:44:12 +0100 | <accord> | dminuoso: I'm implementing a runtime, and I noticed it's basically the same thing. Unexpectedly for myself as well |
| 2022-11-22 14:44:24 +0100 | <accord> | dminuoso: from different perspectives though |
| 2022-11-22 14:44:46 +0100 | <dminuoso> | Not sure what "same thing from different perspectives" means |
| 2022-11-22 14:45:38 +0100 | <opqdonut> | laziness is a good match with immutability, and copy-on-write is an implementation technique for immutability (often called path copying in that context) |
| 2022-11-22 14:45:43 +0100 | <accord> | dminuoso: do you know continuations passing style |
| 2022-11-22 14:46:05 +0100 | <accord> | opqdonut: yes |
| 2022-11-22 14:46:16 +0100 | <dminuoso> | The one thing they have in common, is merely "a deferred action" |
| 2022-11-22 14:46:20 +0100 | <dminuoso> | But that's not much of a commonality |
| 2022-11-22 14:46:35 +0100 | <accord> | Deferred action sure, that's a big part. |
| 2022-11-22 14:47:21 +0100 | <dminuoso> | One is a space optimization technique, the other is an implementation of an evaluation model |
| 2022-11-22 14:47:26 +0100 | jonathanx | (~jonathan@h-98-128-168-222.NA.cust.bahnhof.se) (Remote host closed the connection) |
| 2022-11-22 14:47:43 +0100 | jonathanx | (~jonathan@h-98-128-168-222.NA.cust.bahnhof.se) |
| 2022-11-22 14:48:18 +0100 | stiell | (~stiell@gateway/tor-sasl/stiell) (Remote host closed the connection) |
| 2022-11-22 14:48:56 +0100 | <accord> | dminuoso: lazy eval aims to skip unnecesary computation. copy on-write aims to skip unnecessary allocation. |
| 2022-11-22 14:49:04 +0100 | stiell | (~stiell@gateway/tor-sasl/stiell) |
| 2022-11-22 14:49:05 +0100 | ccapndave | (~ccapndave@xcpe-62-167-164-99.cgn.res.adslplus.ch) |
| 2022-11-22 14:49:07 +0100 | <accord> | It's the good old space-time dichotomy. Lazy eval saves TIME at the expense of more SPACE. And copy-on-write saves SPACE at the expense of more TIME to read from such structures. |
| 2022-11-22 14:49:28 +0100 | <dminuoso> | lazy eval does not necessarily need more space. it can easily also save space. |
| 2022-11-22 14:49:40 +0100 | razetime_ | (~quassel@117.193.6.246) (Ping timeout: 248 seconds) |
| 2022-11-22 14:49:43 +0100 | <dminuoso> | consider something like `repeat 1`, its quite space efficient. |
| 2022-11-22 14:50:18 +0100 | <dminuoso> | well its even space efficient for two reasons, but even without tying the knot, lazyness would defer the space usage until consumption |
| 2022-11-22 14:50:24 +0100 | razetime | (~quassel@117.193.0.25) |
| 2022-11-22 14:51:11 +0100 | <accord> | dminuoso: right |
| 2022-11-22 14:51:21 +0100 | <dminuoso> | Also, COW does not cost more time to read from such structures. |
| 2022-11-22 14:51:35 +0100 | <dminuoso> | It does however impose an additional cost on first modification. |
| 2022-11-22 14:51:38 +0100 | lucerne | (~lucerne@5.116.75.203) (Ping timeout: 256 seconds) |
| 2022-11-22 14:51:44 +0100 | <dminuoso> | That is, with COW the first modification can be very expensive |
| 2022-11-22 14:52:19 +0100 | coot | (~coot@2a02:a310:e241:1b00:ec1a:e9df:79ac:66ba) (Quit: coot) |
| 2022-11-22 14:52:27 +0100 | <dminuoso> | Well I guess it does have some impact on things like TLB and regular cache hierarchy as well, but its hard to quantify that. |
| 2022-11-22 14:52:45 +0100 | sammelweis | (~quassel@2601:401:8200:2d4c:bd9:d04c:7f69:eb10) (Ping timeout: 252 seconds) |
| 2022-11-22 14:53:14 +0100 | sammelweis | (~quassel@2601:401:8200:2d4c:bd9:d04c:7f69:eb10) |
| 2022-11-22 14:55:29 +0100 | califax | (~califax@user/califx) (Quit: ZNC 1.8.2 - https://znc.in) |
| 2022-11-22 14:55:46 +0100 | razetime | (~quassel@117.193.0.25) (Read error: Connection reset by peer) |
| 2022-11-22 14:56:22 +0100 | Inst | (~Liam@c-98-208-218-119.hsd1.fl.comcast.net) |
| 2022-11-22 14:56:29 +0100 | califax | (~califax@user/califx) |
| 2022-11-22 14:56:32 +0100 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 2022-11-22 14:57:11 +0100 | <accord> | dminuoso: COW defers space allocation, and lazy eval defers temporal allocation (execution time) |
| 2022-11-22 14:58:19 +0100 | raehik | (~raehik@cpc95906-rdng25-2-0-cust156.15-3.cable.virginm.net) |
| 2022-11-22 14:59:16 +0100 | <dminuoso> | accord: If I had to compare similar things, there's something between lazyness and demand paging. |
| 2022-11-22 14:59:21 +0100 | <dminuoso> | With COW I just dont see it. |
| 2022-11-22 14:59:35 +0100 | <dminuoso> | (i.e. demand paging is lazy memory allocation) |
| 2022-11-22 14:59:38 +0100 | <accord> | dminuoso: space and time, don't you see them as two sides of the same coin |
| 2022-11-22 14:59:59 +0100 | <dminuoso> | Physically I see them as the same side of the coin. :p |
| 2022-11-22 15:00:00 +0100 | razetime | (~quassel@117.193.2.181) |
| 2022-11-22 15:00:06 +0100 | <accord> | Neat |
| 2022-11-22 15:00:50 +0100 | <accord> | dminuoso: say like 10 construction workers build 1 house in 10 days. How long it takes 2 workers... 50 days. Well that's naive of course, but approximately correct. |
| 2022-11-22 15:01:08 +0100 | <accord> | Space/time tradeoffs are so common |
| 2022-11-22 15:01:17 +0100 | <accord> | Space and time are the same in a way |
| 2022-11-22 15:01:23 +0100 | <accord> | Space is a dimension of time. |
| 2022-11-22 15:01:34 +0100 | <dminuoso> | Comparing two things on the basis there is some space/time tradeoff involved in both does not seem useful. |
| 2022-11-22 15:01:49 +0100 | <accord> | It's useful in order to realize what space and time are. |
| 2022-11-22 15:01:59 +0100 | dminuoso | shrugs |
| 2022-11-22 15:03:28 +0100 | <accord> | dminuoso: what do you think space and time are |
| 2022-11-22 15:04:23 +0100 | <geekosaur> | aspects of program execution that only sometimes have a relationship and rarely have a simplistic "tradeoff" one |
| 2022-11-22 15:04:45 +0100 | <dminuoso> | streaming too is a space optimization technique, it defers/interleaves allocation/computation into the future. but that does not make it useful to look really hard for a connection between lazyness and streaming |
| 2022-11-22 15:05:03 +0100 | <dminuoso> | mostly because these things occur in different universes |
| 2022-11-22 15:05:26 +0100 | <dminuoso> | one is part of the execution model (or even semantic model), the other is some implementation style |
| 2022-11-22 15:05:58 +0100 | razetime | (~quassel@117.193.2.181) (Ping timeout: 268 seconds) |
| 2022-11-22 15:06:11 +0100 | razetime | (~quassel@117.254.35.59) |
| 2022-11-22 15:06:50 +0100 | ccapndave | (~ccapndave@xcpe-62-167-164-99.cgn.res.adslplus.ch) (Quit: My MacBook has gone to sleep. ZZZzzz…) |
| 2022-11-22 15:07:17 +0100 | <dminuoso> | I do not know of a framework that lets express and analyze both at the same time. Say we could look into category theory, but we dont even know what category we want to construct, let alone how to express these two things in the category theory, or what properties to look for.. |
| 2022-11-22 15:08:28 +0100 | califax | (~califax@user/califx) (Remote host closed the connection) |
| 2022-11-22 15:08:53 +0100 | dsrt^ | (~dsrt@76.145.185.103) (Remote host closed the connection) |
| 2022-11-22 15:09:46 +0100 | <accord> | dminuoso: streaming is the same as lazy eval |
| 2022-11-22 15:09:48 +0100 | califax | (~califax@user/califx) |
| 2022-11-22 15:09:52 +0100 | <dminuoso> | No it is not. |
| 2022-11-22 15:09:57 +0100 | <accord> | How |
| 2022-11-22 15:10:09 +0100 | <dminuoso> | One is an implementation of an evaluation strategy of the programming language, the other is something you do with that programming language. |
| 2022-11-22 15:10:38 +0100 | <dminuoso> | While you can do *some* streaming with lazy evaluation, it is extremely limiting. |
| 2022-11-22 15:10:38 +0100 | o-90 | (~o-90@gateway/tor-sasl/o-90) |
| 2022-11-22 15:10:40 +0100 | <accord> | One is what one side does to gradually expose a result. The other is what the other side does to gradually read the same result |
| 2022-11-22 15:11:00 +0100 | <dminuoso> | I think your pattern matching goggles is set too coarse. |
| 2022-11-22 15:11:14 +0100 | <accord> | Yes, but I have a reason to have set my goggles like that |
| 2022-11-22 15:11:23 +0100 | <accord> | You CPU executes a stream of commands |
| 2022-11-22 15:11:33 +0100 | <accord> | All execution is a stream. Sequences are key to execution |
| 2022-11-22 15:11:55 +0100 | rembo10 | (~rembo10@main.remulis.com) (Quit: ZNC 1.8.2 - https://znc.in) |
| 2022-11-22 15:12:07 +0100 | <accord> | And execution is a pipeline. |
| 2022-11-22 15:12:15 +0100 | ccapndave | (~ccapndave@xcpe-62-167-164-99.cgn.res.adslplus.ch) |
| 2022-11-22 15:12:15 +0100 | <accord> | It flatmaps one sequence to another sequence. |
| 2022-11-22 15:12:43 +0100 | o-90 | (~o-90@gateway/tor-sasl/o-90) (Client Quit) |
| 2022-11-22 15:13:07 +0100 | <accord> | Everything fits that definition |
| 2022-11-22 15:13:21 +0100 | <accord> | Kinda monadic |
| 2022-11-22 15:13:36 +0100 | AlexNoo_ | (~AlexNoo@178.34.163.201) |
| 2022-11-22 15:14:06 +0100 | rembo10 | (~rembo10@main.remulis.com) |
| 2022-11-22 15:15:07 +0100 | stiell | (~stiell@gateway/tor-sasl/stiell) (Remote host closed the connection) |
| 2022-11-22 15:17:08 +0100 | AlexNoo | (~AlexNoo@178.34.160.146) (Ping timeout: 256 seconds) |
| 2022-11-22 15:17:08 +0100 | stiell | (~stiell@gateway/tor-sasl/stiell) |
| 2022-11-22 15:17:30 +0100 | coot | (~coot@213.134.171.3) |
| 2022-11-22 15:21:53 +0100 | razetime_ | (~quassel@117.254.35.67) |
| 2022-11-22 15:22:00 +0100 | razetime | (~quassel@117.254.35.59) (Ping timeout: 268 seconds) |
| 2022-11-22 15:23:00 +0100 | AlexNoo_ | AlexNoo |
| 2022-11-22 15:23:26 +0100 | eggplantade | (~Eggplanta@2600:1700:38c5:d800:5866:96fb:16f6:58d1) |
| 2022-11-22 15:23:53 +0100 | chexum | (~quassel@gateway/tor-sasl/chexum) (Quit: No Ping reply in 180 seconds.) |
| 2022-11-22 15:27:22 +0100 | chexum | (~quassel@gateway/tor-sasl/chexum) |
| 2022-11-22 15:27:39 +0100 | ChaiTRex | (~ChaiTRex@user/chaitrex) (Remote host closed the connection) |
| 2022-11-22 15:27:55 +0100 | eggplantade | (~Eggplanta@2600:1700:38c5:d800:5866:96fb:16f6:58d1) (Ping timeout: 260 seconds) |
| 2022-11-22 15:28:28 +0100 | razetime_ | (~quassel@117.254.35.67) (Ping timeout: 256 seconds) |
| 2022-11-22 15:28:31 +0100 | razetime | (~quassel@117.254.34.219) |
| 2022-11-22 15:30:21 +0100 | Alex_test | (~al_test@178.34.163.201) |
| 2022-11-22 15:32:59 +0100 | kenran | (~user@user/kenran) |
| 2022-11-22 15:34:01 +0100 | Alex_test | (~al_test@178.34.163.201) (Quit: ;-) |
| 2022-11-22 15:35:02 +0100 | kenran | (~user@user/kenran) (Remote host closed the connection) |
| 2022-11-22 15:35:56 +0100 | Alex_test | (~al_test@178.34.163.201) |
| 2022-11-22 15:36:07 +0100 | Alex_test | (~al_test@178.34.163.201) (Client Quit) |
| 2022-11-22 15:36:38 +0100 | Alex_test | (~al_test@178.34.163.201) |
| 2022-11-22 15:37:36 +0100 | jakalx | (~jakalx@base.jakalx.net) () |
| 2022-11-22 15:40:34 +0100 | AlexZenon | (~alzenon@178.34.163.201) |
| 2022-11-22 15:45:04 +0100 | jakalx | (~jakalx@base.jakalx.net) |
| 2022-11-22 15:53:31 +0100 | ChaiTRex | (~ChaiTRex@user/chaitrex) |
| 2022-11-22 15:59:36 +0100 | L29Ah | (~L29Ah@wikipedia/L29Ah) (Read error: Connection reset by peer) |
| 2022-11-22 16:00:48 +0100 | L29Ah | (~L29Ah@wikipedia/L29Ah) |
| 2022-11-22 16:01:21 +0100 | Sgeo | (~Sgeo@user/sgeo) |
| 2022-11-22 16:11:34 +0100 | <accord> | It's weird how with lazy eval you can first get the output of something, and then provide the input that produces it |
| 2022-11-22 16:14:44 +0100 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) |
| 2022-11-22 16:18:55 +0100 | sayola1 | (~sayola@dslb-088-064-186-217.088.064.pools.vodafone-ip.de) (Quit: Leaving.) |
| 2022-11-22 16:19:49 +0100 | <dminuoso> | Except its not really true. |
| 2022-11-22 16:20:41 +0100 | jonathanx | (~jonathan@h-98-128-168-222.NA.cust.bahnhof.se) (Ping timeout: 246 seconds) |
| 2022-11-22 16:20:51 +0100 | waleee | (~waleee@2001:9b0:213:7200:cc36:a556:b1e8:b340) |
| 2022-11-22 16:22:21 +0100 | <dminuoso> | accord: Do you have a particular example? |
| 2022-11-22 16:22:31 +0100 | acidjnk_new | (~acidjnk@p200300d6e7137a845929a180a95a2c61.dip0.t-ipconnect.de) (Ping timeout: 252 seconds) |
| 2022-11-22 16:23:33 +0100 | jonathanx | (~jonathan@h-98-128-168-222.NA.cust.bahnhof.se) |
| 2022-11-22 16:24:25 +0100 | razetime | (~quassel@117.254.34.219) (Quit: https://quassel-irc.org - Chat comfortably. Anywhere.) |
| 2022-11-22 16:27:48 +0100 | ubert1 | (~Thunderbi@178.165.183.156.wireless.dyn.drei.com) (Ping timeout: 248 seconds) |
| 2022-11-22 16:28:00 +0100 | merijn | (~merijn@c-001-001-017.client.esciencecenter.eduvpn.nl) (Ping timeout: 260 seconds) |
| 2022-11-22 16:28:32 +0100 | `2jt | (~jtomas@191.red-88-17-199.dynamicip.rima-tde.net) |
| 2022-11-22 16:31:39 +0100 | sayola | (~sayola@dslb-088-064-186-217.088.064.pools.vodafone-ip.de) |
| 2022-11-22 16:31:57 +0100 | L29Ah | (~L29Ah@wikipedia/L29Ah) (Read error: Connection reset by peer) |
| 2022-11-22 16:32:09 +0100 | ec | (~ec@gateway/tor-sasl/ec) (Remote host closed the connection) |
| 2022-11-22 16:32:18 +0100 | L29Ah | (~L29Ah@wikipedia/L29Ah) |
| 2022-11-22 16:35:39 +0100 | ec | (~ec@gateway/tor-sasl/ec) |
| 2022-11-22 16:39:06 +0100 | ubert1 | (~Thunderbi@178.165.183.156.wireless.dyn.drei.com) |
| 2022-11-22 16:41:40 +0100 | pavonia | (~user@user/siracusa) (Quit: Bye!) |
| 2022-11-22 16:44:01 +0100 | beteigeuze | (~Thunderbi@a79-169-109-107.cpe.netcabo.pt) |
| 2022-11-22 16:45:02 +0100 | azimut | (~azimut@gateway/tor-sasl/azimut) (Ping timeout: 255 seconds) |
| 2022-11-22 16:45:24 +0100 | mvk | (~mvk@2607:fea8:5ce3:8500::efb) |
| 2022-11-22 16:45:33 +0100 | azimut | (~azimut@gateway/tor-sasl/azimut) |
| 2022-11-22 16:45:43 +0100 | notzmv | (~zmv@user/notzmv) (Remote host closed the connection) |
| 2022-11-22 16:45:46 +0100 | mvk | (~mvk@2607:fea8:5ce3:8500::efb) (Client Quit) |
| 2022-11-22 16:46:20 +0100 | jao | (~jao@cpc103048-sgyl39-2-0-cust502.18-2.cable.virginm.net) |
| 2022-11-22 16:48:44 +0100 | ccapndave | (~ccapndave@xcpe-62-167-164-99.cgn.res.adslplus.ch) (Quit: My MacBook has gone to sleep. ZZZzzz…) |
| 2022-11-22 16:48:57 +0100 | Guest33 | (~Guest33@ext-1-087.eduroam.chalmers.se) |
| 2022-11-22 16:49:08 +0100 | <Guest33> | Is there a way to block any exception from reaching a process? |
| 2022-11-22 16:49:25 +0100 | ccapndave | (~ccapndave@xcpe-62-167-164-99.cgn.res.adslplus.ch) |
| 2022-11-22 16:51:14 +0100 | <dminuoso> | What is a `process` to you? |
| 2022-11-22 16:51:41 +0100 | <Guest33> | `forkIO $ zthe-process>` |
| 2022-11-22 16:52:15 +0100 | <dminuoso> | Guest33: Can you explain the problem you are having? |
| 2022-11-22 16:52:44 +0100 | <dminuoso> | Im asking because there's a few different tools relating to exceptions, but the right choice depends on what you're trying to accomplish |
| 2022-11-22 16:53:12 +0100 | <Guest33> | `ma `catch` (\some-exception -> do this-must-happen-atomically >> further-exceptions-are-fine-here)` |
| 2022-11-22 16:53:28 +0100 | <Guest33> | I had a guess that `mask` might work, but it did not. |
| 2022-11-22 16:53:58 +0100 | <dminuoso> | Okay, so mask can be pierced by so called interruptilbe operations. |
| 2022-11-22 16:54:07 +0100 | <dminuoso> | mask should have better been called almostButNotQuiteMask |
| 2022-11-22 16:54:21 +0100 | <dminuoso> | Guest33: can you share the exact code here? |
| 2022-11-22 16:54:42 +0100 | <dminuoso> | because again, there may be different things wrong here. |
| 2022-11-22 16:54:52 +0100 | <Guest33> | It is a bit contrived, so I don't think it would do anyone any good. I am using `throwTo` to throw a custom exception from one thread to another |
| 2022-11-22 16:55:01 +0100 | <dminuoso> | Do show contrived code |
| 2022-11-22 16:56:24 +0100 | <Guest33> | ``` |
| 2022-11-22 16:56:25 +0100 | <Guest33> | reports <- catches (sequence (map (flip putMVar ()) barriers) >> sequence (map takeMVar results)) |
| 2022-11-22 16:56:25 +0100 | <Guest33> | [ Handler $ \UserInterrupt -> do sequence $ map (flip throwTo UserInterrupt) tids |
| 2022-11-22 16:56:26 +0100 | <Guest33> | sequence $ map takeMVar results |
| 2022-11-22 16:56:26 +0100 | <Guest33> | , Handler $ \(ConcurrentAbort tid) -> do sequence $ map (flip throwTo (ConcurrentAbort pid)) (filter ((/=) tid) tids) |
| 2022-11-22 16:56:27 +0100 | <Guest33> | sequence $ map takeMVar results |
| 2022-11-22 16:56:27 +0100 | <Guest33> | ] |
| 2022-11-22 16:56:28 +0100 | <Guest33> | ``` |
| 2022-11-22 16:56:32 +0100 | <Guest33> | Hm the formatting never fired |
| 2022-11-22 16:56:36 +0100 | <dminuoso> | Use https://paste.tomsmeding.com next time |
| 2022-11-22 16:56:44 +0100 | <dminuoso> | Pasting large chunks can get you kicked off the IRC network |
| 2022-11-22 16:56:51 +0100 | <Guest33> | Ah, I did not know that |
| 2022-11-22 16:57:01 +0100 | <geekosaur> | and IRC doesn't do formatting |
| 2022-11-22 16:57:23 +0100 | <Guest33> | Honestly, I thought it could handle it, because it `sometimes` formats stuff :P |
| 2022-11-22 16:57:37 +0100 | <dminuoso> | Your client probably does. |
| 2022-11-22 16:57:43 +0100 | <geekosaur> | some clients do, up to a point |
| 2022-11-22 16:57:53 +0100 | <geekosaur> | but all bets are off with multiline stuff |
| 2022-11-22 16:58:05 +0100 | <Guest33> | Ah this makes sense, thanks for clarifying |
| 2022-11-22 16:58:12 +0100 | <dminuoso> | Guest33: alright, where did you try to mask? |
| 2022-11-22 16:58:52 +0100 | eggplantade | (~Eggplanta@104-55-37-220.lightspeed.sntcca.sbcglobal.net) |
| 2022-11-22 16:58:54 +0100 | <dminuoso> | Guest33: And also, you probably want to use STM instead of exceptoins + mask + mvars. |
| 2022-11-22 16:58:58 +0100 | nate4 | (~nate@98.45.169.16) |
| 2022-11-22 16:59:06 +0100 | <Guest33> | In the handler for `ConcurrentAbort`, I tried to mask the expression `sequence $ map (flip throwTo (ConcurrentAbort pid)) (filter ((/=) tid) tids) |
| 2022-11-22 16:59:10 +0100 | ccapndave | (~ccapndave@xcpe-62-167-164-99.cgn.res.adslplus.ch) (Quit: My MacBook has gone to sleep. ZZZzzz…) |
| 2022-11-22 16:59:15 +0100 | <dminuoso> | Yeah just use STM instead of all of this. |
| 2022-11-22 16:59:22 +0100 | <Guest33> | I need this to happen in IO |
| 2022-11-22 16:59:34 +0100 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 2022-11-22 16:59:36 +0100 | merijn | (~merijn@c-001-001-017.client.esciencecenter.eduvpn.nl) |
| 2022-11-22 16:59:48 +0100 | <dminuoso> | Still |
| 2022-11-22 16:59:54 +0100 | ccapndave | (~ccapndave@xcpe-62-167-164-99.cgn.res.adslplus.ch) |
| 2022-11-22 17:00:01 +0100 | <dminuoso> | You can set up the thread action in STM, and when it completes you run the IO action |
| 2022-11-22 17:00:09 +0100 | snek | (sid280155@id-280155.lymington.irccloud.com) |
| 2022-11-22 17:00:13 +0100 | <snek> | is there a way to resolve dependency conflicts with cabal? |
| 2022-11-22 17:00:16 +0100 | <dminuoso> | something like `atomically (waitForCondition ...) >> doIOThing` |
| 2022-11-22 17:00:19 +0100 | ccapndave | (~ccapndave@xcpe-62-167-164-99.cgn.res.adslplus.ch) (Client Quit) |
| 2022-11-22 17:00:26 +0100 | <dminuoso> | snek: Uh sure. |
| 2022-11-22 17:00:30 +0100 | <dminuoso> | snek: What conflict do you have? |
| 2022-11-22 17:01:01 +0100 | <snek> | attoparsec depends on scientific depends on integer-logarithms depends on ghc-prim<0.10 but i have ghc-prim==0.10 installed |
| 2022-11-22 17:01:32 +0100 | Guest33 | (~Guest33@ext-1-087.eduroam.chalmers.se) (Quit: Connection closed) |
| 2022-11-22 17:02:16 +0100 | lortabac | (~lortabac@2a01:e0a:541:b8f0:77f5:99bc:10c3:3c4c) (Quit: WeeChat 2.8) |
| 2022-11-22 17:02:28 +0100 | <dminuoso> | Is that GHC master? |
| 2022-11-22 17:02:43 +0100 | <snek> | basically yeah |
| 2022-11-22 17:03:01 +0100 | <sclv> | in this case i would use the --allow-newer flag |
| 2022-11-22 17:03:27 +0100 | <sclv> | because likely integer-logarithms can work with a newer prim, but it hasn't been tested with it, on account of it is not yet released |
| 2022-11-22 17:03:49 +0100 | nate4 | (~nate@98.45.169.16) (Ping timeout: 260 seconds) |
| 2022-11-22 17:03:51 +0100 | <sclv> | generally if you're working on ghc master, lots of libs will have conflicting bounds against it |
| 2022-11-22 17:03:53 +0100 | <snek> | oh that flag seems perfect |
| 2022-11-22 17:03:55 +0100 | <dminuoso> | At the same time its unlikely to get it in before GHC 9.6 has been released, since there could be future breakage. |
| 2022-11-22 17:04:06 +0100 | <dminuoso> | snek: You can also vendor integer-logarithms and bump the bound |
| 2022-11-22 17:04:12 +0100 | <dminuoso> | That will be more stable at the cost of more work |
| 2022-11-22 17:04:34 +0100 | <sclv> | note that in general if you're working against GHC head you can point at https://ghc.gitlab.haskell.org/head.hackage/ |
| 2022-11-22 17:04:45 +0100 | lucerne | (~lucerne@5.113.148.245) |
| 2022-11-22 17:04:48 +0100 | <sclv> | and often that'll have temp-patches for lots of nonupdated packages |
| 2022-11-22 17:05:30 +0100 | <dminuoso> | That particular package has no patch available though |
| 2022-11-22 17:05:37 +0100 | acidjnk_new | (~acidjnk@p200300d6e7137a175929a180a95a2c61.dip0.t-ipconnect.de) |
| 2022-11-22 17:05:38 +0100 | <sclv> | yep :-/ |
| 2022-11-22 17:05:53 +0100 | <dminuoso> | But I guess you could make a pull request on that one |
| 2022-11-22 17:05:54 +0100 | azimut | (~azimut@gateway/tor-sasl/azimut) (Remote host closed the connection) |
| 2022-11-22 17:06:30 +0100 | ccapndave | (~ccapndave@xcpe-62-167-164-99.cgn.res.adslplus.ch) |
| 2022-11-22 17:06:44 +0100 | azimut | (~azimut@gateway/tor-sasl/azimut) |
| 2022-11-22 17:08:10 +0100 | azimut | (~azimut@gateway/tor-sasl/azimut) (Remote host closed the connection) |
| 2022-11-22 17:08:44 +0100 | azimut | (~azimut@gateway/tor-sasl/azimut) |
| 2022-11-22 17:10:12 +0100 | eggplantade | (~Eggplanta@104-55-37-220.lightspeed.sntcca.sbcglobal.net) (Remote host closed the connection) |
| 2022-11-22 17:10:15 +0100 | ccapndave | (~ccapndave@xcpe-62-167-164-99.cgn.res.adslplus.ch) (Client Quit) |
| 2022-11-22 17:10:39 +0100 | mei__ | (~mei@user/mei) (Quit: mei__) |
| 2022-11-22 17:10:58 +0100 | mei | (~mei@user/mei) |
| 2022-11-22 17:12:06 +0100 | ccapndave | (~ccapndave@xcpe-62-167-164-99.cgn.res.adslplus.ch) |
| 2022-11-22 17:12:08 +0100 | waleee | (~waleee@2001:9b0:213:7200:cc36:a556:b1e8:b340) (Ping timeout: 246 seconds) |
| 2022-11-22 17:12:39 +0100 | cfricke | (~cfricke@user/cfricke) (Quit: WeeChat 3.7.1) |
| 2022-11-22 17:13:29 +0100 | hrberg | (~quassel@171.79-160-161.customer.lyse.net) (Quit: https://quassel-irc.org - Chat comfortably. Anywhere.) |
| 2022-11-22 17:13:48 +0100 | hrberg | (~quassel@171.79-160-161.customer.lyse.net) |
| 2022-11-22 17:15:19 +0100 | hrberg | (~quassel@171.79-160-161.customer.lyse.net) (Client Quit) |
| 2022-11-22 17:15:38 +0100 | hrberg | (~quassel@171.79-160-161.customer.lyse.net) |
| 2022-11-22 17:20:31 +0100 | __monty__ | (~toonn@user/toonn) (Quit: leaving) |
| 2022-11-22 17:21:51 +0100 | Guest75 | (~Guest75@178.141.130.118) |
| 2022-11-22 17:25:13 +0100 | yuribarros | (~Srain@2804:14c:65e4:865c::1000) (Ping timeout: 252 seconds) |
| 2022-11-22 17:26:34 +0100 | <AdamConner-Sax[m> | @snek You can also use a cabal.project file and put more specific "allow-newer" instructions in there. That can be helpful if you eventually want to drop the flag since you can keep narrowing the set. |
| 2022-11-22 17:26:34 +0100 | <lambdabot> | I haven't seen You. |
| 2022-11-22 17:29:15 +0100 | merijn | (~merijn@c-001-001-017.client.esciencecenter.eduvpn.nl) (Ping timeout: 260 seconds) |
| 2022-11-22 17:30:13 +0100 | azimut | (~azimut@gateway/tor-sasl/azimut) (Remote host closed the connection) |
| 2022-11-22 17:30:49 +0100 | azimut | (~azimut@gateway/tor-sasl/azimut) |
| 2022-11-22 17:32:37 +0100 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) |
| 2022-11-22 17:35:03 +0100 | titibandit | (~titibandi@xdsl-78-34-153-165.nc.de) |
| 2022-11-22 17:35:46 +0100 | ccapndave | (~ccapndave@xcpe-62-167-164-99.cgn.res.adslplus.ch) (Quit: My MacBook has gone to sleep. ZZZzzz…) |
| 2022-11-22 17:36:25 +0100 | eggplantade | (~Eggplanta@2600:1700:38c5:d800:5866:96fb:16f6:58d1) |
| 2022-11-22 17:38:40 +0100 | ccapndave | (~ccapndave@xcpe-62-167-164-99.cgn.res.adslplus.ch) |
| 2022-11-22 17:40:50 +0100 | Inst_ | (~Inst@2601:6c4:4081:54f0:681d:b835:8895:3ea8) |
| 2022-11-22 17:41:12 +0100 | <Inst_> | ugh, FML |
| 2022-11-22 17:41:29 +0100 | <Inst_> | I have three parts of my program that either don't work or I'm unsure as to whether it works |
| 2022-11-22 17:42:19 +0100 | <Inst_> | the calculator for removed cards, the generator for maps (doesn't work), and the calculator that uses stuff from the maps (doesn't work) |
| 2022-11-22 17:42:54 +0100 | <Inst_> | guess I have to learn stack and accelerate now |
| 2022-11-22 17:43:03 +0100 | Inst | (~Liam@c-98-208-218-119.hsd1.fl.comcast.net) (Killed (NickServ (GHOST command used by Inst_!~Inst@2601:6c4:4081:54f0:681d:b835:8895:3ea8))) |
| 2022-11-22 17:43:04 +0100 | Inst_ | Inst |
| 2022-11-22 17:43:25 +0100 | InstX1 | (~Liam@2601:6c4:4081:54f0:c59f:75f5:30c:12fd) |
| 2022-11-22 17:45:31 +0100 | razetime | (~quassel@117.254.34.219) |
| 2022-11-22 17:48:02 +0100 | ccapndave | (~ccapndave@xcpe-62-167-164-99.cgn.res.adslplus.ch) (Quit: My MacBook has gone to sleep. ZZZzzz…) |
| 2022-11-22 17:48:20 +0100 | chromoblob | (~user@37.113.164.122) (Ping timeout: 248 seconds) |
| 2022-11-22 17:48:51 +0100 | chromoblob | (~user@37.113.164.122) |
| 2022-11-22 17:49:06 +0100 | yuribarros | (~Srain@2804:14c:65e4:865c::1000) |
| 2022-11-22 17:49:28 +0100 | ccapndave | (~ccapndave@xcpe-62-167-164-99.cgn.res.adslplus.ch) |
| 2022-11-22 17:51:21 +0100 | dfeuer | (~dfeuer@pool-96-231-138-153.washdc.fios.verizon.net) |
| 2022-11-22 17:51:39 +0100 | jonathanx | (~jonathan@h-98-128-168-222.NA.cust.bahnhof.se) (Ping timeout: 260 seconds) |
| 2022-11-22 17:52:23 +0100 | ccapndave | (~ccapndave@xcpe-62-167-164-99.cgn.res.adslplus.ch) (Client Quit) |
| 2022-11-22 17:53:47 +0100 | sammelweis | (~quassel@2601:401:8200:2d4c:bd9:d04c:7f69:eb10) (Ping timeout: 255 seconds) |
| 2022-11-22 17:53:59 +0100 | <[exa]> | Inst: do they work in isolation? |
| 2022-11-22 17:54:06 +0100 | <dfeuer> | Does hedgehog have some weird issues on GHC 9.4? |
| 2022-11-22 17:54:33 +0100 | <Athas> | Inst: Accelerate doesn't work with cabal? |
| 2022-11-22 17:54:57 +0100 | <Inst> | at least not on my machine |
| 2022-11-22 17:55:01 +0100 | <dfeuer> | Or something? My test suite keeps hanging :-(. https://github.com/dagit/logict-sequence/actions/runs/3524962723/jobs/5912004000 |
| 2022-11-22 17:55:05 +0100 | <Inst> | i don't really understand cabal so it's probably my fault anyways |
| 2022-11-22 17:55:33 +0100 | zebrag | (~chris@user/zebrag) |
| 2022-11-22 17:56:04 +0100 | <dfeuer> | Now that *could* be just a matter of lots of unlucky test cases, but ... it looks pretty fishy. |
| 2022-11-22 17:56:26 +0100 | <[exa]> | dfeuer: can you reproduce the hang locally? Otherwise I'd blame github. |
| 2022-11-22 17:57:29 +0100 | <dfeuer> | [exa], I think I actually get hangs with more GHC versions locally, but I'm not sure.... |
| 2022-11-22 17:57:45 +0100 | sammelweis | (~quassel@2601:401:8200:2d4c:bd9:d04c:7f69:eb10) |
| 2022-11-22 17:57:53 +0100 | <Inst> | [exa] I have no clue, it's very hard to test my cases individually |
| 2022-11-22 17:58:05 +0100 | <Inst> | because the reference numbers are on a website, I don't know how to grab the data from the website |
| 2022-11-22 17:58:36 +0100 | <[exa]> | dfeuer: might be useful to catch it hanging and have a look at what it's doing (at least peek in gdb or with strace) |
| 2022-11-22 17:58:41 +0100 | madjestic | (~madjestic@77-63-89-78.mobile.kpn.net) |
| 2022-11-22 17:59:02 +0100 | <dfeuer> | Inst, what is a ... website? Is it just where a spider builds its web? |
| 2022-11-22 17:59:15 +0100 | <[exa]> | Inst: reference numbers to what? |
| 2022-11-22 17:59:37 +0100 | <Inst> | http://www.bjstrat.net/cgi-bin/cdca.cgi |
| 2022-11-22 18:00:14 +0100 | <dfeuer> | [exa], hoo boy. I haven't touched gdb in very many years, and was never exactly proficient. strace isn't a bad idea, I guess.... |
| 2022-11-22 18:03:24 +0100 | jonathanx | (~jonathan@h-178-174-176-109.A357.priv.bahnhof.se) |
| 2022-11-22 18:04:30 +0100 | <[exa]> | dfeuer: even just e.g. peeking in /proc/$pid/fds might hint someting |
| 2022-11-22 18:05:59 +0100 | <[exa]> | Inst: ah that's blackjack. is the algorithm for computing that described somewhere or you trying to reproduce it? |
| 2022-11-22 18:06:19 +0100 | <Inst> | i'm trying to build my own algorithm |
| 2022-11-22 18:07:52 +0100 | coot | (~coot@213.134.171.3) (Quit: coot) |
| 2022-11-22 18:08:23 +0100 | coot | (~coot@2a02:a310:e241:1b00:ec1a:e9df:79ac:66ba) |
| 2022-11-22 18:08:29 +0100 | coot | (~coot@2a02:a310:e241:1b00:ec1a:e9df:79ac:66ba) (Remote host closed the connection) |
| 2022-11-22 18:10:58 +0100 | causal | (~user@2001:470:ea0f:3:329c:23ff:fe3f:1e0d) |
| 2022-11-22 18:12:17 +0100 | azimut | (~azimut@gateway/tor-sasl/azimut) (Remote host closed the connection) |
| 2022-11-22 18:12:54 +0100 | azimut | (~azimut@gateway/tor-sasl/azimut) |
| 2022-11-22 18:14:18 +0100 | eggplantade | (~Eggplanta@2600:1700:38c5:d800:5866:96fb:16f6:58d1) (Remote host closed the connection) |
| 2022-11-22 18:15:09 +0100 | razetime | (~quassel@117.254.34.219) (Quit: https://quassel-irc.org - Chat comfortably. Anywhere.) |
| 2022-11-22 18:15:29 +0100 | causal | (~user@2001:470:ea0f:3:329c:23ff:fe3f:1e0d) (Ping timeout: 246 seconds) |
| 2022-11-22 18:17:30 +0100 | eggplantade | (~Eggplanta@104-55-37-220.lightspeed.sntcca.sbcglobal.net) |
| 2022-11-22 18:17:32 +0100 | <dfeuer> | [exa], what would looking at file descriptors tell me? |
| 2022-11-22 18:17:35 +0100 | madjestic | (~madjestic@77-63-89-78.mobile.kpn.net) (Read error: Connection reset by peer) |
| 2022-11-22 18:17:56 +0100 | <Inst> | jeez |
| 2022-11-22 18:18:15 +0100 | <Inst> | why is it that installing HLS via github feels like installing the acme-everything package? |
| 2022-11-22 18:19:25 +0100 | <geekosaur> | not just HLS |
| 2022-11-22 18:19:51 +0100 | <geekosaur> | my xmonad config uses dbus and depends on half of hackage 😕 |
| 2022-11-22 18:23:23 +0100 | <Franciman> | this is good modularity, at least, no? |
| 2022-11-22 18:23:55 +0100 | teo | (~teo@user/teo) (Ping timeout: 268 seconds) |
| 2022-11-22 18:27:03 +0100 | <c_wraith> | hls looks like it has about 10 sub-packages |
| 2022-11-22 18:27:23 +0100 | <c_wraith> | so it's definitely intended to be modular |
| 2022-11-22 18:28:18 +0100 | ub | (~Thunderbi@178.165.179.227.wireless.dyn.drei.com) |
| 2022-11-22 18:29:06 +0100 | <fendor[m]> | we definitely have more than 10 packages, more like 20 |
| 2022-11-22 18:29:13 +0100 | <fendor[m]> | quick grep says 39 🙂 |
| 2022-11-22 18:29:26 +0100 | ubert1 | (~Thunderbi@178.165.183.156.wireless.dyn.drei.com) (Ping timeout: 246 seconds) |
| 2022-11-22 18:30:05 +0100 | <c_wraith> | oh. I was only counting the ones on hackage that are named hls-something |
| 2022-11-22 18:30:22 +0100 | ubert | (~Thunderbi@178.165.183.156.wireless.dyn.drei.com) (Ping timeout: 256 seconds) |
| 2022-11-22 18:30:22 +0100 | ub | ubert |
| 2022-11-22 18:31:10 +0100 | <fendor[m]> | that still should be around 30 |
| 2022-11-22 18:31:22 +0100 | yoneda | (~mike@193.206.102.122) (Quit: leaving) |
| 2022-11-22 18:31:26 +0100 | <fendor[m]> | but it includes benchmark projects |
| 2022-11-22 18:32:20 +0100 | <c_wraith> | Hmm. I'd say I'm just bad at estimating numbers of things in a list. |
| 2022-11-22 18:35:52 +0100 | <fendor[m]> | tbf, some of the plugins aren't released yet |
| 2022-11-22 18:36:26 +0100 | Guest75 | (~Guest75@178.141.130.118) (Quit: Client closed) |
| 2022-11-22 18:41:06 +0100 | eggplantade | (~Eggplanta@104-55-37-220.lightspeed.sntcca.sbcglobal.net) (Remote host closed the connection) |
| 2022-11-22 18:45:00 +0100 | tzh | (~tzh@c-24-21-73-154.hsd1.or.comcast.net) |
| 2022-11-22 18:45:06 +0100 | nschoe | (~q@2a01:e0a:8e:a190:13d9:919d:218e:b9d2) (Ping timeout: 256 seconds) |
| 2022-11-22 18:49:04 +0100 | merijn | (~merijn@c-001-001-017.client.esciencecenter.eduvpn.nl) |
| 2022-11-22 18:50:46 +0100 | gmg | (~user@user/gehmehgeh) |
| 2022-11-22 18:56:21 +0100 | <Unhammer> | https://hackage.haskell.org/package/hevolisa how is this not named MonadLisa? I should report a bug |
| 2022-11-22 18:58:11 +0100 | gqplox | (~textual@2a02:c7c:941d:fd00:613f:9d6e:948c:2253) |
| 2022-11-22 18:58:15 +0100 | FinnElija | (~finn_elij@user/finn-elija/x-0085643) (Remote host closed the connection) |
| 2022-11-22 18:58:57 +0100 | FinnElija | (~finn_elij@user/finn-elija/x-0085643) |
| 2022-11-22 19:02:22 +0100 | causal | (~user@50.35.83.177) |
| 2022-11-22 19:03:23 +0100 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 2022-11-22 19:03:26 +0100 | causal | (~user@50.35.83.177) (Client Quit) |
| 2022-11-22 19:05:08 +0100 | eggplantade | (~Eggplanta@104-55-37-220.lightspeed.sntcca.sbcglobal.net) |
| 2022-11-22 19:06:51 +0100 | causal | (~user@2001:470:ea0f:3:329c:23ff:fe3f:1e0d) |
| 2022-11-22 19:08:04 +0100 | causal | (~user@2001:470:ea0f:3:329c:23ff:fe3f:1e0d) (Client Quit) |
| 2022-11-22 19:09:10 +0100 | werneta | (~werneta@70-142-214-115.lightspeed.irvnca.sbcglobal.net) (Ping timeout: 252 seconds) |
| 2022-11-22 19:10:09 +0100 | causal | (~user@2001:470:ea0f:3:329c:23ff:fe3f:1e0d) |
| 2022-11-22 19:11:08 +0100 | ksu | (~ksu@user/prtr) (Ping timeout: 252 seconds) |
| 2022-11-22 19:11:14 +0100 | causal | (~user@2001:470:ea0f:3:329c:23ff:fe3f:1e0d) (Client Quit) |
| 2022-11-22 19:12:27 +0100 | ksu | (~ksu@user/prtr) |
| 2022-11-22 19:12:57 +0100 | causal | (~user@50.35.83.177) |
| 2022-11-22 19:13:27 +0100 | ddellacosta | (~ddellacos@143.244.47.82) |
| 2022-11-22 19:15:43 +0100 | Xeroine | (~Xeroine@user/xeroine) (Ping timeout: 268 seconds) |
| 2022-11-22 19:18:32 +0100 | merijn | (~merijn@c-001-001-017.client.esciencecenter.eduvpn.nl) (Ping timeout: 256 seconds) |
| 2022-11-22 19:20:01 +0100 | Xeroine | (~Xeroine@user/xeroine) |
| 2022-11-22 19:21:23 +0100 | gmg | (~user@user/gehmehgeh) (Remote host closed the connection) |
| 2022-11-22 19:22:04 +0100 | gmg | (~user@user/gehmehgeh) |
| 2022-11-22 19:22:06 +0100 | sawilagar | (~sawilagar@user/sawilagar) (Quit: Leaving) |
| 2022-11-22 19:24:49 +0100 | beteigeuze | (~Thunderbi@a79-169-109-107.cpe.netcabo.pt) (Ping timeout: 252 seconds) |
| 2022-11-22 19:25:48 +0100 | <snek> | how does one vendor a dependency with cabal |
| 2022-11-22 19:28:15 +0100 | coot | (~coot@2a02:a310:e241:1b00:ec1a:e9df:79ac:66ba) |
| 2022-11-22 19:28:31 +0100 | <geekosaur> | list its cabal file (or directory containing one) in a "packages:" entry in cabal.project |
| 2022-11-22 19:28:37 +0100 | kenaryn | (~aurele@89-88-44-27.abo.bbox.fr) |
| 2022-11-22 19:28:44 +0100 | <geekosaur> | https://github.com/geekosaur/xmonad.hs/blob/skkukuk/cabal.project |
| 2022-11-22 19:30:10 +0100 | <snek> | how does this work with like |
| 2022-11-22 19:30:16 +0100 | econo | (uid147250@user/econo) |
| 2022-11-22 19:30:16 +0100 | <snek> | my `foo.cabal` file |
| 2022-11-22 19:31:24 +0100 | Guest75 | (~Guest75@178.141.130.118) |
| 2022-11-22 19:31:44 +0100 | <geekosaur> | first entry in my packages: line points to the directory with my cabal file. the rest are git checkouts. there are also ways to tell cabal to clone repos itself at specific branches/tags/commits |
| 2022-11-22 19:32:32 +0100 | <geekosaur> | https://cabal.readthedocs.io/en/3.8/cabal-project.html#specifying-packages-from-remote-version-con… |
| 2022-11-22 19:35:26 +0100 | kenaryn | (~aurele@89-88-44-27.abo.bbox.fr) (Quit: leaving) |
| 2022-11-22 19:37:31 +0100 | <snek> | i just have folders |
| 2022-11-22 19:38:25 +0100 | <geekosaur> | then just list the folders, as I do |
| 2022-11-22 19:38:48 +0100 | <snek> | i did that |
| 2022-11-22 19:39:12 +0100 | <snek> | what do i do with the `build-depends` field in my main cabal file |
| 2022-11-22 19:39:50 +0100 | jrm | (~jrm@user/jrm) (Read error: Connection reset by peer) |
| 2022-11-22 19:40:01 +0100 | <geekosaur> | list the dependencies as usual, of course your versions should match those of the vendored deps (or simply be absent but that's rarely a good idea) |
| 2022-11-22 19:40:02 +0100 | jrm2 | (~jrm@user/jrm) |
| 2022-11-22 19:40:19 +0100 | sammelweis | (~quassel@2601:401:8200:2d4c:bd9:d04c:7f69:eb10) (Read error: Connection reset by peer) |
| 2022-11-22 19:40:51 +0100 | <snek> | ok cool, ty |
| 2022-11-22 19:40:52 +0100 | nschoe | (~q@2a01:e0a:8e:a190:547b:7f8b:8da2:2f93) |
| 2022-11-22 19:41:22 +0100 | jrm2 | jrm |
| 2022-11-22 19:41:25 +0100 | sammelweis | (~quassel@2601:401:8200:2d4c:bd9:d04c:7f69:eb10) |
| 2022-11-22 19:42:44 +0100 | <geekosaur> | that branch of my repo is a complete working project |
| 2022-11-22 19:45:19 +0100 | bilegeek | (~bilegeek@2600:1008:b05b:8372:5c1:76fe:2ae1:5709) |
| 2022-11-22 19:48:57 +0100 | king_gs | (~Thunderbi@187.201.139.206) |
| 2022-11-22 20:00:23 +0100 | ec | (~ec@gateway/tor-sasl/ec) (Remote host closed the connection) |
| 2022-11-22 20:00:59 +0100 | wootehfoot | (~wootehfoo@user/wootehfoot) |
| 2022-11-22 20:01:01 +0100 | <snek> | does anyone know what this error means? google is empty :( `Couldn't find a target code interpreter. Try with -fexternal-interpreter [11 of 67] Compiling TextShow.Data.Either ( src/TextShow/Data/Either.hs, /home/snek/code/random/ducklingjs/dist-newstyle/build/wasm32-wasi/ghc-9.5.20221116/text-show-3.10/build/TextShow/Data/Either.o )` |
| 2022-11-22 20:01:10 +0100 | ec | (~ec@gateway/tor-sasl/ec) |
| 2022-11-22 20:04:32 +0100 | <[exa]> | snek: that's from something ghci-ish? |
| 2022-11-22 20:05:09 +0100 | <snek> | its an error from my running `cabal build` |
| 2022-11-22 20:05:24 +0100 | MajorBiscuit | (~MajorBisc@86-88-79-148.fixed.kpn.net) (Ping timeout: 248 seconds) |
| 2022-11-22 20:05:50 +0100 | Guest75 | (~Guest75@178.141.130.118) (Quit: Client closed) |
| 2022-11-22 20:07:10 +0100 | <[exa]> | snek: the interpreter is used when you need to interpret some code on spot, not just compile it (see here: https://gitlab.haskell.org/ghc/ghc/-/wikis/commentary/compiler/external-interpreter) |
| 2022-11-22 20:07:18 +0100 | <[exa]> | hm maybe there's TemplateHaskell ? |
| 2022-11-22 20:07:28 +0100 | chromoblob | (~user@37.113.164.122) (Ping timeout: 252 seconds) |
| 2022-11-22 20:07:35 +0100 | <snek> | i don't know what TemplateHaskell is but |
| 2022-11-22 20:07:58 +0100 | <snek> | adding `-fexternal-interpreter` to my cabal build call didn't work |
| 2022-11-22 20:08:02 +0100 | <[exa]> | ah yes there is. https://hackage.haskell.org/package/text-show-3.3/docs/src/TextShow-Data-Either.html |
| 2022-11-22 20:09:04 +0100 | <[exa]> | you might need to ask the ghc-wasm people about that, given the whole thing is very new |
| 2022-11-22 20:09:06 +0100 | <geekosaur> | note that the wasm backend is still new and it's possible this doesn't work quite yet |
| 2022-11-22 20:09:40 +0100 | <snek> | so this is like, some sort of existential problem that i can't fix on my end? |
| 2022-11-22 20:10:09 +0100 | chromoblob | (~user@37.113.164.122) |
| 2022-11-22 20:10:30 +0100 | <snek> | i'm ok with vendoring stuff to fix it to work with wasm |
| 2022-11-22 20:10:41 +0100 | <snek> | i just rewrote the entire `clock` library lol |
| 2022-11-22 20:10:47 +0100 | <[exa]> | yeah, stuff with TemplateHaskell looks like it's not going to compile for WASM anytime soon, see the note below here: https://www.tweag.io/blog/2022-11-22-wasm-backend-merged-in-ghc/ |
| 2022-11-22 20:11:45 +0100 | <[exa]> | anyway you might have some limited luck with just rewriting the TH stuff in the packages by hand |
| 2022-11-22 20:11:45 +0100 | <snek> | what is TemplateHaskell about the file you linked? |
| 2022-11-22 20:11:53 +0100 | gregberns__ | (sid315709@id-315709.helmsley.irccloud.com) (Quit: Connection closed for inactivity) |
| 2022-11-22 20:11:58 +0100 | <[exa]> | see slightly below |
| 2022-11-22 20:12:00 +0100 | <snek> | i see it contains `LANGUAGE TemplateHaskell` at the top |
| 2022-11-22 20:12:17 +0100 | <snek> | i'm not sure what that implies of the code in the file though |
| 2022-11-22 20:12:23 +0100 | <snek> | i should note i'm not familiar with haskell in general |
| 2022-11-22 20:12:23 +0100 | <[exa]> | yes, I just wanted to confirm that it really fails on a TH one |
| 2022-11-22 20:12:58 +0100 | <[exa]> | TH is kinda like a very advanced macro system, basically metacompilation that makes various stuff insanely easier and saves a lot of code |
| 2022-11-22 20:13:16 +0100 | <[exa]> | (at the cost that your compiler needs to interpret code instead of just compiling it) |
| 2022-11-22 20:13:25 +0100 | <geekosaur> | there were several TH splices at the bottom |
| 2022-11-22 20:13:48 +0100 | <geekosaur> | the $$(derive…) lines |
| 2022-11-22 20:13:56 +0100 | freeside | (~mengwong@103.252.202.193) (Ping timeout: 248 seconds) |
| 2022-11-22 20:14:08 +0100 | irrgit_ | (~irrgit@89.47.234.74) (Remote host closed the connection) |
| 2022-11-22 20:14:36 +0100 | <snek> | ic |
| 2022-11-22 20:14:59 +0100 | irrgit_ | (~irrgit@146.70.27.250) |
| 2022-11-22 20:15:40 +0100 | merijn | (~merijn@c-001-001-017.client.esciencecenter.eduvpn.nl) |
| 2022-11-22 20:15:45 +0100 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) |
| 2022-11-22 20:16:10 +0100 | <snek> | could i theoretically pre-macro this in another normal not-experimental ghc? |
| 2022-11-22 20:16:16 +0100 | <snek> | i've done a similar trick with expanding macros in c before |
| 2022-11-22 20:16:40 +0100 | <geekosaur> | you could try compiling with -ddump=splices |
| 2022-11-22 20:16:42 +0100 | <snek> | where you just generate a huge output c file from all the input c files |
| 2022-11-22 20:16:49 +0100 | <geekosaur> | er, -ddump-splices |
| 2022-11-22 20:17:07 +0100 | <geekosaur> | back in the day there was zeroth but it's long bitrotted |
| 2022-11-22 20:17:35 +0100 | ec | (~ec@gateway/tor-sasl/ec) (Remote host closed the connection) |
| 2022-11-22 20:18:05 +0100 | ec | (~ec@gateway/tor-sasl/ec) |
| 2022-11-22 20:18:43 +0100 | jtomas | (~jtomas@191.red-88-17-199.dynamicip.rima-tde.net) |
| 2022-11-22 20:21:05 +0100 | `2jt | (~jtomas@191.red-88-17-199.dynamicip.rima-tde.net) (Ping timeout: 246 seconds) |
| 2022-11-22 20:22:54 +0100 | freeside | (~mengwong@103.252.202.193) |
| 2022-11-22 20:25:28 +0100 | <snek> | wow this generates a lot of code lmao |
| 2022-11-22 20:29:30 +0100 | freeside | (~mengwong@103.252.202.193) (Ping timeout: 255 seconds) |
| 2022-11-22 20:30:57 +0100 | coot | (~coot@2a02:a310:e241:1b00:ec1a:e9df:79ac:66ba) (Quit: coot) |
| 2022-11-22 20:33:37 +0100 | madjestic | (~madjestic@88-159-247-120.fixed.kpn.net) |
| 2022-11-22 20:34:33 +0100 | <probie> | How do I write a type signature for a pattern synonym over a GADT? If I just use what the warning says the type should be, I suddenly get a type error |
| 2022-11-22 20:36:38 +0100 | freeside | (~mengwong@103.252.202.193) |
| 2022-11-22 20:37:37 +0100 | <probie> | It says "Pattern synonym with no type signature: pattern Step :: forall {p :: Bool} {i} {o}.() => (p ~ 'True) => i -> [i] -> NonEmpty o -> Accumulator p i o", but if I add it, at usage sites I get "Couldn't match type ‘p’ with ‘'True’" |
| 2022-11-22 20:38:14 +0100 | <probie> | the error actually makes sense - it can't unify p with 'True until after the match succeeds |
| 2022-11-22 20:39:41 +0100 | <probie> | I'm slightly more confused about how it allows `Step` to work when there is no type signature. Are patterns without type signatures "unfolded" before type checking? |
| 2022-11-22 20:40:12 +0100 | king_gs | (~Thunderbi@187.201.139.206) (Ping timeout: 268 seconds) |
| 2022-11-22 20:41:55 +0100 | <EvanR> | that seems like a lot of type signature to say i -> [i] -> NonEmpty o -> Accumulator True i o |
| 2022-11-22 20:42:40 +0100 | belovachap | (~chapman@216-188-233-105.dyn.grandenetworks.net) (Ping timeout: 268 seconds) |
| 2022-11-22 20:43:48 +0100 | <EvanR> | and yeah it makes sense |
| 2022-11-22 20:44:21 +0100 | causal | (~user@50.35.83.177) (Quit: WeeChat 3.7.1) |
| 2022-11-22 20:46:19 +0100 | eggplantade | (~Eggplanta@104-55-37-220.lightspeed.sntcca.sbcglobal.net) (Remote host closed the connection) |
| 2022-11-22 20:46:39 +0100 | causal | (~user@50.35.83.177) |
| 2022-11-22 20:47:02 +0100 | <EvanR> | use ghci to print out the inferred type of Step? |
| 2022-11-22 20:47:50 +0100 | <probie> | What I want is to be able to specify separate types for the actual pattern (which is forall p . i -> [i] -> NonEmpty o -> Accumulator p i o) and the "function" (i -> [i] -> NonEmpty o -> Accumulator 'True i o) |
| 2022-11-22 20:48:10 +0100 | merijn | (~merijn@c-001-001-017.client.esciencecenter.eduvpn.nl) (Ping timeout: 260 seconds) |
| 2022-11-22 20:48:18 +0100 | <probie> | ghci correctly gives "Step :: i -> [i] -> NonEmpty o -> Accumulator 'True i o", and the warning correctly (with noise) gives the type of the pattern |
| 2022-11-22 20:48:24 +0100 | pierrot_ | pierrot |
| 2022-11-22 20:48:25 +0100 | <probie> | I just can't see a way to manually specify both |
| 2022-11-22 20:48:56 +0100 | lyle | (~lyle@104.246.145.85) |
| 2022-11-22 20:51:05 +0100 | lisbeths | (uid135845@id-135845.lymington.irccloud.com) |
| 2022-11-22 20:55:00 +0100 | <probie> | In practice it doesn't matter, since in my use case https://paste.tomsmeding.com/Gb2uDWdY `Step` is not really meant to be used a constructor, so the pattern doesn't need to be bidirectional, but I'm still stuck wondering if there's a way to do it |
| 2022-11-22 20:58:29 +0100 | Unicorn_Princess | (~Unicorn_P@user/Unicorn-Princess/x-3540542) |
| 2022-11-22 21:00:25 +0100 | fserucas | (~fserucas@2001:818:e376:a400:fb92:70c1:dd88:c7d7) (Quit: Leaving) |
| 2022-11-22 21:01:34 +0100 | <probie> | I've got it. It just took reading through the docs. pattern Step :: () => (p ~ 'True) => i -> [i] -> NonEmpty o -> Accumulator p i o; pattern Step i is o <- Next (i:is) o where Step i is o = Next (i:is) o |
| 2022-11-22 21:01:42 +0100 | eggplantade | (~Eggplanta@2600:1700:38c5:d800:5866:96fb:16f6:58d1) |
| 2022-11-22 21:02:16 +0100 | <probie> | The first `() =>` was mandatory and I had to use the `pattern Foo <- ... where Foo = ...` syntax instead of `pattern Foo = ...` |
| 2022-11-22 21:02:28 +0100 | raehik | (~raehik@cpc95906-rdng25-2-0-cust156.15-3.cable.virginm.net) (Ping timeout: 248 seconds) |
| 2022-11-22 21:04:44 +0100 | coot | (~coot@2a02:a310:e241:1b00:ec1a:e9df:79ac:66ba) |
| 2022-11-22 21:04:46 +0100 | <EvanR> | weird |
| 2022-11-22 21:08:37 +0100 | <probie> | Ok, now I'm going insane, apparently I can use the `pattern Foo = ...` syntax |
| 2022-11-22 21:10:32 +0100 | <probie> | and the type that provided by the warning that I directly pasted in works |
| 2022-11-22 21:11:17 +0100 | Vajb | (~Vajb@2001:999:504:3ad6:52a4:a3b5:32d8:e74d) (Read error: Connection reset by peer) |
| 2022-11-22 21:11:43 +0100 | Vajb | (~Vajb@hag-jnsbng11-58c3a5-27.dhcp.inet.fi) |
| 2022-11-22 21:11:48 +0100 | <probie> | They key part was the first `() =>` though |
| 2022-11-22 21:12:01 +0100 | thyriaen | (~thyriaen@2a01:aea0:dd4:470d:6245:cbff:fe9f:48b1) |
| 2022-11-22 21:12:17 +0100 | ukj | (~todor@45.222.24.171) |
| 2022-11-22 21:13:11 +0100 | <geekosaur> | yes, first is wanteds, second is provideds |
| 2022-11-22 21:14:00 +0100 | <geekosaur> | so this one wants nothing and matching it gives you p ~ 'True, iirc |
| 2022-11-22 21:14:13 +0100 | waleee | (~waleee@2001:9b0:213:7200:cc36:a556:b1e8:b340) |
| 2022-11-22 21:14:39 +0100 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 2022-11-22 21:15:22 +0100 | ukj | (~todor@45.222.24.171) (Client Quit) |
| 2022-11-22 21:15:22 +0100 | sawilagar | (~sawilagar@user/sawilagar) |
| 2022-11-22 21:15:32 +0100 | <probie> | Yes, that matches what I've read and seems to match what I'm doing. I'm just not sure why what I originally wrote didn't work since my code seems to back to where it started but now it's type checking |
| 2022-11-22 21:17:03 +0100 | <probie> | All I can think of is that I dropped the `() =>` without thinking about it. It's 7:15am - if I'm braindead already this doesn't bode well for my work day |
| 2022-11-22 21:18:27 +0100 | <snek> | in this text show package, one of the templates generated a reference to `Data.Text.Internal.Fusion.Size.Between` |
| 2022-11-22 21:18:44 +0100 | <snek> | but in the expansion of that, i get `Module ‘Data.Text.Internal.Fusion.Size’ does not export ‘Between’.` |
| 2022-11-22 21:20:34 +0100 | <geekosaur> | hm. TH can cheat and see stuff that isn't otherwise visible, but it's usually not this blatant iirc |
| 2022-11-22 21:21:22 +0100 | <snek> | is this entire `show` thing just for generating debug strings of Text instances? |
| 2022-11-22 21:21:50 +0100 | <snek> | i could just mock this stuff out |
| 2022-11-22 21:22:12 +0100 | <geekosaur> | yes |
| 2022-11-22 21:22:14 +0100 | azimut | (~azimut@gateway/tor-sasl/azimut) (Ping timeout: 255 seconds) |
| 2022-11-22 21:22:31 +0100 | <geekosaur> | oh, also what version of Text are you working with? this may have changed in text-2.0 |
| 2022-11-22 21:22:47 +0100 | <geekosaur> | I note the module is from 2016 so might not have been updated |
| 2022-11-22 21:22:51 +0100 | merijn | (~merijn@c-001-001-017.client.esciencecenter.eduvpn.nl) |
| 2022-11-22 21:22:56 +0100 | <geekosaur> | (or at least so the copyright claims) |
| 2022-11-22 21:22:58 +0100 | <snek> | 3.10 |
| 2022-11-22 21:23:58 +0100 | <geekosaur> | uh? 2.0.1 is latest https://hackage.haskell.org/package/text |
| 2022-11-22 21:24:28 +0100 | <snek> | oh text itself |
| 2022-11-22 21:24:35 +0100 | <snek> | how do i check what version got pulled in |
| 2022-11-22 21:25:59 +0100 | <snek> | oh its definitely not 2 |
| 2022-11-22 21:26:06 +0100 | <snek> | duckling limits this to <1.3 |
| 2022-11-22 21:26:23 +0100 | azimut | (~azimut@gateway/tor-sasl/azimut) |
| 2022-11-22 21:26:55 +0100 | <geekosaur> | I see Between in 2.0.1's source but indeed it's not exported |
| 2022-11-22 21:27:25 +0100 | <snek> | i think i am going to just go into duckling and delete all this code that depends on show-text |
| 2022-11-22 21:27:41 +0100 | merijn | (~merijn@c-001-001-017.client.esciencecenter.eduvpn.nl) (Ping timeout: 268 seconds) |
| 2022-11-22 21:27:52 +0100 | <snek> | its not even that much |
| 2022-11-22 21:28:37 +0100 | eggplantade | (~Eggplanta@2600:1700:38c5:d800:5866:96fb:16f6:58d1) (Remote host closed the connection) |
| 2022-11-22 21:28:55 +0100 | eggplantade | (~Eggplanta@2600:1700:38c5:d800:5866:96fb:16f6:58d1) |
| 2022-11-22 21:37:39 +0100 | dignissimus | (~sam@user/dignissimus) |
| 2022-11-22 21:45:18 +0100 | lyle | (~lyle@104.246.145.85) (Quit: WeeChat 3.7.1) |
| 2022-11-22 21:49:21 +0100 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) |
| 2022-11-22 21:49:56 +0100 | freeside | (~mengwong@103.252.202.193) (Ping timeout: 248 seconds) |
| 2022-11-22 21:50:50 +0100 | dfeuer | (~dfeuer@pool-96-231-138-153.washdc.fios.verizon.net) (Quit: Client closed) |
| 2022-11-22 21:52:32 +0100 | dignissimus | (~sam@user/dignissimus) (Quit: QUIT) |
| 2022-11-22 21:55:27 +0100 | jakalx | (~jakalx@base.jakalx.net) () |
| 2022-11-22 21:55:43 +0100 | jakalx | (~jakalx@base.jakalx.net) |
| 2022-11-22 21:56:39 +0100 | Guest60 | (~Guest60@149.159.207.218) |
| 2022-11-22 21:58:28 +0100 | fserucas | (~fserucas@2001:818:e376:a400:fb92:70c1:dd88:c7d7) |
| 2022-11-22 21:58:31 +0100 | fserucas | (~fserucas@2001:818:e376:a400:fb92:70c1:dd88:c7d7) (Client Quit) |
| 2022-11-22 22:00:22 +0100 | sammelweis | (~quassel@2601:401:8200:2d4c:bd9:d04c:7f69:eb10) (Quit: No Ping reply in 180 seconds.) |
| 2022-11-22 22:01:16 +0100 | hgolden | (~hgolden@cpe-172-251-233-141.socal.res.rr.com) (Remote host closed the connection) |
| 2022-11-22 22:01:53 +0100 | sammelweis | (~quassel@2601:401:8200:2d4c:bd9:d04c:7f69:eb10) |
| 2022-11-22 22:02:29 +0100 | caryhartline | (~caryhartl@2603-8080-6a0e-8d88-c90e-511a-79c3-1695.res6.spectrum.com) |
| 2022-11-22 22:04:02 +0100 | pavonia | (~user@user/siracusa) |
| 2022-11-22 22:07:14 +0100 | azimut | (~azimut@gateway/tor-sasl/azimut) (Ping timeout: 255 seconds) |
| 2022-11-22 22:08:11 +0100 | eggplantade | (~Eggplanta@2600:1700:38c5:d800:5866:96fb:16f6:58d1) (Remote host closed the connection) |
| 2022-11-22 22:09:02 +0100 | gmg | (~user@user/gehmehgeh) (Ping timeout: 255 seconds) |
| 2022-11-22 22:09:38 +0100 | azimut | (~azimut@gateway/tor-sasl/azimut) |
| 2022-11-22 22:10:27 +0100 | gmg | (~user@user/gehmehgeh) |
| 2022-11-22 22:11:10 +0100 | Lycurgus | (~juan@user/Lycurgus) |
| 2022-11-22 22:12:16 +0100 | dtman34 | (~dtman34@76.156.89.180) |
| 2022-11-22 22:14:26 +0100 | titibandit | (~titibandi@xdsl-78-34-153-165.nc.de) (Remote host closed the connection) |
| 2022-11-22 22:16:06 +0100 | Lycurgus | (~juan@user/Lycurgus) (Quit: Exeunt https://tinyurl.com/4m8d4kd5) |
| 2022-11-22 22:16:19 +0100 | freeside | (~mengwong@103.252.202.193) |
| 2022-11-22 22:17:11 +0100 | zer0bitz_ | (~zer0bitz@196.244.192.58) |
| 2022-11-22 22:17:31 +0100 | hgolden | (~hgolden@cpe-172-251-233-141.socal.res.rr.com) |
| 2022-11-22 22:20:07 +0100 | gqplox | (~textual@2a02:c7c:941d:fd00:613f:9d6e:948c:2253) (Quit: Textual IRC Client: www.textualapp.com) |
| 2022-11-22 22:20:44 +0100 | zer0bitz | (~zer0bitz@196.244.192.59) (Ping timeout: 268 seconds) |
| 2022-11-22 22:20:52 +0100 | freeside | (~mengwong@103.252.202.193) (Ping timeout: 248 seconds) |
| 2022-11-22 22:21:27 +0100 | king_gs | (~Thunderbi@2806:103e:29:bfeb:c988:bbd5:2586:4924) |
| 2022-11-22 22:25:03 +0100 | merijn | (~merijn@c-001-001-017.client.esciencecenter.eduvpn.nl) |
| 2022-11-22 22:27:46 +0100 | chromoblob | (~user@37.113.164.122) (Read error: Connection reset by peer) |
| 2022-11-22 22:30:14 +0100 | belovachap | (~chapman@216-188-233-105.dyn.grandenetworks.net) |
| 2022-11-22 22:33:07 +0100 | freeside | (~mengwong@103.252.202.193) |
| 2022-11-22 22:34:41 +0100 | FinnElija | (~finn_elij@user/finn-elija/x-0085643) (Ping timeout: 255 seconds) |
| 2022-11-22 22:36:02 +0100 | FinnElija | (~finn_elij@user/finn-elija/x-0085643) |
| 2022-11-22 22:37:24 +0100 | thyriaen_ | (~thyriaen@2a01:aea0:dd4:470d:6245:cbff:fe9f:48b1) |
| 2022-11-22 22:37:26 +0100 | thyriaen_ | (~thyriaen@2a01:aea0:dd4:470d:6245:cbff:fe9f:48b1) (Remote host closed the connection) |
| 2022-11-22 22:39:09 +0100 | Vajb | (~Vajb@hag-jnsbng11-58c3a5-27.dhcp.inet.fi) (Read error: Connection reset by peer) |
| 2022-11-22 22:39:22 +0100 | <dminuoso> | % f :: forall (r :: ZeroBitType) (s :: r). s -> () |
| 2022-11-22 22:39:22 +0100 | <yahb2> | <interactive>:34:38: error: ; • Expecting a lifted type, but ‘r’ is unlifted ; • In the kind ‘r’ ; In an expression type signature: ; forall (r :: ZeroBitType) (s :: r). s -> ... |
| 2022-11-22 22:39:25 +0100 | <dminuoso> | Why am I getting this error? |
| 2022-11-22 22:39:49 +0100 | <dminuoso> | type ZeroBitType = TYPE ZeroBitRep |
| 2022-11-22 22:39:51 +0100 | <dminuoso> | type ZeroBitRep = 'TupleRep ('[] :: [RuntimeRep]) |
| 2022-11-22 22:40:03 +0100 | <dminuoso> | These two bindings we defined prior to this, as yahb2 is running on an older GHC |
| 2022-11-22 22:41:13 +0100 | <dminuoso> | How does this make any sense, GHC is suggesting that this kind (i.e. the type of a type) to be unlifted - I do not even know what that means. |
| 2022-11-22 22:41:48 +0100 | Vajb | (~Vajb@2001:999:504:3ad6:52a4:a3b5:32d8:e74d) |
| 2022-11-22 22:45:24 +0100 | belovachap | (~chapman@216-188-233-105.dyn.grandenetworks.net) (Ping timeout: 248 seconds) |
| 2022-11-22 22:46:12 +0100 | thyriaen | (~thyriaen@2a01:aea0:dd4:470d:6245:cbff:fe9f:48b1) (Quit: Leaving) |
| 2022-11-22 22:47:23 +0100 | <jackdk> | Can anyone recommend a good idiom for performing a three-deep nested record update? I'm normally on team "just use lens" but this is for a library that wants to eventually become lens/optics agnostic. I'm currently leaning towards writing `updateFoo :: (Foo -> Foo) -> Bar -> Bar` etc and composing them, but it feels a bit messy. Happy to use extensions that are in 8.10.7 or later - `RecordWildCards` etc are fine, `RecordDotSyntax` is not. |
| 2022-11-22 22:48:30 +0100 | mmhat | (~mmh@p200300f1c72dc6ddee086bfffe095315.dip0.t-ipconnect.de) (Ping timeout: 240 seconds) |
| 2022-11-22 22:48:53 +0100 | mmhat | (~mmh@p200300f1c72dc696ee086bfffe095315.dip0.t-ipconnect.de) |
| 2022-11-22 22:49:07 +0100 | <dminuoso> | jackdk: You can do a Van Laarhoven style lens regardless. Recall that `over = coerce`. |
| 2022-11-22 22:49:20 +0100 | <Hecate> | jackdk: gradually update the sub-records until you update the top-level record |
| 2022-11-22 22:49:24 +0100 | <dminuoso> | dont need to depend on lens just for that. |
| 2022-11-22 22:49:42 +0100 | <dminuoso> | Its agnostic, and optics/lens users can seamingly use it too. |
| 2022-11-22 22:50:46 +0100 | <jackdk> | "Recall that `over = coerce`" - can you elaborate further? This is new to me, though I'm pretty OK with writing VL lenses directly. |
| 2022-11-22 22:51:19 +0100 | <jackdk> | Hecate: are you describing an idiom that I do not understand, or are you saying that the simplest way to do the thing it just to do the thing? |
| 2022-11-22 22:51:33 +0100 | <Hecate> | jackdk: the latter yes |
| 2022-11-22 22:51:34 +0100 | <dminuoso> | jackdk: https://gist.github.com/dminuoso/2c4677f3c1bcd05e0c72eeadc6c2e148 |
| 2022-11-22 22:52:03 +0100 | <dminuoso> | Writing lenses by hand is quite trivial and looks nice as well. |
| 2022-11-22 22:52:18 +0100 | Guest60 | (~Guest60@149.159.207.218) (Ping timeout: 260 seconds) |
| 2022-11-22 22:53:03 +0100 | <dminuoso> | And `view l = getConst #. l Const` |
| 2022-11-22 22:53:13 +0100 | <jackdk> | The library I'm tinkering with and its reverse dependencies are moving away from providing most optics, and instead moving towards providing `Generic` instances. While I could keep lenses around, it feels a bit against that goal. |
| 2022-11-22 22:53:26 +0100 | <dminuoso> | For symmetry you can also just write out over |
| 2022-11-22 22:53:28 +0100 | <dminuoso> | `over l f = runIdentity #. l (Identity #. f)` |
| 2022-11-22 22:53:30 +0100 | <jackdk> | I see now why `over = coerce`; thanks for that. Still means I have to get the lens from somewhere. |
| 2022-11-22 22:53:45 +0100 | belovachap | (~chapman@216-188-233-105.dyn.grandenetworks.net) |
| 2022-11-22 22:57:40 +0100 | merijn | (~merijn@c-001-001-017.client.esciencecenter.eduvpn.nl) (Ping timeout: 248 seconds) |
| 2022-11-22 23:00:26 +0100 | <gurkenglas> | Is there any library that uses arcane trickery to construct the pullback of two functions a->c and b->c? |
| 2022-11-22 23:00:45 +0100 | <jackdk> | What's a pullback of two functions? |
| 2022-11-22 23:01:05 +0100 | <gurkenglas> | the type of pairs (a,b) that map to the same c |
| 2022-11-22 23:01:43 +0100 | <gurkenglas> | the arcane trickery might be something like "can't enforce that equality on the type level directly, but here's a type with which you can do the same things" |
| 2022-11-22 23:01:55 +0100 | king_gs | (~Thunderbi@2806:103e:29:bfeb:c988:bbd5:2586:4924) (Remote host closed the connection) |
| 2022-11-22 23:02:15 +0100 | king_gs | (~Thunderbi@2806:103e:29:bfeb:c988:bbd5:2586:4924) |
| 2022-11-22 23:02:26 +0100 | <jackdk> | If you want to enumerate those values, you could do it with no guarantee of timely termination by using https://hackage.haskell.org/package/universe |
| 2022-11-22 23:02:39 +0100 | <gurkenglas> | i don't |
| 2022-11-22 23:03:16 +0100 | <gurkenglas> | i don't even want to require Eq |
| 2022-11-22 23:03:30 +0100 | belovachap | (~chapman@216-188-233-105.dyn.grandenetworks.net) (Ping timeout: 260 seconds) |
| 2022-11-22 23:03:40 +0100 | <jackdk> | *shrug* dunno then |
| 2022-11-22 23:03:57 +0100 | <gurkenglas> | i realize that i'm asking for grand wizardry here but some part of me would be entirely unsurprised if this is possible anyway |
| 2022-11-22 23:07:28 +0100 | <gurkenglas> | subtask 1 then, i guess: get Eq without boolean blindness |
| 2022-11-22 23:07:42 +0100 | money | polo |
| 2022-11-22 23:07:45 +0100 | ft | (~ft@p508dbd59.dip0.t-ipconnect.de) |
| 2022-11-22 23:08:41 +0100 | eggplantade | (~Eggplanta@2600:1700:38c5:d800:5866:96fb:16f6:58d1) |
| 2022-11-22 23:13:17 +0100 | eggplantade | (~Eggplanta@2600:1700:38c5:d800:5866:96fb:16f6:58d1) (Ping timeout: 255 seconds) |
| 2022-11-22 23:14:22 +0100 | <gurkenglas> | perhaps... data Commutes a b where ______("witness that there is precisely one function that can be constructed with the tools available from a to b, up to equality")_____; data Pullback a b c where Pullback :: (a->c) -> (b->c) -> forall x. (x->a) -> (x->b) -> Commutes x c -> x -> Pullback a b c |
| 2022-11-22 23:14:45 +0100 | <dminuoso> | gurkenglas: is this possibly helpful? https://gist.github.com/TOTBWF/0078c21c498e31429f3b4da74453d79d |
| 2022-11-22 23:14:56 +0100 | wootehfoot | (~wootehfoo@user/wootehfoot) (Read error: Connection reset by peer) |
| 2022-11-22 23:15:32 +0100 | albet70 | (~xxx@2400:8902::f03c:92ff:fe60:98d8) (Remote host closed the connection) |
| 2022-11-22 23:16:49 +0100 | <gurkenglas> | is there some way to construct that a type X has exactly one element? an element constructs that there is at least one... |
| 2022-11-22 23:18:04 +0100 | motherfsck | (~motherfsc@user/motherfsck) (Ping timeout: 268 seconds) |
| 2022-11-22 23:18:26 +0100 | jmdaemon | (~jmdaemon@user/jmdaemon) |
| 2022-11-22 23:21:17 +0100 | michalz | (~michalz@185.246.207.197) (Remote host closed the connection) |
| 2022-11-22 23:21:39 +0100 | albet70 | (~xxx@2400:8902::f03c:92ff:fe60:98d8) |
| 2022-11-22 23:26:03 +0100 | coot | (~coot@2a02:a310:e241:1b00:ec1a:e9df:79ac:66ba) (Quit: coot) |
| 2022-11-22 23:27:00 +0100 | <gurkenglas> | perhaps you can say "X has at least two elements" with something like "forall a b. if a and b are not empty then there exists some X->a+b, though I can't construct it, such that if i had it i could make (a,b)" |
| 2022-11-22 23:28:36 +0100 | <gurkenglas> | dminuoso: I suppose Refl does the job, though how would you ever get Refl (map f . map g) (map (f . g))? |
| 2022-11-22 23:30:34 +0100 | opticblast | (~Thunderbi@secure-165.caltech.edu) (Ping timeout: 260 seconds) |
| 2022-11-22 23:33:04 +0100 | motherfsck | (~motherfsc@user/motherfsck) |
| 2022-11-22 23:36:34 +0100 | freeside | (~mengwong@103.252.202.193) (Ping timeout: 268 seconds) |
| 2022-11-22 23:37:22 +0100 | opticblast | (~Thunderbi@secure-165.caltech.edu) |
| 2022-11-22 23:39:51 +0100 | caryhartline | (~caryhartl@2603-8080-6a0e-8d88-c90e-511a-79c3-1695.res6.spectrum.com) (Quit: caryhartline) |
| 2022-11-22 23:41:56 +0100 | gurkenglas | (~gurkengla@p548ac72e.dip0.t-ipconnect.de) (Ping timeout: 248 seconds) |
| 2022-11-22 23:42:26 +0100 | belovachap | (~chapman@216-188-233-105.dyn.grandenetworks.net) |
| 2022-11-22 23:45:20 +0100 | stiell | (~stiell@gateway/tor-sasl/stiell) (Ping timeout: 255 seconds) |
| 2022-11-22 23:46:36 +0100 | king_gs | (~Thunderbi@2806:103e:29:bfeb:c988:bbd5:2586:4924) (Ping timeout: 255 seconds) |
| 2022-11-22 23:48:39 +0100 | freeside | (~mengwong@103.252.202.193) |
| 2022-11-22 23:51:19 +0100 | zebrag | (~chris@user/zebrag) (Ping timeout: 252 seconds) |
| 2022-11-22 23:52:10 +0100 | sammelweis_ | (~quassel@2601:401:8200:2d4c:bd9:d04c:7f69:eb10) |
| 2022-11-22 23:52:27 +0100 | sammelweis | (~quassel@2601:401:8200:2d4c:bd9:d04c:7f69:eb10) (Read error: Connection reset by peer) |
| 2022-11-22 23:53:19 +0100 | freeside | (~mengwong@103.252.202.193) (Ping timeout: 260 seconds) |
| 2022-11-22 23:54:26 +0100 | merijn | (~merijn@c-001-001-017.client.esciencecenter.eduvpn.nl) |
| 2022-11-22 23:54:56 +0100 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 2022-11-22 23:56:02 +0100 | raoul3 | (~raoul@95.179.203.88) |
| 2022-11-22 23:56:12 +0100 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) |
| 2022-11-22 23:56:25 +0100 | tabemann_ | (~tabemann@2600:1700:7990:24e0:a94c:868e:1baa:b99f) |
| 2022-11-22 23:56:28 +0100 | parseval_ | (sid239098@id-239098.helmsley.irccloud.com) |
| 2022-11-22 23:56:30 +0100 | sclv_ | (sid39734@haskell/developer/sclv) |
| 2022-11-22 23:56:41 +0100 | siers69 | (~ij@user/ij) |
| 2022-11-22 23:56:51 +0100 | snek_ | (sid280155@id-280155.lymington.irccloud.com) |
| 2022-11-22 23:56:52 +0100 | scav_ | (sid309693@user/scav) |
| 2022-11-22 23:56:55 +0100 | lll | (~o@user/offon) |
| 2022-11-22 23:57:00 +0100 | maerwald_ | (~maerwald@mail.hasufell.de) |
| 2022-11-22 23:57:09 +0100 | sajith_ | (~sajith@user/sajith) |
| 2022-11-22 23:57:12 +0100 | sunarch_ | (sid526836@user/sunarch) |
| 2022-11-22 23:58:15 +0100 | stiell | (~stiell@gateway/tor-sasl/stiell) |
| 2022-11-22 23:58:27 +0100 | pie__ | (~pie_bnc@user/pie/x-2818909) |
| 2022-11-22 23:58:33 +0100 | ladyfriday | (~robert@what.i.hope.is.not.a.tabernaevagant.es) |
| 2022-11-22 23:58:33 +0100 | kawen_ | (~quassel@static.208.191.216.95.clients.your-server.de) |
| 2022-11-22 23:58:43 +0100 | Batzy_ | (~quassel@user/batzy) |
| 2022-11-22 23:59:07 +0100 | mjacob_ | (~mjacob@adrastea.uberspace.de) |
| 2022-11-22 23:59:15 +0100 | Patternm1ster | (~georg@li1192-118.members.linode.com) |
| 2022-11-22 23:59:15 +0100 | kawzeg_ | (kawzeg@2a01:7e01::f03c:92ff:fee2:ec34) |
| 2022-11-22 23:59:24 +0100 | ncf_ | (~n@monade.li) |
| 2022-11-22 23:59:25 +0100 | RemiYuko | (~licht@user/akechishiro) |
| 2022-11-22 23:59:29 +0100 | robbert | (~robbert@robbertvanderhelm.nl) |
| 2022-11-22 23:59:32 +0100 | AWizzArd_ | (~code@gehrels.uberspace.de) |
| 2022-11-22 23:59:39 +0100 | mtjm_ | (~mutantmel@2604:a880:2:d0::208b:d001) |
| 2022-11-22 23:59:50 +0100 | darchitect1 | (~darchitec@2a00:23c6:3584:df01:8400:aa62:2730:49fa) |