| 2023-04-27 00:07:39 +0200 | thegeekinside | (~thegeekin@189.180.38.222) (Ping timeout: 256 seconds) |
| 2023-04-27 00:11:32 +0200 | zeenk | (~zeenk@2a02:2f04:a20f:5200::fba) (Quit: Konversation terminated!) |
| 2023-04-27 00:15:20 +0200 | coot | (~coot@2a02:a310:e241:1b00:ec1a:e9df:79ac:66ba) (Quit: coot) |
| 2023-04-27 00:16:42 +0200 | sammelweis | (~quassel@2601:401:8200:2d4c:bd9:d04c:7f69:eb10) (Quit: No Ping reply in 180 seconds.) |
| 2023-04-27 00:16:50 +0200 | sammelweis | (~quassel@2601:401:8200:2d4c:bd9:d04c:7f69:eb10) |
| 2023-04-27 00:16:56 +0200 | nick4 | (~nick@2600:8807:9103:b700:c41a:f850:bfc2:4f27) |
| 2023-04-27 00:21:14 +0200 | nick4 | (~nick@2600:8807:9103:b700:c41a:f850:bfc2:4f27) (Ping timeout: 246 seconds) |
| 2023-04-27 00:25:09 +0200 | thegeekinside | (~thegeekin@189.180.38.222) |
| 2023-04-27 00:29:29 +0200 | npmania | (~Thunderbi@121.128.226.31) |
| 2023-04-27 00:33:35 +0200 | Cale | (~cale@cpe80d04ade0a03-cm80d04ade0a01.cpe.net.cable.rogers.com) (Remote host closed the connection) |
| 2023-04-27 00:35:52 +0200 | chiselfuse | (~chiselfus@user/chiselfuse) (Remote host closed the connection) |
| 2023-04-27 00:36:21 +0200 | chiselfuse | (~chiselfus@user/chiselfuse) |
| 2023-04-27 00:36:22 +0200 | Cale | (~cale@cpe80d04ade0a03-cm80d04ade0a01.cpe.net.cable.rogers.com) |
| 2023-04-27 00:40:50 +0200 | Tuplanolla | (~Tuplanoll@91-159-68-236.elisa-laajakaista.fi) (Quit: Leaving.) |
| 2023-04-27 00:42:45 +0200 | gurkenglas | (~gurkengla@dynamic-046-114-002-228.46.114.pool.telefonica.de) (Ping timeout: 240 seconds) |
| 2023-04-27 00:44:26 +0200 | merijn | (~merijn@145.90.225.7) |
| 2023-04-27 00:45:14 +0200 | gurkenglas | (~gurkengla@46.114.179.150) |
| 2023-04-27 01:00:39 +0200 | oljenkins | (~philipp@p5dec4bb3.dip0.t-ipconnect.de) (Ping timeout: 255 seconds) |
| 2023-04-27 01:08:10 +0200 | codaraxis___ | (~codaraxis@user/codaraxis) |
| 2023-04-27 01:09:08 +0200 | acidjnk | (~acidjnk@p200300d6e715c4336965881302acf76a.dip0.t-ipconnect.de) (Ping timeout: 252 seconds) |
| 2023-04-27 01:11:25 +0200 | codaraxis__ | (~codaraxis@user/codaraxis) (Ping timeout: 240 seconds) |
| 2023-04-27 01:13:02 +0200 | codaraxis___ | (~codaraxis@user/codaraxis) (Ping timeout: 246 seconds) |
| 2023-04-27 01:17:48 +0200 | merijn | (~merijn@145.90.225.7) (Ping timeout: 265 seconds) |
| 2023-04-27 01:26:23 +0200 | TheCoffeMaker | (~TheCoffeM@user/thecoffemaker) (Remote host closed the connection) |
| 2023-04-27 01:26:45 +0200 | TheCoffeMaker | (~TheCoffeM@user/thecoffemaker) |
| 2023-04-27 01:26:56 +0200 | chiselfuse | (~chiselfus@user/chiselfuse) (Ping timeout: 240 seconds) |
| 2023-04-27 01:27:11 +0200 | chiselfu1e | (~chiselfus@user/chiselfuse) |
| 2023-04-27 01:27:25 +0200 | jwiegley | johnw` |
| 2023-04-27 01:28:07 +0200 | johnw` | johnw |
| 2023-04-27 01:28:41 +0200 | eggplantade | (~Eggplanta@104-55-37-220.lightspeed.sntcca.sbcglobal.net) (Read error: Connection reset by peer) |
| 2023-04-27 01:29:02 +0200 | eggplantade | (~Eggplanta@2600:1700:38c5:d800:c7a:f7d7:990c:5acb) |
| 2023-04-27 01:30:01 +0200 | Guest75 | (~Guest75@node-1w7jr9qnoiav0z7eosky02l6y.ipv6.telus.net) |
| 2023-04-27 01:37:05 +0200 | finsternis | (~X@23.226.237.192) |
| 2023-04-27 01:39:30 +0200 | Guest75 | (~Guest75@node-1w7jr9qnoiav0z7eosky02l6y.ipv6.telus.net) (Quit: Client closed) |
| 2023-04-27 01:42:49 +0200 | mauke_ | (~mauke@user/mauke) |
| 2023-04-27 01:44:20 +0200 | mauke | (~mauke@user/mauke) (Ping timeout: 252 seconds) |
| 2023-04-27 01:44:20 +0200 | mauke_ | mauke |
| 2023-04-27 01:46:41 +0200 | heartburn | (~gass@2a00:d880:3:1::b1e4:b241) (Ping timeout: 246 seconds) |
| 2023-04-27 01:48:22 +0200 | <Clinton[m]> | Is there a MonadState style typeclass that abstracts over a Key/Value store? Yes, I know I could use StateT and a Map, but I'd like to eventually replace an in memory implementation with some other implementation, like a database based one. I don't want to have to load the whole table each time I want to get one row to conform to the interface. |
| 2023-04-27 01:52:05 +0200 | wroathe | (~wroathe@207-153-38-140.fttp.usinternet.com) |
| 2023-04-27 01:52:05 +0200 | wroathe | (~wroathe@207-153-38-140.fttp.usinternet.com) (Changing host) |
| 2023-04-27 01:52:05 +0200 | wroathe | (~wroathe@user/wroathe) |
| 2023-04-27 01:54:02 +0200 | albet70 | (~xxx@2400:8902::f03c:92ff:fe60:98d8) (Remote host closed the connection) |
| 2023-04-27 01:54:42 +0200 | heartburn | (~gass@2a00:d880:3:1::b1e4:b241) |
| 2023-04-27 02:00:09 +0200 | albet70 | (~xxx@2400:8902::f03c:92ff:fe60:98d8) |
| 2023-04-27 02:01:18 +0200 | gurkenglas | (~gurkengla@46.114.179.150) (Ping timeout: 265 seconds) |
| 2023-04-27 02:02:02 +0200 | Inst | (~Inst@2601:6c4:4081:54f0:e436:a84f:8a3c:7b5) |
| 2023-04-27 02:09:52 +0200 | sammelweis | (~quassel@2601:401:8200:2d4c:bd9:d04c:7f69:eb10) (Ping timeout: 252 seconds) |
| 2023-04-27 02:10:07 +0200 | Lord_of_Life | (~Lord@user/lord-of-life/x-2819915) (Ping timeout: 276 seconds) |
| 2023-04-27 02:10:26 +0200 | sammelweis | (~quassel@2601:401:8200:2d4c:bd9:d04c:7f69:eb10) |
| 2023-04-27 02:11:10 +0200 | Lord_of_Life | (~Lord@user/lord-of-life/x-2819915) |
| 2023-04-27 02:11:45 +0200 | mei | (~mei@user/mei) (Ping timeout: 240 seconds) |
| 2023-04-27 02:14:29 +0200 | mei | (~mei@user/mei) |
| 2023-04-27 02:17:23 +0200 | FinnElija | (~finn_elij@user/finn-elija/x-0085643) (Remote host closed the connection) |
| 2023-04-27 02:17:57 +0200 | FinnElija | (~finn_elij@user/finn-elija/x-0085643) |
| 2023-04-27 02:26:25 +0200 | mncheck | (~mncheck@193.224.205.254) (Ping timeout: 240 seconds) |
| 2023-04-27 02:32:03 +0200 | oljenkins | (~philipp@p5dec4bb3.dip0.t-ipconnect.de) |
| 2023-04-27 02:32:51 +0200 | Me-me | (~Me-me@user/me-me) |
| 2023-04-27 02:36:10 +0200 | ryanbooker | (uid4340@id-4340.hampstead.irccloud.com) |
| 2023-04-27 02:45:21 +0200 | mei | (~mei@user/mei) (Remote host closed the connection) |
| 2023-04-27 02:50:16 +0200 | johnw | (~jwiegley@76-234-69-149.lightspeed.frokca.sbcglobal.net) (Quit: ZNC - http://znc.in) |
| 2023-04-27 02:52:24 +0200 | nate1 | (~nate@98.45.169.16) |
| 2023-04-27 02:53:10 +0200 | mei | (~mei@user/mei) |
| 2023-04-27 02:57:35 +0200 | nate1 | (~nate@98.45.169.16) (Ping timeout: 260 seconds) |
| 2023-04-27 03:04:12 +0200 | gmg | (~user@user/gehmehgeh) |
| 2023-04-27 03:07:20 +0200 | gehmehgeh | (~user@user/gehmehgeh) (Ping timeout: 240 seconds) |
| 2023-04-27 03:08:59 +0200 | <dmj`> | Clinton[m]: Instead of a class, you could define your own data type as a mock that has functions for various map operations. data Context k v m = Context { insert :: k -> v -> m (); lookup :: k -> m (Maybe v); delete :: k -> m (Maybe v) }, then initialize it in either State s or IO, or StateT s IO, etc. swap it out, poor man's IOC. |
| 2023-04-27 03:11:02 +0200 | albet70 | (~xxx@2400:8902::f03c:92ff:fe60:98d8) (Remote host closed the connection) |
| 2023-04-27 03:12:00 +0200 | wroathe | (~wroathe@user/wroathe) (Ping timeout: 248 seconds) |
| 2023-04-27 03:14:22 +0200 | merijn | (~merijn@c-001-001-006.client.esciencecenter.eduvpn.nl) |
| 2023-04-27 03:14:59 +0200 | bitdex | (~bitdex@gateway/tor-sasl/bitdex) |
| 2023-04-27 03:15:05 +0200 | machinedgod | (~machinedg@d198-53-218-113.abhsia.telus.net) (Ping timeout: 240 seconds) |
| 2023-04-27 03:17:10 +0200 | albet70 | (~xxx@2400:8902::f03c:92ff:fe60:98d8) |
| 2023-04-27 03:39:17 +0200 | <Clinton[m]> | [dmj](https://matrix.to/#/@dmj:libera.chat): that's not a bad idea actually! |
| 2023-04-27 03:48:25 +0200 | merijn | (~merijn@c-001-001-006.client.esciencecenter.eduvpn.nl) (Ping timeout: 240 seconds) |
| 2023-04-27 03:48:27 +0200 | nick4 | (~nick@2600:8807:9103:b700:c41a:f850:bfc2:4f27) |
| 2023-04-27 04:00:09 +0200 | drlkf | (~drlkf@192.184.163.34.bc.googleusercontent.com) |
| 2023-04-27 04:08:10 +0200 | [itchyjunk] | (~itchyjunk@user/itchyjunk/x-7353470) (Ping timeout: 260 seconds) |
| 2023-04-27 04:12:17 +0200 | <Clinton[m]> | [dmj](https://matrix.to/#/@dmj:libera.chat): yeah that is a good idea. I was thinking of making my own monad transformer but that won't compose with other transformers as well. |
| 2023-04-27 04:22:45 +0200 | codaraxis | (~codaraxis@user/codaraxis) |
| 2023-04-27 04:23:40 +0200 | codaraxis | (~codaraxis@user/codaraxis) (Max SendQ exceeded) |
| 2023-04-27 04:27:02 +0200 | [itchyjunk] | (~itchyjunk@user/itchyjunk/x-7353470) |
| 2023-04-27 04:28:07 +0200 | xff0x | (~xff0x@ai098135.d.east.v6connect.net) (Ping timeout: 255 seconds) |
| 2023-04-27 04:42:52 +0200 | Square | (~Square4@user/square) (Ping timeout: 276 seconds) |
| 2023-04-27 04:44:27 +0200 | werneta | (~werneta@70-142-214-115.lightspeed.irvnca.sbcglobal.net) (Ping timeout: 248 seconds) |
| 2023-04-27 04:45:20 +0200 | werneta | (~werneta@70-142-214-115.lightspeed.irvnca.sbcglobal.net) |
| 2023-04-27 04:46:42 +0200 | slac11015 | (~slack1256@191.125.227.218) |
| 2023-04-27 04:48:36 +0200 | jespada | (~jespada@cpc121308-nmal25-2-0-cust15.19-2.cable.virginm.net) (Read error: Connection reset by peer) |
| 2023-04-27 04:49:04 +0200 | slack1256 | (~slack1256@181.43.95.185) (Ping timeout: 248 seconds) |
| 2023-04-27 04:49:46 +0200 | talismanick | (~user@2601:204:ef80:6c80::a8e2) |
| 2023-04-27 04:51:10 +0200 | jespada_ | (~jespada@cpc121308-nmal25-2-0-cust15.19-2.cable.virginm.net) |
| 2023-04-27 04:55:37 +0200 | td_ | (~td@i5387093B.versanet.de) (Ping timeout: 250 seconds) |
| 2023-04-27 04:56:32 +0200 | FinnElija | (~finn_elij@user/finn-elija/x-0085643) (Ping timeout: 240 seconds) |
| 2023-04-27 04:57:27 +0200 | td_ | (~td@i53870923.versanet.de) |
| 2023-04-27 04:58:59 +0200 | FinnElija | (~finn_elij@user/finn-elija/x-0085643) |
| 2023-04-27 04:59:00 +0200 | slac11015 | (~slack1256@191.125.227.218) (Read error: Connection reset by peer) |
| 2023-04-27 05:03:31 +0200 | jero98772 | (~jero98772@2800:484:1d84:9000::2) (Remote host closed the connection) |
| 2023-04-27 05:03:47 +0200 | <talismanick> | I'd like to have a `Time` slot in a record, which will be filled out via optparse-generic's `getRecord` - what will parse that read-in datestring for me? |
| 2023-04-27 05:04:03 +0200 | sammelweis | (~quassel@2601:401:8200:2d4c:bd9:d04c:7f69:eb10) (Quit: No Ping reply in 180 seconds.) |
| 2023-04-27 05:04:23 +0200 | <talismanick> | something like "10-4-23" for "October 4th, 2023" |
| 2023-04-27 05:05:46 +0200 | sammelweis | (~quassel@2601:401:8200:2d4c:bd9:d04c:7f69:eb10) |
| 2023-04-27 05:17:15 +0200 | [itchyjunk] | (~itchyjunk@user/itchyjunk/x-7353470) (Remote host closed the connection) |
| 2023-04-27 05:18:49 +0200 | <talismanick> | maybe something that takes a compile-time parameter like `time :: Time "%m-%d-%y"`? |
| 2023-04-27 05:19:31 +0200 | xff0x | (~xff0x@125x103x176x34.ap125.ftth.ucom.ne.jp) |
| 2023-04-27 05:32:44 +0200 | gmg | (~user@user/gehmehgeh) (Remote host closed the connection) |
| 2023-04-27 05:33:29 +0200 | gmg | (~user@user/gehmehgeh) |
| 2023-04-27 05:36:48 +0200 | rf | (~rf@2605:59c8:1604:2210:4a2b:fc:eab3:8901) (Ping timeout: 250 seconds) |
| 2023-04-27 05:38:39 +0200 | <talismanick> | hello? |
| 2023-04-27 05:38:41 +0200 | czy | (~user@host-140-25.ilcub310.champaign.il.us.clients.pavlovmedia.net) |
| 2023-04-27 05:44:25 +0200 | rekahsoft | (~rekahsoft@bras-base-orllon1122w-grc-04-174-88-193-177.dsl.bell.ca) (Ping timeout: 240 seconds) |
| 2023-04-27 05:45:00 +0200 | merijn | (~merijn@c-001-001-006.client.esciencecenter.eduvpn.nl) |
| 2023-04-27 05:46:39 +0200 | phma | (phma@2001:5b0:210b:db18:b6ee:b0c:4d1a:fd0f) (Read error: Connection reset by peer) |
| 2023-04-27 05:47:34 +0200 | phma | (~phma@67.44.208.163) |
| 2023-04-27 05:49:33 +0200 | merijn | (~merijn@c-001-001-006.client.esciencecenter.eduvpn.nl) (Ping timeout: 255 seconds) |
| 2023-04-27 05:50:30 +0200 | czy | (~user@host-140-25.ilcub310.champaign.il.us.clients.pavlovmedia.net) (Remote host closed the connection) |
| 2023-04-27 05:57:19 +0200 | czy | (~user@host-140-25.ilcub310.champaign.il.us.clients.pavlovmedia.net) |
| 2023-04-27 06:04:20 +0200 | <dmj`> | Clinton[m]: cool |
| 2023-04-27 06:05:41 +0200 | jwiegley | (~jwiegley@76-234-69-149.lightspeed.frokca.sbcglobal.net) |
| 2023-04-27 06:08:29 +0200 | <jackdk> | talismanick: it is not clear to me whether you're asking "how do I parse times and what time library to use?" or "how do I wire `Time` into `optparse-generic`?" For the latter, I would just shove a `Time` field into a record inside a newtype (to avoid orphan instances) and then implement any missing instances that GHC complains about" |
| 2023-04-27 06:08:39 +0200 | <jackdk> | talismanick: I have a call coming up so can't help further, sorry |
| 2023-04-27 06:14:22 +0200 | jargon | (~jargon@184.101.73.92) (Remote host closed the connection) |
| 2023-04-27 06:15:18 +0200 | <Clinton[m]> | talismanick: you can do some funky stuff with `generics-sop`. Its tricky though |
| 2023-04-27 06:23:50 +0200 | <probie> | Is there a preferred dependency when one needs to carry values at the type level, or do projects that do that just tend to roll their own? (e.g. something like `class Carrying a b | a -> b where get :: proxy a -> b`) |
| 2023-04-27 06:29:42 +0200 | vglfr | (~vglfr@46.96.174.241) |
| 2023-04-27 06:30:28 +0200 | polyphem | (~polyphem@ip-109-43-50-17.web.vodafone.de) |
| 2023-04-27 06:31:09 +0200 | <dmj`> | probie: Data.Proxy is standard |
| 2023-04-27 06:35:16 +0200 | <probie> | dmj`: Sorry, I wasn't clear. Assuming my `Carrying` class above, what I want to do is something like `foo :: Foo -> Bar -> Baz; foo = some def here; data FooFun; instance Carrying FooFun (Foo -> Bar -> Baz) where get _ = foo` |
| 2023-04-27 06:38:27 +0200 | wroathe | (~wroathe@207-153-38-140.fttp.usinternet.com) |
| 2023-04-27 06:38:27 +0200 | wroathe | (~wroathe@207-153-38-140.fttp.usinternet.com) (Changing host) |
| 2023-04-27 06:38:27 +0200 | wroathe | (~wroathe@user/wroathe) |
| 2023-04-27 06:42:00 +0200 | <jwiegley> | hello, dmj`! |
| 2023-04-27 06:42:24 +0200 | jwiegley | johnw |
| 2023-04-27 06:45:57 +0200 | johnw | (~jwiegley@76-234-69-149.lightspeed.frokca.sbcglobal.net) (Quit: ZNC - http://znc.in) |
| 2023-04-27 06:46:40 +0200 | johnw | (~johnw@76-234-69-149.lightspeed.frokca.sbcglobal.net) |
| 2023-04-27 06:53:55 +0200 | nate1 | (~nate@98.45.169.16) |
| 2023-04-27 06:55:45 +0200 | ryanbooker | (uid4340@id-4340.hampstead.irccloud.com) (Quit: Connection closed for inactivity) |
| 2023-04-27 06:58:51 +0200 | nate1 | (~nate@98.45.169.16) (Ping timeout: 255 seconds) |
| 2023-04-27 07:03:12 +0200 | nick___ | (~nick@2600:8807:9103:b700:c41a:f850:bfc2:4f27) |
| 2023-04-27 07:05:37 +0200 | nick4 | (~nick@2600:8807:9103:b700:c41a:f850:bfc2:4f27) (Ping timeout: 250 seconds) |
| 2023-04-27 07:07:21 +0200 | jonathan_ | (~jonathan@h-176-10-144-60.NA.cust.bahnhof.se) |
| 2023-04-27 07:12:07 +0200 | <jackdk> | probie: https://hackage.haskell.org/package/reflection ? (what are you doing?) |
| 2023-04-27 07:13:01 +0200 | thegeekinside | (~thegeekin@189.180.38.222) (Ping timeout: 276 seconds) |
| 2023-04-27 07:16:11 +0200 | npmania1 | (~Thunderbi@121.128.226.31) |
| 2023-04-27 07:16:36 +0200 | use-value | (~Thunderbi@2a00:23c6:8a03:2f01:75c2:a71f:beaa:29bf) (Quit: use-value) |
| 2023-04-27 07:16:50 +0200 | npmania | (~Thunderbi@121.128.226.31) (Remote host closed the connection) |
| 2023-04-27 07:16:50 +0200 | npmania1 | npmania |
| 2023-04-27 07:17:12 +0200 | <probie> | jackdk: That works. I really just wanted the `Reifies` type class, but since I don't need `reify`, I'd ignored it |
| 2023-04-27 07:17:41 +0200 | takuan | (~takuan@178-116-218-225.access.telenet.be) |
| 2023-04-27 07:18:39 +0200 | <probie> | I'm just abusing `deriving via` in weird ways to save a few key strokes and blow out compile time, but sometimes I need to actually supply a function to this machinery |
| 2023-04-27 07:18:54 +0200 | dimator | (~dimator@035-132-113-218.inf.spectrum.com) |
| 2023-04-27 07:22:35 +0200 | coot | (~coot@2a02:a310:e241:1b00:ec1a:e9df:79ac:66ba) |
| 2023-04-27 07:23:19 +0200 | trev | (~trev@user/trev) |
| 2023-04-27 07:31:42 +0200 | vglfr | (~vglfr@46.96.174.241) (Ping timeout: 255 seconds) |
| 2023-04-27 07:33:43 +0200 | vglfr | (~vglfr@145.224.101.39) |
| 2023-04-27 07:36:03 +0200 | dimator | (~dimator@035-132-113-218.inf.spectrum.com) (Quit: dimator) |
| 2023-04-27 07:36:25 +0200 | Teacup | (~teacup@user/teacup) (Ping timeout: 240 seconds) |
| 2023-04-27 07:36:27 +0200 | vglfr | (~vglfr@145.224.101.39) (Read error: Connection reset by peer) |
| 2023-04-27 07:36:49 +0200 | thegeekinside | (~thegeekin@189.180.38.222) |
| 2023-04-27 07:36:59 +0200 | vglfr | (~vglfr@145.224.101.39) |
| 2023-04-27 07:37:57 +0200 | Teacup | (~teacup@user/teacup) |
| 2023-04-27 07:43:25 +0200 | vglfr | (~vglfr@145.224.101.39) (Ping timeout: 255 seconds) |
| 2023-04-27 07:44:28 +0200 | vglfr | (~vglfr@2a0d:3344:1aaa:7010:183:3e8f:75eb:1bfc) |
| 2023-04-27 07:45:24 +0200 | merijn | (~merijn@c-001-001-006.client.esciencecenter.eduvpn.nl) |
| 2023-04-27 07:46:16 +0200 | euandreh1 | (~Thunderbi@189.6.18.7) |
| 2023-04-27 07:46:52 +0200 | kritzefitz_ | (~kritzefit@debian/kritzefitz) |
| 2023-04-27 07:47:04 +0200 | biberu\ | (~biberu@user/biberu) |
| 2023-04-27 07:47:29 +0200 | remedan_ | (~remedan@ip-94-112-0-18.bb.vodafone.cz) |
| 2023-04-27 07:47:50 +0200 | elkcl_ | (~elkcl@broadband-37-110-27-252.ip.moscow.rt.ru) |
| 2023-04-27 07:47:55 +0200 | son0p | (~ff@181.136.122.143) (Killed (NickServ (GHOST command used by son0p-))) |
| 2023-04-27 07:48:04 +0200 | <dminuoso> | Clinton[m]: "I don't want to have to load the whole table" sounds rather strange. |
| 2023-04-27 07:48:23 +0200 | kritzefitz | (~kritzefit@debian/kritzefitz) (Ping timeout: 255 seconds) |
| 2023-04-27 07:48:23 +0200 | Goodbye_Vincent | (cyvahl@freakshells.net) (Quit: Ping timeout (120 seconds)) |
| 2023-04-27 07:48:23 +0200 | dumptruckman | (~dumptruck@143-42-239-71.ip.linodeusercontent.com) (Quit: ZNC - https://znc.in) |
| 2023-04-27 07:48:23 +0200 | melonai | (~mel@rnrd.eu) (Quit: ZNC 1.8.2 - https://znc.in) |
| 2023-04-27 07:48:29 +0200 | <dminuoso> | It suggests a belief, that perhaps merely having a reference to a map implies copying its entire memory. |
| 2023-04-27 07:48:42 +0200 | melonai | (~mel@rnrd.eu) |
| 2023-04-27 07:48:50 +0200 | Ristovsk- | (~Ristovski@hellomouse/perf/ristovski) |
| 2023-04-27 07:48:56 +0200 | [Ristovski] | (~Ristovski@hellomouse/perf/ristovski) (Write error: Broken pipe) |
| 2023-04-27 07:48:56 +0200 | polyphem | (~polyphem@ip-109-43-50-17.web.vodafone.de) (Ping timeout: 257 seconds) |
| 2023-04-27 07:48:56 +0200 | remedan | (~remedan@ip-94-112-0-18.bb.vodafone.cz) (Ping timeout: 257 seconds) |
| 2023-04-27 07:48:56 +0200 | elkcl | (~elkcl@broadband-37-110-27-252.ip.moscow.rt.ru) (Ping timeout: 257 seconds) |
| 2023-04-27 07:48:56 +0200 | euandreh | (~Thunderbi@189.6.18.7) (Ping timeout: 257 seconds) |
| 2023-04-27 07:48:56 +0200 | elkcl_ | elkcl |
| 2023-04-27 07:48:56 +0200 | euandreh1 | euandreh |
| 2023-04-27 07:49:11 +0200 | biberu | (~biberu@user/biberu) (Quit: ZNC - https://znc.in) |
| 2023-04-27 07:49:11 +0200 | thegeekinside | (~thegeekin@189.180.38.222) (Remote host closed the connection) |
| 2023-04-27 07:49:18 +0200 | biberu\ | biberu |
| 2023-04-27 07:49:23 +0200 | <dminuoso> | A perhaps better technique, is to not expose your StateT directly, and hide the access into the state and contained map behind an interface. |
| 2023-04-27 07:49:36 +0200 | Maxdaman1us | (~Maxdamant@user/maxdamantus) |
| 2023-04-27 07:49:44 +0200 | harveypwca | (~harveypwc@2601:246:c180:a570:3828:d8:e523:3f67) |
| 2023-04-27 07:50:00 +0200 | <dminuoso> | Say `newtype AppM a = AppM { StateT (Map K V) ... }` with some `lookup :: K -> AppM (Maybe V)` |
| 2023-04-27 07:50:09 +0200 | dumptruckman | (~dumptruck@143-42-239-71.ip.linodeusercontent.com) |
| 2023-04-27 07:51:01 +0200 | thegeekinside | (~thegeekin@189.180.38.222) |
| 2023-04-27 07:51:04 +0200 | <dminuoso> | It goes further than what dmj` suggested, by hiding even the way state is implemented (say by using Control.Monad.State.Class). This has an added benefit that you can easily replace the StateT with say an IORef. |
| 2023-04-27 07:51:43 +0200 | kritzefitz_ | kritzefitz |
| 2023-04-27 07:51:50 +0200 | Maxdamantus | (~Maxdamant@user/maxdamantus) (Ping timeout: 256 seconds) |
| 2023-04-27 07:57:11 +0200 | talismanick | (~user@2601:204:ef80:6c80::a8e2) (Ping timeout: 250 seconds) |
| 2023-04-27 08:00:02 +0200 | michalz | (~michalz@185.246.207.197) |
| 2023-04-27 08:00:22 +0200 | mmhat | (~mmh@p200300f1c701f14fee086bfffe095315.dip0.t-ipconnect.de) |
| 2023-04-27 08:01:14 +0200 | gnalzo | (~gnalzo@2a01:e0a:498:fd50:fcc6:bb5d:489a:ce8c) |
| 2023-04-27 08:11:44 +0200 | npmania | (~Thunderbi@121.128.226.31) (Ping timeout: 248 seconds) |
| 2023-04-27 08:12:03 +0200 | npmania | (~Thunderbi@138.199.21.242) |
| 2023-04-27 08:13:59 +0200 | milia | (~milia@user/milia) () |
| 2023-04-27 08:15:28 +0200 | Maxdaman1us | Maxdamantus |
| 2023-04-27 08:18:23 +0200 | echoreply | (~echoreply@45.32.163.16) (Quit: WeeChat 2.8) |
| 2023-04-27 08:18:26 +0200 | npmania | (~Thunderbi@138.199.21.242) (Ping timeout: 250 seconds) |
| 2023-04-27 08:19:42 +0200 | echoreply | (~echoreply@45.32.163.16) |
| 2023-04-27 08:20:10 +0200 | merijn | (~merijn@c-001-001-006.client.esciencecenter.eduvpn.nl) (Ping timeout: 260 seconds) |
| 2023-04-27 08:20:13 +0200 | srk_ | (~sorki@user/srk) |
| 2023-04-27 08:22:24 +0200 | srk | (~sorki@user/srk) (Ping timeout: 248 seconds) |
| 2023-04-27 08:22:54 +0200 | srk_ | srk |
| 2023-04-27 08:24:03 +0200 | wroathe | (~wroathe@user/wroathe) (Ping timeout: 250 seconds) |
| 2023-04-27 08:24:39 +0200 | chexum | (~quassel@gateway/tor-sasl/chexum) (Remote host closed the connection) |
| 2023-04-27 08:24:59 +0200 | chexum | (~quassel@gateway/tor-sasl/chexum) |
| 2023-04-27 08:33:04 +0200 | mncheck | (~mncheck@193.224.205.254) |
| 2023-04-27 08:38:03 +0200 | img | (~img@user/img) (Quit: ZNC 1.8.2 - https://znc.in) |
| 2023-04-27 08:39:16 +0200 | vglfr | (~vglfr@2a0d:3344:1aaa:7010:183:3e8f:75eb:1bfc) (Ping timeout: 252 seconds) |
| 2023-04-27 08:39:33 +0200 | vglfr | (~vglfr@2a0d:3344:1aaa:7010:bc50:996f:da58:7890) |
| 2023-04-27 08:43:00 +0200 | img | (~img@user/img) |
| 2023-04-27 08:50:49 +0200 | nick___ | (~nick@2600:8807:9103:b700:c41a:f850:bfc2:4f27) (Ping timeout: 252 seconds) |
| 2023-04-27 08:50:55 +0200 | bgs | (~bgs@212-85-160-171.dynamic.telemach.net) |
| 2023-04-27 08:55:40 +0200 | kalj | (~kalj@h-158-174-207-174.NA.cust.bahnhof.se) |
| 2023-04-27 09:05:04 +0200 | vglfr | (~vglfr@2a0d:3344:1aaa:7010:bc50:996f:da58:7890) (Ping timeout: 248 seconds) |
| 2023-04-27 09:07:08 +0200 | lortabac | (~lortabac@88.125.6.227) |
| 2023-04-27 09:08:20 +0200 | oo_miguel | (~Thunderbi@77-252-46-249.static.ip.netia.com.pl) |
| 2023-04-27 09:10:01 +0200 | gurkenglas | (~gurkengla@dynamic-046-114-179-150.46.114.pool.telefonica.de) |
| 2023-04-27 09:13:08 +0200 | vglfr | (~vglfr@88.155.54.209) |
| 2023-04-27 09:14:58 +0200 | shriekingnoise | (~shrieking@186.137.175.87) (Ping timeout: 252 seconds) |
| 2023-04-27 09:15:46 +0200 | kenran | (~user@user/kenran) |
| 2023-04-27 09:16:12 +0200 | kenran | (~user@user/kenran) (Remote host closed the connection) |
| 2023-04-27 09:18:21 +0200 | werneta | (~werneta@70-142-214-115.lightspeed.irvnca.sbcglobal.net) (Ping timeout: 255 seconds) |
| 2023-04-27 09:20:08 +0200 | werneta | (~werneta@70-142-214-115.lightspeed.irvnca.sbcglobal.net) |
| 2023-04-27 09:21:21 +0200 | acidjnk | (~acidjnk@p200300d6e715c433193c078f58513b55.dip0.t-ipconnect.de) |
| 2023-04-27 09:24:58 +0200 | jinsl- | (~jinsl@123.117.251.25) |
| 2023-04-27 09:25:05 +0200 | bgs | (~bgs@212-85-160-171.dynamic.telemach.net) (Remote host closed the connection) |
| 2023-04-27 09:25:36 +0200 | jinsl | (~jinsl@2408:8207:2552:dc20:211:32ff:fec8:6aea) (Ping timeout: 250 seconds) |
| 2023-04-27 09:32:25 +0200 | mc47 | (~mc47@xmonad/TheMC47) |
| 2023-04-27 09:34:55 +0200 | eggplantade | (~Eggplanta@2600:1700:38c5:d800:c7a:f7d7:990c:5acb) (Remote host closed the connection) |
| 2023-04-27 09:39:05 +0200 | merijn | (~merijn@145.90.225.7) |
| 2023-04-27 09:40:25 +0200 | vglfr | (~vglfr@88.155.54.209) (Ping timeout: 240 seconds) |
| 2023-04-27 09:40:52 +0200 | vglfr | (~vglfr@2a0d:3344:1aaa:7010:64df:5e0:8934:df87) |
| 2023-04-27 09:49:27 +0200 | hsw | (~hsw@2001-b030-2303-0104-0172-0025-0012-0132.hinet-ip6.hinet.net) |
| 2023-04-27 09:53:57 +0200 | zer0bitz_ | (~zer0bitz@2001:2003:f443:d600:878:5e67:f0ac:a07d) |
| 2023-04-27 09:55:27 +0200 | zer0bitz | (~zer0bitz@2001:2003:f443:d600:d2a:4f3:eccf:87eb) (Ping timeout: 265 seconds) |
| 2023-04-27 09:56:00 +0200 | machinedgod | (~machinedg@d198-53-218-113.abhsia.telus.net) |
| 2023-04-27 10:00:00 +0200 | zeenk | (~zeenk@2a02:2f04:a20f:5200::fba) |
| 2023-04-27 10:00:38 +0200 | Sgeo | (~Sgeo@user/sgeo) (Read error: Connection reset by peer) |
| 2023-04-27 10:05:12 +0200 | _ht | (~Thunderbi@82.174.52.28) |
| 2023-04-27 10:11:34 +0200 | cfricke | (~cfricke@user/cfricke) |
| 2023-04-27 10:14:24 +0200 | kalj | (~kalj@h-158-174-207-174.NA.cust.bahnhof.se) (Quit: Client closed) |
| 2023-04-27 10:14:30 +0200 | tzh | (~tzh@c-24-21-73-154.hsd1.or.comcast.net) (Quit: zzz) |
| 2023-04-27 10:15:21 +0200 | chanceyan | (~chanceyan@user/chanceyan) |
| 2023-04-27 10:15:37 +0200 | mbuf | (~Shakthi@49.207.178.186) |
| 2023-04-27 10:16:32 +0200 | chanceyan | (~chanceyan@user/chanceyan) (Client Quit) |
| 2023-04-27 10:17:36 +0200 | vglfr | (~vglfr@2a0d:3344:1aaa:7010:64df:5e0:8934:df87) (Ping timeout: 248 seconds) |
| 2023-04-27 10:20:18 +0200 | vglfr | (~vglfr@2a0d:3344:1aaa:7010:f119:b6e:3fb7:8f5e) |
| 2023-04-27 10:22:32 +0200 | acidjnk | (~acidjnk@p200300d6e715c433193c078f58513b55.dip0.t-ipconnect.de) (Ping timeout: 246 seconds) |
| 2023-04-27 10:24:02 +0200 | mmhat | (~mmh@p200300f1c701f14fee086bfffe095315.dip0.t-ipconnect.de) (Quit: WeeChat 3.8) |
| 2023-04-27 10:27:09 +0200 | enoq | (~enoq@2a05:1141:1f5:5600:b9c9:721a:599:bfe7) |
| 2023-04-27 10:27:13 +0200 | oo_miguel | (~Thunderbi@77-252-46-249.static.ip.netia.com.pl) (Quit: oo_miguel) |
| 2023-04-27 10:34:29 +0200 | vglfr | (~vglfr@2a0d:3344:1aaa:7010:f119:b6e:3fb7:8f5e) (Ping timeout: 246 seconds) |
| 2023-04-27 10:34:42 +0200 | vglfr | (~vglfr@88.155.54.209) |
| 2023-04-27 10:35:14 +0200 | gnalzo | (~gnalzo@2a01:e0a:498:fd50:fcc6:bb5d:489a:ce8c) (Quit: WeeChat 3.8) |
| 2023-04-27 10:35:48 +0200 | eggplantade | (~Eggplanta@2600:1700:38c5:d800:9c1f:523e:3299:c913) |
| 2023-04-27 10:36:51 +0200 | ubert | (~Thunderbi@2a02:8109:abc0:6434:61ed:6a1e:f689:25d3) |
| 2023-04-27 10:38:41 +0200 | harveypwca | (~harveypwc@2601:246:c180:a570:3828:d8:e523:3f67) (Quit: Leaving) |
| 2023-04-27 10:39:43 +0200 | thegeekinside | (~thegeekin@189.180.38.222) (Ping timeout: 276 seconds) |
| 2023-04-27 10:40:10 +0200 | eggplantade | (~Eggplanta@2600:1700:38c5:d800:9c1f:523e:3299:c913) (Ping timeout: 260 seconds) |
| 2023-04-27 10:40:20 +0200 | chiselfu1e | chiselfuse |
| 2023-04-27 10:42:20 +0200 | merijn | (~merijn@145.90.225.7) (Ping timeout: 265 seconds) |
| 2023-04-27 10:45:00 +0200 | ft | (~ft@p4fc2a88b.dip0.t-ipconnect.de) (Quit: leaving) |
| 2023-04-27 10:47:32 +0200 | mc47 | (~mc47@xmonad/TheMC47) (Remote host closed the connection) |
| 2023-04-27 10:47:56 +0200 | gensyst | (~gensyst@user/gensyst) |
| 2023-04-27 10:48:35 +0200 | <gensyst> | Does mkWeakIORef execute the finalizing IO action on the same thread? https://hackage.haskell.org/package/base-4.18.0.0/docs/Data-IORef.html#v:mkWeakIORef |
| 2023-04-27 10:48:49 +0200 | <gensyst> | (Otherwise, this will be kinda useless for C things that have to be closed on the same thread) |
| 2023-04-27 10:49:14 +0200 | chele | (~chele@user/chele) |
| 2023-04-27 10:49:32 +0200 | <[exa]> | I wouldn't bet on that |
| 2023-04-27 10:50:38 +0200 | <[exa]> | but well, why'd you need that? |
| 2023-04-27 10:51:48 +0200 | <geekosaur> | bound threads exist in part for C code that uses TLS |
| 2023-04-27 10:52:13 +0200 | <geekosaur> | but I don't know if weak refs obey that, as opposed to ForeignPtrs |
| 2023-04-27 10:52:38 +0200 | <[exa]> | like, the commentary below about the IORef operation reordering doesn't leave much hope tbh |
| 2023-04-27 10:52:48 +0200 | drdo | (~drdo@bl14-14-164.dsl.telepac.pt) (Quit: Ping timeout (120 seconds)) |
| 2023-04-27 10:53:10 +0200 | drdo | (~drdo@bl14-14-164.dsl.telepac.pt) |
| 2023-04-27 10:55:25 +0200 | nate1 | (~nate@98.45.169.16) |
| 2023-04-27 10:58:08 +0200 | <gensyst> | geekosaur, foreign pointers finalizer do execute on the same thread? |
| 2023-04-27 10:58:25 +0200 | <geekosaur> | they should |
| 2023-04-27 10:58:56 +0200 | <geekosaur> | if they don't I'd report it as a bug |
| 2023-04-27 10:59:44 +0200 | <gensyst> | geekosaur, The whole issue is that I've encountered a C "close" function that doesn't return void. It returns an Int, so to handle it correctly (check nonzero) I went with resourcet - type stuff like mkWeakIORef. |
| 2023-04-27 10:59:58 +0200 | <gensyst> | but now it turns out that won't work, for the different thread reason. |
| 2023-04-27 11:00:15 +0200 | nate1 | (~nate@98.45.169.16) (Ping timeout: 265 seconds) |
| 2023-04-27 11:00:26 +0200 | <gensyst> | The "safest" alternative, create "with" API isn't ideal because I want to open it for a stream and let GC handle closing |
| 2023-04-27 11:00:48 +0200 | <geekosaur> | I wouldn't want to rely on GC to close in general, tbh |
| 2023-04-27 11:00:58 +0200 | <gensyst> | Another way is to just ignore that int and create a void wrapper C function, but that's baaaad |
| 2023-04-27 11:01:15 +0200 | <geekosaur> | you have no guarantees that GC swill run in a timely manner, so resources can stick around for a lot longer than you expect them to |
| 2023-04-27 11:02:32 +0200 | <gensyst> | by what magic can they make foreignptr run on same thread, but mkWeakIORef not? |
| 2023-04-27 11:03:07 +0200 | <geekosaur> | uh? weak refs are a lot different than strong ones, and are handled completely differently |
| 2023-04-27 11:04:46 +0200 | <geekosaur> | this said it is entirely possible that they expect you to do cleanup yourself on the appropriate thread, for the reason I just said. relying on GC for external resource cleanup is pretty bad in general |
| 2023-04-27 11:05:08 +0200 | <geekosaur> | in fact resourcet exists in large part to avoid that |
| 2023-04-27 11:10:28 +0200 | <jonathan_> | Building with --pedantic allows me to find imports that aren't needed. Is there a way to remove these automatically? Going through things manually is a bit of a drag. I'm on vscode, using HLS. |
| 2023-04-27 11:11:29 +0200 | jonathan_ | (~jonathan@h-176-10-144-60.NA.cust.bahnhof.se) (Quit: Leaving) |
| 2023-04-27 11:14:02 +0200 | merijn | (~merijn@c-001-001-006.client.esciencecenter.eduvpn.nl) |
| 2023-04-27 11:17:09 +0200 | jonathan_ | (~jonathan@h-176-10-144-60.NA.cust.bahnhof.se) |
| 2023-04-27 11:20:07 +0200 | <geekosaur> | doesn't HLS have a code action for that? |
| 2023-04-27 11:22:47 +0200 | vpan | (~0@mail.elitnet.lt) |
| 2023-04-27 11:30:39 +0200 | econo | (uid147250@user/econo) (Quit: Connection closed for inactivity) |
| 2023-04-27 11:31:00 +0200 | tremon | (~tremon@83.80.159.219) |
| 2023-04-27 11:36:02 +0200 | zeenk | (~zeenk@2a02:2f04:a20f:5200::fba) (Remote host closed the connection) |
| 2023-04-27 11:36:24 +0200 | zeenk | (~zeenk@2a02:2f04:a20f:5200::7fe) |
| 2023-04-27 11:36:59 +0200 | kalj | (~kalj@h-158-174-207-174.NA.cust.bahnhof.se) |
| 2023-04-27 11:41:54 +0200 | __monty__ | (~toonn@user/toonn) |
| 2023-04-27 11:42:44 +0200 | czy | (~user@host-140-25.ilcub310.champaign.il.us.clients.pavlovmedia.net) (Remote host closed the connection) |
| 2023-04-27 11:48:20 +0200 | merijn | (~merijn@c-001-001-006.client.esciencecenter.eduvpn.nl) (Ping timeout: 246 seconds) |
| 2023-04-27 12:02:53 +0200 | coot | (~coot@2a02:a310:e241:1b00:ec1a:e9df:79ac:66ba) (Ping timeout: 250 seconds) |
| 2023-04-27 12:06:17 +0200 | <gensyst> | geekosaur, thanks for discussion |
| 2023-04-27 12:06:38 +0200 | <gensyst> | What's the best Haskell matrix channel? Is it more active than this IRC chan? |
| 2023-04-27 12:07:02 +0200 | <geekosaur> | this channel is by far the most active. but #haskell:matrix.org exists |
| 2023-04-27 12:07:45 +0200 | <geekosaur> | there's also #haskell-space:matrix.org but that's a space / collection of channels |
| 2023-04-27 12:08:25 +0200 | <gensyst> | interesting how you've stayed on irc |
| 2023-04-27 12:08:30 +0200 | <gensyst> | what's the idea? |
| 2023-04-27 12:09:14 +0200 | <geekosaur> | I'm actually on both. but I'm an op and IRC ops from matrix are really painful |
| 2023-04-27 12:10:01 +0200 | <geekosaur> | so I'm on IRC for most things but there are a few IRC channels which are mostly populated by matrix denizens (and where I'm not an op) so I use matrix for those |
| 2023-04-27 12:10:04 +0200 | xff0x | (~xff0x@125x103x176x34.ap125.ftth.ucom.ne.jp) (Ping timeout: 276 seconds) |
| 2023-04-27 12:12:01 +0200 | merijn | (~merijn@c-001-001-006.client.esciencecenter.eduvpn.nl) |
| 2023-04-27 12:14:52 +0200 | <geekosaur> | also I use matrix to monitor from my phone because IRC clients for Android are generally sucky and far too prone to disconnect on you |
| 2023-04-27 12:15:10 +0200 | acidjnk | (~acidjnk@p200300d6e715c433608801d841343278.dip0.t-ipconnect.de) |
| 2023-04-27 12:16:01 +0200 | geekosaur[m] | says hello from Element for Android |
| 2023-04-27 12:16:25 +0200 | merijn | (~merijn@c-001-001-006.client.esciencecenter.eduvpn.nl) (Ping timeout: 240 seconds) |
| 2023-04-27 12:17:00 +0200 | vglfr | (~vglfr@88.155.54.209) (Ping timeout: 260 seconds) |
| 2023-04-27 12:19:05 +0200 | werneta | (~werneta@70-142-214-115.lightspeed.irvnca.sbcglobal.net) (Ping timeout: 240 seconds) |
| 2023-04-27 12:20:31 +0200 | gensyst | (~gensyst@user/gensyst) (Ping timeout: 240 seconds) |
| 2023-04-27 12:21:46 +0200 | <gry> | geekosaur: there is quasseldroid, which runs a core elsewhere (you need to host it). I have found it amazingly friendly, including for an op. |
| 2023-04-27 12:22:21 +0200 | <geekosaur> | I know about quassel, but I have no elsewhere to run the core/host |
| 2023-04-27 12:22:30 +0200 | <geekosaur> | at least, not yet |
| 2023-04-27 12:22:30 +0200 | <gry> | geekosaur: (it is free and open source, though unfortunately not written in haskell (it is in cpp and qt)). |
| 2023-04-27 12:23:23 +0200 | <geekosaur> | and a big reason I still use IRC is I want greppable logs, which would be on the host with quassel 🙂 |
| 2023-04-27 12:23:51 +0200 | <gry> | geekosaur: i run it on a tiny vps with "networkpresence"; previously prgmr, scaleway, linode, and a home laptop with static ip and ports forwarded. to be fair, i like the latter option and when my hardware stops being a glorious mess, i most likely will go back to it. |
| 2023-04-27 12:23:55 +0200 | nschoe | (~q@2a01:e0a:8e:a190:68:b720:5bc4:5867) |
| 2023-04-27 12:31:22 +0200 | <gry> | geekosaur: there is a web ui for log search of quassel |
| 2023-04-27 12:31:44 +0200 | <gry> | geekosaur: or you can ssh and export to .txt files, then grep |
| 2023-04-27 12:32:09 +0200 | <gry> | geekosaur: android's termux includes an awesome ssh client |
| 2023-04-27 12:33:01 +0200 | drdo | (~drdo@bl14-14-164.dsl.telepac.pt) (Ping timeout: 240 seconds) |
| 2023-04-27 12:34:03 +0200 | drdo | (~drdo@bl14-14-164.dsl.telepac.pt) |
| 2023-04-27 12:39:04 +0200 | albet70 | (~xxx@2400:8902::f03c:92ff:fe60:98d8) (Remote host closed the connection) |
| 2023-04-27 12:41:18 +0200 | gnalzo | (~gnalzo@2a01:e0a:498:fd50:fcc6:bb5d:489a:ce8c) |
| 2023-04-27 12:45:10 +0200 | albet70 | (~xxx@2400:8902::f03c:92ff:fe60:98d8) |
| 2023-04-27 12:45:16 +0200 | gemmaro | (~user@240f:74:d1f0:1:ba1:e787:c9e:b1dc) |
| 2023-04-27 12:53:24 +0200 | barcisz | (~barcisz@79.191.75.215.ipv4.supernova.orange.pl) |
| 2023-04-27 13:02:50 +0200 | vglfr | (~vglfr@145.224.101.39) |
| 2023-04-27 13:05:39 +0200 | kalj | (~kalj@h-158-174-207-174.NA.cust.bahnhof.se) (Quit: Client closed) |
| 2023-04-27 13:07:02 +0200 | vglfr | (~vglfr@145.224.101.39) (Ping timeout: 246 seconds) |
| 2023-04-27 13:09:50 +0200 | xff0x | (~xff0x@ai098135.d.east.v6connect.net) |
| 2023-04-27 13:24:03 +0200 | vglfr | (~vglfr@145.224.101.39) |
| 2023-04-27 13:31:18 +0200 | akegalj | (~akegalj@89-164-123-55.dsl.iskon.hr) |
| 2023-04-27 13:33:45 +0200 | pyook | (~puke@user/puke) (Ping timeout: 240 seconds) |
| 2023-04-27 13:41:50 +0200 | monoidal | (~monoidal@2001:861:3f42:1b60:ceb5:92cc:e114:9355) |
| 2023-04-27 13:43:44 +0200 | vglfr | (~vglfr@145.224.101.39) (Ping timeout: 252 seconds) |
| 2023-04-27 13:47:00 +0200 | oljenkins | (~philipp@p5dec4bb3.dip0.t-ipconnect.de) (Ping timeout: 255 seconds) |
| 2023-04-27 13:48:43 +0200 | Square | (~Square4@user/square) |
| 2023-04-27 13:50:53 +0200 | oljenkins | (~philipp@p5dec4bb3.dip0.t-ipconnect.de) |
| 2023-04-27 13:54:36 +0200 | nschoe | (~q@2a01:e0a:8e:a190:68:b720:5bc4:5867) (Quit: Switching off) |
| 2023-04-27 13:56:45 +0200 | akegalj | (~akegalj@89-164-123-55.dsl.iskon.hr) (Ping timeout: 240 seconds) |
| 2023-04-27 14:02:41 +0200 | vglfr | (~vglfr@37.73.76.54) |
| 2023-04-27 14:03:13 +0200 | terrorjack | (~terrorjac@2a01:4f8:c17:87f8::) (Quit: The Lounge - https://thelounge.chat) |
| 2023-04-27 14:05:06 +0200 | terrorjack | (~terrorjac@2a01:4f8:c17:87f8::) |
| 2023-04-27 14:10:48 +0200 | cfricke | (~cfricke@user/cfricke) (Quit: WeeChat 3.8) |
| 2023-04-27 14:14:12 +0200 | elain4 | (~textual@2601:5c0:8200:990:e188:657f:cc6c:2c3) |
| 2023-04-27 14:15:45 +0200 | xff0x | (~xff0x@ai098135.d.east.v6connect.net) (Ping timeout: 240 seconds) |
| 2023-04-27 14:16:08 +0200 | bitdex | (~bitdex@gateway/tor-sasl/bitdex) (Ping timeout: 240 seconds) |
| 2023-04-27 14:18:21 +0200 | xff0x | (~xff0x@178.255.149.135) |
| 2023-04-27 14:23:52 +0200 | kalj | (~kalj@h-158-174-207-174.NA.cust.bahnhof.se) |
| 2023-04-27 14:30:56 +0200 | acidjnk | (~acidjnk@p200300d6e715c433608801d841343278.dip0.t-ipconnect.de) (Ping timeout: 248 seconds) |
| 2023-04-27 14:32:00 +0200 | vpan | (~0@mail.elitnet.lt) (Ping timeout: 255 seconds) |
| 2023-04-27 14:32:12 +0200 | kuribas | (~user@ip-188-118-57-242.reverse.destiny.be) |
| 2023-04-27 14:33:25 +0200 | <eldritchcookie[m> | can't believe i can't have a 9223372036854775808 long bytestring |
| 2023-04-27 14:34:09 +0200 | Mohsen | (~mohsen@196.221.18.142) |
| 2023-04-27 14:34:28 +0200 | <[exa]> | eldritchcookie[m: where'd you put it? |
| 2023-04-27 14:38:49 +0200 | vpan | (~0@mail.elitnet.lt) |
| 2023-04-27 14:39:13 +0200 | vpan | Guest8211 |
| 2023-04-27 14:40:47 +0200 | titibandit | (~titibandi@user/titibandit) |
| 2023-04-27 14:40:51 +0200 | <eldritchcookie[m> | currently ? nowhere but the Bekenstein bound is really far away |
| 2023-04-27 14:41:00 +0200 | vglfr | (~vglfr@37.73.76.54) (Ping timeout: 255 seconds) |
| 2023-04-27 14:41:19 +0200 | vglfr | (~vglfr@37.73.76.54) |
| 2023-04-27 14:42:35 +0200 | Guest8211 | vpan |
| 2023-04-27 14:43:16 +0200 | <[exa]> | at that time we'll have new haskell with longer bytestrings |
| 2023-04-27 14:43:50 +0200 | <[exa]> | (and new computers that might actually support arrays that long) |
| 2023-04-27 14:47:15 +0200 | <eldritchcookie[m> | anyone here used effectful or a effect system with dynamic effects? how do you structure effects? |
| 2023-04-27 14:47:41 +0200 | jmdaemon | (~jmdaemon@user/jmdaemon) (Ping timeout: 256 seconds) |
| 2023-04-27 14:47:53 +0200 | akegalj | (~akegalj@89-164-123-55.dsl.iskon.hr) |
| 2023-04-27 14:49:53 +0200 | Mohsen | (~mohsen@196.221.18.142) (Quit: Leaving) |
| 2023-04-27 14:50:35 +0200 | xff0x | (~xff0x@178.255.149.135) (Ping timeout: 250 seconds) |
| 2023-04-27 14:52:41 +0200 | xff0x | (~xff0x@2405:6580:b080:900:cafc:e64d:9b94:1b2b) |
| 2023-04-27 14:55:42 +0200 | <eldritchcookie[m> | also [exa] Int is only guaranteed to be able to represent up to 500 million so it could be possible to get a situation where you have a 500GB bytestring |
| 2023-04-27 14:56:21 +0200 | <eldritchcookie[m> | and wow i don't want to be the person that will debug that |
| 2023-04-27 14:56:56 +0200 | nate1 | (~nate@98.45.169.16) |
| 2023-04-27 15:01:42 +0200 | nate1 | (~nate@98.45.169.16) (Ping timeout: 255 seconds) |
| 2023-04-27 15:05:51 +0200 | Me-me | (~Me-me@user/me-me) (Quit: Something has gone terribly, terribly wrong, that being that I'm not here any more.) |
| 2023-04-27 15:09:33 +0200 | sammelweis | (~quassel@2601:401:8200:2d4c:bd9:d04c:7f69:eb10) (Quit: No Ping reply in 180 seconds.) |
| 2023-04-27 15:10:49 +0200 | sammelweis | (~quassel@2601:401:8200:2d4c:bd9:d04c:7f69:eb10) |
| 2023-04-27 15:18:05 +0200 | jle` | (~jle`@cpe-23-240-75-236.socal.res.rr.com) (Ping timeout: 240 seconds) |
| 2023-04-27 15:19:44 +0200 | <eldritchcookie[m> | does the unit type exist at runtime? |
| 2023-04-27 15:20:10 +0200 | califax | (~califax@user/califx) (Remote host closed the connection) |
| 2023-04-27 15:20:12 +0200 | <geekosaur> | no types exist at runtime |
| 2023-04-27 15:20:19 +0200 | jle` | (~jle`@cpe-23-240-75-236.socal.res.rr.com) |
| 2023-04-27 15:20:54 +0200 | <eldritchcookie[m> | sorry wrong question |
| 2023-04-27 15:21:12 +0200 | <eldritchcookie[m> | is the unit value represented by anything at runtime? |
| 2023-04-27 15:21:33 +0200 | <eldritchcookie[m> | or is it optmized away? |
| 2023-04-27 15:22:24 +0200 | <geekosaur> | it can be optimized away if it can be proven to be strict, otherwise it's a pointer which may be to bottom/exception |
| 2023-04-27 15:23:06 +0200 | <eldritchcookie[m> | what about sum types? |
| 2023-04-27 15:23:25 +0200 | <eldritchcookie[m> | like data Ex = Cons1 | Cons2 |
| 2023-04-27 15:24:12 +0200 | <geekosaur> | same, they will be represented by pointers. in that case they can't be optimized away since you have to be able to distinguish constructors |
| 2023-04-27 15:24:41 +0200 | <geekosaur> | if there's only one constructor it may be optimized away of proven strict at compile time |
| 2023-04-27 15:24:44 +0200 | <geekosaur> | *if |
| 2023-04-27 15:24:45 +0200 | <jade[m]> | https://youtu.be/I4lnCG18TaY |
| 2023-04-27 15:25:08 +0200 | <jade[m]> | this gives an overview about how haskell on the surface translates into pointers/the heap layout |
| 2023-04-27 15:26:03 +0200 | califax | (~califax@user/califx) |
| 2023-04-27 15:26:35 +0200 | pyook | (~puke@user/puke) |
| 2023-04-27 15:26:41 +0200 | <eldritchcookie[m> | say if i receive an Either String a but am expecting for it to be really rare to get the String should i throw an exception? |
| 2023-04-27 15:26:49 +0200 | <geekosaur> | in general bottom complicates this kind of optimization |
| 2023-04-27 15:27:46 +0200 | <geekosaur> | in general I would say avoid exceptions in pure code |
| 2023-04-27 15:28:20 +0200 | <eldritchcookie[m> | it is in a monad |
| 2023-04-27 15:28:43 +0200 | <geekosaur> | is it in IO, though? |
| 2023-04-27 15:29:21 +0200 | <eldritchcookie[m> | yes |
| 2023-04-27 15:29:31 +0200 | <geekosaur> | (even something like StateT s IO is not a great idea because you will lose the s on exception) |
| 2023-04-27 15:30:44 +0200 | <eldritchcookie[m> | i am using effectful so i won't lose the state on exception |
| 2023-04-27 15:31:25 +0200 | <geekosaur> | you're better off asking them, then |
| 2023-04-27 15:32:06 +0200 | <eldritchcookie[m> | ok, could you explain why we should avoid exceptions in pure code? |
| 2023-04-27 15:32:44 +0200 | <jade[m]> | because exceptions bad |
| 2023-04-27 15:33:07 +0200 | <geekosaur> | because they can only be caught in IO and you will lose anything that was being done in the pure code, plus you have no control over when/where it happens |
| 2023-04-27 15:33:11 +0200 | <jade[m]> | it's always better if functions are total |
| 2023-04-27 15:33:12 +0200 | <jade[m]> | that's one of the main reasons we write functional code; safety |
| 2023-04-27 15:33:27 +0200 | <jade[m]> | * we write purely functional code; |
| 2023-04-27 15:33:28 +0200 | <geekosaur> | in particular throwIO is safer than throw |
| 2023-04-27 15:33:39 +0200 | <geekosaur> | also because exceptions in pure code can leak out |
| 2023-04-27 15:33:44 +0200 | <geekosaur> | as bottoms |
| 2023-04-27 15:34:02 +0200 | califax | (~califax@user/califx) (Remote host closed the connection) |
| 2023-04-27 15:34:41 +0200 | <geekosaur> | so even if you try to catch them, if you don't fully force evaluation the exception may happen outside your exception handler |
| 2023-04-27 15:35:14 +0200 | <geekosaur> | but fully forcing evaluation may mean doing more work than necessary |
| 2023-04-27 15:35:16 +0200 | acidjnk | (~acidjnk@p200300d6e715c4337c794ccf8cdd483c.dip0.t-ipconnect.de) |
| 2023-04-27 15:37:00 +0200 | rf | (~rf@2605:59c8:1604:2210:be1c:913:3607:51c7) |
| 2023-04-27 15:38:48 +0200 | <geekosaur> | basically, you don't want to have to reason about bottoms outside of IO if you can help it, but if you use undefined/error/throw you're pretty much forcing yourself to have to reason about it |
| 2023-04-27 15:39:33 +0200 | <eldritchcookie[m> | ok i am convinced, however assuming normal IO monad is it better for return an Either or to throw an exception with throwIO if there isn't a clear winner what are the pros and cons of each? |
| 2023-04-27 15:39:35 +0200 | <geekosaur> | also I don't think effectful will save you here. ResourceT + MonadBaseControl would |
| 2023-04-27 15:40:02 +0200 | wroathe | (~wroathe@207-153-38-140.fttp.usinternet.com) |
| 2023-04-27 15:40:03 +0200 | wroathe | (~wroathe@207-153-38-140.fttp.usinternet.com) (Changing host) |
| 2023-04-27 15:40:03 +0200 | wroathe | (~wroathe@user/wroathe) |
| 2023-04-27 15:40:17 +0200 | <jade[m]> | eldritchcookie[m: Avoid exceptions as much as possible and only use them at the highest level of composition (imo) |
| 2023-04-27 15:40:39 +0200 | <jade[m]> | pure/total code is always preferable |
| 2023-04-27 15:40:44 +0200 | <geekosaur> | I would say reserve exceptions for things you can't recover from, as much as possible |
| 2023-04-27 15:40:47 +0200 | <jade[m]> | * always preferable and easier to maintain |
| 2023-04-27 15:40:51 +0200 | <jade[m]> | mhm |
| 2023-04-27 15:41:10 +0200 | <geekosaur> | if there is a way to recover, use Either or some other in-band failure signal |
| 2023-04-27 15:42:12 +0200 | <jade[m]> | for this reason I really don't like `head` and usually use something along the lines of `fst <$> uncons` |
| 2023-04-27 15:42:27 +0200 | <jade[m]> | or destructure directly |
| 2023-04-27 15:42:28 +0200 | gnalzo | (~gnalzo@2a01:e0a:498:fd50:fcc6:bb5d:489a:ce8c) (Quit: WeeChat 3.8) |
| 2023-04-27 15:44:21 +0200 | <eldritchcookie[m> | basically i am using decode for the size of the message so i probably would need to exit my current level and reconnect isn't this the exact situation where i should use exceptions? |
| 2023-04-27 15:45:16 +0200 | <jade[m]> | I'm not sure I understand the context but it sounds like a `Maybe` |
| 2023-04-27 15:45:22 +0200 | <geekosaur> | ^ |
| 2023-04-27 15:46:23 +0200 | <jade[m]> | Specifically in combination with the Alternative instance if I understand right what you are trying to do |
| 2023-04-27 15:47:45 +0200 | <eldritchcookie[m> | i have 2 programs communicating, in the function of send i first send a Int and then the message, in the receive i first read 8 bytes and try converting to a Int using decode, if this fails i don't think the situation is recoverable |
| 2023-04-27 15:47:45 +0200 | vglfr | (~vglfr@37.73.76.54) (Read error: Connection reset by peer) |
| 2023-04-27 15:47:48 +0200 | wroathe | (~wroathe@user/wroathe) (Ping timeout: 250 seconds) |
| 2023-04-27 15:48:03 +0200 | califax | (~califax@user/califx) |
| 2023-04-27 15:48:07 +0200 | <geekosaur> | then you have a candidate for an exception |
| 2023-04-27 15:49:37 +0200 | mc47 | (~mc47@xmonad/TheMC47) |
| 2023-04-27 15:49:55 +0200 | cheater | (~Username@user/cheater) (Ping timeout: 252 seconds) |
| 2023-04-27 15:51:26 +0200 | Digitteknohippie | (~user@user/digit) |
| 2023-04-27 15:52:26 +0200 | Digit | (~user@user/digit) (Ping timeout: 252 seconds) |
| 2023-04-27 15:54:12 +0200 | califax | (~califax@user/califx) (Remote host closed the connection) |
| 2023-04-27 15:54:28 +0200 | califax | (~califax@user/califx) |
| 2023-04-27 15:58:23 +0200 | merijn | (~merijn@86-86-29-250.fixed.kpn.net) |
| 2023-04-27 15:58:52 +0200 | gurkenglas | (~gurkengla@dynamic-046-114-179-150.46.114.pool.telefonica.de) (Ping timeout: 276 seconds) |
| 2023-04-27 15:59:06 +0200 | cheater | (~Username@user/cheater) |
| 2023-04-27 16:00:48 +0200 | thegeekinside | (~thegeekin@189.180.38.222) |
| 2023-04-27 16:00:59 +0200 | cheater_ | (~Username@user/cheater) |
| 2023-04-27 16:03:23 +0200 | cheater | (~Username@user/cheater) (Ping timeout: 248 seconds) |
| 2023-04-27 16:03:26 +0200 | cheater_ | cheater |
| 2023-04-27 16:03:44 +0200 | jinsun_ | (~jinsun@user/jinsun) |
| 2023-04-27 16:03:44 +0200 | jinsun | Guest9038 |
| 2023-04-27 16:03:44 +0200 | Guest9038 | (~jinsun@user/jinsun) (Killed (sodium.libera.chat (Nickname regained by services))) |
| 2023-04-27 16:03:44 +0200 | jinsun_ | jinsun |
| 2023-04-27 16:05:25 +0200 | mc47 | (~mc47@xmonad/TheMC47) (Ping timeout: 240 seconds) |
| 2023-04-27 16:06:34 +0200 | coot | (~coot@2a02:a310:e241:1b00:ec1a:e9df:79ac:66ba) |
| 2023-04-27 16:07:49 +0200 | shriekingnoise | (~shrieking@186.137.175.87) |
| 2023-04-27 16:12:58 +0200 | <dminuoso> | 15:33:36 geekosaur | [13:33:07] because they can only be caught in IO and you will lose anything that was being done in the pure code, plus you have no control over when/where it happens |
| 2023-04-27 16:13:03 +0200 | <dminuoso> | I think there's something even worse than that. |
| 2023-04-27 16:13:11 +0200 | <dminuoso> | pure exceptions are imprecise. |
| 2023-04-27 16:13:51 +0200 | <eldritchcookie[m> | what do you mean by imprecise? |
| 2023-04-27 16:14:27 +0200 | <dminuoso> | See https://www.microsoft.com/en-us/research/wp-content/uploads/1999/05/except.pdf |
| 2023-04-27 16:15:03 +0200 | <dminuoso> | Consider something like `error "foo" + error "bar"` |
| 2023-04-27 16:15:11 +0200 | <dminuoso> | Which error should you get? |
| 2023-04-27 16:15:59 +0200 | <dminuoso> | Being able to catch only in IO is at best an inconvenience, but the imprecise semantics of them makes it hard to recover knowledge from the fact that you caught one. |
| 2023-04-27 16:17:16 +0200 | <dminuoso> | Or have any behavior or recovery. |
| 2023-04-27 16:18:04 +0200 | <dmj`> | johnw: A belated hello o/ :) |
| 2023-04-27 16:19:03 +0200 | mc47 | (~mc47@xmonad/TheMC47) |
| 2023-04-27 16:19:35 +0200 | <dminuoso> | While it's probably fine if you just take note of the error but propagate it outwards, any recovery will be imprecise and its behavior can change with something mundane as a different optimization level in GHC. |
| 2023-04-27 16:20:43 +0200 | <geekosaur> | that's a large part of why I said you should only throw an exception if it's a situation you can't recover from |
| 2023-04-27 16:22:25 +0200 | <jade[m]> | not to mention that it makes recovery more difficult and also less explicit |
| 2023-04-27 16:22:47 +0200 | <dminuoso> | Well recovery in IO exceptions is just fine. |
| 2023-04-27 16:23:02 +0200 | <dminuoso> | IO exceptions is a feature that is widely underused in my opinion. |
| 2023-04-27 16:23:25 +0200 | mc47 | (~mc47@xmonad/TheMC47) (Ping timeout: 240 seconds) |
| 2023-04-27 16:23:40 +0200 | <dminuoso> | I guess the desire to experiment with functional ideas made things like ExceptT/MonadError far more interesting |
| 2023-04-27 16:25:31 +0200 | Sgeo | (~Sgeo@user/sgeo) |
| 2023-04-27 16:25:55 +0200 | <dminuoso> | That said |
| 2023-04-27 16:26:02 +0200 | <dminuoso> | :t upon |
| 2023-04-27 16:26:03 +0200 | <lambdabot> | (Indexable [Int] p, Data s, Data a, Applicative f) => (s -> a) -> p a (f a) -> s -> f s |
| 2023-04-27 16:26:44 +0200 | <dminuoso> | This thing makes evil use of `error` to recover structural information from arbitrary data structures. |
| 2023-04-27 16:26:46 +0200 | lortabac | (~lortabac@88.125.6.227) (Quit: WeeChat 2.8) |
| 2023-04-27 16:26:49 +0200 | <dminuoso> | > (2,4) & upon fst *~ 5 |
| 2023-04-27 16:26:51 +0200 | <lambdabot> | (10,4) |
| 2023-04-27 16:28:59 +0200 | <dminuoso> | But for this particular use case its actually benign and safe. |
| 2023-04-27 16:29:13 +0200 | <dminuoso> | Well. Sort of anyway. |
| 2023-04-27 16:32:25 +0200 | merijn | (~merijn@86-86-29-250.fixed.kpn.net) (Ping timeout: 240 seconds) |
| 2023-04-27 16:32:26 +0200 | mc47 | (~mc47@xmonad/TheMC47) |
| 2023-04-27 16:34:59 +0200 | tcard | (~tcard@2400:4051:5801:7500:cf17:befc:ff82:5303) (Remote host closed the connection) |
| 2023-04-27 16:35:12 +0200 | tcard | (~tcard@2400:4051:5801:7500:cf17:befc:ff82:5303) |
| 2023-04-27 16:35:38 +0200 | kalj | (~kalj@h-158-174-207-174.NA.cust.bahnhof.se) (Ping timeout: 245 seconds) |
| 2023-04-27 16:35:47 +0200 | Square2 | (~Square4@user/square) |
| 2023-04-27 16:36:11 +0200 | mc47 | (~mc47@xmonad/TheMC47) (Remote host closed the connection) |
| 2023-04-27 16:36:35 +0200 | mc47 | (~mc47@xmonad/TheMC47) |
| 2023-04-27 16:37:46 +0200 | Square | (~Square4@user/square) (Ping timeout: 252 seconds) |
| 2023-04-27 16:40:11 +0200 | vglfr | (~vglfr@145.224.101.39) |
| 2023-04-27 16:40:28 +0200 | vglfr | (~vglfr@145.224.101.39) (Read error: Connection reset by peer) |
| 2023-04-27 16:40:43 +0200 | vglfr | (~vglfr@37.73.72.183) |
| 2023-04-27 16:44:53 +0200 | szkl | (uid110435@id-110435.uxbridge.irccloud.com) |
| 2023-04-27 16:52:20 +0200 | pavonia | (~user@user/siracusa) (Quit: Bye!) |
| 2023-04-27 16:53:56 +0200 | mc47 | (~mc47@xmonad/TheMC47) (Remote host closed the connection) |
| 2023-04-27 17:07:43 +0200 | erisco | (~erisco@d24-141-66-165.home.cgocable.net) (Ping timeout: 260 seconds) |
| 2023-04-27 17:07:49 +0200 | ubert | (~Thunderbi@2a02:8109:abc0:6434:61ed:6a1e:f689:25d3) (Remote host closed the connection) |
| 2023-04-27 17:08:00 +0200 | erisco | (~erisco@d24-141-66-165.home.cgocable.net) |
| 2023-04-27 17:12:47 +0200 | jero98772 | (~jero98772@2800:484:1d84:9000::2) |
| 2023-04-27 17:16:09 +0200 | eggplantade | (~Eggplanta@2600:1700:38c5:d800:6cda:c72d:6503:1251) |
| 2023-04-27 17:18:06 +0200 | nick___ | (~nick@50.86.118.19) |
| 2023-04-27 17:23:59 +0200 | jonathan_ | (~jonathan@h-176-10-144-60.NA.cust.bahnhof.se) (Ping timeout: 246 seconds) |
| 2023-04-27 17:26:02 +0200 | polyphem | (~polyphem@ip-109-43-50-210.web.vodafone.de) |
| 2023-04-27 17:27:26 +0200 | pharonix71 | (~pharonix7@user/pharonix71) |
| 2023-04-27 17:33:08 +0200 | kuribas | (~user@ip-188-118-57-242.reverse.destiny.be) (Quit: ERC (IRC client for Emacs 27.1)) |
| 2023-04-27 17:34:14 +0200 | Tuplanolla | (~Tuplanoll@91-159-68-236.elisa-laajakaista.fi) |
| 2023-04-27 17:44:09 +0200 | titibandit | (~titibandi@user/titibandit) (Remote host closed the connection) |
| 2023-04-27 17:44:11 +0200 | tzh | (~tzh@c-24-21-73-154.hsd1.wa.comcast.net) |
| 2023-04-27 17:48:26 +0200 | gensyst | (~gensyst@user/gensyst) |
| 2023-04-27 17:49:18 +0200 | mmhat | (~mmh@p200300f1c701f14fee086bfffe095315.dip0.t-ipconnect.de) |
| 2023-04-27 17:49:25 +0200 | <gensyst> | When attoparsec returns back unprocessed result (ByteString), was that ByteString provided efficiently with "unsafe" operations under the hood, or was it done inefficiently with O(n) copy operations? |
| 2023-04-27 17:49:32 +0200 | xff0x | (~xff0x@2405:6580:b080:900:cafc:e64d:9b94:1b2b) (Ping timeout: 246 seconds) |
| 2023-04-27 17:49:55 +0200 | xff0x | (~xff0x@ai098135.d.east.v6connect.net) |
| 2023-04-27 17:52:52 +0200 | <c_wraith> | gensyst: probably neither? |
| 2023-04-27 17:53:46 +0200 | Square2 | Square |
| 2023-04-27 17:54:12 +0200 | <c_wraith> | gensyst: I'd expect it to use a call like drop on its latest input |
| 2023-04-27 17:56:24 +0200 | <c_wraith> | gensyst: ByteString is intended for O(1) substring-like calls. The danger is accidentally holding on to a large buffer, not accidentally copying. |
| 2023-04-27 17:58:35 +0200 | rburkholder | (~blurb@96.45.2.121) |
| 2023-04-27 17:59:02 +0200 | Square | (~Square4@user/square) (Remote host closed the connection) |
| 2023-04-27 18:06:01 +0200 | harveypwca | (~harveypwc@2601:246:c180:a570:3828:d8:e523:3f67) |
| 2023-04-27 18:07:00 +0200 | vpan | (~0@mail.elitnet.lt) (Quit: Leaving.) |
| 2023-04-27 18:10:10 +0200 | <gensyst> | c_wraith, makes sense, thanks! |
| 2023-04-27 18:14:29 +0200 | Digitteknohippie | Digit |
| 2023-04-27 18:20:41 +0200 | werneta | (~werneta@2600:1700:4819:103f:d664:ab08:b618:a81) |
| 2023-04-27 18:22:25 +0200 | vglfr | (~vglfr@37.73.72.183) (Ping timeout: 255 seconds) |
| 2023-04-27 18:22:49 +0200 | vglfr | (~vglfr@2a0d:3344:1aaa:7010:b88c:e5df:9589:2051) |
| 2023-04-27 18:27:25 +0200 | nick___ | (~nick@50.86.118.19) (Ping timeout: 240 seconds) |
| 2023-04-27 18:28:59 +0200 | chele | (~chele@user/chele) (Remote host closed the connection) |
| 2023-04-27 18:29:02 +0200 | mbuf | (~Shakthi@49.207.178.186) (Quit: Leaving) |
| 2023-04-27 18:29:23 +0200 | merijn | (~merijn@c-001-001-006.client.esciencecenter.eduvpn.nl) |
| 2023-04-27 18:30:50 +0200 | werneta | (~werneta@2600:1700:4819:103f:d664:ab08:b618:a81) (Remote host closed the connection) |
| 2023-04-27 18:32:02 +0200 | zeenk | (~zeenk@2a02:2f04:a20f:5200::7fe) (Quit: Konversation terminated!) |
| 2023-04-27 18:33:39 +0200 | polyphem | (~polyphem@ip-109-43-50-210.web.vodafone.de) (Ping timeout: 255 seconds) |
| 2023-04-27 18:34:23 +0200 | vglfr | (~vglfr@2a0d:3344:1aaa:7010:b88c:e5df:9589:2051) (Ping timeout: 264 seconds) |
| 2023-04-27 18:35:27 +0200 | merijn | (~merijn@c-001-001-006.client.esciencecenter.eduvpn.nl) (Ping timeout: 255 seconds) |
| 2023-04-27 18:39:17 +0200 | hayden_ | (~hayden@158.123.160.43) |
| 2023-04-27 18:39:35 +0200 | gemmaro | (~user@240f:74:d1f0:1:ba1:e787:c9e:b1dc) (Remote host closed the connection) |
| 2023-04-27 18:41:23 +0200 | vglfr | (~vglfr@145.224.101.39) |
| 2023-04-27 18:47:09 +0200 | hayden_ | (~hayden@158.123.160.43) (Remote host closed the connection) |
| 2023-04-27 18:47:28 +0200 | hayden_ | (~hayden@158.123.160.43) |
| 2023-04-27 18:48:04 +0200 | mmhat | (~mmh@p200300f1c701f14fee086bfffe095315.dip0.t-ipconnect.de) (Quit: WeeChat 3.8) |
| 2023-04-27 18:49:42 +0200 | jonathan_ | (~jonathan@h-176-10-144-60.NA.cust.bahnhof.se) |
| 2023-04-27 18:57:04 +0200 | szkl | (uid110435@id-110435.uxbridge.irccloud.com) (Quit: Connection closed for inactivity) |
| 2023-04-27 18:58:33 +0200 | nate1 | (~nate@98.45.169.16) |
| 2023-04-27 19:01:09 +0200 | hayden_ | (~hayden@158.123.160.43) (Ping timeout: 255 seconds) |
| 2023-04-27 19:03:21 +0200 | nate1 | (~nate@98.45.169.16) (Ping timeout: 255 seconds) |
| 2023-04-27 19:04:26 +0200 | akegalj | (~akegalj@89-164-123-55.dsl.iskon.hr) (Ping timeout: 246 seconds) |
| 2023-04-27 19:07:45 +0200 | gensyst | (~gensyst@user/gensyst) (Quit: Leaving) |
| 2023-04-27 19:08:54 +0200 | hayden_ | (~hayden@158.123.160.43) |
| 2023-04-27 19:10:43 +0200 | sammelweis | (~quassel@2601:401:8200:2d4c:bd9:d04c:7f69:eb10) (Quit: No Ping reply in 180 seconds.) |
| 2023-04-27 19:11:35 +0200 | econo | (uid147250@user/econo) |
| 2023-04-27 19:12:00 +0200 | sammelweis | (~quassel@2601:401:8200:2d4c:bd9:d04c:7f69:eb10) |
| 2023-04-27 19:15:25 +0200 | hayden_ | (~hayden@158.123.160.43) (Ping timeout: 240 seconds) |
| 2023-04-27 19:17:45 +0200 | LMonty | (~Thunderbi@ip178-67.outside.westmont.edu) |
| 2023-04-27 19:18:15 +0200 | L29Ah | (~L29Ah@wikipedia/L29Ah) () |
| 2023-04-27 19:27:10 +0200 | hayden_ | (~hayden@158.123.160.43) |
| 2023-04-27 19:30:01 +0200 | justsomeguy | (~justsomeg@user/justsomeguy) (Ping timeout: 240 seconds) |
| 2023-04-27 19:31:50 +0200 | hayden_ | (~hayden@158.123.160.43) (Ping timeout: 250 seconds) |
| 2023-04-27 19:35:50 +0200 | wootehfoot | (~wootehfoo@user/wootehfoot) |
| 2023-04-27 19:37:36 +0200 | vglfr | (~vglfr@145.224.101.39) (Read error: Connection reset by peer) |
| 2023-04-27 19:39:59 +0200 | segfaultfizzbuzz | (~segfaultf@23-93-74-212.fiber.dynamic.sonic.net) |
| 2023-04-27 19:40:22 +0200 | <segfaultfizzbuzz> | "haskell requires gc" and "you can write hardware in haskell (e.g. output verilog/program an fpga" -- how are these compatible |
| 2023-04-27 19:46:25 +0200 | <yushyin> | what's the problem? |
| 2023-04-27 19:48:05 +0200 | <segfaultfizzbuzz> | it seems like it would be hard to have a "heap" for logic |
| 2023-04-27 19:48:14 +0200 | vglfr | (~vglfr@145.224.101.39) |
| 2023-04-27 19:48:50 +0200 | remedan_ | (~remedan@ip-94-112-0-18.bb.vodafone.cz) (Read error: Connection reset by peer) |
| 2023-04-27 19:50:25 +0200 | <ddellacosta> | I'm not much of an expert on this area of Haskell, but I think most of the time wrt the latter the Haskell program is outputting code to be fed into some other system, like with copilot https://copilot-language.github.io/ |
| 2023-04-27 19:50:55 +0200 | ph88 | (~ph88@213.23.78.154) |
| 2023-04-27 19:51:01 +0200 | <segfaultfizzbuzz> | well okay, but it seems like if you are outputting logic then there would be rather strict limits on "allocation" and the like,... |
| 2023-04-27 19:52:14 +0200 | <yushyin> | do you have a specific project in mind? i can think of clash, which is a high level description language (an eDSL in haskell) to generate verilog/vhdl |
| 2023-04-27 19:52:25 +0200 | <segfaultfizzbuzz> | more that i am just curious to understand |
| 2023-04-27 19:56:19 +0200 | justsomeguy | (~justsomeg@user/justsomeguy) |
| 2023-04-27 20:01:12 +0200 | <monochrom> | jhc proves that Haskell doesn't require GC. >:) |
| 2023-04-27 20:02:27 +0200 | <Hecate> | segfaultfizzbuzz: Hardware description language is not C code for micro-controllers, it just describes Hardware. It's not for running Haskell code on it |
| 2023-04-27 20:02:41 +0200 | <monochrom> | But generally, ignore Internet hearsay. |
| 2023-04-27 20:03:16 +0200 | vglfr | (~vglfr@145.224.101.39) (Ping timeout: 276 seconds) |
| 2023-04-27 20:04:19 +0200 | <monochrom> | But yeah you can make an EDSL to be a hardware description language. |
| 2023-04-27 20:04:47 +0200 | <monochrom> | At which point the EDSL can live in pretty much any half-decent language. |
| 2023-04-27 20:04:48 +0200 | segfaultfizzbuzz | (~segfaultf@23-93-74-212.fiber.dynamic.sonic.net) (Ping timeout: 248 seconds) |
| 2023-04-27 20:05:16 +0200 | <monochrom> | And if it's DSL without E, it can be coded up in pretty much any language, half-decent or not. |
| 2023-04-27 20:05:49 +0200 | <monochrom> | Definition: A "half-decent" language is one that is good enough to admit EDSLs. >:) |
| 2023-04-27 20:06:07 +0200 | vglfr | (~vglfr@145.224.101.39) |
| 2023-04-27 20:06:11 +0200 | monoidal | (~monoidal@2001:861:3f42:1b60:ceb5:92cc:e114:9355) (Quit: Client closed) |
| 2023-04-27 20:06:15 +0200 | <monochrom> | (Counterexample: That rules out C. >:) ) |
| 2023-04-27 20:06:59 +0200 | <monochrom> | (OK OK, I forgot that CPP could help. I saw a C macro library that let you write Pascal...) |
| 2023-04-27 20:08:31 +0200 | harveypwca | (~harveypwc@2601:246:c180:a570:3828:d8:e523:3f67) (Quit: Leaving) |
| 2023-04-27 20:09:45 +0200 | gnalzo | (~gnalzo@2a01:e0a:498:fd50:fcc6:bb5d:489a:ce8c) |
| 2023-04-27 20:10:37 +0200 | hayden_ | (~hayden@158.123.160.43) |
| 2023-04-27 20:14:56 +0200 | vglfr | (~vglfr@145.224.101.39) (Ping timeout: 254 seconds) |
| 2023-04-27 20:17:37 +0200 | hayden_ | (~hayden@158.123.160.43) (Ping timeout: 255 seconds) |
| 2023-04-27 20:18:28 +0200 | markasoftware | (~quassel@107.161.26.124) (Quit: No Ping reply in 180 seconds.) |
| 2023-04-27 20:18:31 +0200 | barcisz | (~barcisz@79.191.75.215.ipv4.supernova.orange.pl) (Quit: Connection closed) |
| 2023-04-27 20:18:50 +0200 | barcisz | (~barcisz@79.191.75.215.ipv4.supernova.orange.pl) |
| 2023-04-27 20:19:44 +0200 | markasoftware | (~quassel@107.161.26.124) |
| 2023-04-27 20:19:56 +0200 | wootehfoot | (~wootehfoo@user/wootehfoot) (Read error: Connection reset by peer) |
| 2023-04-27 20:25:37 +0200 | mauke | (~mauke@user/mauke) (Quit: off) |
| 2023-04-27 20:30:20 +0200 | bilegeek | (~bilegeek@2600:1008:b019:587b:c252:9330:8577:b9b1) |
| 2023-04-27 20:32:00 +0200 | ph88 | (~ph88@213.23.78.154) (Quit: Leaving) |
| 2023-04-27 20:32:23 +0200 | merijn | (~merijn@c-001-001-006.client.esciencecenter.eduvpn.nl) |
| 2023-04-27 20:32:32 +0200 | LMonty | (~Thunderbi@ip178-67.outside.westmont.edu) (Quit: LMonty) |
| 2023-04-27 20:32:55 +0200 | jinsl- | (~jinsl@123.117.251.25) (Ping timeout: 255 seconds) |
| 2023-04-27 20:33:01 +0200 | mauke | (~mauke@user/mauke) |
| 2023-04-27 20:33:38 +0200 | jinsl | (~jinsl@123.117.251.25) |
| 2023-04-27 20:35:32 +0200 | alexherbo2 | (~alexherbo@2a02-842a-8180-4601-196c-66e3-323f-365c.rev.sfr.net) |
| 2023-04-27 20:37:37 +0200 | ft | (~ft@p4fc2a88b.dip0.t-ipconnect.de) |
| 2023-04-27 20:49:53 +0200 | sammelweis | (~quassel@2601:401:8200:2d4c:bd9:d04c:7f69:eb10) (Quit: No Ping reply in 180 seconds.) |
| 2023-04-27 20:51:09 +0200 | sammelweis | (~quassel@2601:401:8200:2d4c:bd9:d04c:7f69:eb10) |
| 2023-04-27 20:53:36 +0200 | Joao003 | (~Joao003@2804:840:8309:0:bd3a:fbd2:7590:2609) |
| 2023-04-27 20:54:06 +0200 | <Joao003> | Any equivalents to APL's fork construct? |
| 2023-04-27 21:00:21 +0200 | vglfr | (~vglfr@2a0d:3344:1aaa:7010:b88c:e5df:9589:2051) |
| 2023-04-27 21:00:30 +0200 | <eldritchcookie[m> | what does it do? |
| 2023-04-27 21:01:22 +0200 | Inst_ | (~Inst@2601:6c4:4081:54f0:e436:a84f:8a3c:7b5) |
| 2023-04-27 21:02:18 +0200 | eggplant_ | (~Eggplanta@2600:1700:38c5:d800:6cda:c72d:6503:1251) |
| 2023-04-27 21:02:25 +0200 | <mauke> | liftA2 |
| 2023-04-27 21:04:43 +0200 | eggplantade | (~Eggplanta@2600:1700:38c5:d800:6cda:c72d:6503:1251) (Ping timeout: 248 seconds) |
| 2023-04-27 21:04:43 +0200 | Inst | (~Inst@2601:6c4:4081:54f0:e436:a84f:8a3c:7b5) (Ping timeout: 248 seconds) |
| 2023-04-27 21:05:16 +0200 | u0_a202 | (~u0_a202@47.60.32.137) |
| 2023-04-27 21:05:45 +0200 | merijn | (~merijn@c-001-001-006.client.esciencecenter.eduvpn.nl) (Ping timeout: 255 seconds) |
| 2023-04-27 21:05:50 +0200 | Benzi-Junior | (~BenziJuni@dsl-149-66-52.hive.is) (Ping timeout: 265 seconds) |
| 2023-04-27 21:06:01 +0200 | B-J | (~BenziJuni@dsl-149-64-86.hive.is) |
| 2023-04-27 21:06:23 +0200 | hueso | (~root@user/hueso) (Quit: No Ping reply in 210 seconds.) |
| 2023-04-27 21:07:43 +0200 | hueso | (~root@user/hueso) |
| 2023-04-27 21:09:25 +0200 | vglfr | (~vglfr@2a0d:3344:1aaa:7010:b88c:e5df:9589:2051) (Read error: Connection reset by peer) |
| 2023-04-27 21:10:05 +0200 | vglfr | (~vglfr@145.224.101.39) |
| 2023-04-27 21:13:38 +0200 | nick___ | (~nick@98.186.193.170) |
| 2023-04-27 21:13:58 +0200 | u0_a202 | dom0 |
| 2023-04-27 21:15:45 +0200 | segfaultfizzbuzz | (~segfaultf@23-93-74-212.fiber.dynamic.sonic.net) |
| 2023-04-27 21:16:39 +0200 | Digitteknohippie | (~user@user/digit) |
| 2023-04-27 21:16:59 +0200 | justsomeguy | (~justsomeg@user/justsomeguy) (Ping timeout: 256 seconds) |
| 2023-04-27 21:17:51 +0200 | Digit | (~user@user/digit) (Ping timeout: 241 seconds) |
| 2023-04-27 21:18:12 +0200 | <fr33domlover> | o/ If I use an acid-state "database" from a single thread, so never concurrent queries/updates, does it still make sense to use acid-state? Or is there some less powerful but more efficient-for-my-use-case option? |
| 2023-04-27 21:20:21 +0200 | <fr33domlover> | (More precisely, queries might be concurrent but updates only from a single thread) |
| 2023-04-27 21:20:22 +0200 | dom0 | (~u0_a202@47.60.32.137) (Remote host closed the connection) |
| 2023-04-27 21:21:42 +0200 | Joao003 | (~Joao003@2804:840:8309:0:bd3a:fbd2:7590:2609) (Quit: Leaving) |
| 2023-04-27 21:21:43 +0200 | vglfr | (~vglfr@145.224.101.39) (Read error: Connection reset by peer) |
| 2023-04-27 21:23:22 +0200 | vglfr | (~vglfr@145.224.101.39) |
| 2023-04-27 21:23:25 +0200 | Digitteknohippie | Digit |
| 2023-04-27 21:26:23 +0200 | <c_wraith> | I wouldn't use acid-state under any circumstances |
| 2023-04-27 21:27:17 +0200 | vglfr | (~vglfr@145.224.101.39) (Read error: Connection reset by peer) |
| 2023-04-27 21:29:31 +0200 | remedan | (~remedan@ip-94-112-0-18.bb.vodafone.cz) |
| 2023-04-27 21:30:18 +0200 | pavonia | (~user@user/siracusa) |
| 2023-04-27 21:31:04 +0200 | mei | (~mei@user/mei) (Remote host closed the connection) |
| 2023-04-27 21:31:45 +0200 | coot | (~coot@2a02:a310:e241:1b00:ec1a:e9df:79ac:66ba) (Quit: coot) |
| 2023-04-27 21:34:12 +0200 | eggplant_ | (~Eggplanta@2600:1700:38c5:d800:6cda:c72d:6503:1251) (Remote host closed the connection) |
| 2023-04-27 21:34:35 +0200 | accord | (uid568320@id-568320.hampstead.irccloud.com) |
| 2023-04-27 21:39:08 +0200 | mei | (~mei@user/mei) |
| 2023-04-27 21:47:44 +0200 | jpds | (~jpds@gateway/tor-sasl/jpds) (Ping timeout: 240 seconds) |
| 2023-04-27 21:49:56 +0200 | hugo- | (znc@verdigris.lysator.liu.se) (Ping timeout: 246 seconds) |
| 2023-04-27 21:51:12 +0200 | jpds | (~jpds@gateway/tor-sasl/jpds) |
| 2023-04-27 21:51:50 +0200 | <somerandomnick> | fr33domlover: from my experience in GHC 8, `readMVar` is already very efficient, although atomic |
| 2023-04-27 21:53:28 +0200 | <somerandomnick> | @index readMVar |
| 2023-04-27 21:53:28 +0200 | <lambdabot> | Control.Concurrent.MVar, Control.Concurrent |
| 2023-04-27 21:56:32 +0200 | pharonix71 | (~pharonix7@user/pharonix71) (Remote host closed the connection) |
| 2023-04-27 21:57:12 +0200 | pharonix71 | (~pharonix7@user/pharonix71) |
| 2023-04-27 21:57:24 +0200 | justsomeguy | (~justsomeg@user/justsomeguy) |
| 2023-04-27 21:58:20 +0200 | bratwurst | (~dfadsva@2604:3d09:207f:f650::9c24) |
| 2023-04-27 21:58:55 +0200 | juri_ | (~juri@84-19-175-179.pool.ovpn.com) (Ping timeout: 260 seconds) |
| 2023-04-27 21:59:28 +0200 | segfaultfizzbuzz | (~segfaultf@23-93-74-212.fiber.dynamic.sonic.net) (Ping timeout: 248 seconds) |
| 2023-04-27 21:59:42 +0200 | juri_ | (~juri@79.140.114.190) |
| 2023-04-27 21:59:46 +0200 | zeenk | (~zeenk@2a02:2f04:a20f:5200::7fe) |
| 2023-04-27 22:05:28 +0200 | nick3 | (~nick@98.186.193.170) |
| 2023-04-27 22:07:52 +0200 | hugo- | (znc@verdigris.lysator.liu.se) |
| 2023-04-27 22:08:00 +0200 | nick___ | (~nick@98.186.193.170) (Ping timeout: 248 seconds) |
| 2023-04-27 22:16:55 +0200 | hochata | (~user@user/hochata) |
| 2023-04-27 22:17:46 +0200 | jonathan_ | (~jonathan@h-176-10-144-60.NA.cust.bahnhof.se) (Ping timeout: 255 seconds) |
| 2023-04-27 22:18:45 +0200 | juri_ | (~juri@79.140.114.190) (Read error: Connection reset by peer) |
| 2023-04-27 22:23:56 +0200 | <jade[m]> | is haskell.org down? |
| 2023-04-27 22:24:21 +0200 | <mauke> | https://www.haskell.org/ loads for me |
| 2023-04-27 22:24:34 +0200 | juri_ | (~juri@79.140.114.190) |
| 2023-04-27 22:26:15 +0200 | Square2 | (~Square4@user/square) |
| 2023-04-27 22:27:20 +0200 | <jade[m]> | oddly enough it seems to be an ISP problem |
| 2023-04-27 22:27:29 +0200 | <jade[m]> | with mobile data everything loads fine, whereas with wifi ~50% of domains seem not to resolve properly |
| 2023-04-27 22:30:39 +0200 | jmdaemon | (~jmdaemon@user/jmdaemon) |
| 2023-04-27 22:32:59 +0200 | cheater_ | (~Username@user/cheater) |
| 2023-04-27 22:34:41 +0200 | eggplantade | (~Eggplanta@2600:1700:38c5:d800:6cda:c72d:6503:1251) |
| 2023-04-27 22:35:01 +0200 | cheater | (~Username@user/cheater) (Ping timeout: 240 seconds) |
| 2023-04-27 22:35:06 +0200 | cheater_ | cheater |
| 2023-04-27 22:36:56 +0200 | FinnElija | (~finn_elij@user/finn-elija/x-0085643) (Ping timeout: 240 seconds) |
| 2023-04-27 22:38:19 +0200 | Cale | (~cale@cpe80d04ade0a03-cm80d04ade0a01.cpe.net.cable.rogers.com) (Remote host closed the connection) |
| 2023-04-27 22:39:07 +0200 | eggplantade | (~Eggplanta@2600:1700:38c5:d800:6cda:c72d:6503:1251) (Ping timeout: 248 seconds) |
| 2023-04-27 22:39:13 +0200 | FinnElija | (~finn_elij@user/finn-elija/x-0085643) |
| 2023-04-27 22:41:56 +0200 | slack1256 | (~slack1256@186.11.11.208) |
| 2023-04-27 22:43:03 +0200 | <slack1256> | I have been playing with monomer. I think this is it, this is the UI library I had been waiting for. |
| 2023-04-27 22:43:17 +0200 | <slack1256> | Does anyone has experience running it on windows? Is it even possible? |
| 2023-04-27 22:45:21 +0200 | <jade[m]> | it says it's cross platform |
| 2023-04-27 22:46:31 +0200 | <slack1256> | Yeah, but with UIs I would like more recent reports. The build uses GLEW and SDL on linux. Those must be a pain to look for on windows. |
| 2023-04-27 22:47:28 +0200 | Square2 | Square |
| 2023-04-27 22:50:15 +0200 | cheater_ | (~Username@user/cheater) |
| 2023-04-27 22:52:25 +0200 | cheater | (~Username@user/cheater) (Ping timeout: 240 seconds) |
| 2023-04-27 22:52:32 +0200 | cheater_ | cheater |
| 2023-04-27 22:57:43 +0200 | sammelweis | (~quassel@2601:401:8200:2d4c:bd9:d04c:7f69:eb10) (Quit: No Ping reply in 180 seconds.) |
| 2023-04-27 22:59:20 +0200 | sammelweis | (~quassel@2601:401:8200:2d4c:bd9:d04c:7f69:eb10) |
| 2023-04-27 22:59:29 +0200 | rf | (~rf@2605:59c8:1604:2210:be1c:913:3607:51c7) (Remote host closed the connection) |
| 2023-04-27 23:00:03 +0200 | nate1 | (~nate@98.45.169.16) |
| 2023-04-27 23:00:28 +0200 | juri_ | (~juri@79.140.114.190) (Read error: Connection reset by peer) |
| 2023-04-27 23:01:02 +0200 | __monty__ | (~toonn@user/toonn) (Quit: leaving) |
| 2023-04-27 23:01:30 +0200 | juri_ | (~juri@79.140.114.190) |
| 2023-04-27 23:02:46 +0200 | merijn | (~merijn@c-001-001-006.client.esciencecenter.eduvpn.nl) |
| 2023-04-27 23:04:31 +0200 | nate1 | (~nate@98.45.169.16) (Ping timeout: 240 seconds) |
| 2023-04-27 23:07:01 +0200 | nick4 | (~nick@98.186.193.170) |
| 2023-04-27 23:07:12 +0200 | juri_ | (~juri@79.140.114.190) (Ping timeout: 250 seconds) |
| 2023-04-27 23:07:33 +0200 | _ht | (~Thunderbi@82.174.52.28) (Quit: _ht) |
| 2023-04-27 23:08:30 +0200 | merijn | (~merijn@c-001-001-006.client.esciencecenter.eduvpn.nl) (Ping timeout: 250 seconds) |
| 2023-04-27 23:08:36 +0200 | nick3 | (~nick@98.186.193.170) (Ping timeout: 255 seconds) |
| 2023-04-27 23:11:25 +0200 | dumarrr^ | (~dumarrr@c-76-105-96-13.hsd1.ga.comcast.net) |
| 2023-04-27 23:15:13 +0200 | zeenk | (~zeenk@2a02:2f04:a20f:5200::7fe) (Quit: Konversation terminated!) |
| 2023-04-27 23:15:28 +0200 | <jackdk> | Everything is a pain on Windows though. |
| 2023-04-27 23:16:45 +0200 | mncheck | (~mncheck@193.224.205.254) (Ping timeout: 240 seconds) |
| 2023-04-27 23:19:24 +0200 | gnalzo | (~gnalzo@2a01:e0a:498:fd50:fcc6:bb5d:489a:ce8c) (Quit: WeeChat 3.8) |
| 2023-04-27 23:22:12 +0200 | coot | (~coot@2a02:a310:e241:1b00:ec1a:e9df:79ac:66ba) |
| 2023-04-27 23:26:54 +0200 | takuan | (~takuan@178-116-218-225.access.telenet.be) (Remote host closed the connection) |
| 2023-04-27 23:27:35 +0200 | coot | (~coot@2a02:a310:e241:1b00:ec1a:e9df:79ac:66ba) (Ping timeout: 260 seconds) |
| 2023-04-27 23:28:09 +0200 | coot | (~coot@2a02:a310:e241:1b00:ec1a:e9df:79ac:66ba) |
| 2023-04-27 23:28:32 +0200 | machinedgod | (~machinedg@d198-53-218-113.abhsia.telus.net) (Ping timeout: 248 seconds) |
| 2023-04-27 23:28:47 +0200 | Joao003 | (~Joao003@2804:840:8309:0:bd3a:fbd2:7590:2609) |
| 2023-04-27 23:29:16 +0200 | <Joao003> | Is there an equivalent for the S combinator, and in what library is it? |
| 2023-04-27 23:30:37 +0200 | <jackdk> | S is (<*>) for the ((->) r) applicative, isn't it? (Don't quote me here) |
| 2023-04-27 23:30:53 +0200 | <Rembane> | There should be one among the birds |
| 2023-04-27 23:30:55 +0200 | <jade[m]> | can't you just s f g x = f x (g x)? |
| 2023-04-27 23:31:20 +0200 | <hpc> | > (f <*> g) x |
| 2023-04-27 23:31:22 +0200 | <lambdabot> | error: |
| 2023-04-27 23:31:22 +0200 | <lambdabot> | • Could not deduce (Show a0) arising from a use of ‘f’ |
| 2023-04-27 23:31:22 +0200 | <lambdabot> | from the context: FromExpr t |
| 2023-04-27 23:31:24 +0200 | <jade[m]> | also wait isn't that `>>=` on `(->) r` |
| 2023-04-27 23:31:45 +0200 | <jade[m]> | > (f >>= g) x |
| 2023-04-27 23:31:46 +0200 | <lambdabot> | error: |
| 2023-04-27 23:31:46 +0200 | <lambdabot> | • Could not deduce (FromExpr a0) arising from a use of ‘f’ |
| 2023-04-27 23:31:46 +0200 | <lambdabot> | from the context: FromExpr t |
| 2023-04-27 23:31:55 +0200 | <somerandomnick> | @pl \ f g x -> f x (g x) |
| 2023-04-27 23:31:55 +0200 | <lambdabot> | ap |
| 2023-04-27 23:31:58 +0200 | <jackdk> | % :t (<*>) @ ((->) _) |
| 2023-04-27 23:31:58 +0200 | <yahb2> | <interactive>:1:11: error: parse error on input ‘->’ |
| 2023-04-27 23:32:12 +0200 | <somerandomnick> | @type ap |
| 2023-04-27 23:32:13 +0200 | <lambdabot> | Monad m => m (a -> b) -> m a -> m b |
| 2023-04-27 23:32:28 +0200 | <somerandomnick> | @type (>>=) |
| 2023-04-27 23:32:29 +0200 | <lambdabot> | Monad m => m a -> (a -> m b) -> m b |
| 2023-04-27 23:32:39 +0200 | <jackdk> | Ah, so it is what I said: `(<*>)` on the `((->) r)` applicative |
| 2023-04-27 23:32:45 +0200 | <somerandomnick> | 🙏 |
| 2023-04-27 23:32:48 +0200 | slack1256 | (~slack1256@186.11.11.208) (Remote host closed the connection) |
| 2023-04-27 23:32:52 +0200 | <jade[m]> | mh |
| 2023-04-27 23:33:07 +0200 | <somerandomnick> | @type (<*>) |
| 2023-04-27 23:33:07 +0200 | <ncf> | >>= is the same but with the arguments to f flipped |
| 2023-04-27 23:33:08 +0200 | <lambdabot> | Applicative f => f (a -> b) -> f a -> f b |
| 2023-04-27 23:33:24 +0200 | <jade[m]> | ncf: ah yeah, was thinking of that |
| 2023-04-27 23:33:36 +0200 | Kuttenbrunzer | (~Kuttenbru@2a02:8108:8b80:1d48::28da) |
| 2023-04-27 23:34:00 +0200 | <jade[m]> | I remember because I did some shenaningans with `(>>= (==))` as a fixed point thingy before |
| 2023-04-27 23:35:11 +0200 | ddellacosta | (~ddellacos@static-198-44-136-216.cust.tzulo.com) (Quit: WeeChat 3.8) |
| 2023-04-27 23:37:30 +0200 | trev | (~trev@user/trev) (Quit: trev) |
| 2023-04-27 23:37:43 +0200 | bilegeek_ | (~bilegeek@225.sub-174-208-233.myvzw.com) |
| 2023-04-27 23:38:27 +0200 | zeenk | (~zeenk@2a02:2f04:a20f:5200::7fe) |
| 2023-04-27 23:38:52 +0200 | ddellacosta | (~ddellacos@static-198-44-136-216.cust.tzulo.com) |
| 2023-04-27 23:40:08 +0200 | bilegeek | (~bilegeek@2600:1008:b019:587b:c252:9330:8577:b9b1) (Ping timeout: 250 seconds) |
| 2023-04-27 23:41:49 +0200 | Wauchope | (~Wauchope@cpc86639-seve26-2-0-cust168.13-3.cable.virginm.net) |
| 2023-04-27 23:42:05 +0200 | shriekingnoise | (~shrieking@186.137.175.87) (Quit: Quit) |
| 2023-04-27 23:42:12 +0200 | Joao003 | (~Joao003@2804:840:8309:0:bd3a:fbd2:7590:2609) (Quit: Leaving) |
| 2023-04-27 23:42:26 +0200 | <Wauchope> | Hi, forgive the probably simple question: I've a list of objects containing various elements |
| 2023-04-27 23:42:42 +0200 | <Wauchope> | I'm trying to sort the list by the first element, a string |
| 2023-04-27 23:42:43 +0200 | <monochrom> | "f (a->b) -> f a -> f b" and "(a -> f b) -> f a -> f b" are subtly very different. :) |
| 2023-04-27 23:42:54 +0200 | barcisz | (~barcisz@79.191.75.215.ipv4.supernova.orange.pl) (Quit: Connection closed) |
| 2023-04-27 23:43:11 +0200 | barcisz | (~barcisz@79.191.75.215.ipv4.supernova.orange.pl) |
| 2023-04-27 23:43:21 +0200 | <monochrom> | Is there an example? I don't know what "sort by the first element" means. |
| 2023-04-27 23:43:33 +0200 | <Wauchope> | sortBy (<here i need somethign to sort by the name attribute of each city>) unorderedObjects is where i'm at |
| 2023-04-27 23:43:58 +0200 | <Wauchope> | So say, data someObjectHere { name = String .... }, I'm trying to sort a list of someObjectHere by name |
| 2023-04-27 23:44:27 +0200 | <jade[m]> | sortBy (comparing `on` name) cities? |
| 2023-04-27 23:44:54 +0200 | <ncf> | sortOn name |
| 2023-04-27 23:45:14 +0200 | <jade[m]> | wait, where does sortOn come from? |
| 2023-04-27 23:45:18 +0200 | <Wauchope> | aha, that was much simpler than i thought wasn't aware of sortOn |
| 2023-04-27 23:46:03 +0200 | <Wauchope> | thank you! |
| 2023-04-27 23:46:53 +0200 | <jade[m]> | * ``sortBy (compare `on` name) cities``? |
| 2023-04-27 23:47:27 +0200 | <monochrom> | Data.List has sortOn |
| 2023-04-27 23:48:22 +0200 | <jade[m]> | neat, I've always been using sortBy (compare `on` f) or sortBy (comparing f) which are equivalent afaik |
| 2023-04-27 23:48:28 +0200 | <monochrom> | sortBy (comparing `on` name) cities is also right |
| 2023-04-27 23:48:42 +0200 | <monochrom> | Err wait, no. |
| 2023-04-27 23:49:18 +0200 | <monochrom> | Haha OK, comparing name, compare `on` name |
| 2023-04-27 23:49:45 +0200 | <monochrom> | "This is getting out of hand. Now there are two of them!" |
| 2023-04-27 23:50:14 +0200 | <geekosaur> | comparing came first, then was generalized to on |
| 2023-04-27 23:50:15 +0200 | <jade[m]> | haha |
| 2023-04-27 23:51:29 +0200 | <jade[m]> | isn't `on` also some "formal" combinator? |
| 2023-04-27 23:51:46 +0200 | segfaultfizzbuzz | (~segfaultf@23-93-74-212.fiber.dynamic.sonic.net) |
| 2023-04-27 23:53:42 +0200 | <Rembane> | It's a bird! |
| 2023-04-27 23:54:19 +0200 | Guest75 | (~Guest75@95.91.231.168) |
| 2023-04-27 23:54:35 +0200 | Guest42 | (~Guest42@95.91.231.168) |
| 2023-04-27 23:54:47 +0200 | <monochrom> | @type on |
| 2023-04-27 23:54:48 +0200 | <lambdabot> | (b -> b -> c) -> (a -> b) -> a -> a -> c |
| 2023-04-27 23:55:36 +0200 | <monochrom> | (b -> b -> c) -> (c -> n, b -> c) -> c -> n -> n |
| 2023-04-27 23:55:47 +0200 | <monochrom> | err wait no, doesn't work that way haha |
| 2023-04-27 23:55:48 +0200 | enoq | (~enoq@2a05:1141:1f5:5600:b9c9:721a:599:bfe7) (Quit: enoq) |
| 2023-04-27 23:55:48 +0200 | <Rembane> | Psi combinator according to this page: https://hackage.haskell.org/package/data-aviary-0.4.0/docs/Data-Aviary-Birds.html |
| 2023-04-27 23:55:48 +0200 | <somerandomnick> | @type \ f g x -> f x (g x) |
| 2023-04-27 23:55:49 +0200 | <lambdabot> | (t1 -> t2 -> t3) -> (t1 -> t2) -> t1 -> t3 |
| 2023-04-27 23:56:06 +0200 | <monochrom> | (Trying poorly to make a pun on BBC and CNN) |
| 2023-04-27 23:56:38 +0200 | <monochrom> | "psi bird" sounds very sus. |
| 2023-04-27 23:56:58 +0200 | jade[m] | uploaded an image: (24KiB) < https://libera.ems.host/_matrix/media/v3/download/matrix.org/vkGEOJJFTePopxCcIKSlqgbM/SmartSelect_… > |
| 2023-04-27 23:56:59 +0200 | <jade[m]> | Seems to be a specific case of this more general bird? |
| 2023-04-27 23:57:22 +0200 | <somerandomnick> | @compose djinn type on |
| 2023-04-27 23:57:23 +0200 | <lambdabot> | f a b c _ = a (b c) (b c) |
| 2023-04-27 23:57:32 +0200 | <somerandomnick> | nvm |
| 2023-04-27 23:58:45 +0200 | michalz | (~michalz@185.246.207.197) (Remote host closed the connection) |
| 2023-04-27 23:59:34 +0200 | <Rembane> | This is a very particular rabbithole: https://raw.githubusercontent.com/codereport/Content/main/Publications/Combinatory_Logic_and_Combi… |
| 2023-04-27 23:59:57 +0200 | <ncf> | it's `flip contramap` for an appropriate contravariant functor |
