| 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 |
| 2025-01-08 12:55:35 +0100 | dsrt^ | (dsrt@c-98-242-74-66.hsd1.ga.comcast.net) |
| 2025-01-08 12:57:19 +0100 | paotsaq | (~paotsaq@127.209.37.188.rev.vodafone.pt) |
| 2025-01-08 13:00:14 +0100 | AlexNoo_ | (~AlexNoo@94.233.240.147) |
| 2025-01-08 13:02:35 +0100 | AlexZenon | (~alzenon@5.139.233.96) (Ping timeout: 252 seconds) |
| 2025-01-08 13:03:45 +0100 | AlexNoo | (~AlexNoo@5.139.233.96) (Ping timeout: 265 seconds) |
| 2025-01-08 13:04:23 +0100 | <merijn> | kuribas: I didn't get around to arranging time to get there, sadly |
| 2025-01-08 13:06:33 +0100 | AlexZenon | (~alzenon@94.233.240.147) |
| 2025-01-08 13:07:45 +0100 | JuanDaugherty | (~juan@user/JuanDaugherty) JuanDaugherty |
| 2025-01-08 13:07:49 +0100 | <haskellbridge> | <magic_rb> tomsmeding: nah this is my game engine :) |
| 2025-01-08 13:08:38 +0100 | <JuanDaugherty> | i have looked for a thing and not found it so asking |
| 2025-01-08 13:09:43 +0100 | <JuanDaugherty> | which is somekina pkg which is a generalization of content mgt or of actual dataschemes, e.g. relational ones |
| 2025-01-08 13:10:29 +0100 | Smiles | (uid551636@id-551636.lymington.irccloud.com) Smiles |
| 2025-01-08 13:10:38 +0100 | <JuanDaugherty> | the hs content mgt things i found just do CMS housekeeping and dont do anything about the above |
| 2025-01-08 13:11:06 +0100 | <JuanDaugherty> | *or even of |
| 2025-01-08 13:11:59 +0100 | ash3en | (~Thunderbi@2a03:7846:b6eb:101:93ac:a90a:da67:f207) ash3en |
| 2025-01-08 13:12:08 +0100 | Nixkernal | (~Nixkernal@90.74.198.178.dynamic.cust.swisscom.net) (Quit: https://quassel-irc.org - Chat comfortably. Anywhere.) |
| 2025-01-08 13:12:34 +0100 | <JuanDaugherty> | 40 years ago i did a project which i called 'matadatabase' because it's charter was to abstract of over a variety of sources of DOD training data |
| 2025-01-08 13:13:27 +0100 | <JuanDaugherty> | so that's an example use case, a generalization is called for there to abstract over the different actual, in that case, mainframe, data systems |
| 2025-01-08 13:14:12 +0100 | <JuanDaugherty> | i haven found anything substantailly in that direction on hackage or elsewhere |
| 2025-01-08 13:15:11 +0100 | xff0x | (~xff0x@2405:6580:b080:900:6d94:dd0b:4250:b8b3) |
| 2025-01-08 13:15:58 +0100 | <JuanDaugherty> | and ofc not a hs monoglot so anything highly relevant is good but a hs pkg would be ideal |
| 2025-01-08 13:16:46 +0100 | cjay | (cjay@nerdbox.nerd2nerd.org) (Remote host closed the connection) |
| 2025-01-08 13:19:51 +0100 | <albet70> | async used for client, is simple, can async used for server since server's connection is always making? |
| 2025-01-08 13:21:42 +0100 | <JuanDaugherty> | thx in advance for any responses that come later which i'll see on the log |
| 2025-01-08 13:22:11 +0100 | <ash3en> | can anyone help with this issue in tidal cycles? https://github.com/tidalcycles/Tidal/issues/1094 |
| 2025-01-08 13:24:03 +0100 | p3n | (~p3n@217.198.124.246) (Quit: ZNC 1.8.2 - https://znc.in) |
| 2025-01-08 13:27:58 +0100 | <JuanDaugherty> | https://github.com/polyfy/polylith this closure thing is as close as i've found sofar and again not on the money of practical data scheme generalization |
| 2025-01-08 13:28:17 +0100 | <JuanDaugherty> | *clojure |
| 2025-01-08 13:28:50 +0100 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 2025-01-08 13:29:39 +0100 | <JuanDaugherty> | just doin a last call due dili for prior art |
| 2025-01-08 13:36:19 +0100 | Sciencentistguy | (~sciencent@hacksoc/ordinary-member) (Ping timeout: 252 seconds) |
| 2025-01-08 13:38:23 +0100 | JuanDaugherty | also to be clear, training data above was data about training programs not its current common usage |
| 2025-01-08 13:38:36 +0100 | p3n | (~p3n@217.198.124.246) p3n |
| 2025-01-08 13:40:18 +0100 | p3n | (~p3n@217.198.124.246) (Remote host closed the connection) |
| 2025-01-08 13:41:09 +0100 | Sciencentistguy | (~sciencent@hacksoc/ordinary-member) sciencentistguy |
| 2025-01-08 13:43:43 +0100 | avdb13 | (~avdb13@2001-14ba-a0a9-f200--18c.rev.dnainternet.fi) |
| 2025-01-08 13:49:12 +0100 | kuribas | (~user@ptr-17d51eo5v3yo1z5ic8l.18120a2.ip6.access.telenet.be) (Ping timeout: 244 seconds) |
| 2025-01-08 13:51:43 +0100 | AlexNoo_ | AlexNoo |
| 2025-01-08 13:53:17 +0100 | p3n | (~p3n@2a00:19a0:3:7c:0:d9c6:7cf6:1) p3n |
| 2025-01-08 13:59:23 +0100 | JuanDaugherty | (~juan@user/JuanDaugherty) (Quit: JuanDaugherty) |
| 2025-01-08 14:02:25 +0100 | merijn | (~merijn@77.242.116.146) (Ping timeout: 244 seconds) |
| 2025-01-08 14:05:25 +0100 | CiaoSen | (~Jura@2a05:5800:213:8800:ca4b:d6ff:fec1:99da) (Ping timeout: 248 seconds) |
| 2025-01-08 14:05:52 +0100 | nkatte | (~nkatte@user/nkatte) nkatte |
| 2025-01-08 14:11:16 +0100 | homo | (~homo@user/homo) (Read error: Connection reset by peer) |
| 2025-01-08 14:12:35 +0100 | merijn | (~merijn@77.242.116.146) merijn |
| 2025-01-08 14:13:37 +0100 | l_k | (~student@213.24.135.42) |
| 2025-01-08 14:17:06 +0100 | l__k | (~student@85.172.111.143) (Ping timeout: 276 seconds) |
| 2025-01-08 14:40:28 +0100 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) |
| 2025-01-08 14:49:10 +0100 | bitdex | (~bitdex@gateway/tor-sasl/bitdex) (Quit: = "") |
| 2025-01-08 14:51:41 +0100 | weary-traveler | (~user@user/user363627) user363627 |
| 2025-01-08 14:51:42 +0100 | weary-traveler | (~user@user/user363627) (Remote host closed the connection) |
| 2025-01-08 14:52:46 +0100 | pavonia | (~user@user/siracusa) siracusa |
| 2025-01-08 14:54:16 +0100 | weary-traveler | (~user@user/user363627) user363627 |
| 2025-01-08 14:57:18 +0100 | weary-traveler | (~user@user/user363627) (Remote host closed the connection) |
| 2025-01-08 14:59:00 +0100 | weary-traveler | (~user@user/user363627) user363627 |
| 2025-01-08 15:00:57 +0100 | acidjnk_new | (~acidjnk@p200300d6e7283f6814cd06cb5011f3d5.dip0.t-ipconnect.de) (Ping timeout: 272 seconds) |
| 2025-01-08 15:05:04 +0100 | merijn | (~merijn@77.242.116.146) (Ping timeout: 252 seconds) |
| 2025-01-08 15:06:24 +0100 | merijn | (~merijn@77.242.116.146) merijn |
| 2025-01-08 15:10:01 +0100 | lortabac | (~lortabac@2a01:e0a:541:b8f0:55ab:e185:7f81:54a4) (Quit: WeeChat 4.4.2) |
| 2025-01-08 15:11:17 +0100 | acidjnk_new | (~acidjnk@p200300d6e7283f68a1608a41cd6a32b2.dip0.t-ipconnect.de) |
| 2025-01-08 15:21:45 +0100 | yaroot | (~yaroot@p3031163-ipngn4701souka.saitama.ocn.ne.jp) (Remote host closed the connection) |
| 2025-01-08 15:22:27 +0100 | yaroot | (~yaroot@p3031163-ipngn4701souka.saitama.ocn.ne.jp) yaroot |
| 2025-01-08 15:25:57 +0100 | l__k | (~student@213.24.135.58) |
| 2025-01-08 15:29:01 +0100 | l_k | (~student@213.24.135.42) (Ping timeout: 252 seconds) |
| 2025-01-08 15:30:16 +0100 | l_k | (~student@85.172.77.82) |
| 2025-01-08 15:32:54 +0100 | gmg | (~user@user/gehmehgeh) (Remote host closed the connection) |
| 2025-01-08 15:33:21 +0100 | l__k | (~student@213.24.135.58) (Ping timeout: 244 seconds) |
| 2025-01-08 15:34:03 +0100 | mari70558 | (~mari-este@user/mari-estel) mari-estel |
| 2025-01-08 15:35:06 +0100 | merijn | (~merijn@77.242.116.146) (Ping timeout: 276 seconds) |
| 2025-01-08 15:36:14 +0100 | mari-estel | (~mari-este@user/mari-estel) (Ping timeout: 245 seconds) |
| 2025-01-08 15:38:11 +0100 | gmg | (~user@user/gehmehgeh) gehmehgeh |
| 2025-01-08 15:46:17 +0100 | merijn | (~merijn@77.242.116.146) merijn |
| 2025-01-08 15:53:18 +0100 | mari70558 | (~mari-este@user/mari-estel) () |
| 2025-01-08 16:00:55 +0100 | JuanDaugherty | (~juan@user/JuanDaugherty) JuanDaugherty |
| 2025-01-08 16:01:15 +0100 | lxsameer | (~lxsameer@Serene/lxsameer) (Ping timeout: 244 seconds) |
| 2025-01-08 16:09:41 +0100 | l__k | (~student@217.107.124.218) |
| 2025-01-08 16:12:44 +0100 | l_k | (~student@85.172.77.82) (Ping timeout: 265 seconds) |
| 2025-01-08 16:14:02 +0100 | l_k | (~student@81.177.126.233) |
| 2025-01-08 16:15:03 +0100 | saulosilva | (~saulosilv@181.216.220.21) saulosilva |
| 2025-01-08 16:16:38 +0100 | hseg | (~gesh@46.120.21.249) hseg |
| 2025-01-08 16:16:56 +0100 | l__k | (~student@217.107.124.218) (Ping timeout: 252 seconds) |
| 2025-01-08 16:17:45 +0100 | <hseg> | Just realized a potential legal problem with distributing statically-linked haskell code -- how am I supposed to comply with the obligation to distribute the licenses for all the dependencies? |
| 2025-01-08 16:18:51 +0100 | <merijn> | hseg: That depends on said licenses |
| 2025-01-08 16:19:16 +0100 | <merijn> | hseg: Generally they require an "About" function in the binary with the licenses |
| 2025-01-08 16:20:17 +0100 | <hseg> | I mean, I already distribute the top-level package's LICENSE file in the tarball |
| 2025-01-08 16:21:01 +0100 | <hseg> | presumably, I'd need to have a directory LICENSES/$dep ? |
| 2025-01-08 16:22:06 +0100 | <hseg> | (at least for those dependencies that require distribution of their license, eg MIT, BSD-n with n>=2, GPL, ...) |
| 2025-01-08 16:28:17 +0100 | <haskellbridge> | <magic_rb> Realistically no one does this, so unless youve a very good reason to do it, i wouldnt worry about it |
| 2025-01-08 16:28:33 +0100 | <haskellbridge> | <magic_rb> Especially if your project is also free software |
| 2025-01-08 16:29:43 +0100 | <hseg> | Fair enough. The topic came to mind because Arch just started demanding packaging files be licensed, and the train of thought got me there |
| 2025-01-08 16:37:04 +0100 | saulosilva | (~saulosilv@181.216.220.21) (Quit: Client closed) |
| 2025-01-08 16:40:08 +0100 | <merijn> | hseg: Realistically, if you ship GPL in a binary you're already kinda hosed :p |
| 2025-01-08 16:40:44 +0100 | <merijn> | hseg: btw, I vaguelly recall cabal-plan having a command for collecting all transitive dependencies |
| 2025-01-08 16:41:01 +0100 | <hseg> | Yup -- cabal plan license-report |
| 2025-01-08 16:42:06 +0100 | <hseg> | Which looks official and nice, but given BSD, MIT, ISC all require you to distribute their copyright notices, is still slightly off what's technically needed |
| 2025-01-08 16:42:34 +0100 | <hseg> | Still, that's better than stack ls dependencies --license which just gives the author's spelling of their licenses |
| 2025-01-08 16:42:54 +0100 | <merijn> | hseg: I mean, that's pretty much the way to go, tbh |
| 2025-01-08 16:43:09 +0100 | <merijn> | Do you have a library or a binary? |
| 2025-01-08 16:43:16 +0100 | <hseg> | binary |
| 2025-01-08 16:43:35 +0100 | <hseg> | Ah, dammit -- hledger *is* GPL |
| 2025-01-08 16:43:42 +0100 | <hseg> | at least it's a top-level dep |
| 2025-01-08 16:44:01 +0100 | <hseg> | s/a top-level dep/the package I'm building/ |
| 2025-01-08 16:45:08 +0100 | <merijn> | hseg: having a --about or --licenses that prints out all licenses seems the most correct way to comply |
| 2025-01-08 16:45:45 +0100 | <sm> | that sounds nice |
| 2025-01-08 16:46:17 +0100 | <hseg> | yeah. Or I was thinking of installing something like https://hackage.haskell.org/package/src/example/cabal-plan.html next to hledger's LICENSE file |
| 2025-01-08 16:46:29 +0100 | <hseg> | problem is that that doesn't really satisfy obligations |
| 2025-01-08 16:47:29 +0100 | <sm> | stack ls dependencies --license looks excellent, isn't that a good starting point ? |
| 2025-01-08 16:47:45 +0100 | <sm> | group them by license, then add the texts ? |
| 2025-01-08 16:49:46 +0100 | <sm> | stack ls dependencies --license | awk '{print $2 " " $1}' | sed -E 's/(BSD|GPL)-/\1/' | sort |
| 2025-01-08 16:49:55 +0100 | <hseg> | two problems. 1) non-canonical license names -- am seeing BSD2, BSD-2. That's OK, but with GPL there's a significant difference between GPL3 and GPL3+ which needs to be reflected |
| 2025-01-08 16:50:33 +0100 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 2025-01-08 16:50:39 +0100 | <sm> | hledger itself is the only GPL thing (!) |
| 2025-01-08 16:50:58 +0100 | <sm> | and for the record it's GPLv3+ (cabal format can't express that IIRC) |
| 2025-01-08 16:51:08 +0100 | <hseg> | 2) as mentioned above -- some licenses require distributing their copyright notices, it is insufficient to have a report saying "I depend on the BSD-licensed foo package" |
| 2025-01-08 16:51:23 +0100 | <hseg> | sm: that's true of hledger, and makes my life easier |
| 2025-01-08 16:52:03 +0100 | <hseg> | it can! license: GPL-3.0-or-later |
| 2025-01-08 16:55:23 +0100 | <yushyin> | glad to see that cabal adopted spdx ids |
| 2025-01-08 16:55:49 +0100 | <sm> | hseg: good to know, thanks! |
| 2025-01-08 16:57:03 +0100 | <sm> | do you know the earliest version of cabal-install that supports that ? |
| 2025-01-08 16:57:30 +0100 | <tomsmeding> | https://cabal.readthedocs.io/en/stable/cabal-package-description-file.html#pkg-field-license |
| 2025-01-08 16:58:19 +0100 | <tomsmeding> | it's with reference to a `cabal-version` version, not cabal-install, but perhaps those are synchronised? |
| 2025-01-08 16:58:25 +0100 | <sm> | 🙏🏻 |
| 2025-01-08 16:58:36 +0100 | <tomsmeding> | in any case, long |
| 2025-01-08 16:58:52 +0100 | rachelambda8 | (~rachelamb@cust-95-80-25-71.csbnet.se) (Quit: β reduced) |
| 2025-01-08 16:59:40 +0100 | <sm> | next I hunt for cabal-version release dates |
| 2025-01-08 16:59:56 +0100 | <sm> | nobody puts those in their docs :) |
| 2025-01-08 17:00:38 +0100 | <tomsmeding> | naturally :) |
| 2025-01-08 17:00:50 +0100 | Smiles | (uid551636@id-551636.lymington.irccloud.com) (Quit: Connection closed for inactivity) |
| 2025-01-08 17:00:54 +0100 | <tomsmeding> | > The sequence of specification version numbers is not contiguous because it’s synchronised with the version of the Cabal library. |
| 2025-01-08 17:00:54 +0100 | <hseg> | The earliest commit I see in the cabal repo mentioning SPDX is 3dfc0ea466d254fcefb3826d6f15cda30d95cc0a |
| 2025-01-08 17:00:56 +0100 | <tomsmeding> | https://cabal.readthedocs.io/en/stable/file-format-changelog.html#spec-history |
| 2025-01-08 17:00:59 +0100 | mari-estel | (~mari-este@user/mari-estel) mari-estel |
| 2025-01-08 17:01:26 +0100 | <hseg> | https://0x0.st/8-sC.txt is the list of tags containing that commit |
| 2025-01-08 17:02:00 +0100 | <tomsmeding> | looks like 2.2 and onwards? |
| 2025-01-08 17:02:02 +0100 | <sm> | it became supported in https://github.com/haskell/cabal/blob/master/Cabal/ChangeLog.md#2200-mikhail-glushenkov-march-2018 I think |
| 2025-01-08 17:02:09 +0100 | <sm> | yup, thanks |
| 2025-01-08 17:02:27 +0100 | <tomsmeding> | which is consistent with the `cabal-version: 2.2` note and the fact that the two are synchronised |
| 2025-01-08 17:02:38 +0100 | sm | didn't want to assume |
| 2025-01-08 17:02:39 +0100 | <hseg> | yay! |
| 2025-01-08 17:03:44 +0100 | alecs | (~alecs@nat16.software.imdea.org) (Ping timeout: 264 seconds) |
| 2025-01-08 17:04:23 +0100 | <tomsmeding> | nice |
| 2025-01-08 17:09:54 +0100 | <hseg> | hm, actually just realized the licenses appear under ~/.cabal/store/$HC/$PKG/share/doc/LICENSE |
| 2025-01-08 17:10:59 +0100 | merijn | (~merijn@77.242.116.146) (Ping timeout: 260 seconds) |
| 2025-01-08 17:11:18 +0100 | <hseg> | so in theory, cabal-plan's report could copy them into the license directory |
| 2025-01-08 17:12:46 +0100 | jespada | (~jespada@2800:a4:f9:a300:c8c1:20a5:1a94:f1) (Ping timeout: 244 seconds) |
| 2025-01-08 17:13:03 +0100 | lxsameer | (~lxsameer@Serene/lxsameer) lxsameer |
| 2025-01-08 17:13:20 +0100 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) |
| 2025-01-08 17:14:01 +0100 | rachelambda8 | (~rachelamb@cust-95-80-25-71.csbnet.se) |
| 2025-01-08 17:14:20 +0100 | Square2 | (~Square@user/square) Square |
| 2025-01-08 17:17:19 +0100 | jespada | (~jespada@2800:a4:113:8c00:655c:4889:ada3:2b47) jespada |
| 2025-01-08 17:23:04 +0100 | Smiles | (uid551636@id-551636.lymington.irccloud.com) Smiles |
| 2025-01-08 17:23:36 +0100 | JuanDaugherty | (~juan@user/JuanDaugherty) (Quit: JuanDaugherty) |
| 2025-01-08 17:23:49 +0100 | merijn | (~merijn@77.242.116.146) merijn |
| 2025-01-08 17:24:00 +0100 | <__monty__> | What if the PKG lists multiple license-files? |
| 2025-01-08 17:25:15 +0100 | <hseg> | then all would need to be copied, presumably |
| 2025-01-08 17:25:25 +0100 | saulosilva | (~saulosilv@181.216.220.21) saulosilva |
| 2025-01-08 17:27:30 +0100 | <__monty__> | Maybe it's worth looking into some of the reproducible builds stuff? SALSA and the like? They tend to care about source provenance and licensing is part of that so maybe they have tools that make this easy. |
| 2025-01-08 17:30:44 +0100 | merijn | (~merijn@77.242.116.146) (Ping timeout: 264 seconds) |
| 2025-01-08 17:32:51 +0100 | target_i | (~target_i@user/target-i/x-6023099) target_i |
| 2025-01-08 17:34:02 +0100 | <hseg> | I thought https://reuse.software might have something, but apparently not |
| 2025-01-08 17:34:06 +0100 | merijn | (~merijn@77.242.116.146) merijn |
| 2025-01-08 17:35:22 +0100 | <merijn> | sm: to add onto tomsmeding answer, cabal-version refers to the cabal *spec* i.e. supported features, (generally equal to "the earliest cabal version that supports it") |
| 2025-01-08 17:35:40 +0100 | <tomsmeding> | merijn: "generally"? |
| 2025-01-08 17:35:48 +0100 | <merijn> | tomsmeding: I'm not 100% it's guaranteed |
| 2025-01-08 17:36:27 +0100 | <merijn> | tomsmeding: In general there's no real reason the spec and cabal-install versions should correspond (they always have and do at the moment, but there's no specific reason) |
| 2025-01-08 17:36:29 +0100 | <tomsmeding> | merijn: the Note here seems to give more certainty https://cabal.readthedocs.io/en/stable/file-format-changelog.html#spec-history |
| 2025-01-08 17:36:43 +0100 | <tomsmeding> | ah |
| 2025-01-08 17:36:52 +0100 | <merijn> | ah, right |
| 2025-01-08 17:38:06 +0100 | <merijn> | sm: At any rate, the core idea is that the semantics of a field will never change for a specific cabal-version, so even if field "foo" changes behaviour in a later version of the spec, any file declaring version X will always use the semantics of 'foo' at time X |
| 2025-01-08 17:39:24 +0100 | <merijn> | anyway, cabal 2.2 is over a decade old, so :p |
| 2025-01-08 17:39:36 +0100 | <merijn> | 2.4 is the version I used at the start of my phd in 2014 |
| 2025-01-08 17:40:05 +0100 | <merijn> | sm: So that should be MORE than old enough to require ;) |
| 2025-01-08 17:41:04 +0100 | <merijn> | ah, no I'm misremebering it seems, it's from 2018 |
| 2025-01-08 17:41:24 +0100 | saulosilva | (~saulosilv@181.216.220.21) (Quit: Client closed) |
| 2025-01-08 17:42:42 +0100 | jokoon | (~jokoon@2a01:cb1d:8f84:4f00:60a2:6701:a66e:bb95) |
| 2025-01-08 17:42:56 +0100 | <jokoon> | can I access the first element of a list without the head function? |
| 2025-01-08 17:43:41 +0100 | <tomsmeding> | pattern-match on it? |
| 2025-01-08 17:44:28 +0100 | <jokoon> | https://bpa.st/KICQ like this? |
| 2025-01-08 17:44:47 +0100 | <tomsmeding> | f8 (a : _) = a |
| 2025-01-08 17:44:55 +0100 | <tomsmeding> | which will still crash if f8 gets an empty list |
| 2025-01-08 17:45:18 +0100 | <jokoon> | and how can I raise an error if the list is empty? |
| 2025-01-08 17:45:25 +0100 | <tomsmeding> | what have you tried? |
| 2025-01-08 17:45:26 +0100 | <jokoon> | put some if? |
| 2025-01-08 17:45:34 +0100 | <jokoon> | I will try to put an if |
| 2025-01-08 17:45:42 +0100 | <tomsmeding> | you can give multiple equations to a function |
| 2025-01-08 17:45:56 +0100 | <tomsmeding> | foo 1 = "was one" |
| 2025-01-08 17:45:59 +0100 | <tomsmeding> | foo 2 = "was two" |
| 2025-01-08 17:46:02 +0100 | merijn | (~merijn@77.242.116.146) (Ping timeout: 252 seconds) |
| 2025-01-08 17:46:03 +0100 | <tomsmeding> | foo n = "was something else: " ++ show n |
| 2025-01-08 17:49:06 +0100 | <jokoon> | like this then https://bpa.st/SDXA |
| 2025-01-08 17:49:09 +0100 | <jokoon> | that works |
| 2025-01-08 17:49:26 +0100 | <mauke> | yes, that's pretty much how head is defined |
| 2025-01-08 17:49:51 +0100 | <jokoon> | you can guess that I am doing homework haha |
| 2025-01-08 17:50:14 +0100 | <jokoon> | although to be fair I just had a student send me his haskell homework |
| 2025-01-08 17:50:20 +0100 | <mauke> | @src head |
| 2025-01-08 17:50:20 +0100 | <lambdabot> | head (x:_) = x |
| 2025-01-08 17:50:21 +0100 | <lambdabot> | head [] = error "Prelude.head: empty list" |
| 2025-01-08 17:50:49 +0100 | <jokoon> | no idea if he will solve this with chatpgt without help |
| 2025-01-08 17:51:41 +0100 | saulosilva | (~saulosilv@181.216.220.21) saulosilva |
| 2025-01-08 17:51:46 +0100 | <tomsmeding> | much as I am usually condescending about the abilities of LLMs, I'm quite sure it can generate the source for `head`. :) |
| 2025-01-08 17:53:07 +0100 | <int-e> | . o O ( or a good approximation thereof ) |
| 2025-01-08 17:53:18 +0100 | <mauke> | <insert nsfw joke here> |
| 2025-01-08 17:53:32 +0100 | <int-e> | does it involve giving |
| 2025-01-08 17:55:07 +0100 | homo | (~homo@user/homo) homo |
| 2025-01-08 17:57:01 +0100 | mari-estel | (~mari-este@user/mari-estel) (Remote host closed the connection) |
| 2025-01-08 17:57:16 +0100 | mari-estel | (~mari-este@user/mari-estel) mari-estel |
| 2025-01-08 18:02:17 +0100 | ubert | (~Thunderbi@2a02:8109:ab8a:5a00:13a7:b05b:d8a6:72f8) (Quit: ubert) |
| 2025-01-08 18:07:17 +0100 | homo | (~homo@user/homo) (Ping timeout: 252 seconds) |
| 2025-01-08 18:11:31 +0100 | homo_ | (~homo@user/homo) homo |
| 2025-01-08 18:13:35 +0100 | machinedgod | (~machinedg@d108-173-18-100.abhsia.telus.net) (Ping timeout: 260 seconds) |
| 2025-01-08 18:17:42 +0100 | econo_ | (uid147250@id-147250.tinside.irccloud.com) |
| 2025-01-08 18:26:21 +0100 | <hseg> | For some reason, ghcup's ghc 9.8.4 compiles to store the Cabal store under ghc-9.8.4-c895 Any idea why? |
| 2025-01-08 18:27:00 +0100 | jokoon | (~jokoon@2a01:cb1d:8f84:4f00:60a2:6701:a66e:bb95) (Quit: Leaving) |
| 2025-01-08 18:28:53 +0100 | ChaiTRex | (~ChaiTRex@user/chaitrex) (Remote host closed the connection) |
| 2025-01-08 18:29:20 +0100 | ChaiTRex | (~ChaiTRex@user/chaitrex) ChaiTRex |
| 2025-01-08 18:30:12 +0100 | <geekosaur> | because that's the correct thing to do but wasn't possible in earlier versions |
| 2025-01-08 18:30:21 +0100 | <geekosaur> | the store is very sensitive to ghc abi |
| 2025-01-08 18:32:28 +0100 | <hseg> | Oh? Wait, is that c895 a truncated hash? |
| 2025-01-08 18:35:18 +0100 | <geekosaur> | yes |
| 2025-01-08 18:35:46 +0100 | <hseg> | ah. OK, making a symlink there works, but I've reported this upstream to cabal-plan |
| 2025-01-08 18:36:03 +0100 | <hseg> | how is one supposed to find that store, then? |
| 2025-01-08 18:36:06 +0100 | <geekosaur> | you will find it in the package.conf for the "ghc" package, since that's the closest we currentlhy get to an ABI for a full GHC install |
| 2025-01-08 18:36:35 +0100 | <hseg> | which is where? |
| 2025-01-08 18:37:00 +0100 | euphores | (~SASL_euph@user/euphores) (Ping timeout: 252 seconds) |
| 2025-01-08 18:38:05 +0100 | <hseg> | answer: ghc-pkg list ghc |
| 2025-01-08 18:38:22 +0100 | <hseg> | any way of getting that location programmatically |
| 2025-01-08 18:38:24 +0100 | <hseg> | ? |
| 2025-01-08 18:39:53 +0100 | homo_ | homo |
| 2025-01-08 18:40:16 +0100 | <int-e> | run ghc-pkg and parse the output programmatically. --simple-output helps with that |
| 2025-01-08 18:40:43 +0100 | <geekosaur> | if you want the file, ghc --print-global-package-db |
| 2025-01-08 18:40:43 +0100 | <hseg> | no, I meant from within haskell source |
| 2025-01-08 18:40:56 +0100 | <hseg> | cabal-plan needs to be able to find the Cabal store |
| 2025-01-08 18:41:32 +0100 | <int-e> | I'm pretty sure the Cabal library interrogates ghc-pkg too. |
| 2025-01-08 18:42:06 +0100 | <hseg> | what, with system("ghc-pkg ...")? I doubt that |
| 2025-01-08 18:42:47 +0100 | <geekosaur> | it runs a lot of external programs, actually |
| 2025-01-08 18:42:54 +0100 | <int-e> | well using System.Process |
| 2025-01-08 18:43:00 +0100 | <geekosaur> | that said, it does not use ghc-pkg because it *is* ghc-pkg |
| 2025-01-08 18:43:22 +0100 | <geekosaur> | that si, ghc-pkg is a wrapper around the Cabal library's package db management |
| 2025-01-08 18:45:41 +0100 | <hseg> | OK, I don't quite follow, but that's as deep as I can afford to go down this rabbit hole right now |
| 2025-01-08 18:47:48 +0100 | <int-e> | There's also some baked-in paths here: ghc --print-global-package-db |
| 2025-01-08 18:48:19 +0100 | <int-e> | geekosaur: I don't think that's correct. Yes, ghc-pkg uses (parts of) the Cabal library. But it's still invoked by Cabal or at least cabal-install anyway. |
| 2025-01-08 18:49:07 +0100 | <int-e> | geekosaur: I guess partly because the Cabal versions used may be different. |
| 2025-01-08 18:49:54 +0100 | <int-e> | But also because the ghc-pkg wrapper script sets a bunch of paths that are hard to figure out otherwise. |
| 2025-01-08 18:58:43 +0100 | euphores | (~SASL_euph@user/euphores) euphores |
| 2025-01-08 19:03:47 +0100 | prasad | (~Thunderbi@c-73-75-25-251.hsd1.in.comcast.net) |
| 2025-01-08 19:05:30 +0100 | sprotte24 | (~sprotte24@p200300d16f1e660091235e642331973a.dip0.t-ipconnect.de) |
| 2025-01-08 19:14:08 +0100 | L29Ah | (~L29Ah@wikipedia/L29Ah) (Read error: Connection reset by peer) |
| 2025-01-08 19:16:19 +0100 | plitter | (~plitter@user/plitter) (Ping timeout: 264 seconds) |
| 2025-01-08 19:19:29 +0100 | L29Ah | (~L29Ah@wikipedia/L29Ah) L29Ah |
| 2025-01-08 19:22:01 +0100 | ljdarj | (~Thunderbi@user/ljdarj) ljdarj |
| 2025-01-08 19:26:38 +0100 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 2025-01-08 19:33:10 +0100 | Lord_of_Life_ | (~Lord@user/lord-of-life/x-2819915) Lord_of_Life |
| 2025-01-08 19:33:58 +0100 | mari41300 | (~mari-este@user/mari-estel) mari-estel |
| 2025-01-08 19:34:57 +0100 | Lord_of_Life | (~Lord@user/lord-of-life/x-2819915) (Ping timeout: 276 seconds) |
| 2025-01-08 19:34:57 +0100 | Lord_of_Life_ | Lord_of_Life |
| 2025-01-08 19:35:21 +0100 | mari-estel | (~mari-este@user/mari-estel) (Read error: Connection reset by peer) |
| 2025-01-08 19:38:42 +0100 | fun-safe-math | (~fun-safe-@2601:1c2:1b7f:801f:25c5:ab3d:d3f4:6796) (Ping timeout: 246 seconds) |
| 2025-01-08 19:38:51 +0100 | <smiesner> | does anyone have a tip how i can use cabal repl effectively with happy and alex? how can i regenerate .hs files, build and reload? |
| 2025-01-08 19:39:23 +0100 | <smiesner> | i have to use cabal build, cabal repl, :l Parser all the time |
| 2025-01-08 19:39:57 +0100 | <mari41300> | huh, :r not enough, i guess |
| 2025-01-08 19:40:03 +0100 | <smiesner> | sadly no |
| 2025-01-08 19:40:41 +0100 | <smiesner> | ah but wait |
| 2025-01-08 19:40:47 +0100 | <smiesner> | maybe its :l Parser again |
| 2025-01-08 19:41:11 +0100 | mari41300 | crosses fingers |
| 2025-01-08 19:43:02 +0100 | <smiesner> | nope.. |
| 2025-01-08 19:43:09 +0100 | <mari41300> | meh |
| 2025-01-08 19:44:21 +0100 | <mari41300> | not sure, i think recompiling worked fine for me when i had the chance to leverage the repl. Maybe a complex project with multiple packages? |
| 2025-01-08 19:44:40 +0100 | fun-safe-math | (~fun-safe-@2601:1c2:1b7f:801f:9be8:50a:7d0a:fa49) fun-safe-math |
| 2025-01-08 19:45:18 +0100 | <smiesner> | my project? so far only happy and alex files :) |
| 2025-01-08 19:45:39 +0100 | <smiesner> | :r does not rebuild the parsers |
| 2025-01-08 19:45:40 +0100 | <mari41300> | hmm single package then |
| 2025-01-08 19:46:33 +0100 | <smiesner> | i list Lexer and Parser (as i named the modules) in exposed-modules of the library in my cabal file |
| 2025-01-08 19:46:43 +0100 | <smiesner> | maybe that's the wrong way? |
| 2025-01-08 19:48:05 +0100 | tzh | (~tzh@c-76-115-131-146.hsd1.or.comcast.net) |
| 2025-01-08 19:51:53 +0100 | <mari41300> | well does not sound wrong but not sure whether the structure of the cabal file could affect compilation in the interpreter. I would be surprised |
| 2025-01-08 19:55:53 +0100 | Guest20 | (~Guest20@136.158.16.131) |
| 2025-01-08 19:56:11 +0100 | dolio | (~dolio@130.44.140.168) (Quit: ZNC 1.9.1 - https://znc.in) |
| 2025-01-08 19:56:21 +0100 | Guest20 | (~Guest20@136.158.16.131) () |
| 2025-01-08 20:02:30 +0100 | dolio | (~dolio@130.44.140.168) dolio |
| 2025-01-08 20:05:39 +0100 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) |
| 2025-01-08 20:05:51 +0100 | ljdarj | (~Thunderbi@user/ljdarj) (Ping timeout: 244 seconds) |
| 2025-01-08 20:06:11 +0100 | <c_wraith> | huh. I found a case where I'd really like to benchmark the difference between -O2 and default in a single criterion suite, but... uh... The levels don't work right for that. |
| 2025-01-08 20:06:16 +0100 | <haskellbridge> | <sm> smiesner: ghcid is flexible in which ghci commands it can run on change, including :! shell commands I expect. I'd try to get that working in a side window. Then if you :r in your ghci window the parser will already be regenerated. |
| 2025-01-08 20:07:16 +0100 | <smiesner> | thanks, will look into it! |
| 2025-01-08 20:08:01 +0100 | <haskellbridge> | <sm> I meant, try to get ghcid doing the regeneration as well as compilation. Or, and this might be simpler, run watchexec to regenerate the parser continually, and just reload ghci when you need |
| 2025-01-08 20:08:34 +0100 | ash3en | (~Thunderbi@2a03:7846:b6eb:101:93ac:a90a:da67:f207) (Quit: ash3en) |
| 2025-01-08 20:08:57 +0100 | <haskellbridge> | <sm> also, if you are reloading a lot, I find this really useful in .ghci: :def rmain \args -> return $ ":reload\n:main "<>args |
| 2025-01-08 20:10:04 +0100 | <mari41300> | hm but odd that the cabal repl does not detect changes cabal build would |
| 2025-01-08 20:10:14 +0100 | saulosilva | (~saulosilv@181.216.220.21) (Quit: Client closed) |
| 2025-01-08 20:11:24 +0100 | l__k | (~student@188.254.126.139) |
| 2025-01-08 20:11:26 +0100 | <mari41300> | i did not get what you meant c_wraith |
| 2025-01-08 20:13:34 +0100 | OftenFaded53 | (~OftenFade@user/tisktisk) OftenFaded |
| 2025-01-08 20:13:55 +0100 | <c_wraith> | mari41300: I can't compile my test suite with -O1 and -O2 simultaneously. The best I could manage is moving it into multiple modules with different ghc options per module and duplicating the definition between multiple modules. That's not great for maintainability |
| 2025-01-08 20:14:02 +0100 | <c_wraith> | err, benchmark suite |
| 2025-01-08 20:14:10 +0100 | l_k | (~student@81.177.126.233) (Ping timeout: 252 seconds) |
| 2025-01-08 20:14:55 +0100 | <mari41300> | well i guess it would be common for benchs to be run multiple times with different opts |
| 2025-01-08 20:15:49 +0100 | <c_wraith> | usually you'd only run benchmarks with the options you're actually using. My case is uncommon in that what I really want to demonstrate is the difference between them. (One benchmark is unaffected, a different one improves immensely) |
| 2025-01-08 20:17:11 +0100 | <c_wraith> | (my point is to demonstrate how much easier a time GHC has when you write code that's easily amenable to optimization, instead of making it apply the slow -O2 stuff to find places to optimize) |
| 2025-01-08 20:17:20 +0100 | OftenFaded53 | (~OftenFade@user/tisktisk) () |
| 2025-01-08 20:18:23 +0100 | plitter | (~plitter@user/plitter) plitter |
| 2025-01-08 20:18:53 +0100 | l_k | (~student@213.24.133.217) |
| 2025-01-08 20:21:37 +0100 | l__k | (~student@188.254.126.139) (Ping timeout: 252 seconds) |
| 2025-01-08 20:23:13 +0100 | <tomsmeding> | smiesner: also try running 'cabal build' in another terminal, and then :r |
| 2025-01-08 20:23:37 +0100 | sord937 | (~sord937@gateway/tor-sasl/sord937) (Quit: sord937) |
| 2025-01-08 20:24:02 +0100 | <tomsmeding> | if that works, then you can `:def R \_ -> Prelude.return ":!cabal build\n:r"` to define a ghci command :R that first builds and then reloads ;) |
| 2025-01-08 20:27:08 +0100 | <smiesner> | tomsmeding: will try that for sure! |
| 2025-01-08 20:27:21 +0100 | <smiesner> | thanks all :) |
| 2025-01-08 20:27:37 +0100 | <tomsmeding> | c_wraith: is it just one function? mark them as INLINE, use them (trivially, in a wrapper function) in two separate modules, compile those two modules with different options? |
| 2025-01-08 20:27:51 +0100 | <mari41300> | exit |
| 2025-01-08 20:27:55 +0100 | <mari41300> | :P |
| 2025-01-08 20:28:06 +0100 | <mari41300> | sorry i'm tired. See you all o/ |
| 2025-01-08 20:28:10 +0100 | mari41300 | (~mari-este@user/mari-estel) (Remote host closed the connection) |
| 2025-01-08 20:28:16 +0100 | <tomsmeding> | ctrl-D is often faster than typing "exit" ... oh too late |
| 2025-01-08 20:30:11 +0100 | ljdarj | (~Thunderbi@user/ljdarj) ljdarj |
| 2025-01-08 20:33:15 +0100 | <c_wraith> | Huh. Not sure how INLINE interacts with this. |
| 2025-01-08 20:35:15 +0100 | <tomsmeding> | yeah this may be too much trickery |
| 2025-01-08 20:35:44 +0100 | <tomsmeding> | but the GHC user's guide says: ( https://downloads.haskell.org/ghc/latest/docs/users_guide/exts/pragmas.html#inline-and-noinline-pr… ) |
| 2025-01-08 20:35:51 +0100 | <tomsmeding> | > So GHC guarantees to inline precisely the code that you wrote, no more and no less. |
| 2025-01-08 20:35:57 +0100 | <tomsmeding> | which sounds like what you want here |
| 2025-01-08 20:41:28 +0100 | raym | (~ray@user/raym) raym |
| 2025-01-08 20:52:07 +0100 | weary-traveler | (~user@user/user363627) (Remote host closed the connection) |
| 2025-01-08 20:53:26 +0100 | <c_wraith> | Huh. Looks like cabal might override the -O2 in an OPTIONS_GHC pragma |
| 2025-01-08 20:53:50 +0100 | <c_wraith> | I might need to compile it as a sublibrary |
| 2025-01-08 20:55:26 +0100 | rvalue | (~rvalue@user/rvalue) (Read error: Connection reset by peer) |
| 2025-01-08 20:55:56 +0100 | rvalue | (~rvalue@user/rvalue) rvalue |
| 2025-01-08 21:00:04 +0100 | caconym | (~caconym@user/caconym) (Quit: bye) |
| 2025-01-08 21:00:35 +0100 | visilii_ | (~visilii@188.254.110.9) |
| 2025-01-08 21:00:44 +0100 | caconym | (~caconym@user/caconym) caconym |
| 2025-01-08 21:03:50 +0100 | hseg | (~gesh@46.120.21.249) (Ping timeout: 272 seconds) |
| 2025-01-08 21:04:40 +0100 | visilii | (~visilii@213.24.125.237) (Ping timeout: 265 seconds) |
| 2025-01-08 21:07:00 +0100 | ash3en | (~Thunderbi@2a03:7846:b6eb:101:93ac:a90a:da67:f207) ash3en |
| 2025-01-08 21:09:51 +0100 | <c_wraith> | Oh. No, I think this idea just doesn't work. |
| 2025-01-08 21:09:51 +0100 | ash3en | (~Thunderbi@2a03:7846:b6eb:101:93ac:a90a:da67:f207) (Client Quit) |
| 2025-01-08 21:10:21 +0100 | <c_wraith> | I think the INLINE pragma is being ignored because the definition it would need to apply to is directly recursive |
| 2025-01-08 21:10:38 +0100 | <c_wraith> | It needs a worker/wrapper transform for GHC to inline it at all |
| 2025-01-08 21:11:05 +0100 | <c_wraith> | And while it can do that in a single module with -O2, it does not appear to do it cross-module with -O2 |
| 2025-01-08 21:12:59 +0100 | gorignak | (~gorignak@user/gorignak) gorignak |
| 2025-01-08 21:14:40 +0100 | JuanDaugherty | (~juan@user/JuanDaugherty) JuanDaugherty |
| 2025-01-08 21:15:58 +0100 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 2025-01-08 21:17:00 +0100 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) |
| 2025-01-08 21:17:39 +0100 | cjay | (cjay@nerdbox.nerd2nerd.org) cjay |
| 2025-01-08 21:17:46 +0100 | <c_wraith> | And, yeah. OPTIONS_GHC -O2 does in fact override cabal's global optimization level. It just wasn't visible because of the cross-module stuff |
| 2025-01-08 21:18:43 +0100 | weary-traveler | (~user@user/user363627) user363627 |
| 2025-01-08 21:21:40 +0100 | <c_wraith> | Oh, right. "GHC tries not to select a function with an INLINE pragma as a loop breaker, but when there is no choice even an INLINE function can be selected, in which case the INLINE pragma is ignored. For example, for a self-recursive function, the loop breaker can only be the function itself, so an INLINE pragma is always ignored." |
| 2025-01-08 21:21:58 +0100 | <c_wraith> | So yeah... When *that* is the issue I'm trying to demonstrate, INLINE is useless. |
| 2025-01-08 21:25:58 +0100 | <EvanR> | a self recursive function can't be inlined |
| 2025-01-08 21:26:03 +0100 | <EvanR> | I guess that makes sense on multiple levels |
| 2025-01-08 21:26:25 +0100 | <EvanR> | wait a minute, isn't that what loop unrolling is |
| 2025-01-08 21:27:12 +0100 | <c_wraith> | it is. |
| 2025-01-08 21:29:32 +0100 | l__k | (~student@217.107.126.148) |
| 2025-01-08 21:32:08 +0100 | l_k | (~student@213.24.133.217) (Ping timeout: 244 seconds) |
| 2025-01-08 21:32:09 +0100 | Digit | (~user@user/digit) (Read error: Connection reset by peer) |
| 2025-01-08 21:32:56 +0100 | Digit | (~user@user/digit) Digit |
| 2025-01-08 21:35:00 +0100 | <c_wraith> | within a single module, GHC will do a worker-wrapper transform to inline directly recursive definitions at -O2. But making that optimization fire across modules seems hard. |
| 2025-01-08 21:36:14 +0100 | <c_wraith> | Further reading of the docs suggests you might be able to do it with INLINEABLE *and* the magic inline function. https://hackage.haskell.org/package/base-4.21.0.0/docs/GHC-Base.html#v:inline |
| 2025-01-08 21:36:28 +0100 | <c_wraith> | But that means you need to cooperate at the call site. eww. |
| 2025-01-08 21:37:43 +0100 | <Leary> | Perhaps artificially introduce a loop breaker: `bar = ... bar ...` --> `foo = bar; {-# INLINE bar #-}; bar = ... foo ...` |
| 2025-01-08 21:51:19 +0100 | <hololeap> | JuanDaugherty: are you aware of https://en.wikipedia.org/wiki/Relational_algebra |
| 2025-01-08 21:51:37 +0100 | <c_wraith> | Leary: if you're rewriting it to make it inline properly, you might as well worker/wrapper it yourself |
| 2025-01-08 21:53:23 +0100 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 2025-01-08 21:53:56 +0100 | <Leary> | Well, worker/wrapper only lets you inline the wrapper. This would let you inline the entire body, so your other module can optimise it differently. |
| 2025-01-08 21:54:46 +0100 | avdb13 | (~avdb13@2001-14ba-a0a9-f200--18c.rev.dnainternet.fi) (Remote host closed the connection) |
| 2025-01-08 21:54:47 +0100 | machinedgod | (~machinedg@d108-173-18-100.abhsia.telus.net) machinedgod |
| 2025-01-08 21:55:14 +0100 | Digit | (~user@user/digit) (Read error: Connection reset by peer) |
| 2025-01-08 21:55:25 +0100 | <c_wraith> | inlining the wrapper copies in the worker definition so that things can be inlined into it. |
| 2025-01-08 21:55:57 +0100 | <c_wraith> | The only thing it doesn't do is any kind of unrolling |
| 2025-01-08 21:56:03 +0100 | Digit | (~user@user/digit) Digit |
| 2025-01-08 21:56:14 +0100 | lxsameer | (~lxsameer@Serene/lxsameer) (Ping timeout: 245 seconds) |
| 2025-01-08 21:56:38 +0100 | <JuanDaugherty> | hololeap, ofc, i;m juan@acm.org |
| 2025-01-08 21:58:13 +0100 | <JuanDaugherty> | to be clear, i did not go to the damn enwiki relational algebra article |
| 2025-01-08 22:01:40 +0100 | <JuanDaugherty> | but ty anyway |
| 2025-01-08 22:03:18 +0100 | <JuanDaugherty> | pretty sure i looked for hs things that woulda done integration based on relational algebra with null result |
| 2025-01-08 22:05:14 +0100 | <JuanDaugherty> | and i apologize for being a bore on this because i know i've asked b4 and wont again |
| 2025-01-08 22:06:05 +0100 | <hololeap> | I think it's just very niche and if someone who does know doesn't catch it, it will just get lost in the IRC backlog |
| 2025-01-08 22:06:42 +0100 | <JuanDaugherty> | well it woulda been before the current public log i think, nyefs |
| 2025-01-08 22:07:26 +0100 | <JuanDaugherty> | it is niche but ofc there's a huge draw for the end function and actual commercial products targetting the task in various ways |
| 2025-01-08 22:08:16 +0100 | <hololeap> | asking on the haskell discourse or the subreddit _might_ get you more responses simply because of better retention |
| 2025-01-08 22:08:44 +0100 | <JuanDaugherty> | stuff is only bridged one way from there here? |
| 2025-01-08 22:09:52 +0100 | <hololeap> | there's a matrix bridge |
| 2025-01-08 22:10:02 +0100 | <JuanDaugherty> | although actually haven seen bridged stuff lately and heard theres some maint goin on |
| 2025-01-08 22:11:25 +0100 | <hc> | Hello, I would like to use the uniform function (System.Random) with a custom enum, how? |
| 2025-01-08 22:13:31 +0100 | <JuanDaugherty> | my understanding is the #haskelll name space here is still the main hs community thing |
| 2025-01-08 22:15:11 +0100 | <hololeap> | I'm just saying chat has its shortcomings compared to something like https://discourse.haskell.org/ where people can go back and read old threads |
| 2025-01-08 22:15:17 +0100 | <haskellbridge> | <sm> JuanDaugherty: I wouldn't say that, haskell community is a bit more spread out these days |
| 2025-01-08 22:15:29 +0100 | <haskellbridge> | <sm> scattered, some might say |
| 2025-01-08 22:15:48 +0100 | <haskellbridge> | <sm> and hololeap is right |
| 2025-01-08 22:16:39 +0100 | <hc> | Ah lol, the answer to my question seems to be hidden in the System.Random.hs source code and is more involved (generics) than I had anticipated =) |
| 2025-01-08 22:17:05 +0100 | econo_ | (uid147250@id-147250.tinside.irccloud.com) (Quit: Connection closed for inactivity) |
| 2025-01-08 22:19:02 +0100 | <JuanDaugherty> | sm noted |
| 2025-01-08 22:21:11 +0100 | <JuanDaugherty> | yeah 10 or so ago there would have been 3X as many in this channel |
| 2025-01-08 22:21:22 +0100 | <JuanDaugherty> | *10 y |
| 2025-01-08 22:22:10 +0100 | <haskellbridge> | <sm> we have a lot more communication channels now |
| 2025-01-08 22:25:26 +0100 | <EvanR> | I'm going down with the ship tyvm |
| 2025-01-08 22:26:44 +0100 | <Leary> | hc: https://play.haskell.org/saved/gE2vt5ch |
| 2025-01-08 22:29:22 +0100 | <glguy> | hololeap: I think discourse different. Similarly it has shortcomings with its threaded structure compared to the conversation that can happen in something like IRC |
| 2025-01-08 22:30:21 +0100 | <hololeap> | I agree |
| 2025-01-08 22:30:32 +0100 | <glguy> | *is just different* |
| 2025-01-08 22:30:39 +0100 | <hc> | Leary: Thanks! Much simpler :) |
| 2025-01-08 22:31:01 +0100 | <hc> | Discourse is neither free nor distributed, is it? |
| 2025-01-08 22:31:44 +0100 | jespada | (~jespada@2800:a4:113:8c00:655c:4889:ada3:2b47) (Quit: My Mac has gone to sleep. ZZZzzz…) |
| 2025-01-08 22:33:43 +0100 | <hololeap> | it's the closest thing to an official haskell forum that I know of |
| 2025-01-08 22:34:47 +0100 | <mauke> | Discourse is jeffware |
| 2025-01-08 22:37:06 +0100 | <hc> | (using haskell first day after long while) what's the operator again that applies a function to the 1st element of a tuple and keeps the 2nd element untouched? |
| 2025-01-08 22:37:48 +0100 | <glguy> | You could use first: https://hackage.haskell.org/package/base-4.21.0.0/docs/Data-Bifunctor.html#t:Bifunctor |
| 2025-01-08 22:39:05 +0100 | <hololeap> | mauke: jeffware? |
| 2025-01-08 22:39:41 +0100 | <mauke> | jeff atwood |
| 2025-01-08 22:40:17 +0100 | <EvanR> | hc, if you are not picky about the 1st or 2nd element, there's fmap, which applies to the 2nd |
| 2025-01-08 22:40:29 +0100 | <EvanR> | > fmap (+1) (0,0) |
| 2025-01-08 22:40:30 +0100 | <lambdabot> | (0,1) |
| 2025-01-08 22:40:41 +0100 | <EvanR> | the operator is <$> |
| 2025-01-08 22:41:35 +0100 | <hololeap> | I see |
| 2025-01-08 22:41:39 +0100 | michalz | (~michalz@185.246.207.221) (Remote host closed the connection) |
| 2025-01-08 22:42:28 +0100 | <hololeap> | well, it looks like discourse is at least foss (https://github.com/discourse/discourse) |
| 2025-01-08 22:42:28 +0100 | ThePenguin | (~ThePengui@cust-95-80-24-166.csbnet.se) (Remote host closed the connection) |
| 2025-01-08 22:42:50 +0100 | JuanDaugherty | (~juan@user/JuanDaugherty) (Quit: JuanDaugherty) |
| 2025-01-08 22:43:03 +0100 | ThePenguin | (~ThePengui@cust-95-80-24-166.csbnet.se) ThePenguin |
| 2025-01-08 22:43:12 +0100 | ThePenguin | (~ThePengui@cust-95-80-24-166.csbnet.se) (Remote host closed the connection) |
| 2025-01-08 22:43:35 +0100 | <mauke> | > over _1 (+1) (0,0) |
| 2025-01-08 22:43:37 +0100 | <lambdabot> | (1,0) |
| 2025-01-08 22:43:46 +0100 | ThePenguin | (~ThePengui@cust-95-80-24-166.csbnet.se) ThePenguin |
| 2025-01-08 22:43:55 +0100 | ThePenguin | (~ThePengui@cust-95-80-24-166.csbnet.se) (Remote host closed the connection) |
| 2025-01-08 22:44:42 +0100 | ThePenguin | (~ThePengui@cust-95-80-24-166.csbnet.se) ThePenguin |
| 2025-01-08 22:44:43 +0100 | ThePenguin | (~ThePengui@cust-95-80-24-166.csbnet.se) (Remote host closed the connection) |
| 2025-01-08 22:45:16 +0100 | ThePenguin | (~ThePengui@cust-95-80-24-166.csbnet.se) ThePenguin |
| 2025-01-08 22:45:25 +0100 | ThePenguin | (~ThePengui@cust-95-80-24-166.csbnet.se) (Remote host closed the connection) |
| 2025-01-08 22:45:58 +0100 | ThePenguin | (~ThePengui@cust-95-80-24-166.csbnet.se) ThePenguin |
| 2025-01-08 22:46:08 +0100 | ThePenguin | (~ThePengui@cust-95-80-24-166.csbnet.se) (Remote host closed the connection) |
| 2025-01-08 22:46:33 +0100 | user363627 | (~user@user/user363627) user363627 |
| 2025-01-08 22:47:24 +0100 | ThePenguin | (~ThePengui@cust-95-80-24-166.csbnet.se) ThePenguin |
| 2025-01-08 22:47:34 +0100 | ThePenguin | (~ThePengui@cust-95-80-24-166.csbnet.se) (Remote host closed the connection) |
| 2025-01-08 22:48:09 +0100 | ThePenguin | (~ThePengui@cust-95-80-24-166.csbnet.se) ThePenguin |
| 2025-01-08 22:48:18 +0100 | ThePenguin | (~ThePengui@cust-95-80-24-166.csbnet.se) (Remote host closed the connection) |
| 2025-01-08 22:48:50 +0100 | ThePenguin | (~ThePengui@cust-95-80-24-166.csbnet.se) ThePenguin |
| 2025-01-08 22:48:59 +0100 | ThePenguin | (~ThePengui@cust-95-80-24-166.csbnet.se) (Remote host closed the connection) |
| 2025-01-08 22:50:40 +0100 | weary-traveler | (~user@user/user363627) (Ping timeout: 252 seconds) |
| 2025-01-08 22:51:17 +0100 | ThePenguin | (~ThePengui@cust-95-80-24-166.csbnet.se) ThePenguin |
| 2025-01-08 22:51:17 +0100 | ThePenguin | (~ThePengui@cust-95-80-24-166.csbnet.se) (Remote host closed the connection) |
| 2025-01-08 22:51:49 +0100 | ThePenguin | (~ThePengui@cust-95-80-24-166.csbnet.se) ThePenguin |
| 2025-01-08 22:51:55 +0100 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) |
| 2025-01-08 22:51:59 +0100 | ThePenguin | (~ThePengui@cust-95-80-24-166.csbnet.se) (Remote host closed the connection) |
| 2025-01-08 22:52:29 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
| 2025-01-08 22:52:32 +0100 | ThePenguin | (~ThePengui@cust-95-80-24-166.csbnet.se) ThePenguin |
| 2025-01-08 22:52:33 +0100 | ThePenguin | (~ThePengui@cust-95-80-24-166.csbnet.se) (Remote host closed the connection) |
| 2025-01-08 22:53:50 +0100 | <hc> | glguy: Thanks, I used first, works |
| 2025-01-08 22:54:24 +0100 | <hc> | EvanR: thanks also, I prefer first over <$> in this case :) I vaguely remember there used to be some arrow functions |
| 2025-01-08 22:54:51 +0100 | <mauke> | > fst $ do ("no", "harm") |
| 2025-01-08 22:54:52 +0100 | <lambdabot> | "no" |
| 2025-01-08 22:56:36 +0100 | <tomsmeding> | hc: there's also 'second', which does... the obvious other thing |
| 2025-01-08 22:56:48 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 246 seconds) |
| 2025-01-08 22:56:56 +0100 | ThePenguin | (~ThePengui@cust-95-80-24-166.csbnet.se) ThePenguin |
| 2025-01-08 22:56:57 +0100 | ThePenguin | (~ThePengui@cust-95-80-24-166.csbnet.se) (Remote host closed the connection) |
| 2025-01-08 22:57:31 +0100 | ThePenguin | (~ThePengui@cust-95-80-24-166.csbnet.se) ThePenguin |
| 2025-01-08 22:57:32 +0100 | ThePenguin | (~ThePengui@cust-95-80-24-166.csbnet.se) (Remote host closed the connection) |
| 2025-01-08 22:58:05 +0100 | ThePenguin | (~ThePengui@cust-95-80-24-166.csbnet.se) ThePenguin |
| 2025-01-08 22:58:07 +0100 | ThePenguin | (~ThePengui@cust-95-80-24-166.csbnet.se) (Remote host closed the connection) |
| 2025-01-08 22:59:42 +0100 | takuan | (~takuan@178-116-218-225.access.telenet.be) (Remote host closed the connection) |
| 2025-01-08 23:00:11 +0100 | ystael | (~ystael@user/ystael) (Ping timeout: 265 seconds) |