| 2025-01-08 00:04:37 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 265 seconds) |
| 2025-01-08 00:07:59 +0100 | remedan | (~remedan@ip-62-245-108-153.bb.vodafone.cz) (Quit: Bye!) |
| 2025-01-08 00:09:23 +0100 | remedan | (~remedan@ip-62-245-108-153.bb.vodafone.cz) remedan |
| 2025-01-08 00:10:26 +0100 | machinedgod | (~machinedg@d108-173-18-100.abhsia.telus.net) machinedgod |
| 2025-01-08 00:15:09 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
| 2025-01-08 00:15:19 +0100 | ljdarj1 | (~Thunderbi@user/ljdarj) ljdarj |
| 2025-01-08 00:16:31 +0100 | target_i | (~target_i@user/target-i/x-6023099) (Quit: leaving) |
| 2025-01-08 00:18:19 +0100 | orangeFlu | (~orangeFlu@240-100-179-143.ftth.glasoperator.nl) orangeFlu |
| 2025-01-08 00:18:33 +0100 | ljdarj | (~Thunderbi@user/ljdarj) (Ping timeout: 244 seconds) |
| 2025-01-08 00:18:33 +0100 | ljdarj1 | ljdarj |
| 2025-01-08 00:21:36 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 246 seconds) |
| 2025-01-08 00:33:11 +0100 | __monty__ | (~toonn@user/toonn) (Quit: leaving) |
| 2025-01-08 00:33:12 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
| 2025-01-08 00:37:27 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 244 seconds) |
| 2025-01-08 00:40:05 +0100 | peterbecich | (~Thunderbi@syn-047-229-123-186.res.spectrum.com) (Ping timeout: 248 seconds) |
| 2025-01-08 00:41:03 +0100 | Sgeo | (~Sgeo@user/sgeo) Sgeo |
| 2025-01-08 00:41:19 +0100 | acidjnk_new | (~acidjnk@p200300d6e7283f16946c8eff929943ae.dip0.t-ipconnect.de) (Ping timeout: 252 seconds) |
| 2025-01-08 00:45:49 +0100 | sprotte24 | (~sprotte24@p200300d16f116c002c29764fca4182ef.dip0.t-ipconnect.de) (Quit: Leaving) |
| 2025-01-08 00:48:34 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
| 2025-01-08 00:53:42 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 276 seconds) |
| 2025-01-08 00:57:57 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
| 2025-01-08 00:59:23 +0100 | emmanuelux | (~emmanuelu@user/emmanuelux) emmanuelux |
| 2025-01-08 01:02:28 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 245 seconds) |
| 2025-01-08 01:05:24 +0100 | dsrt^ | (~dsrt@c-98-242-74-66.hsd1.ga.comcast.net) (Ping timeout: 252 seconds) |
| 2025-01-08 01:11:44 +0100 | connrs | (~connrs@user/connrs) (Read error: Connection reset by peer) |
| 2025-01-08 01:14:32 +0100 | dsrt^ | (dsrt@c-98-242-74-66.hsd1.ga.comcast.net) |
| 2025-01-08 01:15:41 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
| 2025-01-08 01:16:47 +0100 | kaskal | (~kaskal@84-115-237-124.cable.dynamic.surfer.at) (Quit: ZNC - https://znc.in) |
| 2025-01-08 01:17:19 +0100 | kaskal | (~kaskal@84-115-237-124.cable.dynamic.surfer.at) kaskal |
| 2025-01-08 01:21:28 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 265 seconds) |
| 2025-01-08 01:24:11 +0100 | connrs | (~connrs@user/connrs) connrs |
| 2025-01-08 01:24:23 +0100 | whatsupdoc_ | (uid509081@id-509081.hampstead.irccloud.com) (Quit: Connection closed for inactivity) |
| 2025-01-08 01:24:32 +0100 | JuanDaugherty | (~juan@user/JuanDaugherty) (Quit: JuanDaugherty) |
| 2025-01-08 01:24:49 +0100 | xff0x_ | (~xff0x@2405:6580:b080:900:7a35:e66e:66c0:36ee) (Ping timeout: 260 seconds) |
| 2025-01-08 01:31:55 +0100 | <danso> | i'm confused about why this line defines a function which returns Nothing for all inputs |
| 2025-01-08 01:32:01 +0100 | <danso> | safediv :: Int -> Int -> Maybe Int; safediv x y = Nothing >> pure (x `div` y) |
| 2025-01-08 01:32:05 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
| 2025-01-08 01:32:52 +0100 | <danso> | i expected (>>) to discard the nothing and return pure (div x y) for all inputs (sometimes failing) |
| 2025-01-08 01:33:53 +0100 | ljdarj | (~Thunderbi@user/ljdarj) (Ping timeout: 248 seconds) |
| 2025-01-08 01:36:33 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 248 seconds) |
| 2025-01-08 01:38:10 +0100 | <orangeFlu> | You are basically making a chain of monads, piping the result from one to the other. if any of those Maybe's is Nothing, the whole thing is Nothing. It's just how this monad works |
| 2025-01-08 01:41:13 +0100 | <ncf> | if you think of Maybe as an exception/failure monad, then your program is do fail; pure ... |
| 2025-01-08 01:41:23 +0100 | <ncf> | this fails instead of returning anything, as in every language |
| 2025-01-08 01:41:48 +0100 | <ncf> | in other words >> discards values, not effects |
| 2025-01-08 01:42:45 +0100 | <orangeFlu> | If you know >>=, then >> is like it except it discards the result of the computation, like ncf said, it doesn't 'bind' it to anything |
| 2025-01-08 01:45:21 +0100 | ft | (~ft@p4fc2a354.dip0.t-ipconnect.de) (Remote host closed the connection) |
| 2025-01-08 01:45:25 +0100 | notzmv | (~umar@user/notzmv) notzmv |
| 2025-01-08 01:45:55 +0100 | <EvanR> | what did you want Nothing >> something to do |
| 2025-01-08 01:46:10 +0100 | <EvanR> | if it was like 0 + something... it would have no effect |
| 2025-01-08 01:46:34 +0100 | <EvanR> | though it's acting more like 0 * something = 0 |
| 2025-01-08 01:47:28 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
| 2025-01-08 01:49:16 +0100 | ft | (~ft@p4fc2a354.dip0.t-ipconnect.de) ft |
| 2025-01-08 01:55:16 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 252 seconds) |
| 2025-01-08 01:57:21 +0100 | prasad | (~Thunderbi@c-73-75-25-251.hsd1.in.comcast.net) (Ping timeout: 248 seconds) |
| 2025-01-08 02:07:08 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
| 2025-01-08 02:08:48 +0100 | prasad | (~Thunderbi@c-73-75-25-251.hsd1.in.comcast.net) |
| 2025-01-08 02:12:21 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 276 seconds) |
| 2025-01-08 02:12:46 +0100 | xff0x | (~xff0x@fsb6a9491c.tkyc517.ap.nuro.jp) |
| 2025-01-08 02:22:30 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
| 2025-01-08 02:22:56 +0100 | Tuplanolla | (~Tuplanoll@91-159-69-59.elisa-laajakaista.fi) (Quit: Leaving.) |
| 2025-01-08 02:26:54 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 252 seconds) |
| 2025-01-08 02:32:26 +0100 | doyougnu | (~doyougnu@syn-045-046-170-068.res.spectrum.com) (Quit: ZNC 1.8.2 - https://znc.in) |
| 2025-01-08 02:32:53 +0100 | lbseale | (~quassel@user/ep1ctetus) (Quit: No Ping reply in 180 seconds.) |
| 2025-01-08 02:33:00 +0100 | saulosilva | (~saulosilv@181.216.220.21) saulosilva |
| 2025-01-08 02:34:18 +0100 | lbseale | (~quassel@user/ep1ctetus) ep1ctetus |
| 2025-01-08 02:34:43 +0100 | doyougnu | (~doyougnu@syn-045-046-170-068.res.spectrum.com) doyougnu |
| 2025-01-08 02:35:00 +0100 | <sim590> | I'm presently looking at how to make Haskell bindings for a C++ library. I'm reading https://wiki.haskell.org/Cxx_foreign_function_interface and I see that there are many approaches. From the history of the page, fficxx seems to have been brought up most recently. It doesn't mean it's best. I'm looking for an opinion as to what to look at first. |
| 2025-01-08 02:37:53 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
| 2025-01-08 02:40:15 +0100 | otto_s | (~user@p5de2f2cf.dip0.t-ipconnect.de) (Ping timeout: 265 seconds) |
| 2025-01-08 02:41:53 +0100 | otto_s | (~user@p4ff2701d.dip0.t-ipconnect.de) |
| 2025-01-08 02:42:35 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 260 seconds) |
| 2025-01-08 02:48:36 +0100 | Jeanne-Kamikaze | (~Jeanne-Ka@79.127.217.40) Jeanne-Kamikaze |
| 2025-01-08 02:53:15 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
| 2025-01-08 02:54:30 +0100 | Too2manyQ5 | (~Too2manyQ@mwg-w15.infosec.fedex.com) |
| 2025-01-08 02:57:41 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 248 seconds) |
| 2025-01-08 03:02:43 +0100 | xdminsy | (~xdminsy@117.147.71.200) (Read error: Connection reset by peer) |
| 2025-01-08 03:03:46 +0100 | xdminsy | (~xdminsy@117.147.71.200) xdminsy |
| 2025-01-08 03:04:23 +0100 | <sim590> | I guess that the page hints on the approach of making C++ look like C. They say "This seems to be the standard technique for bridging the gap between Haskell and C++.". I guess, I will look into that first. |
| 2025-01-08 03:06:10 +0100 | m1dnight_ | (~m1dnight@d8D861908.access.telenet.be) (Read error: Connection reset by peer) |
| 2025-01-08 03:08:38 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
| 2025-01-08 03:11:50 +0100 | saulosilva | (~saulosilv@181.216.220.21) (Quit: Client closed) |
| 2025-01-08 03:12:06 +0100 | m1dnight_ | (~m1dnight@d8D861908.access.telenet.be) m1dnight |
| 2025-01-08 03:13:36 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 265 seconds) |
| 2025-01-08 03:21:52 +0100 | Smiles | (uid551636@id-551636.lymington.irccloud.com) Smiles |
| 2025-01-08 03:24:00 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
| 2025-01-08 03:30:45 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 248 seconds) |
| 2025-01-08 03:37:41 +0100 | Too2manyQ5 | (~Too2manyQ@mwg-w15.infosec.fedex.com) (Quit: Client closed) |
| 2025-01-08 03:38:40 +0100 | OftenFaded48 | (~OftenFade@user/tisktisk) OftenFaded |
| 2025-01-08 03:42:02 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
| 2025-01-08 03:45:36 +0100 | weary-traveler | (~user@user/user363627) user363627 |
| 2025-01-08 03:46:22 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 252 seconds) |
| 2025-01-08 03:49:43 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
| 2025-01-08 03:55:17 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 248 seconds) |
| 2025-01-08 03:57:52 +0100 | OftenFaded48 | (~OftenFade@user/tisktisk) (Quit: Client closed) |
| 2025-01-08 04:06:07 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
| 2025-01-08 04:07:07 +0100 | JuanDaugherty | (~juan@user/JuanDaugherty) JuanDaugherty |
| 2025-01-08 04:10:52 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 252 seconds) |
| 2025-01-08 04:15:03 +0100 | Square | (~Square@user/square) (Ping timeout: 246 seconds) |
| 2025-01-08 04:15:15 +0100 | machinedgod | (~machinedg@d108-173-18-100.abhsia.telus.net) (Ping timeout: 252 seconds) |
| 2025-01-08 04:19:45 +0100 | prasad | (~Thunderbi@c-73-75-25-251.hsd1.in.comcast.net) (Ping timeout: 276 seconds) |
| 2025-01-08 04:21:30 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
| 2025-01-08 04:23:41 +0100 | <haskellbridge> | <maerwald> When will merijn fix his bouncer? |
| 2025-01-08 04:25:49 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 244 seconds) |
| 2025-01-08 04:35:36 +0100 | Square | (~Square@user/square) Square |
| 2025-01-08 04:36:54 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
| 2025-01-08 04:41:18 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 246 seconds) |
| 2025-01-08 04:47:57 +0100 | Square | (~Square@user/square) (Ping timeout: 246 seconds) |
| 2025-01-08 04:49:29 +0100 | Jeanne-Kamikaze | (~Jeanne-Ka@79.127.217.40) (Quit: Leaving) |
| 2025-01-08 04:52:17 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
| 2025-01-08 04:55:14 +0100 | caconym3 | (~caconym@user/caconym) caconym |
| 2025-01-08 04:56:33 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 248 seconds) |
| 2025-01-08 04:57:05 +0100 | caconym | (~caconym@user/caconym) (Ping timeout: 248 seconds) |
| 2025-01-08 04:57:06 +0100 | caconym3 | caconym |
| 2025-01-08 05:00:36 +0100 | bitdex | (~bitdex@gateway/tor-sasl/bitdex) bitdex |
| 2025-01-08 05:00:59 +0100 | huhu | (~huhu@2605:52c0:2:4de:f040:60ff:fe3f:6e4a) |
| 2025-01-08 05:02:36 +0100 | lianhuayu | (~lianhuayu@2605:52c0:2:4de:f040:60ff:fe3f:6e4a) |
| 2025-01-08 05:04:43 +0100 | huhu | (~huhu@2605:52c0:2:4de:f040:60ff:fe3f:6e4a) (Client Quit) |
| 2025-01-08 05:04:48 +0100 | lianhuayu | (~lianhuayu@2605:52c0:2:4de:f040:60ff:fe3f:6e4a) (Client Quit) |
| 2025-01-08 05:07:40 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
| 2025-01-08 05:08:03 +0100 | aforemny | (~aforemny@i59F4C56A.versanet.de) aforemny |
| 2025-01-08 05:08:53 +0100 | aforemny_ | (~aforemny@2001:9e8:6cc4:4700:8cff:3cd6:574c:3859) (Ping timeout: 248 seconds) |
| 2025-01-08 05:12:34 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 272 seconds) |
| 2025-01-08 05:14:00 +0100 | nkatte | (~nkatte@user/nkatte) (Quit: nkatte) |
| 2025-01-08 05:17:49 +0100 | notzmv | (~umar@user/notzmv) (Ping timeout: 265 seconds) |
| 2025-01-08 05:23:12 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
| 2025-01-08 05:24:19 +0100 | caconym | (~caconym@user/caconym) (Quit: bye) |
| 2025-01-08 05:24:44 +0100 | caconym3 | (~caconym@user/caconym) caconym |
| 2025-01-08 05:25:21 +0100 | caconym3 | caconym |
| 2025-01-08 05:26:08 +0100 | Square | (~Square4@user/square) Square |
| 2025-01-08 05:27:02 +0100 | Square | (~Square4@user/square) (Quit: Leaving) |
| 2025-01-08 05:27:52 +0100 | Square | (~Square4@user/square) Square |
| 2025-01-08 05:27:58 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 265 seconds) |
| 2025-01-08 05:32:12 +0100 | Square2 | (~Square@user/square) Square |
| 2025-01-08 05:36:29 +0100 | JuanDaugherty | (~juan@user/JuanDaugherty) (Quit: JuanDaugherty) |
| 2025-01-08 05:38:34 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
| 2025-01-08 05:41:00 +0100 | Smiles | (uid551636@id-551636.lymington.irccloud.com) (Quit: Connection closed for inactivity) |
| 2025-01-08 05:42:57 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 252 seconds) |
| 2025-01-08 05:47:45 +0100 | <hololeap> | anyone know if there is a canonical way to "lift" m [a] to ListT m a |
| 2025-01-08 05:47:56 +0100 | <hololeap> | err LogicT m a |
| 2025-01-08 05:48:39 +0100 | pavonia | (~user@user/siracusa) (Quit: Bye!) |
| 2025-01-08 05:49:01 +0100 | <hololeap> | d <- blah $ listDirectory dataDir |
| 2025-01-08 05:49:31 +0100 | <hololeap> | blah :: IO [FilePath] -> LogicT IO FilePath |
| 2025-01-08 05:49:35 +0100 | Square2 | (~Square@user/square) (Remote host closed the connection) |
| 2025-01-08 05:49:38 +0100 | peterbecich | (~Thunderbi@syn-047-229-123-186.res.spectrum.com) peterbecich |
| 2025-01-08 05:49:50 +0100 | <c_wraith> | based on the type, it's not going to be as nice as you'd want |
| 2025-01-08 05:49:59 +0100 | Square2 | (~Square@user/square) Square |
| 2025-01-08 05:50:39 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
| 2025-01-08 05:50:43 +0100 | <c_wraith> | the issue is that m [a] is a *single* action that produces an entire list. |
| 2025-01-08 05:51:00 +0100 | <c_wraith> | LogicT really wants to break that apart |
| 2025-01-08 05:52:22 +0100 | <hololeap> | c_wraith: I have some old code that uses ListT, and I'm trying to replace it so that it builds on newer base (since they removed ListT) |
| 2025-01-08 05:52:27 +0100 | <hololeap> | https://github.com/hololeap/cabal-portage/blob/main/portage-hs/test/Emerge/ParserTests.hs#L66-L76 |
| 2025-01-08 05:52:42 +0100 | <c_wraith> | you really should be using conduit or something for that |
| 2025-01-08 05:53:10 +0100 | <c_wraith> | like https://hackage.haskell.org/package/conduit-1.3.6/docs/Data-Conduit-List.html exists specifically to replace ListT |
| 2025-01-08 05:53:17 +0100 | <hololeap> | I felt like conduit would be overkill |
| 2025-01-08 05:53:22 +0100 | <hololeap> | but maybe you're right |
| 2025-01-08 05:53:30 +0100 | <c_wraith> | oh, I guess https://hackage.haskell.org/package/conduit-1.3.6/docs/Data-Conduit-Combinators.html is the better option |
| 2025-01-08 05:53:53 +0100 | <c_wraith> | conduit *is* overkill, but it's at least overkill designed for the job. |
| 2025-01-08 05:54:44 +0100 | <int-e> | @pl \x -> LogicT (\f c -> x >>= foldr f c) |
| 2025-01-08 05:54:44 +0100 | <lambdabot> | LogicT . (. foldr) . (.) . (>>=) |
| 2025-01-08 05:56:54 +0100 | Feuermagier | (~Feuermagi@user/feuermagier) Feuermagier |
| 2025-01-08 05:57:00 +0100 | <hololeap> | this was the one use-case where ListT was actually the most elegant way to do it |
| 2025-01-08 05:57:57 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 248 seconds) |
| 2025-01-08 05:58:09 +0100 | <int-e> | oh it's \m -> lift m >>= fromList |
| 2025-01-08 05:58:54 +0100 | Square2 | (~Square@user/square) (Ping timeout: 265 seconds) |
| 2025-01-08 05:59:25 +0100 | <c_wraith> | I mean, conduit really is better. |
| 2025-01-08 05:59:36 +0100 | <c_wraith> | you have tools like https://hackage.haskell.org/package/conduit-1.3.6/docs/Data-Conduit-Combinators.html#v:sourceDirec… |
| 2025-01-08 05:59:48 +0100 | <c_wraith> | which actually won't construct the whole list in memory before moving to the next step |
| 2025-01-08 06:00:35 +0100 | <c_wraith> | that's kind of the whole point of it. |
| 2025-01-08 06:00:36 +0100 | <int-e> | I'm not arguing against that, it's a separate question |
| 2025-01-08 06:01:12 +0100 | <hololeap> | I'm ok with using conduit here |
| 2025-01-08 06:03:12 +0100 | eL_Bart0 | (eL_Bart0@dietunichtguten.org) (Ping timeout: 246 seconds) |
| 2025-01-08 06:08:04 +0100 | <jackdk> | I like https://hackage.haskell.org/package/directory-tree for this sort of thing, unless you really need to handle large inputs (I haven't tested its lazy `readDirectoryWithL` function). Otherwise, yeah, streaming libraries would be the way to go. I tend to use package `streaming`. |
| 2025-01-08 06:09:00 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
| 2025-01-08 06:12:17 +0100 | forell | (~forell@user/forell) (Ping timeout: 248 seconds) |
| 2025-01-08 06:15:36 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 252 seconds) |
| 2025-01-08 06:27:03 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
| 2025-01-08 06:31:39 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 245 seconds) |
| 2025-01-08 06:36:40 +0100 | <monochrom> | Belated: Nothing >> pure foo = Nothing is pretty much forced by the monad laws. Several laws are involved, but the most damning one is k >>= pure = k, now let k be Nothing. |
| 2025-01-08 06:37:49 +0100 | <monochrom> | But if you prefer pragmatics to theory, every exception system, in every language, says that { throw Exception; return (div 5 2); } is going to throw that exception rather than return normally. |
| 2025-01-08 06:39:34 +0100 | <monochrom> | If you want Nothing ??? pure foo = pure foo, consider using <|> instead: Nothing <|> pure foo. In other words, you are looking for { throw Exception; } catch Exception { return foo; } |
| 2025-01-08 06:42:26 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
| 2025-01-08 06:50:22 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 252 seconds) |
| 2025-01-08 06:55:19 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
| 2025-01-08 06:56:13 +0100 | <haskellbridge> | <yatta> maerwald: Maybe the jokes on us and his bouncer is performing exactly as planned? |
| 2025-01-08 06:56:18 +0100 | peterbecich | (~Thunderbi@syn-047-229-123-186.res.spectrum.com) (Ping timeout: 252 seconds) |
| 2025-01-08 06:57:52 +0100 | dtman34 | (~dtman34@2601:447:d080:1a3c:effe:71d9:1c5c:6a1a) (Ping timeout: 265 seconds) |
| 2025-01-08 06:59:58 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 252 seconds) |
| 2025-01-08 07:00:22 +0100 | michalz | (~michalz@185.246.207.221) |
| 2025-01-08 07:10:28 +0100 | peterbecich | (~Thunderbi@syn-047-229-123-186.res.spectrum.com) peterbecich |
| 2025-01-08 07:10:50 +0100 | sord937 | (~sord937@gateway/tor-sasl/sord937) sord937 |
| 2025-01-08 07:11:18 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
| 2025-01-08 07:11:42 +0100 | Eoco | (~ian@128.101.131.218) (Ping timeout: 252 seconds) |
| 2025-01-08 07:12:44 +0100 | Eoco | (~ian@128.101.131.218) Eoco |
| 2025-01-08 07:15:48 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 244 seconds) |
| 2025-01-08 07:15:59 +0100 | hgolden | (~hgolden@2603:8000:9d00:3ed1:6ff3:8389:b901:6363) (Ping timeout: 260 seconds) |
| 2025-01-08 07:16:42 +0100 | hgolden | (~hgolden@2603:8000:9d00:3ed1:6ff3:8389:b901:6363) hgolden |
| 2025-01-08 07:17:52 +0100 | dtman34 | (~dtman34@2601:447:d080:1a3c:6104:fe1a:e15b:6312) dtman34 |
| 2025-01-08 07:18:09 +0100 | takuan | (~takuan@178-116-218-225.access.telenet.be) |
| 2025-01-08 07:22:01 +0100 | <hololeap> | this looks a lot cleaner with conduit: https://github.com/hololeap/cabal-portage/blob/c85bc09e23514d816b6d1936b7ebbacb058fe58a/portage-hs… |
| 2025-01-08 07:22:35 +0100 | <hololeap> | my only question is if Data.Text.IO.readFile makes sense here |
| 2025-01-08 07:23:44 +0100 | <haskellbridge> | <maerwald> jackdk: Uh... directory-tree uses lazy IO. That's not the same as a proper streaming library. It just blows up randomly in your face. |
| 2025-01-08 07:24:02 +0100 | <hololeap> | I tried using (\f -> sourceFile f .| decodeUtf8Lenient .| mapC (f,)), but for some reason it only read part of the file when I tested it |
| 2025-01-08 07:26:40 +0100 | peterbecich | (~Thunderbi@syn-047-229-123-186.res.spectrum.com) (Ping timeout: 260 seconds) |
| 2025-01-08 07:26:41 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
| 2025-01-08 07:27:56 +0100 | rvalue- | (~rvalue@user/rvalue) rvalue |
| 2025-01-08 07:28:43 +0100 | rvalue | (~rvalue@user/rvalue) (Ping timeout: 244 seconds) |
| 2025-01-08 07:31:17 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 248 seconds) |
| 2025-01-08 07:32:32 +0100 | rvalue- | rvalue |
| 2025-01-08 07:42:05 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
| 2025-01-08 07:46:28 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 252 seconds) |
| 2025-01-08 07:52:41 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
| 2025-01-08 07:54:46 +0100 | acidjnk_new | (~acidjnk@p200300d6e7283f6814cd06cb5011f3d5.dip0.t-ipconnect.de) acidjnk |
| 2025-01-08 07:55:35 +0100 | hughjfchen | (~hughjfche@vmi556545.contaboserver.net) (Quit: WeeChat 4.2.2) |
| 2025-01-08 07:56:05 +0100 | hughjfchen | (~hughjfche@vmi556545.contaboserver.net) hughjfchen |
| 2025-01-08 07:57:41 +0100 | Square2 | (~Square@user/square) Square |
| 2025-01-08 07:59:15 +0100 | famubu | (~julinuser@user/famubu) (Ping timeout: 265 seconds) |
| 2025-01-08 07:59:24 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 246 seconds) |
| 2025-01-08 08:01:37 +0100 | hughjfchen | (~hughjfche@vmi556545.contaboserver.net) (Quit: WeeChat 4.2.2) |
| 2025-01-08 08:02:09 +0100 | Square | (~Square4@user/square) (Ping timeout: 265 seconds) |
| 2025-01-08 08:04:33 +0100 | hughjfchen | (~hughjfche@vmi556545.contaboserver.net) hughjfchen |
| 2025-01-08 08:06:26 +0100 | CiaoSen | (~Jura@2a05:5800:213:8800:ca4b:d6ff:fec1:99da) CiaoSen |
| 2025-01-08 08:09:13 +0100 | <jackdk> | maerwald: True, but for simple directory-walking things I don't mind it as a way to get started, and then replace it once I've written a program that I've liked and used enough to have it blow up in my face. |
| 2025-01-08 08:09:51 +0100 | <haskellbridge> | <maerwald> I'd be surprised if you go back and actually replace it |
| 2025-01-08 08:09:57 +0100 | <haskellbridge> | <maerwald> most people never replace their prototypes |
| 2025-01-08 08:11:29 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
| 2025-01-08 08:15:49 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 245 seconds) |
| 2025-01-08 08:23:19 +0100 | agent314 | (~quassel@138.199.43.74) (Read error: Connection reset by peer) |
| 2025-01-08 08:26:51 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
| 2025-01-08 08:29:28 +0100 | <jackdk> | And to be fair, I didn't either. But I never had the lazy i/o blow up in my face, which was the forcing function to replace it with a proper streaming abstraction |
| 2025-01-08 08:30:53 +0100 | lbseale | (~quassel@user/ep1ctetus) (Ping timeout: 252 seconds) |
| 2025-01-08 08:32:47 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 244 seconds) |
| 2025-01-08 08:32:49 +0100 | Guest5708 | (~guest5708@117.222.137.69) |
| 2025-01-08 08:42:53 +0100 | mchav | (~mchav@197.221.255.246) |
| 2025-01-08 08:43:49 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
| 2025-01-08 08:46:08 +0100 | Sgeo | (~Sgeo@user/sgeo) (Read error: Connection reset by peer) |
| 2025-01-08 08:47:40 +0100 | mchav | (~mchav@197.221.255.246) (Ping timeout: 240 seconds) |
| 2025-01-08 08:48:05 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 248 seconds) |
| 2025-01-08 08:53:42 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
| 2025-01-08 08:58:12 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 246 seconds) |
| 2025-01-08 09:00:00 +0100 | caconym | (~caconym@user/caconym) (Quit: bye) |
| 2025-01-08 09:00:40 +0100 | caconym | (~caconym@user/caconym) caconym |
| 2025-01-08 09:06:55 +0100 | Square2 | (~Square@user/square) (Ping timeout: 265 seconds) |
| 2025-01-08 09:08:17 +0100 | alist | (~alist@108-224-153-186.lightspeed.cicril.sbcglobal.net) |
| 2025-01-08 09:08:56 +0100 | alist | (~alist@108-224-153-186.lightspeed.cicril.sbcglobal.net) () |
| 2025-01-08 09:09:01 +0100 | alist | (~alist@108-224-153-186.lightspeed.cicril.sbcglobal.net) |
| 2025-01-08 09:09:14 +0100 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) |
| 2025-01-08 09:09:38 +0100 | <alist> | hi all, im looking for help understanding the paper theorema for free |
| 2025-01-08 09:10:10 +0100 | <alist> | is this the right channel? haskell-in-depth seems to have very few people comparatively |
| 2025-01-08 09:11:01 +0100 | weary-traveler | (~user@user/user363627) (Quit: Konversation terminated!) |
| 2025-01-08 09:11:29 +0100 | <mauke> | potentially yes, but personally I'm not familiar with the paper (beyond the title) |
| 2025-01-08 09:12:15 +0100 | <alist> | ok, to be fair its a pretty specific question so no worries if you cant help |
| 2025-01-08 09:13:50 +0100 | <alist> | basically, on the top of page 6 the author expands the forall quantifier for relations by specializing the fold function for the types A and B. |
| 2025-01-08 09:14:55 +0100 | <alist> | but the definition of fold in that example is defined as (a->b->b)->a etc., where a, b are functions from A->A', B->B' |
| 2025-01-08 09:16:41 +0100 | <alist> | the previous page defines forall expansion and i think accordingly fold should be specialized to a, b (lowercase) in this instance my question |
| 2025-01-08 09:17:09 +0100 | <alist> | *my question is what am i missing, or did the author make a mistake |
| 2025-01-08 09:17:27 +0100 | CiaoSen | (~Jura@2a05:5800:213:8800:ca4b:d6ff:fec1:99da) (Ping timeout: 276 seconds) |
| 2025-01-08 09:20:20 +0100 | <mauke> | I don't know, but I'm reading the paper and I already found a bug on page 1 |
| 2025-01-08 09:21:06 +0100 | <alist> | where? i thought i found a bug earlier than 6 too |
| 2025-01-08 09:23:09 +0100 | <mauke> | the inc*/odds ≠ odds/inc* example shows incoherent intermediate results |
| 2025-01-08 09:23:32 +0100 | <mauke> | it's true that the results are not the same, but I don't see how they can be [2,4] and [4], respectively |
| 2025-01-08 09:24:46 +0100 | <mauke> | it's either [2,4] and [3], or [3] and [2,4], depending on how odds is defined |
| 2025-01-08 09:24:55 +0100 | <mauke> | but I have no idea how you can get [4] |
| 2025-01-08 09:25:57 +0100 | <alist> | youre right, that makes no sense |
| 2025-01-08 09:26:51 +0100 | <alist> | by saying odds "removes all odd elements from a list of integers" id argue it has to be [3], right |
| 2025-01-08 09:28:26 +0100 | <alist> | i thought this paper was very popular. maybe im sounding mean but is this like a preprint or something that is circulating online? ive never read a paper with such obvious typos |
| 2025-01-08 09:34:04 +0100 | <mauke> | I'm looking at https://www2.cs.sfu.ca/CourseCentral/831/burton/Notes/July14/free.pdf, which is a "revised version" |
| 2025-01-08 09:38:15 +0100 | <alist> | i have the same problem with its version of page 6 |
| 2025-01-08 09:40:01 +0100 | <alist> | i am disappointed because im reading a book on haskell and was interested in the fact that there is only one functiom of typs a -> a. someone recommended me this paper |
| 2025-01-08 09:40:12 +0100 | <ncf> | alist: what's wrong with page 6? |
| 2025-01-08 09:40:34 +0100 | <ncf> | the specialisation looks correct to me |
| 2025-01-08 09:40:42 +0100 | <alist> | oh i see |
| 2025-01-08 09:40:57 +0100 | mari-estel | (~mari-este@user/mari-estel) mari-estel |
| 2025-01-08 09:41:41 +0100 | <alist> | i think the specialization should be fold_{ab} since on the previous page, expanding the forall quantifier requires specializing on the type(s) it depends on |
| 2025-01-08 09:42:19 +0100 | <ncf> | what |
| 2025-01-08 09:43:31 +0100 | <ncf> | (fold, fold) : ∀ X. ∀ Y. (X → Y → Y) → Y → X* → Y |
| 2025-01-08 09:43:32 +0100 | merijn | (~merijn@77.242.116.146) merijn |
| 2025-01-08 09:43:54 +0100 | <ncf> | (fold_A, fold_A') : ∀ Y. (a → Y → Y) → Y → a* → Y |
| 2025-01-08 09:44:09 +0100 | <ncf> | (fold_AB, fold_A'B') : (a → b → b) → b → a* → b |
| 2025-01-08 09:44:48 +0100 | <ncf> | i don't see how fold_ab would be defined in the notation of the paper |
| 2025-01-08 09:48:28 +0100 | <alist> | well for one, immediately prior the author writes fold_AB is specialized to functions |
| 2025-01-08 09:48:52 +0100 | <alist> | neither A nor B are types of functions, right? |
| 2025-01-08 09:49:06 +0100 | <ncf> | no, a and b are functions |
| 2025-01-08 09:49:52 +0100 | <alist> | rigfold_AB is the specialization of fold to the types |
| 2025-01-08 09:50:14 +0100 | <ncf> | instead of relations 𝒜 : A ⇔ A', ℬ : B ⇔ B' we use functions a : A → A', b : B → B' |
| 2025-01-08 09:50:27 +0100 | <alist> | oh hm |
| 2025-01-08 09:50:29 +0100 | <ncf> | i.e. functional relations |
| 2025-01-08 09:51:09 +0100 | <alist> | OH i see |
| 2025-01-08 09:51:16 +0100 | <alist> | because functions are relations hehe |
| 2025-01-08 09:51:37 +0100 | <mari-estel> | hm sortof |
| 2025-01-08 09:51:49 +0100 | <alist> | well they correspond directly |
| 2025-01-08 09:52:02 +0100 | <mari-estel> | functions are unidirectional |
| 2025-01-08 09:52:32 +0100 | <mauke> | unidirectional relations are valid. we don't discriminate |
| 2025-01-08 09:53:05 +0100 | <alist> | well really in the authors definition of relation as just a subset of the cross product they are |
| 2025-01-08 09:53:10 +0100 | <mari-estel> | well then yes, functions are relations, but relations are not functions |
| 2025-01-08 09:53:26 +0100 | <alist> | so either way i understand what hes writing better |
| 2025-01-08 09:53:47 +0100 | <ncf> | a white horse is a horse |
| 2025-01-08 09:54:39 +0100 | Guest5708 | (~guest5708@117.222.137.69) (Leaving) |
| 2025-01-08 09:54:57 +0100 | <alist> | ncf: thanks for the help!! |
| 2025-01-08 09:56:30 +0100 | machinedgod | (~machinedg@d108-173-18-100.abhsia.telus.net) machinedgod |
| 2025-01-08 10:00:26 +0100 | alist | (~alist@108-224-153-186.lightspeed.cicril.sbcglobal.net) (Remote host closed the connection) |
| 2025-01-08 10:01:00 +0100 | <monochrom> | Sometimes you really want to use a non-function relation, e.g., when proving that e :: forall a. Maybe (a->a) can only be Nothing or Just id. |
| 2025-01-08 10:02:00 +0100 | <monochrom> | Err, that one still works with a function relation. |
| 2025-01-08 10:03:02 +0100 | lortabac | (~lortabac@2a01:e0a:541:b8f0:55ab:e185:7f81:54a4) |
| 2025-01-08 10:03:59 +0100 | <monochrom> | But if you replace Maybe by the System F encoding, i.e., prove that e :: forall a. forall b. b -> ((a -> a) -> b) -> b has only two possibilities, that will require you to use a non-function relation for b. |
| 2025-01-08 10:05:14 +0100 | <monochrom> | But the paper doesn't contain such advanced examples. All examples are basically natural transformations like "oh rev is a natural transformation". Those don't need arbitrary relations, just functions. |
| 2025-01-08 10:10:34 +0100 | alist | (~alist@108-224-153-186.lightspeed.cicril.sbcglobal.net) |
| 2025-01-08 10:18:11 +0100 | l__k | (~student@85.172.111.143) |
| 2025-01-08 10:18:14 +0100 | l_k | (~student@85.172.76.134) (Read error: Connection reset by peer) |
| 2025-01-08 10:22:49 +0100 | Smiles | (uid551636@id-551636.lymington.irccloud.com) Smiles |
| 2025-01-08 10:28:00 +0100 | <monochrom> | @free fold :: (x -> y -> y) -> y -> [x] -> y |
| 2025-01-08 10:28:00 +0100 | <lambdabot> | (forall x. g . h x = k (f x) . g) => g . fold h y = fold k (g y) . $map f |
| 2025-01-08 10:31:56 +0100 | lxsameer | (~lxsameer@Serene/lxsameer) lxsameer |
| 2025-01-08 10:33:28 +0100 | eL_Bart0 | (eL_Bart0@dietunichtguten.org) |
| 2025-01-08 10:34:56 +0100 | ash3en | (~Thunderbi@2a03:7846:b6eb:101:93ac:a90a:da67:f207) ash3en |
| 2025-01-08 10:36:44 +0100 | tzh | (~tzh@c-76-115-131-146.hsd1.or.comcast.net) (Quit: zzz) |
| 2025-01-08 10:36:48 +0100 | mari-estel | m_ |
| 2025-01-08 10:37:16 +0100 | m_ | mari-estel |
| 2025-01-08 10:37:49 +0100 | merijn | (~merijn@77.242.116.146) (Ping timeout: 244 seconds) |
| 2025-01-08 10:41:21 +0100 | jespada | (~jespada@2800:a4:f9:a300:c8c1:20a5:1a94:f1) jespada |
| 2025-01-08 10:43:31 +0100 | <ncf> | monochrom: what relation do you use for b? i'd think a function Bool → b is enough |
| 2025-01-08 10:44:08 +0100 | p3n | (~p3n@2a00:19a0:3:7c:0:d9c6:7cf6:1) (Quit: ZNC 1.8.2 - https://znc.in) |
| 2025-01-08 10:44:41 +0100 | p3n | (~p3n@217.198.124.246) p3n |
| 2025-01-08 10:44:47 +0100 | mud | (~mud@user/kadoban) (Remote host closed the connection) |
| 2025-01-08 10:45:12 +0100 | mud | (~mud@user/kadoban) kadoban |
| 2025-01-08 10:46:01 +0100 | Guest17 | (~Guest17@91.243.81.204) |
| 2025-01-08 10:46:58 +0100 | ash3en | (~Thunderbi@2a03:7846:b6eb:101:93ac:a90a:da67:f207) (Ping timeout: 265 seconds) |
| 2025-01-08 10:51:14 +0100 | merijn | (~merijn@77.242.116.146) merijn |
| 2025-01-08 10:55:22 +0100 | CiaoSen | (~Jura@2a05:5800:213:8800:ca4b:d6ff:fec1:99da) CiaoSen |
| 2025-01-08 10:55:43 +0100 | forell | (~forell@user/forell) forell |
| 2025-01-08 10:57:56 +0100 | merijn | (~merijn@77.242.116.146) (Ping timeout: 252 seconds) |
| 2025-01-08 10:58:36 +0100 | xff0x | (~xff0x@fsb6a9491c.tkyc517.ap.nuro.jp) (Ping timeout: 246 seconds) |
| 2025-01-08 11:01:01 +0100 | merijn | (~merijn@77.242.116.146) merijn |
| 2025-01-08 11:04:23 +0100 | tomsmeding | (~tomsmedin@2a01:4f8:c0c:5e5e::2) (Quit: ZNC 1.9.1 - https://znc.in) |
| 2025-01-08 11:06:06 +0100 | tomsmeding | (~tomsmedin@2a01:4f8:c0c:5e5e::2) tomsmeding |
| 2025-01-08 11:07:16 +0100 | <haskellbridge> | <magic_rb> is there no way to directly read from a Unboxed Mutable Vector using Int# as the index and read the undoxed type directly? https://hackage.haskell.org/package/vector-0.13.2.0/docs/Data-Vector-Unboxed-Mutable.html i dont see anything in the module |
| 2025-01-08 11:13:34 +0100 | tnt1 | (~Thunderbi@user/tnt1) (Ping timeout: 272 seconds) |
| 2025-01-08 11:13:37 +0100 | tnt2 | (~Thunderbi@user/tnt1) tnt1 |
| 2025-01-08 11:15:55 +0100 | tnt2 | tnt1 |
| 2025-01-08 11:17:22 +0100 | Guest17 | (~Guest17@91.243.81.204) (Quit: Client closed) |
| 2025-01-08 11:17:34 +0100 | Guest17 | (~Guest17@91.243.81.204) |
| 2025-01-08 11:19:20 +0100 | <tomsmeding> | are you sure you need that for performance? |
| 2025-01-08 11:19:31 +0100 | <tomsmeding> | recall my earlier comments on the ghc unboxer |
| 2025-01-08 11:20:10 +0100 | <tomsmeding> | but unboxed types in an unboxed vector (as opposed to a _storable_ vector) are stored in struct-of-arrays format |
| 2025-01-08 11:20:29 +0100 | <tomsmeding> | and also, the 'a' here is a boxed type |
| 2025-01-08 11:21:28 +0100 | <tomsmeding> | an `MVector s (Int, Int)` in the end consists of _two_ `MutableByteArray s`es |
| 2025-01-08 11:21:43 +0100 | <tomsmeding> | one containing the fst components, the other containing the snd components |
| 2025-01-08 11:22:38 +0100 | <tomsmeding> | are you sure you're not looking for Data.Vector.Storable.Mutable? |
| 2025-01-08 11:23:14 +0100 | <tomsmeding> | if you want to read manually from a MutableByteArray, https://hackage.haskell.org/package/base-4.19.0.0/docs/GHC-Exts.html#v:readInt64Array-35- |
| 2025-01-08 11:26:03 +0100 | <tomsmeding> | https://hackage.haskell.org/package/vector-0.13.2.0/src/internal/unbox-tuple-instances |
| 2025-01-08 11:28:58 +0100 | Guest17 | (~Guest17@91.243.81.204) (Quit: Client closed) |
| 2025-01-08 11:29:55 +0100 | jespada | (~jespada@2800:a4:f9:a300:c8c1:20a5:1a94:f1) (Quit: My Mac has gone to sleep. ZZZzzz…) |
| 2025-01-08 11:33:27 +0100 | __monty__ | (~toonn@user/toonn) toonn |
| 2025-01-08 11:33:38 +0100 | mari50420 | (~mari-este@user/mari-estel) mari-estel |
| 2025-01-08 11:34:30 +0100 | <haskellbridge> | <magic_rb> tomsmeding i looked at the core and its doing boxing unboxing in a single call to exists, i counted 3 or 4 boxes unboxes |
| 2025-01-08 11:34:42 +0100 | <haskellbridge> | <magic_rb> Which is a lot if exists is called hundreds of times per frame |
| 2025-01-08 11:35:45 +0100 | mari-estel | (~mari-este@user/mari-estel) (Ping timeout: 260 seconds) |
| 2025-01-08 11:37:03 +0100 | <merijn> | magic_rb: You should probably take some time browsing ghc-prim if you haven't yet :) |
| 2025-01-08 11:37:32 +0100 | <haskellbridge> | <magic_rb> yeah i didnt want to go that deep, was hoping i could avoid it :) |
| 2025-01-08 11:37:37 +0100 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 2025-01-08 11:37:54 +0100 | <tomsmeding> | I see |
| 2025-01-08 11:38:36 +0100 | <merijn> | magic_rb: Once you start wondering "how do I avoid boxing/reboxing" you can't really avoid looking at that kinda stuff ;) |
| 2025-01-08 11:39:00 +0100 | <haskellbridge> | <magic_rb> yeah fair, loking at the primitive package and PrimArray, i think thats what i need |
| 2025-01-08 11:39:03 +0100 | <merijn> | That said, (most of) ghc-prim is perfectly safe and really not that complicated |
| 2025-01-08 11:39:24 +0100 | <haskellbridge> | <magic_rb> should i not be using primitive? |
| 2025-01-08 11:39:26 +0100 | <merijn> | Just not very portable, but that only matters in a universe where we still pretend anything but GHC matters :P |
| 2025-01-08 11:39:34 +0100 | <merijn> | primitive is fine too |
| 2025-01-08 11:39:47 +0100 | <merijn> | it's a slightly higher wrapper around stuff like ghc-prim |
| 2025-01-08 11:42:06 +0100 | <haskellbridge> | <magic_rb> Im kind of tempted to implement the sparse sets as foreign primops in C |
| 2025-01-08 11:42:28 +0100 | <haskellbridge> | <magic_rb> But that would then mean id have to write different preambles per architecture which i dont really feel like doing :) |
| 2025-01-08 11:43:36 +0100 | <merijn> | magic_rb: Right, but that's basically the same as writing it directly using ghc-prim, except then the portability problem is outsourced to GHC ;) |
| 2025-01-08 11:43:42 +0100 | ubert | (~Thunderbi@2a02:8109:ab8a:5a00:bcbc:bf70:1416:c809) ubert |
| 2025-01-08 11:44:08 +0100 | <haskellbridge> | <magic_rb> Benefit of doing it in C is that there is only one implementation that i can call into from C for free |
| 2025-01-08 11:45:06 +0100 | <haskellbridge> | <magic_rb> For certain systems it might be beneficial to do the bulk of the logic in C. Currently the way the renderer works is it every frame copies all my entities that need to be rendered into a storable array of structs and then passes that to C which loops over it. Its surprisingly fast lol |
| 2025-01-08 11:45:10 +0100 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) |
| 2025-01-08 11:54:02 +0100 | notzmv | (~umar@user/notzmv) notzmv |
| 2025-01-08 11:54:04 +0100 | siborg | (sid630849@user/rawles) () |
| 2025-01-08 11:56:49 +0100 | xff0x | (~xff0x@2405:6580:b080:900:6a01:c501:bf5a:df58) |
| 2025-01-08 11:57:49 +0100 | dsrt^ | (dsrt@c-98-242-74-66.hsd1.ga.comcast.net) (Ping timeout: 252 seconds) |
| 2025-01-08 12:02:19 +0100 | kuribas | (~user@ptr-17d51eo5v3yo1z5ic8l.18120a2.ip6.access.telenet.be) kuribas |
| 2025-01-08 12:05:51 +0100 | tomsmeding | . o O ( if the point was to implement a filesystem in haskell, why is there a bunch of C code ) |
| 2025-01-08 12:06:52 +0100 | <kuribas> | Anyone going to FP dag? |
| 2025-01-08 12:07:24 +0100 | <tomsmeding> | o/ |
| 2025-01-08 12:07:32 +0100 | <tomsmeding> | saw you were a speaker :) |
| 2025-01-08 12:07:52 +0100 | <kuribas> | yeah :) |
| 2025-01-08 12:08:50 +0100 | <mari50420> | Kristof Bastiaensen? |
| 2025-01-08 12:08:56 +0100 | <kuribas> | it's me. |
| 2025-01-08 12:10:29 +0100 | <mari50420> | hm the idea of a layered SQL generator is compelling |
| 2025-01-08 12:13:49 +0100 | <kuribas> | I had hoped to work on the postgresql version, but I've been sick last week. |
| 2025-01-08 12:16:49 +0100 | <kuribas> | The mysql version is usable though. |
| 2025-01-08 12:17:07 +0100 | mari50420 | (~mari-este@user/mari-estel) (Remote host closed the connection) |
| 2025-01-08 12:17:23 +0100 | mari-estel | (~mari-este@user/mari-estel) mari-estel |
| 2025-01-08 12:22:04 +0100 | xff0x | (~xff0x@2405:6580:b080:900:6a01:c501:bf5a:df58) (Ping timeout: 245 seconds) |
| 2025-01-08 12:23:12 +0100 | paotsaq | (~paotsaq@127.209.37.188.rev.vodafone.pt) (Quit: ZNC 1.9.0 - https://znc.in) |
| 2025-01-08 12:23:30 +0100 | paotsaq | (~paotsaq@127.209.37.188.rev.vodafone.pt) |
| 2025-01-08 12:26:47 +0100 | ubert | (~Thunderbi@2a02:8109:ab8a:5a00:bcbc:bf70:1416:c809) (Remote host closed the connection) |
| 2025-01-08 12:27:00 +0100 | ubert | (~Thunderbi@2a02:8109:ab8a:5a00:13a7:b05b:d8a6:72f8) ubert |
| 2025-01-08 12:27:47 +0100 | p3n | (~p3n@217.198.124.246) (Quit: ZNC 1.8.2 - https://znc.in) |
| 2025-01-08 12:31:37 +0100 | p3n | (~p3n@217.198.124.246) p3n |
| 2025-01-08 12:34:29 +0100 | paotsaq | (~paotsaq@127.209.37.188.rev.vodafone.pt) (Ping timeout: 260 seconds) |
| 2025-01-08 12:34:41 +0100 | homo | (~homo@user/homo) homo |
| 2025-01-08 12:36:14 +0100 | paotsaq | (~paotsaq@127.209.37.188.rev.vodafone.pt) |
| 2025-01-08 12:40:48 +0100 | paotsaq | (~paotsaq@127.209.37.188.rev.vodafone.pt) (Ping timeout: 246 seconds) |
| 2025-01-08 12:40:50 +0100 | Smiles | (uid551636@id-551636.lymington.irccloud.com) (Quit: Connection closed for inactivity) |
| 2025-01-08 12:46:16 +0100 | Nixkernal | (~Nixkernal@90.74.198.178.dynamic.cust.swisscom.net) Nixkernal |
| 2025-01-08 12:48:23 +0100 | jespada | (~jespada@2800:a4:f9:a300:c8c1:20a5:1a94:f1) jespada |