| 2025-03-28 00:04:09 +0100 | j1n37- | (~j1n37@user/j1n37) (Read error: Connection reset by peer) |
| 2025-03-28 00:06:31 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-03-28 00:07:12 +0100 | j1n37 | (~j1n37@user/j1n37) j1n37 |
| 2025-03-28 00:08:06 +0100 | machinedgod | (~machinedg@d108-173-18-100.abhsia.telus.net) (Ping timeout: 246 seconds) |
| 2025-03-28 00:11:17 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 244 seconds) |
| 2025-03-28 00:15:31 +0100 | HelloImSteven | (~HelloImSt@user/HelloImSteven) (Quit: HelloImSteven) |
| 2025-03-28 00:22:17 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-03-28 00:24:01 +0100 | malte | (~malte@mal.tc) malte |
| 2025-03-28 00:24:10 +0100 | __monty__ | (~toonn@user/toonn) (Quit: leaving) |
| 2025-03-28 00:29:16 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 252 seconds) |
| 2025-03-28 00:36:43 +0100 | vavakado | (~vavakado@user/Vavakado) (Quit: Lost terminal) |
| 2025-03-28 00:40:49 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-03-28 00:43:56 +0100 | malte | (~malte@mal.tc) (Ping timeout: 252 seconds) |
| 2025-03-28 00:45:54 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 244 seconds) |
| 2025-03-28 00:46:01 +0100 | malte | (~malte@mal.tc) malte |
| 2025-03-28 00:48:29 +0100 | xff0x | (~xff0x@2405:6580:b080:900:879:4ff2:52d5:5929) (Quit: xff0x) |
| 2025-03-28 00:52:44 +0100 | malte | (~malte@mal.tc) (Ping timeout: 252 seconds) |
| 2025-03-28 00:56:35 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-03-28 01:01:32 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 252 seconds) |
| 2025-03-28 01:05:23 +0100 | anselmschueler | (~quassel@user/schuelermine) schuelermine |
| 2025-03-28 01:05:24 +0100 | <anselmschueler> | Hi |
| 2025-03-28 01:05:24 +0100 | sprotte24 | (~sprotte24@p200300d16f0a80004582713a1a0df846.dip0.t-ipconnect.de) (Read error: Connection reset by peer) |
| 2025-03-28 01:05:28 +0100 | <anselmschueler> | ’s been a while |
| 2025-03-28 01:05:55 +0100 | xff0x | (~xff0x@2405:6580:b080:900:879:4ff2:52d5:5929) |
| 2025-03-28 01:06:05 +0100 | geekosaur | waves |
| 2025-03-28 01:07:51 +0100 | <anselmschueler> | does anyone know when stimes was changed to document that it’ll work with 0 only for some implementors, and that stimesMonoid was added to enforce stimesMonoid 0 = mempty? |
| 2025-03-28 01:07:59 +0100 | <anselmschueler> | I seem to remember it wasn’t so some time ago |
| 2025-03-28 01:08:19 +0100 | <anselmschueler> | specifically when I wrote this rejected proposal: https://github.com/haskell/core-libraries-committee/issues/72 |
| 2025-03-28 01:12:23 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-03-28 01:12:40 +0100 | peterbecich | (~Thunderbi@syn-047-229-123-186.res.spectrum.com) peterbecich |
| 2025-03-28 01:14:56 +0100 | tdammers | (~tdammers@110-136-178-143.ftth.glasoperator.nl) (Ping timeout: 265 seconds) |
| 2025-03-28 01:17:25 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 244 seconds) |
| 2025-03-28 01:27:51 +0100 | tdammers | (~tdammers@110-136-178-143.ftth.glasoperator.nl) tdammers |
| 2025-03-28 01:28:09 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-03-28 01:30:30 +0100 | toby-bro | (~toby-bro@user/toby-bro) (Ping timeout: 276 seconds) |
| 2025-03-28 01:32:03 +0100 | malte | (~malte@mal.tc) malte |
| 2025-03-28 01:34:41 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 244 seconds) |
| 2025-03-28 01:35:21 +0100 | st_aldini | (~Thunderbi@136.48.22.91) (Remote host closed the connection) |
| 2025-03-28 01:36:12 +0100 | jacopovalanzano | (~jacopoval@cpc151911-cove17-2-0-cust105.3-1.cable.virginm.net) (Quit: Client closed) |
| 2025-03-28 01:39:30 +0100 | JuanDaugherty | (~juan@user/JuanDaugherty) JuanDaugherty |
| 2025-03-28 01:41:52 +0100 | aetepe | (~aetepe@188.119.58.34) (Ping timeout: 252 seconds) |
| 2025-03-28 01:44:34 +0100 | olivial | (~benjaminl@user/benjaminl) (Ping timeout: 260 seconds) |
| 2025-03-28 01:46:13 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-03-28 01:51:47 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 268 seconds) |
| 2025-03-28 01:54:15 +0100 | acidjnk | (~acidjnk@p200300d6e71c4f64e0b826361c3e438a.dip0.t-ipconnect.de) (Ping timeout: 268 seconds) |
| 2025-03-28 01:55:34 +0100 | anselmschueler | (~quassel@user/schuelermine) (Remote host closed the connection) |
| 2025-03-28 01:55:57 +0100 | Tuplanolla | (~Tuplanoll@91-159-69-59.elisa-laajakaista.fi) (Quit: Leaving.) |
| 2025-03-28 01:58:11 +0100 | anselmschueler | (~quassel@user/schuelermine) schuelermine |
| 2025-03-28 01:58:14 +0100 | <EvanR> | :t \n -> (!! n) . iterate |
| 2025-03-28 01:58:15 +0100 | <lambdabot> | error: |
| 2025-03-28 01:58:15 +0100 | <lambdabot> | • Couldn't match type ‘a -> [a]’ with ‘[c]’ |
| 2025-03-28 01:58:15 +0100 | <lambdabot> | Expected type: (a -> a) -> [c] |
| 2025-03-28 01:58:35 +0100 | <EvanR> | :t \n f -> (!! n) . iterate f |
| 2025-03-28 01:58:36 +0100 | <lambdabot> | Int -> (c -> c) -> c -> c |
| 2025-03-28 02:01:59 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-03-28 02:04:21 +0100 | <anselmschueler> | :h |
| 2025-03-28 02:04:24 +0100 | <anselmschueler> | :? |
| 2025-03-28 02:04:30 +0100 | <anselmschueler> | hm |
| 2025-03-28 02:05:31 +0100 | <geekosaur> | it only supports :t and :k (from ghci) plus "> " to evaluate expressions, otherwise commands start with @ |
| 2025-03-28 02:05:36 +0100 | <anselmschueler> | oh |
| 2025-03-28 02:05:38 +0100 | <anselmschueler> | ok |
| 2025-03-28 02:06:25 +0100 | <geekosaur> | (the in-channel help isn't so helpful, you might prefer https://github.com/lambdabot/lambdabot/pull/205/files) |
| 2025-03-28 02:06:48 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 252 seconds) |
| 2025-03-28 02:08:02 +0100 | <anselmschueler> | @djinn [a] -> (a -> [b]) -> [b] |
| 2025-03-28 02:08:02 +0100 | <lambdabot> | Error: Undefined type [] |
| 2025-03-28 02:09:18 +0100 | <geekosaur> | djinn doesn't understand recursively defined types. there was a bot that did (exference) but it's bitrotted, and even when working it could fail to find solutions |
| 2025-03-28 02:09:42 +0100 | <anselmschueler> | geekosaur: the source code is just lost? |
| 2025-03-28 02:09:44 +0100 | <anselmschueler> | sad |
| 2025-03-28 02:09:50 +0100 | <anselmschueler> | I assume it’s also a hard problem |
| 2025-03-28 02:09:54 +0100 | <anselmschueler> | to generate those |
| 2025-03-28 02:10:18 +0100 | <geekosaur> | no, it's there, it was broken by compiler changes and I couldn't figure out how to update it when I tried forking it |
| 2025-03-28 02:10:23 +0100 | <geekosaur> | ghc internals change a lot |
| 2025-03-28 02:10:52 +0100 | <geekosaur> | https://github.com/lspitzner/exference |
| 2025-03-28 02:11:02 +0100 | <anselmschueler> | ok |
| 2025-03-28 02:11:13 +0100 | xff0x | (~xff0x@2405:6580:b080:900:879:4ff2:52d5:5929) (Ping timeout: 248 seconds) |
| 2025-03-28 02:12:16 +0100 | <anselmschueler> | hm @free isn’t working |
| 2025-03-28 02:12:19 +0100 | <anselmschueler> | @free fmap |
| 2025-03-28 02:12:20 +0100 | <lambdabot> | Extra stuff at end of line in retrieved type "Functor f => (a -> b) -> f a -> f b" |
| 2025-03-28 02:12:48 +0100 | <Leary> | @djinn (r -> (a -> r -> r) -> r) -> (a -> (s -> (b -> s -> s) -> s)) -> (t -> (b -> t -> t) -> t) |
| 2025-03-28 02:12:48 +0100 | <lambdabot> | f _ _ a _ = a |
| 2025-03-28 02:12:51 +0100 | <geekosaur> | @free map |
| 2025-03-28 02:12:52 +0100 | <lambdabot> | g . h = k . f => $map g . map h = map k . $map f |
| 2025-03-28 02:13:16 +0100 | <geekosaur> | which is actually fmap; this is something of a hack because @free doesn't understand typeclasses |
| 2025-03-28 02:13:25 +0100 | otto_s | (~user@p5de2f7cc.dip0.t-ipconnect.de) (Ping timeout: 265 seconds) |
| 2025-03-28 02:13:25 +0100 | <Leary> | (i.e. `f _ _ = []`) |
| 2025-03-28 02:13:29 +0100 | <anselmschueler> | oh |
| 2025-03-28 02:13:52 +0100 | <anselmschueler> | @free fmap @[] |
| 2025-03-28 02:13:52 +0100 | <lambdabot> | Extra stuff at end of line |
| 2025-03-28 02:14:01 +0100 | <anselmschueler> | :( |
| 2025-03-28 02:14:09 +0100 | <Axman6> | you can play with lambdabot in private messages too |
| 2025-03-28 02:14:15 +0100 | <anselmschueler> | ok |
| 2025-03-28 02:14:19 +0100 | <Leary> | @free fmap :: (a -> b) -> F a -> F b |
| 2025-03-28 02:14:19 +0100 | <lambdabot> | g . h = k . f => $map_F g . fmap h = fmap k . $map_F f |
| 2025-03-28 02:14:28 +0100 | <anselmschueler> | it’s been too long since I’ve done Haskell |
| 2025-03-28 02:14:33 +0100 | vanishingideal | (~vanishing@user/vanishingideal) (Ping timeout: 245 seconds) |
| 2025-03-28 02:14:34 +0100 | <anselmschueler> | like proper |
| 2025-03-28 02:14:54 +0100 | otto_s | (~user@p5de2fe2d.dip0.t-ipconnect.de) |
| 2025-03-28 02:14:59 +0100 | <geekosaur> | well, most of these failures are because most of the bot plugins weren't updated |
| 2025-03-28 02:15:10 +0100 | <geekosaur> | like, no TypeApplications support |
| 2025-03-28 02:15:15 +0100 | <anselmschueler> | yeah |
| 2025-03-28 02:16:11 +0100 | <anselmschueler> | two years ago I wrote a small (230 lines) code (still my best Haskell code to date) for directory traversal |
| 2025-03-28 02:16:26 +0100 | <anselmschueler> | do you think using existentials for that is overkill? |
| 2025-03-28 02:16:40 +0100 | vanishingideal | (~vanishing@user/vanishingideal) vanishingideal |
| 2025-03-28 02:17:03 +0100 | <anselmschueler> | I had data Landmark = forall t. Landmark { prepare :: FilePath -> IO t, check :: t -> Check } |
| 2025-03-28 02:17:09 +0100 | <anselmschueler> | so when the program starts it collects data |
| 2025-03-28 02:17:14 +0100 | JuanDaugherty | (~juan@user/JuanDaugherty) (Quit: praxis.meansofproduction.biz (juan@acm.org)) |
| 2025-03-28 02:17:26 +0100 | <anselmschueler> | and then it starts traversing and each time it checks for each file |
| 2025-03-28 02:17:31 +0100 | <anselmschueler> | something |
| 2025-03-28 02:17:46 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-03-28 02:18:00 +0100 | <anselmschueler> | and existentials seemed like a natural solution |
| 2025-03-28 02:18:04 +0100 | <anselmschueler> | but idk if it is anymore |
| 2025-03-28 02:19:13 +0100 | peterbecich | (~Thunderbi@syn-047-229-123-186.res.spectrum.com) (Ping timeout: 248 seconds) |
| 2025-03-28 02:20:08 +0100 | <Leary> | It's not really any different from `newtype Landmark = Landmark{ prepareAndCheck :: FilePath -> IO Check }`. |
| 2025-03-28 02:20:47 +0100 | olivial | (~benjaminl@user/benjaminl) benjaminl |
| 2025-03-28 02:22:05 +0100 | notdabs | (~Owner@2600:1700:69cf:9000:9c7c:26a2:e9ed:cf3a) (Read error: Connection reset by peer) |
| 2025-03-28 02:22:31 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 244 seconds) |
| 2025-03-28 02:33:32 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-03-28 02:34:08 +0100 | <EvanR> | there's usually a way to reword your datatype so that existentials, and sometimes higher rank types aren't required |
| 2025-03-28 02:34:42 +0100 | <EvanR> | alternatively with higher rank polymorphism, you can make data types not required |
| 2025-03-28 02:34:56 +0100 | <EvanR> | whatever is more convenient |
| 2025-03-28 02:35:14 +0100 | ljdarj1 | (~Thunderbi@user/ljdarj) ljdarj |
| 2025-03-28 02:35:43 +0100 | Googulator | (~Googulato@2a01-036d-0106-01d5-c415-995d-99e3-7810.pool6.digikabel.hu) (Quit: Client closed) |
| 2025-03-28 02:36:00 +0100 | Googulator | (~Googulato@2a01-036d-0106-01d5-c415-995d-99e3-7810.pool6.digikabel.hu) |
| 2025-03-28 02:37:22 +0100 | ljdarj | (~Thunderbi@user/ljdarj) (Ping timeout: 248 seconds) |
| 2025-03-28 02:37:22 +0100 | ljdarj1 | ljdarj |
| 2025-03-28 02:38:39 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 268 seconds) |
| 2025-03-28 02:41:02 +0100 | aetepe | (~aetepe@188.119.58.34) aetepe |
| 2025-03-28 02:44:12 +0100 | anselmschueler | (~quassel@user/schuelermine) (Ping timeout: 268 seconds) |
| 2025-03-28 02:45:59 +0100 | aetepe | (~aetepe@188.119.58.34) (Ping timeout: 260 seconds) |
| 2025-03-28 02:49:19 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-03-28 02:53:57 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 248 seconds) |
| 2025-03-28 02:56:09 +0100 | weary-traveler | (~user@user/user363627) user363627 |
| 2025-03-28 02:59:24 +0100 | ljdarj | (~Thunderbi@user/ljdarj) (Quit: ljdarj) |
| 2025-03-28 03:03:48 +0100 | gmg | (~user@user/gehmehgeh) (Remote host closed the connection) |
| 2025-03-28 03:03:54 +0100 | jmcantrell | (~weechat@user/jmcantrell) (Quit: WeeChat 4.6.0) |
| 2025-03-28 03:04:32 +0100 | gmg | (~user@user/gehmehgeh) gehmehgeh |
| 2025-03-28 03:04:39 +0100 | jmcantrell | (~weechat@user/jmcantrell) jmcantrell |
| 2025-03-28 03:04:48 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-03-28 03:05:20 +0100 | xff0x | (~xff0x@fsb6a9491c.tkyc517.ap.nuro.jp) |
| 2025-03-28 03:11:38 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 245 seconds) |
| 2025-03-28 03:17:39 +0100 | werneta | (~werneta@syn-071-083-160-242.res.spectrum.com) werneta |
| 2025-03-28 03:22:51 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-03-28 03:27:50 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 252 seconds) |
| 2025-03-28 03:38:36 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-03-28 03:39:54 +0100 | aetepe | (~aetepe@188.119.58.34) aetepe |
| 2025-03-28 03:43:30 +0100 | ensyde | (~ensyde@2601:5c6:c200:6dc0::8955) |
| 2025-03-28 03:43:38 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 244 seconds) |
| 2025-03-28 03:44:44 +0100 | aetepe | (~aetepe@188.119.58.34) (Ping timeout: 260 seconds) |
| 2025-03-28 03:51:13 +0100 | tomku | (~tomku@user/tomku) (Ping timeout: 245 seconds) |
| 2025-03-28 03:51:24 +0100 | <haskellbridge> | <Bowuigi> EvanR programming with rank N stuff only can be annoying sometimes, specially on a total system |
| 2025-03-28 03:51:28 +0100 | tomku | (~tomku@user/tomku) tomku |
| 2025-03-28 03:52:16 +0100 | <haskellbridge> | <Bowuigi> Mendler-style recursion schemes are fantastic though, if only there was a way to get histomorphisms working on a total setting... |
| 2025-03-28 03:54:22 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-03-28 03:55:33 +0100 | aetepe | (~aetepe@188.119.58.34) aetepe |
| 2025-03-28 03:59:06 +0100 | LainExperiments | (~LainExper@user/LainExperiments) LainExperiments |
| 2025-03-28 03:59:22 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 252 seconds) |
| 2025-03-28 04:00:02 +0100 | aetepe | (~aetepe@188.119.58.34) (Ping timeout: 248 seconds) |
| 2025-03-28 04:02:48 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-03-28 04:07:24 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 244 seconds) |
| 2025-03-28 04:11:17 +0100 | aetepe | (~aetepe@188.119.58.34) aetepe |
| 2025-03-28 04:12:19 +0100 | tromp | (~textual@2001:1c00:3487:1b00:f8c0:4558:f838:6f52) (Ping timeout: 260 seconds) |
| 2025-03-28 04:13:23 +0100 | LainExperiments | (~LainExper@user/LainExperiments) (Quit: Client closed) |
| 2025-03-28 04:14:36 +0100 | emmanuelux_ | (~emmanuelu@user/emmanuelux) emmanuelux |
| 2025-03-28 04:16:05 +0100 | emmanuelux | (~emmanuelu@user/emmanuelux) (Ping timeout: 268 seconds) |
| 2025-03-28 04:16:15 +0100 | aetepe | (~aetepe@188.119.58.34) (Ping timeout: 276 seconds) |
| 2025-03-28 04:17:35 +0100 | <haskellbridge> | <thirdofmay18081814goya> what exactly is a higher-order effect that algebraic effects can't handle? |
| 2025-03-28 04:17:51 +0100 | <haskellbridge> | <thirdofmay18081814goya> is it an effect that takes another effect? something like "Effect a -> Effect b"? |
| 2025-03-28 04:18:33 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-03-28 04:21:33 +0100 | LainExperiments | (~LainExper@user/LainExperiments) LainExperiments |
| 2025-03-28 04:23:25 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 244 seconds) |
| 2025-03-28 04:34:20 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-03-28 04:38:59 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 260 seconds) |
| 2025-03-28 04:39:10 +0100 | <Leary> | thirdofmay: `data Catch e m a where Catch :: m a -> (e -> m a) -> Catch e m a`. The effect `runCatchEM :: forall a. Catch E M (M a) -> M a` is a higher order effect because `Catch` needs to know about `M`, and it isn't algebraic because `runCatch c >>= k /= runCatch (c <&> (>>= k))`. |
| 2025-03-28 04:40:00 +0100 | LainExperiments3 | (LainExperi@user/LainExperiments) LainExperiments |
| 2025-03-28 04:41:15 +0100 | <jackdk> | Is LainExperiments serially-numbered? |
| 2025-03-28 04:42:06 +0100 | LainExperiments | (~LainExper@user/LainExperiments) (Ping timeout: 240 seconds) |
| 2025-03-28 04:45:08 +0100 | <haskellbridge> | <thirdofmay18081814goya> Leary: I see! thanks a lot for the comment! |
| 2025-03-28 04:46:52 +0100 | <EvanR> | I had to look at join parts to get that one |
| 2025-03-28 04:49:31 +0100 | <haskellbridge> | <Liamzee> are people doing much with civilian linear types these days? |
| 2025-03-28 04:49:52 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-03-28 04:56:39 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 260 seconds) |
| 2025-03-28 04:57:12 +0100 | <haskellbridge> | <Liamzee> i still feel bad about not writing a linearly typed growable vector lib, because it wouldn't have been any good |
| 2025-03-28 04:58:15 +0100 | <jackdk> | Axman6 and I have a half-done port of streaming-bytestring to linear types but never finished it |
| 2025-03-28 04:58:44 +0100 | <Axman6> | We should finish that |
| 2025-03-28 04:59:17 +0100 | <Axman6> | I feel like there wasn't all that much left |
| 2025-03-28 04:59:44 +0100 | <EvanR> | https://hackage.haskell.org/package/linear-base-0.4.0/docs/Data-Vector-Mutable-Linear.html |
| 2025-03-28 05:03:00 +0100 | <Axman6> | Is there a linear state monad or something that can make passing around linear values a little nicer? |
| 2025-03-28 05:06:28 +0100 | <jackdk> | https://hackage.haskell.org/package/linear-base-0.4.0/docs/Control-Functor-Linear.html#g:4 Not the module I would've expected |
| 2025-03-28 05:07:56 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-03-28 05:09:10 +0100 | <haskellbridge> | <Liamzee> oh, i never realized that linear base had dynamic vectors, only mutable ones |
| 2025-03-28 05:10:00 +0100 | <EvanR> | there is also a destination array thing in there |
| 2025-03-28 05:10:43 +0100 | <Leary> | thirdofmay: Err, I guess that should have been `data Catch e m a where Catch :: m x -> (Either e x -> a) -> Catch e m a`, which probably clarifies the rest of what I said. |
| 2025-03-28 05:12:21 +0100 | aetepe | (~aetepe@188.119.58.34) aetepe |
| 2025-03-28 05:13:01 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 244 seconds) |
| 2025-03-28 05:14:05 +0100 | <haskellbridge> | <Liamzee> but no one has built a linearly typed webserver and put it on hackage? |
| 2025-03-28 05:16:49 +0100 | <haskellbridge> | <Liamzee> fun recent linear types: |
| 2025-03-28 05:16:50 +0100 | <haskellbridge> | <Liamzee> https://hackage.haskell.org/package/text-builder-linear |
| 2025-03-28 05:16:54 +0100 | <haskellbridge> | <Liamzee> by bodigrim |
| 2025-03-28 05:17:03 +0100 | aetepe | (~aetepe@188.119.58.34) (Ping timeout: 245 seconds) |
| 2025-03-28 05:18:36 +0100 | LainExperiments3 | (LainExperi@user/LainExperiments) (Quit: Client closed) |
| 2025-03-28 05:19:40 +0100 | <EvanR> | it's not linearly typed but it does do the thing everyone thinks linear types are for http://www.impredicative.com/ur/ |
| 2025-03-28 05:19:49 +0100 | <EvanR> | Ur/Web |
| 2025-03-28 05:23:23 +0100 | michalz | (~michalz@185.246.207.205) |
| 2025-03-28 05:23:43 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-03-28 05:24:38 +0100 | <haskellbridge> | <thirdofmay18081814goya> does anyone know if there's a way to embed a max number of recursive calls in an arbitrary recursive function? |
| 2025-03-28 05:24:57 +0100 | <haskellbridge> | <thirdofmay18081814goya> i guess necessarily some method with recursion-schemes right |
| 2025-03-28 05:26:19 +0100 | <haskellbridge> | <thirdofmay18081814goya> the idea would be to have a recursive function whose specification is separate from the requirement that it terminates after n calls |
| 2025-03-28 05:26:36 +0100 | <haskellbridge> | <thirdofmay18081814goya> so that you can also use it without enforcing the max recursive call |
| 2025-03-28 05:27:26 +0100 | <haskellbridge> | <thirdofmay18081814goya> trivially a catamorphism whose algebra returns a pair can do this, any other ideas? |
| 2025-03-28 05:28:06 +0100 | aetepe | (~aetepe@188.119.58.34) aetepe |
| 2025-03-28 05:28:21 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 246 seconds) |
| 2025-03-28 05:28:46 +0100 | <EvanR> | this isn't doesn't "monkey patch" the way you want, but the partiality monad will let you decide elsewhere how long a recursive algorithm gets to terminate |
| 2025-03-28 05:29:04 +0100 | <Leary> | I would write `fixMaxDepth :: Int -> (a -> a) -> Maybe a`. |
| 2025-03-28 05:29:24 +0100 | <Leary> | Err, maybe not. |
| 2025-03-28 05:29:53 +0100 | <Leary> | `fixMaxDepth :: Int -> (a -> Either a b) -> Maybe b`? |
| 2025-03-28 05:29:55 +0100 | LainExperiments | (~LainExper@user/LainExperiments) LainExperiments |
| 2025-03-28 05:30:10 +0100 | <EvanR> | well, now it's nearly the partiality monad |
| 2025-03-28 05:30:48 +0100 | aforemny_ | (~aforemny@2001:9e8:6cdb:6d00:dc2e:87c9:d5a9:a75) (Ping timeout: 245 seconds) |
| 2025-03-28 05:31:23 +0100 | aforemny | (~aforemny@i577B139C.versanet.de) aforemny |
| 2025-03-28 05:31:30 +0100 | <haskellbridge> | <thirdofmay18081814goya> i'll check out the partiality monad, thanks! |
| 2025-03-28 05:33:14 +0100 | aetepe | (~aetepe@188.119.58.34) (Ping timeout: 260 seconds) |
| 2025-03-28 05:34:47 +0100 | LainExperiments4 | (~LainExper@user/LainExperiments) LainExperiments |
| 2025-03-28 05:36:06 +0100 | LainExperiments | (~LainExper@user/LainExperiments) (Ping timeout: 240 seconds) |
| 2025-03-28 05:36:07 +0100 | bitdex | (~bitdex@gateway/tor-sasl/bitdex) bitdex |
| 2025-03-28 05:38:54 +0100 | peterbecich | (~Thunderbi@syn-047-229-123-186.res.spectrum.com) peterbecich |
| 2025-03-28 05:39:30 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-03-28 05:40:52 +0100 | Digitteknohippie | Digit |
| 2025-03-28 05:44:37 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 248 seconds) |
| 2025-03-28 05:51:33 +0100 | haskellbridge | (~hackager@syn-024-093-192-219.res.spectrum.com) (Ping timeout: 252 seconds) |
| 2025-03-28 05:53:05 +0100 | Digitteknohippie | (~user@user/digit) Digit |
| 2025-03-28 05:54:07 +0100 | Digit | (~user@user/digit) (Ping timeout: 252 seconds) |
| 2025-03-28 05:54:24 +0100 | haskellbridge | (~hackager@syn-024-093-192-219.res.spectrum.com) hackager |
| 2025-03-28 05:54:24 +0100 | ChanServ | +v haskellbridge |
| 2025-03-28 05:55:18 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-03-28 05:55:23 +0100 | xff0x | (~xff0x@fsb6a9491c.tkyc517.ap.nuro.jp) (Ping timeout: 245 seconds) |
| 2025-03-28 05:55:35 +0100 | <jackdk> | thirdofmay18081814goya: Hughes does this for a game tree by generating the infinite tree and then pruning it to N levels, which works because laziness |
| 2025-03-28 06:00:02 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 244 seconds) |
| 2025-03-28 06:03:49 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-03-28 06:06:30 +0100 | LainExperiments4 | (~LainExper@user/LainExperiments) (Ping timeout: 240 seconds) |
| 2025-03-28 06:08:08 +0100 | <haskellbridge> | <thirdofmay18081814goya> jackdk: ah very neat, will check this out too, have not considered any notion of laziness so far |
| 2025-03-28 06:08:10 +0100 | <haskellbridge> | <thirdofmay18081814goya> thanks! |
| 2025-03-28 06:08:49 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 244 seconds) |
| 2025-03-28 06:10:44 +0100 | peterbecich | (~Thunderbi@syn-047-229-123-186.res.spectrum.com) (Ping timeout: 265 seconds) |
| 2025-03-28 06:10:54 +0100 | xff0x | (~xff0x@fsb6a9491c.tkyc517.ap.nuro.jp) |
| 2025-03-28 06:12:03 +0100 | gmg | (~user@user/gehmehgeh) (Remote host closed the connection) |
| 2025-03-28 06:12:45 +0100 | gmg | (~user@user/gehmehgeh) gehmehgeh |
| 2025-03-28 06:13:33 +0100 | LainExperiments | (~LainExper@user/LainExperiments) LainExperiments |
| 2025-03-28 06:17:39 +0100 | Digitteknohippie | Digit |
| 2025-03-28 06:19:33 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-03-28 06:21:56 +0100 | <ski> | Leary : `Either e x -> a' a la "Exceptional Syntax" ? |
| 2025-03-28 06:22:06 +0100 | <ski> | EvanR : Ur has uniqueness ? |
| 2025-03-28 06:22:53 +0100 | <EvanR> | does it? |
| 2025-03-28 06:23:01 +0100 | <ski> | i dunno |
| 2025-03-28 06:23:10 +0100 | <ski> | you said "it does do the thing everyone thinks linear types are for" |
| 2025-03-28 06:24:07 +0100 | <EvanR> | memory management, or lack there of |
| 2025-03-28 06:24:34 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 248 seconds) |
| 2025-03-28 06:27:19 +0100 | <ski> | mhm |
| 2025-03-28 06:29:09 +0100 | aetepe | (~aetepe@188.119.58.34) aetepe |
| 2025-03-28 06:32:48 +0100 | Digitteknohippie | (~user@user/digit) Digit |
| 2025-03-28 06:33:06 +0100 | <Leary> | ski: I'm not familiar with the paper. I pulled that `data Catch` out of my arse, though it may have been inspired by 'A Framework for Higher-Order Effects & Handlers'. |
| 2025-03-28 06:33:37 +0100 | aetepe | (~aetepe@188.119.58.34) (Ping timeout: 244 seconds) |
| 2025-03-28 06:34:13 +0100 | Digit | (~user@user/digit) (Ping timeout: 268 seconds) |
| 2025-03-28 06:35:20 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-03-28 06:36:40 +0100 | Digitteknohippie | Digit |
| 2025-03-28 06:41:03 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 252 seconds) |
| 2025-03-28 06:44:35 +0100 | ChaiTRex | (~ChaiTRex@user/chaitrex) (Remote host closed the connection) |
| 2025-03-28 06:46:08 +0100 | ChaiTRex | (~ChaiTRex@user/chaitrex) ChaiTRex |
| 2025-03-28 06:46:09 +0100 | takuan | (~takuan@d8D86B601.access.telenet.be) |
| 2025-03-28 06:51:54 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-03-28 06:53:14 +0100 | Square | (~Square@user/square) Square |
| 2025-03-28 06:57:08 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 265 seconds) |
| 2025-03-28 06:57:19 +0100 | weary-traveler | (~user@user/user363627) (Remote host closed the connection) |
| 2025-03-28 06:58:01 +0100 | <ski> | Leary : "Exceptional Syntax" by Nick Benton,Andrew Kennedy in 2001 at <https://www.microsoft.com/en-us/research/wp-content/uploads/2016/02/exceptionalsyntax.pdf> (<http://lambda-the-ultimate.org/node/1193) |
| 2025-03-28 06:58:19 +0100 | nvoid | (~nvoid@2601:140:8700:25fe:5820:136c:b0ce:f5b1) |
| 2025-03-28 06:59:07 +0100 | <ski> | basically argues for (in Haskell terms) `catchBind :: Exception e => IO a -> (e -> IO b) -> (a -> IO b) -> IO b' being more appropriate as a primitive, than `catch :: Exception e => IO a -> (e -> IO a) -> IO a' |
| 2025-03-28 06:59:40 +0100 | <ski> | one reason being tail calls |
| 2025-03-28 07:04:46 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-03-28 07:05:47 +0100 | nvoid | (~nvoid@2601:140:8700:25fe:5820:136c:b0ce:f5b1) (Quit: nvoid) |
| 2025-03-28 07:09:40 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 252 seconds) |
| 2025-03-28 07:10:06 +0100 | LainExperiments | (~LainExper@user/LainExperiments) (Ping timeout: 240 seconds) |
| 2025-03-28 07:10:32 +0100 | <sim590> | Consider the following problem: https://projecteuler.net/problem=32. Which I have solved. My algorithm uses some math analysis to determine an upper bound for the search space. Anyway, I use the following function to recognize a pandigital triplet: https://paste.debian.net/1365804/. Using this function, my algorithms gave me the right answer. Then, I decided to rewrite the function a bit to make |
| 2025-03-28 07:10:34 +0100 | <sim590> | it simpler. I rewrote it to https://paste.debian.net/1365805/. I don't understand why, but now my whole algorithme doesn't give me the right answer anymore. |
| 2025-03-28 07:12:49 +0100 | <sim590> | To me, I thought that the second version made more sense... I'm now doubting if I accidently got the right answer because of a bad upper bound and a bad algorithm... lol |
| 2025-03-28 07:16:51 +0100 | rvalue | (~rvalue@user/rvalue) (Read error: Connection reset by peer) |
| 2025-03-28 07:17:23 +0100 | rvalue | (~rvalue@user/rvalue) rvalue |
| 2025-03-28 07:19:09 +0100 | LainExperiments | (~LainExper@user/LainExperiments) LainExperiments |
| 2025-03-28 07:20:34 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-03-28 07:20:57 +0100 | <sim590> | The funny thing is with the first function, the algorithm executes in 280 seconds while with the second function, it executes in 420 seconds... (it's by now means optimal, I tried a brute force approach with the help of an upper bound) |
| 2025-03-28 07:22:51 +0100 | emmanuelux_ | (~emmanuelu@user/emmanuelux) (Read error: Connection reset by peer) |
| 2025-03-28 07:23:49 +0100 | <sim590> | Ah. I get it. The second version doesn't take into account repeating numbers while the Set approach took care of that. |
| 2025-03-28 07:24:46 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 244 seconds) |
| 2025-03-28 07:24:49 +0100 | hattckory | (~hattckory@bras-base-toroon4524w-grc-30-70-27-118-207.dsl.bell.ca) (Ping timeout: 248 seconds) |
| 2025-03-28 07:30:14 +0100 | aetepe | (~aetepe@188.119.58.34) aetepe |
| 2025-03-28 07:30:52 +0100 | <Leary> | thirdofmay: I might be beating a dead horse at this point, but there are some details I kinda bungled due to algebraicity depending on precisely how on operation is expressed (and I prefer to fix these things). `catch :: M a -> (E -> M a) -> M a` naively becomes `catch :: Sig_Catch (M a) -> M a` with `Sig_Catch r = (r, E -> r)` which /isn't/ algebraic, but the last `data Catch` I wrote has a `runCatch` that actually /is/. That's because I cheated and us |
| 2025-03-28 07:30:53 +0100 | <Leary> | ed `try` disguised as `catch`: `M a -> M (Either E a)` ~ `M a -> Codensity M (Either E a)` ~ `M a -> (Either E a -> M b) -> M b` ~ `Sig_Try (M b) -> M b` where `Sig_Try r = (M a, Either E a -> r)`. |
| 2025-03-28 07:31:40 +0100 | hattckory | (~hattckory@70.27.118.207) |
| 2025-03-28 07:33:50 +0100 | <Leary> | ski: I see. Those tail calls and algebraicity are probably related. |
| 2025-03-28 07:34:57 +0100 | aetepe | (~aetepe@188.119.58.34) (Ping timeout: 248 seconds) |
| 2025-03-28 07:35:57 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-03-28 07:41:00 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 244 seconds) |
| 2025-03-28 07:43:22 +0100 | echoreply | (~echoreply@2001:19f0:9002:1f3b:5400:ff:fe6f:8b8d) (Quit: WeeChat 2.8) |
| 2025-03-28 07:43:55 +0100 | echoreply | (~echoreply@45.32.163.16) echoreply |
| 2025-03-28 07:43:59 +0100 | Digitteknohippie | (~user@user/digit) Digit |
| 2025-03-28 07:45:13 +0100 | Digit | (~user@user/digit) (Ping timeout: 252 seconds) |
| 2025-03-28 07:48:50 +0100 | <haskellbridge> | <thirdofmay18081814goya> Leary: am parsing these comments, thanks for the answer! |
| 2025-03-28 07:51:45 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-03-28 07:56:09 +0100 | hattckory | (~hattckory@70.27.118.207) (Ping timeout: 260 seconds) |
| 2025-03-28 07:58:18 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 245 seconds) |
| 2025-03-28 08:00:00 +0100 | caconym | (~caconym@user/caconym) (Quit: bye) |
| 2025-03-28 08:01:02 +0100 | caconym | (~caconym@user/caconym) caconym |
| 2025-03-28 08:03:08 +0100 | Digitteknohippie | Digit |
| 2025-03-28 08:05:36 +0100 | aetepe | (~aetepe@188.119.58.34) aetepe |
| 2025-03-28 08:05:46 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-03-28 08:10:15 +0100 | aetepe | (~aetepe@188.119.58.34) (Ping timeout: 276 seconds) |
| 2025-03-28 08:10:32 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 252 seconds) |
| 2025-03-28 08:15:55 +0100 | Lord_of_Life | (~Lord@user/lord-of-life/x-2819915) (Ping timeout: 244 seconds) |
| 2025-03-28 08:15:59 +0100 | ensyde | (~ensyde@2601:5c6:c200:6dc0::8955) (Ping timeout: 260 seconds) |
| 2025-03-28 08:17:48 +0100 | ensyde | (~ensyde@2601:5c6:c200:6dc0::6f7f) ensyde |
| 2025-03-28 08:18:43 +0100 | jmcantrell | (~weechat@user/jmcantrell) (Ping timeout: 244 seconds) |
| 2025-03-28 08:19:11 +0100 | ft | (~ft@p508db463.dip0.t-ipconnect.de) (Quit: leaving) |
| 2025-03-28 08:19:25 +0100 | Lord_of_Life | (~Lord@user/lord-of-life/x-2819915) Lord_of_Life |
| 2025-03-28 08:21:32 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-03-28 08:26:39 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 260 seconds) |
| 2025-03-28 08:30:06 +0100 | LainExperiments | (~LainExper@user/LainExperiments) (Quit: Client closed) |
| 2025-03-28 08:31:37 +0100 | ash3en | (~Thunderbi@ip1f10cbd6.dynamic.kabel-deutschland.de) ash3en |
| 2025-03-28 08:33:39 +0100 | wootehfoot | (~wootehfoo@user/wootehfoot) wootehfoot |
| 2025-03-28 08:37:21 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-03-28 08:42:14 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 260 seconds) |
| 2025-03-28 08:44:16 +0100 | connrs | (~connrs@user/connrs) (Quit: ZNC 1.9.1 - https://znc.in) |
| 2025-03-28 08:52:39 +0100 | ash3en | (~Thunderbi@ip1f10cbd6.dynamic.kabel-deutschland.de) (Ping timeout: 265 seconds) |
| 2025-03-28 08:53:18 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-03-28 08:54:35 +0100 | L29Ah | (~L29Ah@wikipedia/L29Ah) (Read error: Connection timed out) |
| 2025-03-28 08:56:56 +0100 | acidjnk | (~acidjnk@p200300d6e71c4f71c835c1b6e3010b6c.dip0.t-ipconnect.de) acidjnk |
| 2025-03-28 08:58:11 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 252 seconds) |
| 2025-03-28 09:00:15 +0100 | lortabac | (~lortabac@2a01:e0a:541:b8f0:55ab:e185:7f81:54a4) lortabac |
| 2025-03-28 09:00:19 +0100 | connrs | (~connrs@user/connrs) connrs |
| 2025-03-28 09:02:36 +0100 | CiaoSen | (~Jura@2a02:8071:64e1:da0:5a47:caff:fe78:33db) CiaoSen |
| 2025-03-28 09:04:51 +0100 | developer_ | (~developer@85.50.149.196) |
| 2025-03-28 09:06:46 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-03-28 09:07:14 +0100 | vpan | (~vpan@212.117.1.172) |
| 2025-03-28 09:11:39 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 245 seconds) |
| 2025-03-28 09:12:06 +0100 | Googulator | (~Googulato@2a01-036d-0106-01d5-c415-995d-99e3-7810.pool6.digikabel.hu) (Ping timeout: 240 seconds) |
| 2025-03-28 09:14:37 +0100 | auri | (~auri@fsf/member/auri) auri |
| 2025-03-28 09:21:30 +0100 | __monty__ | (~toonn@user/toonn) toonn |
| 2025-03-28 09:22:34 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-03-28 09:29:29 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 260 seconds) |
| 2025-03-28 09:33:44 +0100 | econo_ | (uid147250@id-147250.tinside.irccloud.com) (Quit: Connection closed for inactivity) |
| 2025-03-28 09:40:37 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-03-28 09:43:44 +0100 | sord937 | (~sord937@gateway/tor-sasl/sord937) sord937 |
| 2025-03-28 09:44:54 +0100 | sprout | (~sprout@84-80-106-227.fixed.kpn.net) (Ping timeout: 246 seconds) |
| 2025-03-28 09:45:30 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 252 seconds) |
| 2025-03-28 09:52:36 +0100 | Sgeo | (~Sgeo@user/sgeo) (Read error: Connection reset by peer) |
| 2025-03-28 09:53:26 +0100 | hattckory | (~hattckory@bras-base-toroon4524w-grc-30-70-27-118-207.dsl.bell.ca) |
| 2025-03-28 09:56:23 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-03-28 09:58:09 +0100 | hattckory | (~hattckory@bras-base-toroon4524w-grc-30-70-27-118-207.dsl.bell.ca) (Ping timeout: 276 seconds) |
| 2025-03-28 09:58:57 +0100 | <haskellbridge> | <Liamzee> also, Axman6 |
| 2025-03-28 09:58:58 +0100 | <haskellbridge> | <Liamzee> https://media.discordapp.net/attachments/968989726633779215/1355089415214465144/image.png?ex=67e7a… |
| 2025-03-28 09:59:25 +0100 | lxsameer | (~lxsameer@Serene/lxsameer) lxsameer |
| 2025-03-28 10:01:44 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 260 seconds) |
| 2025-03-28 10:02:23 +0100 | ash3en | (~Thunderbi@185.209.196.192) ash3en |
| 2025-03-28 10:06:17 +0100 | sprout | (~sprout@84-80-106-227.fixed.kpn.net) sprout |
| 2025-03-28 10:07:46 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-03-28 10:10:15 +0100 | sord937 | (~sord937@gateway/tor-sasl/sord937) (Remote host closed the connection) |
| 2025-03-28 10:10:35 +0100 | sord937 | (~sord937@gateway/tor-sasl/sord937) sord937 |
| 2025-03-28 10:11:08 +0100 | aetepe | (~aetepe@188.119.58.34) aetepe |
| 2025-03-28 10:12:33 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 246 seconds) |
| 2025-03-28 10:15:20 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-03-28 10:17:20 +0100 | sord937 | (~sord937@gateway/tor-sasl/sord937) (Quit: sord937) |
| 2025-03-28 10:18:14 +0100 | Googulator | (~Googulato@81.183.235.203) |
| 2025-03-28 10:18:43 +0100 | tzh | (~tzh@c-76-115-131-146.hsd1.or.comcast.net) (Quit: zzz) |
| 2025-03-28 10:19:36 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 252 seconds) |
| 2025-03-28 10:25:05 +0100 | fp | (~Thunderbi@130.233.70.95) fp |
| 2025-03-28 10:25:16 +0100 | Googulator | (~Googulato@81.183.235.203) (Quit: Client closed) |
| 2025-03-28 10:25:29 +0100 | Googulator | (~Googulato@81.183.235.203) |
| 2025-03-28 10:25:46 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-03-28 10:27:00 +0100 | tromp | (~textual@2001:1c00:3487:1b00:6095:11f3:6fa5:fb3d) |
| 2025-03-28 10:27:01 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Read error: Connection reset by peer) |
| 2025-03-28 10:28:34 +0100 | merijn | (~merijn@77.242.116.146) merijn |
| 2025-03-28 10:28:51 +0100 | Square | (~Square@user/square) (Remote host closed the connection) |
| 2025-03-28 10:31:59 +0100 | sord937 | (~sord937@gateway/tor-sasl/sord937) sord937 |
| 2025-03-28 10:38:27 +0100 | chele | (~chele@user/chele) chele |
| 2025-03-28 10:43:41 +0100 | j1n37 | (~j1n37@user/j1n37) (Ping timeout: 244 seconds) |
| 2025-03-28 10:44:25 +0100 | j1n37 | (~j1n37@user/j1n37) j1n37 |
| 2025-03-28 10:44:54 +0100 | alp | (~alp@2001:861:8ca0:4940:97d8:ee2c:4105:6ce6) |
| 2025-03-28 10:48:20 +0100 | sord937 | (~sord937@gateway/tor-sasl/sord937) (Remote host closed the connection) |
| 2025-03-28 10:48:39 +0100 | sord937 | (~sord937@gateway/tor-sasl/sord937) sord937 |
| 2025-03-28 10:53:25 +0100 | arahael | (~arahael@user/arahael) (Ping timeout: 248 seconds) |
| 2025-03-28 10:53:28 +0100 | sord937 | (~sord937@gateway/tor-sasl/sord937) (Remote host closed the connection) |
| 2025-03-28 10:53:48 +0100 | sord937 | (~sord937@gateway/tor-sasl/sord937) sord937 |
| 2025-03-28 10:54:41 +0100 | tabaqui | (~tabaqui@167.71.80.236) tabaqui |
| 2025-03-28 10:55:48 +0100 | CiaoSen | (~Jura@2a02:8071:64e1:da0:5a47:caff:fe78:33db) (Ping timeout: 245 seconds) |
| 2025-03-28 10:56:46 +0100 | j1n37 | (~j1n37@user/j1n37) (Read error: Connection reset by peer) |
| 2025-03-28 10:56:54 +0100 | Googulator | (~Googulato@81.183.235.203) (Quit: Client closed) |
| 2025-03-28 10:57:12 +0100 | Googulator | (~Googulato@81.183.235.203) |
| 2025-03-28 10:58:17 +0100 | wildsalander | (~wildsalan@47.red-80-29-238.dynamicip.rima-tde.net) |
| 2025-03-28 10:58:42 +0100 | wildsalander | (~wildsalan@47.red-80-29-238.dynamicip.rima-tde.net) (Client Quit) |
| 2025-03-28 10:59:58 +0100 | j1n37 | (~j1n37@user/j1n37) j1n37 |
| 2025-03-28 11:01:08 +0100 | Square | (~Square@user/square) Square |
| 2025-03-28 11:04:02 +0100 | xff0x | (~xff0x@fsb6a9491c.tkyc517.ap.nuro.jp) (Ping timeout: 248 seconds) |
| 2025-03-28 11:06:29 +0100 | ljdarj | (~Thunderbi@user/ljdarj) ljdarj |
| 2025-03-28 11:17:15 +0100 | dhil | (~dhil@2a0c:b381:52e:3600:cbb4:807:319f:c7af) dhil |
| 2025-03-28 11:21:52 +0100 | CiaoSen | (~Jura@2a02:8071:64e1:da0:5a47:caff:fe78:33db) CiaoSen |
| 2025-03-28 11:25:42 +0100 | pavonia | (~user@user/siracusa) (Quit: Bye!) |
| 2025-03-28 11:26:18 +0100 | tt12310978324354 | (~tt1231@2603:6010:8700:4a81:219f:50d3:618a:a6ee) (Quit: The Lounge - https://thelounge.chat) |
| 2025-03-28 11:27:20 +0100 | tt12310978324354 | (~tt1231@2603:6010:8700:4a81:219f:50d3:618a:a6ee) tt1231 |
| 2025-03-28 11:28:12 +0100 | <haskellbridge> | <Morj> I've been playing around with using texinfo as a target for structured docs of haddock and other tools. Here's the unstyled result: https://morj.men/ron_html/Quick-start.html and the hackage page for comparison: https://hackage.haskell.org/package/ron-hs-0.4.0/docs/Data-Ron.html |
| 2025-03-28 11:29:33 +0100 | <haskellbridge> | <Morj> It's fun to see how much importance the creators of texinfo placed on the printed material, compared to now where I want options for easier hierarchy (like a module has classes, classes have functions and implementors, all hyperlinked). This forced me to use '@node' everywhere which inserts a page break |
| 2025-03-28 11:31:07 +0100 | <haskellbridge> | <Morj> I also wouldn't call it good for hyperlinked manuals: the dichotomy how there is a node hierarchy, and a chapter-subchapter hierarchy is weird, plus there isn't even an option to make the table of contents automatically |
| 2025-03-28 11:31:25 +0100 | <haskellbridge> | <Morj> But this was fun, thanks to someone from here for telling me of this format |
| 2025-03-28 11:42:18 +0100 | ash3en | (~Thunderbi@185.209.196.192) (Ping timeout: 265 seconds) |
| 2025-03-28 11:49:49 +0100 | Square | (~Square@user/square) (Ping timeout: 244 seconds) |
| 2025-03-28 11:53:49 +0100 | <haskellbridge> | <Liamzee> wait, what? |
| 2025-03-28 11:53:51 +0100 | <haskellbridge> | <Liamzee> https://hackage.haskell.org/package/linear-base-0.4.0/docs/src/Data.List.Linear.html#take |
| 2025-03-28 11:53:55 +0100 | <haskellbridge> | <Liamzee> look at the take function, why is it like this? |
| 2025-03-28 11:56:45 +0100 | ash3en | (~Thunderbi@185.209.196.192) ash3en |
| 2025-03-28 12:00:06 +0100 | L29Ah | (~L29Ah@wikipedia/L29Ah) L29Ah |
| 2025-03-28 12:15:01 +0100 | ensyde | (~ensyde@2601:5c6:c200:6dc0::6f7f) (Ping timeout: 248 seconds) |
| 2025-03-28 12:18:08 +0100 | lortabac | (~lortabac@2a01:e0a:541:b8f0:55ab:e185:7f81:54a4) (Ping timeout: 272 seconds) |
| 2025-03-28 12:20:48 +0100 | ljdarj | (~Thunderbi@user/ljdarj) (Ping timeout: 245 seconds) |
| 2025-03-28 12:20:50 +0100 | ubert1 | (~Thunderbi@2a02:8109:ab8a:5a00:7d86:d0e8:c2d1:2ee3) ubert |
| 2025-03-28 12:26:49 +0100 | acidjnk | (~acidjnk@p200300d6e71c4f71c835c1b6e3010b6c.dip0.t-ipconnect.de) (Ping timeout: 252 seconds) |
| 2025-03-28 12:27:44 +0100 | ash3en | (~Thunderbi@185.209.196.192) (Ping timeout: 265 seconds) |
| 2025-03-28 12:36:37 +0100 | <haskellbridge> | <jv> Liamzee: i remember having it done beautifully on this channel (or maybe #haskell-beginners). should be in the logs from about 6 years ago |
| 2025-03-28 12:36:54 +0100 | <haskellbridge> | <jv> or so |
| 2025-03-28 12:36:55 +0100 | <jackdk> | Because if you have [a] %1 -> b, then you need to do away with the entire list, not just the prefix that you take |
| 2025-03-28 12:37:36 +0100 | <haskellbridge> | <jv> under a different nick though |
| 2025-03-28 12:38:07 +0100 | JuanDaugherty | (~juan@user/JuanDaugherty) JuanDaugherty |
| 2025-03-28 12:39:18 +0100 | Googulator | (~Googulato@81.183.235.203) (Ping timeout: 240 seconds) |
| 2025-03-28 12:57:13 +0100 | aetepe | (~aetepe@188.119.58.34) (Ping timeout: 265 seconds) |
| 2025-03-28 12:57:24 +0100 | lortabac | (~lortabac@2a01:e0a:541:b8f0:55ab:e185:7f81:54a4) lortabac |
| 2025-03-28 12:57:35 +0100 | tremon | (~tremon@83.80.159.219) tremon |
| 2025-03-28 12:58:00 +0100 | fp | (~Thunderbi@130.233.70.95) (Ping timeout: 252 seconds) |
| 2025-03-28 12:59:04 +0100 | aetepe | (~aetepe@188.119.58.34) aetepe |
| 2025-03-28 12:59:56 +0100 | CiaoSen | (~Jura@2a02:8071:64e1:da0:5a47:caff:fe78:33db) (Ping timeout: 272 seconds) |
| 2025-03-28 13:00:52 +0100 | <tomsmeding> | Liamzee: in other words, that `lseq` is actually doing something, see its definition and the Consumable class |
| 2025-03-28 13:03:30 +0100 | ljdarj | (~Thunderbi@user/ljdarj) ljdarj |
| 2025-03-28 13:03:51 +0100 | merijn | (~merijn@77.242.116.146) (Ping timeout: 252 seconds) |
| 2025-03-28 13:04:31 +0100 | fp | (~Thunderbi@130.233.70.95) fp |
| 2025-03-28 13:10:58 +0100 | bitdex | (~bitdex@gateway/tor-sasl/bitdex) (Quit: = "") |
| 2025-03-28 13:16:53 +0100 | acidjnk | (~acidjnk@p200300d6e71c4f71c835c1b6e3010b6c.dip0.t-ipconnect.de) acidjnk |
| 2025-03-28 13:17:01 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-03-28 13:22:53 +0100 | Googulator | (~Googulato@81.183.235.203) |
| 2025-03-28 13:23:48 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 265 seconds) |
| 2025-03-28 13:28:36 +0100 | <__monty__> | I thought `%1 ->` meant at most once, not exactly once? |
| 2025-03-28 13:29:23 +0100 | tromp | (~textual@2001:1c00:3487:1b00:6095:11f3:6fa5:fb3d) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 2025-03-28 13:33:59 +0100 | <yushyin> | i think it is exactly once |
| 2025-03-28 13:35:18 +0100 | Googulator | (~Googulato@81.183.235.203) (Ping timeout: 240 seconds) |
| 2025-03-28 13:35:22 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-03-28 13:35:56 +0100 | ft | (~ft@p508db463.dip0.t-ipconnect.de) ft |
| 2025-03-28 13:37:58 +0100 | <tomsmeding> | __monty__: it means exactly once. At most once would be an "affine" arrow, not a "linear" one, I think, in the prevailing jargon |
| 2025-03-28 13:40:36 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 244 seconds) |
| 2025-03-28 13:43:24 +0100 | zungi | (~tory@user/andrewchawk) (Ping timeout: 264 seconds) |
| 2025-03-28 13:43:42 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-03-28 13:44:27 +0100 | <__monty__> | In what context is it important to consume the argument? Limiting to once is easier to reason about, side-effects are a good reason for example. |
| 2025-03-28 13:47:14 +0100 | Googulator | (~Googulato@81.183.235.203) |
| 2025-03-28 13:48:06 +0100 | zungi | (~tory@user/andrewchawk) andrewchawk |
| 2025-03-28 13:48:21 +0100 | <vpan> | hi, `foldMapM` from GHC.Utils.Monad seems useful (found it on hoogle), but calling something from the compiler's namespace feels wrong. There must be a reason those functions aren't in base. Is my intuition correct that typical applications (that don't process Haskell code) should stay away from GHC.*? |
| 2025-03-28 13:51:03 +0100 | <__monty__> | I think the reason not to use the GHC modules is the size of the package. |
| 2025-03-28 13:52:50 +0100 | Unicorn_Princess | (~Unicorn_P@user/Unicorn-Princess/x-3540542) (Remote host closed the connection) |
| 2025-03-28 13:54:36 +0100 | <__monty__> | @hoogle foldrM |
| 2025-03-28 13:54:37 +0100 | <lambdabot> | Data.Foldable foldrM :: (Foldable t, Monad m) => (a -> b -> m b) -> b -> t a -> m b |
| 2025-03-28 13:54:37 +0100 | <lambdabot> | Data.Vector.Fusion.Bundle.Monadic foldrM :: Monad m => (a -> b -> m b) -> b -> Bundle m v a -> m b |
| 2025-03-28 13:54:37 +0100 | <lambdabot> | Data.Vector.Fusion.Stream.Monadic foldrM :: Monad m => (a -> b -> m b) -> b -> Stream m a -> m b |
| 2025-03-28 13:54:45 +0100 | <__monty__> | That does seem similar. |
| 2025-03-28 13:54:54 +0100 | <Leary> | :t (getAp .) . foldMap . (Ap .) |
| 2025-03-28 13:54:55 +0100 | <lambdabot> | forall k (t :: * -> *) (f :: k -> *) (a1 :: k) a2. (Foldable t, Monoid (Ap f a1)) => (a2 -> f a1) -> t a2 -> f a1 |
| 2025-03-28 13:57:30 +0100 | hattckory | (~hattckory@bras-base-toroon4524w-grc-30-70-27-118-207.dsl.bell.ca) |
| 2025-03-28 13:57:37 +0100 | weary-traveler | (~user@user/user363627) user363627 |
| 2025-03-28 13:58:44 +0100 | chele | (~chele@user/chele) (Remote host closed the connection) |
| 2025-03-28 14:01:18 +0100 | <vpan> | thanks for the hints. The trick using `Ap` looks cool. :) |
| 2025-03-28 14:03:41 +0100 | <tomsmeding> | __monty__: if you require linearity, you can use linear types as a memory management system. Opened files need to be closed, allocated arrays need to be freed; if you have affine arrows only, you still need a GC to clean them up |
| 2025-03-28 14:04:49 +0100 | hattckory | (~hattckory@bras-base-toroon4524w-grc-30-70-27-118-207.dsl.bell.ca) (Ping timeout: 260 seconds) |
| 2025-03-28 14:04:52 +0100 | <tomsmeding> | in that sense, linear arrows are "more general": they allow expressing safe APIs for more kinds of resources (i.e. ones that need to be closed/freed/... -- i.e. "consumed" -- at a predictable time) |
| 2025-03-28 14:05:30 +0100 | <__monty__> | And `free` is the only possible operation that consumes consumes an array without producing one? |
| 2025-03-28 14:05:32 +0100 | <tomsmeding> | I guess with affine arrows you can still opt-in to explicit consumption as the user, but with linear arrows, the API designer can _require_ explicit consumption |
| 2025-03-28 14:05:53 +0100 | <tomsmeding> | well, that depends on the API |
| 2025-03-28 14:05:57 +0100 | <tomsmeding> | for arrays, kind of? |
| 2025-03-28 14:06:16 +0100 | <tomsmeding> | though sometimes it comes in a different guise, like `toList :: Array a -> [a]` |
| 2025-03-28 14:06:25 +0100 | <tomsmeding> | er, `toList :: Array a %1-> [a]`, of course |
| 2025-03-28 14:06:35 +0100 | <tomsmeding> | (I hate the visuals of that %1-> syntax.) |
| 2025-03-28 14:07:04 +0100 | <__monty__> | Yeah, bring back the lollipop. |
| 2025-03-28 14:07:20 +0100 | <tomsmeding> | or hell, if you don't want letters in a symbol, do -%> or something |
| 2025-03-28 14:08:01 +0100 | <tomsmeding> | originally the syntax allowed multiplicity polymorphism, where you could have `forall p. a %p-> b`, but IIRC ghc doesn't currently implement that or something |
| 2025-03-28 14:08:22 +0100 | <__monty__> | How about array indexing? It'd be pretty inconvenient if that had to free the array. |
| 2025-03-28 14:08:53 +0100 | <tomsmeding> | oh, apparently ghc does support multiplicity polymorphism |
| 2025-03-28 14:09:12 +0100 | <tomsmeding> | __monty__: I suggest you peruse this page :) https://hackage.haskell.org/package/linear-base-0.4.0/docs/Data-Array-Mutable-Linear.html#v:get |
| 2025-03-28 14:09:31 +0100 | <tomsmeding> | % :seti -XLinearTypes |
| 2025-03-28 14:09:31 +0100 | <yahb2> | <no output> |
| 2025-03-28 14:09:39 +0100 | <tomsmeding> | % foo :: forall a b p. (a %p-> b) -> a %p-> b ; foo g x = g x |
| 2025-03-28 14:09:39 +0100 | <yahb2> | <no output> |
| 2025-03-28 14:09:55 +0100 | JuanDaugherty | (~juan@user/JuanDaugherty) (Quit: praxis.meansofproduction.biz (juan@acm.org)) |
| 2025-03-28 14:09:56 +0100 | <__monty__> | Is it still all smoke and mirrors or does linear data actually get allocated/freed outside of the GCed memory? |
| 2025-03-28 14:09:58 +0100 | <tomsmeding> | % :seti -fprint-explicit-foralls |
| 2025-03-28 14:09:58 +0100 | <yahb2> | <no output> |
| 2025-03-28 14:10:01 +0100 | <tomsmeding> | % :t foo |
| 2025-03-28 14:10:01 +0100 | <yahb2> | foo ; :: forall a b (p :: GHC.Types.Multiplicity). ; (a %p -> b) -> a %p -> b |
| 2025-03-28 14:10:54 +0100 | <tomsmeding> | __monty__: I think for this module, it's indeed smoke and mirrors, as you say |
| 2025-03-28 14:11:06 +0100 | <tomsmeding> | as in: you do get the advantage that the array can be used outside of IO or ST |
| 2025-03-28 14:11:15 +0100 | <tomsmeding> | but indeed the strict linearity is inessential |
| 2025-03-28 14:12:41 +0100 | <Leary> | __monty__: GHC doesn't do any magic for you, it gives you the tools to create safe interfaces over your own manually allocated/freed data. |
| 2025-03-28 14:12:52 +0100 | <tomsmeding> | ^ |
| 2025-03-28 14:12:56 +0100 | malte | (~malte@mal.tc) (Ping timeout: 244 seconds) |
| 2025-03-28 14:13:53 +0100 | <tomsmeding> | not unlikely that for arrays, allocating the array itself outside of the GC'd heap would be counterproductive, because if it's a boxed array then you'd have to register all the contained pointers as additional GC roots anyway, and it's not boxed then the GC spends only O(1) time on it |
| 2025-03-28 14:17:18 +0100 | jacopovalanzano | (~jacopoval@cpc151911-cove17-2-0-cust105.3-1.cable.virginm.net) |
| 2025-03-28 14:17:21 +0100 | <jacopovalanzano> | o/ |
| 2025-03-28 14:21:00 +0100 | paotsaq | (~paotsaq@127.209.37.188.rev.vodafone.pt) (Ping timeout: 272 seconds) |
| 2025-03-28 14:21:56 +0100 | malte | (~malte@mal.tc) malte |
| 2025-03-28 14:26:29 +0100 | agentultra | (~user@104-195-156-122.cpe.teksavvy.com) agentultra |
| 2025-03-28 14:29:12 +0100 | <agentultra> | i'm trying to compile a static executable with `cabal -v build --enable-static --enable-executable-static` but I am finding that theres a build step that fails as cabal seems to be passing `-dynamic` and `-shared` regardless. anyone have links to a guide on how to get cabal to build statically-linked executables? |
| 2025-03-28 14:30:40 +0100 | <tomsmeding> | agentultra: https://cs-syd.eu/posts/2024-04-20-static-linking-haskell-nix or https://hasufell.github.io/posts/2024-04-21-static-linking.html perhaps |
| 2025-03-28 14:31:11 +0100 | <agentultra> | thanks tomsmeding |
| 2025-03-28 14:31:21 +0100 | <tomsmeding> | agentultra: I'm assuming here that you're talking about statically-linking _system_ dependencies, not haskell dependencies |
| 2025-03-28 14:31:39 +0100 | <tomsmeding> | haskell dependencies are already linked statically by default, except (essentially) on Arch Linux system GHCs |
| 2025-03-28 14:33:17 +0100 | <tomsmeding> | (PSA: if you're on arch linux, as always but especially for you, please use ghcup and not the GHC from the system package manager) |
| 2025-03-28 14:34:43 +0100 | <agentultra> | yes. i'm linking in a shared object file that seems to be compiled in a funny way... when i link dynamically, I get a relink error from `sin` from the shared object. it seems to conflict with GHC's dynamically link with libm. I'm trying to statically link to see if that resolves the issue. |
| 2025-03-28 14:35:50 +0100 | hattckory | (~hattckory@bras-base-toroon4524w-grc-30-70-27-118-207.dsl.bell.ca) |
| 2025-03-28 14:36:08 +0100 | <tomsmeding> | agentultra: what exactly is that relink error? |
| 2025-03-28 14:36:21 +0100 | <tomsmeding> | compiling haskell programs statically is a bit of a rabbit hole, as you can see from those posts |
| 2025-03-28 14:37:06 +0100 | <agentultra> | It's a bit long: /home/jking/Projects/tigerbeetle-hs/dist-newstyle/build/x86_64-linux/ghc-9.6.6/tigerbeetle-hs-0.1.0.0/x/tigerbeetle-hs/build/tigerbeetle-hs/tigerbeetle-hs: Relink `/nix/store/x3v27x8fz9di2nv2j91xgsypvxgy34g9-libtb_client/lib/libtb_client.so' with `/nix/store/h7zcxabfxa7v5xdna45y2hplj31ncf8a-glibc-2.40-36/lib/libm.so.6' for IFUNC symbol `sin' |
| 2025-03-28 14:37:13 +0100 | ash3en | (~Thunderbi@185.209.196.192) ash3en |
| 2025-03-28 14:37:43 +0100 | tomsmeding | has never seen that particular error phrasing before |
| 2025-03-28 14:37:58 +0100 | <tomsmeding> | if you're using nix already anyway, though, getting a static link _may_ be easy enough |
| 2025-03-28 14:38:04 +0100 | tomsmeding | doesn't use nix |
| 2025-03-28 14:38:10 +0100 | ystael | (~ystael@user/ystael) ystael |
| 2025-03-28 14:38:31 +0100 | <agentultra> | i'm learning nix as I go here myself :D |
| 2025-03-28 14:38:57 +0100 | <agentultra> | but I'm mostly just using it to create the developer shell and compiling like normal with cabal |
| 2025-03-28 14:39:01 +0100 | <tomsmeding> | my first step in debugging this would be to check how that libtb_client.so refers to 'sin', first by running `nm` on it and if necessary perhaps with objdump |
| 2025-03-28 14:39:07 +0100 | <tomsmeding> | ah |
| 2025-03-28 14:40:18 +0100 | developer_ | (~developer@85.50.149.196) (Ping timeout: 252 seconds) |
| 2025-03-28 14:40:21 +0100 | robobub | (uid248673@id-248673.uxbridge.irccloud.com) (Quit: Connection closed for inactivity) |
| 2025-03-28 14:40:54 +0100 | hattckory | (~hattckory@bras-base-toroon4524w-grc-30-70-27-118-207.dsl.bell.ca) (Ping timeout: 276 seconds) |
| 2025-03-28 14:42:25 +0100 | <tomsmeding> | agentultra: bit of a shot in the dark: what happens if you don't put only `libtb_client` in your extra-libraries, but also `m`? |
| 2025-03-28 14:43:32 +0100 | <tomsmeding> | but also output of `ldd /nix/store/x3v27x8fz9di2nv2j91xgsypvxgy34g9-libtb_client/lib/libtb_client.so` might be helpful |
| 2025-03-28 14:43:36 +0100 | random-jellyfish | (~developer@user/random-jellyfish) random-jellyfish |
| 2025-03-28 14:44:45 +0100 | <agentultra> | yeah, so the symbol for `sin` from that library is listed as a W,F (Warning/Normal, Function) |
| 2025-03-28 14:45:16 +0100 | <yushyin> | agentultra: can't hurt to also ask in #haskell:nixos.org (matrix room) in case you suspect a nix-related issue |
| 2025-03-28 14:45:21 +0100 | <agentultra> | and ldd says it's linked with linux-vdso, libpthread, libc.so.6... but not libm |
| 2025-03-28 14:45:49 +0100 | <tomsmeding> | agentultra: "W" is weak, not warning |
| 2025-03-28 14:45:59 +0100 | <agentultra> | ah right, my b |
| 2025-03-28 14:46:14 +0100 | <tomsmeding> | do try also telling ghc to link with libm |
| 2025-03-28 14:46:24 +0100 | <agentultra> | a dynamically linked GHC executable does dynamically link with libm |
| 2025-03-28 14:46:26 +0100 | <tomsmeding> | (as I suggested a few lines above) |
| 2025-03-28 14:46:32 +0100 | <tomsmeding> | oh |
| 2025-03-28 14:46:42 +0100 | <agentultra> | ah k, i'll double check that |
| 2025-03-28 14:47:15 +0100 | chele | (~chele@user/chele) chele |
| 2025-03-28 14:51:02 +0100 | tromp | (~textual@2001:1c00:3487:1b00:6095:11f3:6fa5:fb3d) |
| 2025-03-28 14:55:38 +0100 | jespada | (~jespada@2800:a4:2225:2c00:21b7:d8ab:6242:25ba) jespada |
| 2025-03-28 15:01:46 +0100 | <agentultra> | yeah, shot in the dark doesn't change anything... the executable is still dynamically linked with libm.so.6, the libtb_client.so file is not. So the "relink" issue, as I understand it, is because that library's symbol table is looking for the implementation of that function which is conflicting with one already defined globally by the executable? |
| 2025-03-28 15:02:25 +0100 | malte | (~malte@mal.tc) (Ping timeout: 248 seconds) |
| 2025-03-28 15:02:31 +0100 | <tomsmeding> | I _think_ the error is saying that you need to re-link libtb_client.so with libm.so |
| 2025-03-28 15:02:48 +0100 | <tomsmeding> | that it to say, it's not an observation that a re-link is happening, it's an instruction to change libtb_client.so |
| 2025-03-28 15:03:18 +0100 | <tomsmeding> | your "it's a bit long" is also funny because in fact the error was really short: _despite_ very long paths, it still fit in a single IRC message |
| 2025-03-28 15:03:38 +0100 | <tomsmeding> | which is typical for linker errors, unfortunately: concise to the point of incomprehensibility |
| 2025-03-28 15:03:54 +0100 | <agentultra> | true! :D |
| 2025-03-28 15:04:23 +0100 | <tomsmeding> | so my feeling (!) is that there is no conflict at all, and that instead, the symbol 'sin' is _missing_ somehow |
| 2025-03-28 15:04:29 +0100 | <tomsmeding> | but I don't know enough here |
| 2025-03-28 15:05:12 +0100 | <agentultra> | it gives me some ideas though, so thanks for sounding off with me |
| 2025-03-28 15:05:34 +0100 | <tomsmeding> | also try linking that libtb_client.so with a simple C file |
| 2025-03-28 15:05:39 +0100 | <tomsmeding> | just with plain gcc |
| 2025-03-28 15:08:13 +0100 | ash3en | (~Thunderbi@185.209.196.192) (Ping timeout: 244 seconds) |
| 2025-03-28 15:08:18 +0100 | malte | (~malte@mal.tc) malte |
| 2025-03-28 15:09:24 +0100 | toby-bro | (~toby-bro@user/toby-bro) toby-bro |
| 2025-03-28 15:14:35 +0100 | <hellwolf> | what's the alternative to "replicateM constant" where I can pattern matching. Pattern matching the list is not as convenient, as far as I can tell. |
| 2025-03-28 15:15:02 +0100 | <hellwolf> | say `replicateN 2 mb >>= \(x1, x2) -> _` |
| 2025-03-28 15:17:22 +0100 | notdabs | (~Owner@2600:1700:69cf:9000:a99a:9123:20e6:65c6) |
| 2025-03-28 15:22:38 +0100 | <mauke> | :t replicateM 2 ?mb >>= \[x1, x2] -> ?result |
| 2025-03-28 15:22:38 +0100 | <lambdabot> | (Monad m, ?mb::m a, ?result::m b) => m b |
| 2025-03-28 15:27:29 +0100 | <hellwolf> | maybe my skill issue, but I don't like pattermatching these list output when I gave a Int constant as the "size" input. |
| 2025-03-28 15:27:42 +0100 | <hellwolf> | what's the idiomatic way of doing it? |
| 2025-03-28 15:28:09 +0100 | <__monty__> | Isn't static the default with GHC, I thought Arch's packaging was always so problematic because they want dynamic everything? |
| 2025-03-28 15:29:03 +0100 | Square | (~Square@user/square) Square |
| 2025-03-28 15:29:10 +0100 | <agentultra> | statically linking the Haskell object files, yes... but we still dynamically link libc, libgmp, etc. |
| 2025-03-28 15:29:34 +0100 | malte | (~malte@mal.tc) (Ping timeout: 260 seconds) |
| 2025-03-28 15:30:24 +0100 | jrm | (~jrm@user/jrm) (Quit: ciao) |
| 2025-03-28 15:30:26 +0100 | <Leary> | hellwolf: `mb >>= \x1 -> mb >>= \x2 -> ...` |
| 2025-03-28 15:30:27 +0100 | <haskellbridge> | <Morj> I think the tuple replicate would look something like "replicateN @2 mb >>= \(x1 :/\ x2) -> _" |
| 2025-03-28 15:30:35 +0100 | malte | (~malte@mal.tc) malte |
| 2025-03-28 15:30:47 +0100 | <haskellbridge> | <Morj> I vaguely remember seing those tuples somewhere, but that might have been purescript |
| 2025-03-28 15:31:57 +0100 | jrm | (~jrm@user/jrm) jrm |
| 2025-03-28 15:33:18 +0100 | <Leary> | You can of course write something like `replicateA :: Applicative f => SNat n -> f a -> f (Vec n a)`, but it's not more idiomatic than the dead-simple approach. |
| 2025-03-28 15:34:13 +0100 | <haskellbridge> | <Morj> But can ghc already prove that pattern-matching is exhastive here? |
| 2025-03-28 15:34:22 +0100 | <haskellbridge> | <Morj> With Vec runtimeValue I mean |
| 2025-03-28 15:34:29 +0100 | vpan | (~vpan@212.117.1.172) (Quit: Leaving.) |
| 2025-03-28 15:35:00 +0100 | <haskellbridge> | <Morj> Or, ugh, is it even runtime here, I got confused |
| 2025-03-28 15:35:07 +0100 | <hellwolf> | we have lift2M, we just need liftNM |
| 2025-03-28 15:35:55 +0100 | <hellwolf> | with "Vec n", we probably can pattern matching, perhaps pattern synonyms would be required. |
| 2025-03-28 15:36:16 +0100 | alp | (~alp@2001:861:8ca0:4940:97d8:ee2c:4105:6ce6) (Ping timeout: 268 seconds) |
| 2025-03-28 15:36:21 +0100 | paotsaq | (~paotsaq@127.209.37.188.rev.vodafone.pt) |
| 2025-03-28 15:36:29 +0100 | <hellwolf> | excuse me, from lift2, to liftN, I meant to say. |
| 2025-03-28 15:37:11 +0100 | <hellwolf> | but unless it's in the base/core library, it's not idiomatic... |
| 2025-03-28 15:37:17 +0100 | <hellwolf> | I know how to write my own, but that's not the point. |
| 2025-03-28 15:38:38 +0100 | <agentultra> | hm, it does dynamically link with gcc. |
| 2025-03-28 15:39:16 +0100 | <haskellbridge> | <Morj> I sometimes think it would be better if `,` were a right-associative operator instead of built-in construct. This way all (a, b, c) = (a, (b, c)) and we can create our own functions that work with tuples of arbitrary arity |
| 2025-03-28 15:39:51 +0100 | <haskellbridge> | <Morj> I think ocaml and sml already do that with `*`? |
| 2025-03-28 15:39:56 +0100 | <agentultra> | gcc doesn't explicitly link `libm` though and we don't get a runtime relink error if we try to execute it. |
| 2025-03-28 15:42:39 +0100 | <__monty__> | Morj: Are you secretly a LISPer? -_- |
| 2025-03-28 15:42:53 +0100 | <haskellbridge> | <Morj> I dream of learning lisp one day! |
| 2025-03-28 15:43:04 +0100 | <hellwolf> | use emacs :) |
| 2025-03-28 15:43:15 +0100 | <hellwolf> | and have elisp nightmare, instead |
| 2025-03-28 15:43:32 +0100 | <haskellbridge> | <Morj> I read a blog of a big janet fan, and for some reason it's very hard for me to understand their quoting and unquoting, even when I have no problems using them in template haskell |
| 2025-03-28 15:44:01 +0100 | <haskellbridge> | <Morj> > emacs |
| 2025-03-28 15:44:01 +0100 | <haskellbridge> | I've already written 100k lines of vimscript >_< |
| 2025-03-28 15:44:30 +0100 | Googulator | (~Googulato@81.183.235.203) (Ping timeout: 240 seconds) |
| 2025-03-28 15:45:41 +0100 | <tomsmeding> | agentultra: so it works with gcc? What if you pass -lm to gcc as well? |
| 2025-03-28 15:50:17 +0100 | prasad | (~Thunderbi@c-73-246-138-70.hsd1.in.comcast.net) |
| 2025-03-28 15:59:28 +0100 | jmcantrell | (~weechat@user/jmcantrell) jmcantrell |
| 2025-03-28 15:59:44 +0100 | jespada | (~jespada@2800:a4:2225:2c00:21b7:d8ab:6242:25ba) (Ping timeout: 260 seconds) |
| 2025-03-28 16:03:00 +0100 | jespada | (~jespada@2800:a4:231e:8900:903f:fbe:20bf:5608) jespada |
| 2025-03-28 16:04:11 +0100 | jmcantrell | (~weechat@user/jmcantrell) (Client Quit) |
| 2025-03-28 16:04:27 +0100 | jmcantrell | (~weechat@user/jmcantrell) jmcantrell |
| 2025-03-28 16:05:44 +0100 | malte | (~malte@mal.tc) (Ping timeout: 252 seconds) |
| 2025-03-28 16:08:47 +0100 | hattckory | (~hattckory@bras-base-toroon4524w-grc-30-70-27-118-207.dsl.bell.ca) |
| 2025-03-28 16:12:12 +0100 | <agentultra> | tomsmeding: oof, it links fine with `-lm` and no runtime relink error :( |
| 2025-03-28 16:12:35 +0100 | <tomsmeding> | agentultra: you're saying "runtime" again. Does that "Relink" error occur at _runtime_ of your haskell application? |
| 2025-03-28 16:12:56 +0100 | malte | (~malte@mal.tc) malte |
| 2025-03-28 16:13:24 +0100 | <agentultra> | yes |
| 2025-03-28 16:13:59 +0100 | <tomsmeding> | O.o |
| 2025-03-28 16:14:16 +0100 | <merijn> | I mean, depending on your definition of runtime that's logical |
| 2025-03-28 16:14:17 +0100 | <tomsmeding> | what does `ldd` say on your compiled haskell application and on that simple C executable? |
| 2025-03-28 16:14:42 +0100 | <merijn> | everything be linked statically by default only applies to the Haskell bits |
| 2025-03-28 16:14:58 +0100 | <tomsmeding> | merijn: I know what a runtime linker is and roughly what it does, but I was running on the wrong assumption here that it was `ld` that was complaining, not `ld-linux.so` |
| 2025-03-28 16:15:22 +0100 | <merijn> | But yeah, pastebin ldd output |
| 2025-03-28 16:15:39 +0100 | <tomsmeding> | compile-time linking succeeding and then runtime linking _failing_ sounds like a LD_RUNTIME_PATH mistake somewhere |
| 2025-03-28 16:15:45 +0100 | <tomsmeding> | and given that this is nix, it smells a lot like nix issues |
| 2025-03-28 16:15:51 +0100 | <merijn> | oh, oof |
| 2025-03-28 16:15:54 +0100 | merijn | taps out |
| 2025-03-28 16:16:02 +0100 | <tomsmeding> | because of the mention of nix? :p |
| 2025-03-28 16:16:06 +0100 | <merijn> | Yes :p |
| 2025-03-28 16:16:31 +0100 | <tomsmeding> | *LD_LIBRARY_PATH is what I meant |
| 2025-03-28 16:16:51 +0100 | <agentultra> | is there a pastebin for this channel? |
| 2025-03-28 16:16:54 +0100 | fp | (~Thunderbi@130.233.70.95) (Ping timeout: 272 seconds) |
| 2025-03-28 16:16:58 +0100 | <tomsmeding> | @where paste |
| 2025-03-28 16:16:58 +0100 | <lambdabot> | Help us help you: please paste full code, input and/or output at e.g. https://paste.tomsmeding.com |
| 2025-03-28 16:17:00 +0100 | <tomsmeding> | (also see topic) |
| 2025-03-28 16:19:07 +0100 | <agentultra> | tomsmeding: https://paste.tomsmeding.com/FmcDXN4e |
| 2025-03-28 16:19:31 +0100 | hattckory | (~hattckory@bras-base-toroon4524w-grc-30-70-27-118-207.dsl.bell.ca) (Read error: Connection reset by peer) |
| 2025-03-28 16:20:39 +0100 | <tomsmeding> | agentultra: and the former gives the Relink error at runtime and the latter doesn't? |
| 2025-03-28 16:20:48 +0100 | <agentultra> | tomsmeding: correct |
| 2025-03-28 16:20:50 +0100 | <tomsmeding> | Do you actually use functions from libtb_client.so in the C program? |
| 2025-03-28 16:21:01 +0100 | <tomsmeding> | perhaps the runtime linker is lazy and only loads it in once it's actually used |
| 2025-03-28 16:21:37 +0100 | <agentultra> | no, just linking. I was in the middle of adding a usage, I can get that going and try running it. |
| 2025-03-28 16:21:51 +0100 | <tomsmeding> | lazy runtime linking is a thing |
| 2025-03-28 16:22:37 +0100 | <tomsmeding> | (if you manually invoke the runtime linker with dlopen(2), it's the RTLD_LAZY flag) |
| 2025-03-28 16:22:53 +0100 | <tomsmeding> | er, dlopen(3) |
| 2025-03-28 16:24:33 +0100 | <agentultra> | odd that the Haskell executable doesn't call anything from the library either, it just links... wonder if something in the generated FFI bindings invokes something in the library? |
| 2025-03-28 16:26:33 +0100 | <tomsmeding> | agentultra: another thing you can try: set LD_DEBUG=files,libs,bindings (or perhaps LD_DEBUG=all) when starting the two executables and check if there is a difference in the resulting outputs |
| 2025-03-28 16:26:42 +0100 | <tomsmeding> | *difference between |
| 2025-03-28 16:26:54 +0100 | <tomsmeding> | (LD_DEBUG is from ld-linux(8)) |
| 2025-03-28 16:26:58 +0100 | ystael | (~ystael@user/ystael) (Ping timeout: 244 seconds) |
| 2025-03-28 16:27:31 +0100 | <agentultra> | roger, roger |
| 2025-03-28 16:29:04 +0100 | ystael | (~ystael@user/ystael) ystael |
| 2025-03-28 16:32:52 +0100 | malte | (~malte@mal.tc) (Ping timeout: 252 seconds) |
| 2025-03-28 16:34:38 +0100 | <agentultra> | So calling the library from C, no run-time relink error. |
| 2025-03-28 16:34:52 +0100 | <agentultra> | Checking the differences |
| 2025-03-28 16:35:01 +0100 | <merijn> | Is the link invocation for the C code and Haskell the same, though? |
| 2025-03-28 16:36:22 +0100 | tomsmeding | . o O ( `cabal build --ghc-options=-v` ) |
| 2025-03-28 16:36:25 +0100 | xff0x | (~xff0x@2405:6580:b080:900:73c3:617e:93dd:971) |
| 2025-03-28 16:36:36 +0100 | <tomsmeding> | still doesn't print the ld invocation, though |
| 2025-03-28 16:37:10 +0100 | <tomsmeding> | merijn: do you know of a way to make ghc print the actual ld invocation? `bear intercept` doesn't work because ghc passes options through `@` files so the actual flags are not in the cmdline. |
| 2025-03-28 16:37:32 +0100 | <merijn> | If you set -v high enough it just prints out everything it does |
| 2025-03-28 16:37:42 +0100 | <merijn> | Last I tried anyway |
| 2025-03-28 16:37:42 +0100 | <tomsmeding> | (I still have to hack bear at some point to understand this and open those options files) |
| 2025-03-28 16:38:57 +0100 | <tomsmeding> | oh wait -v does already show the gcc call, I somehow missed that |
| 2025-03-28 16:39:31 +0100 | <merijn> | :) |
| 2025-03-28 16:39:45 +0100 | <tomsmeding> | (gcc and ghc look too much alike) |
| 2025-03-28 16:41:04 +0100 | malte | (~malte@mal.tc) malte |
| 2025-03-28 16:42:05 +0100 | <agentultra> | https://paste.tomsmeding.com/rde825xQ |
| 2025-03-28 16:42:44 +0100 | <tomsmeding> | agentultra: you need `--ghc-options=-v`, this makes the cabal build verbose but not what ghc itself does |
| 2025-03-28 16:42:59 +0100 | <agentultra> | tomsmeding: ah, sorry will do. |
| 2025-03-28 16:43:14 +0100 | <tomsmeding> | we're interested in that "Linking..." line at :589 ;) |
| 2025-03-28 16:44:50 +0100 | <agentultra> | tomsmeding: https://paste.tomsmeding.com/9QHmZK9i |
| 2025-03-28 16:46:13 +0100 | werneta | (~werneta@syn-071-083-160-242.res.spectrum.com) (Ping timeout: 245 seconds) |
| 2025-03-28 16:46:16 +0100 | <tomsmeding> | always nice when ghc links in your library three times |
| 2025-03-28 16:46:29 +0100 | <tomsmeding> | agentultra: the line in question is :952 there |
| 2025-03-28 16:47:03 +0100 | <tomsmeding> | no less than 5 occurrences of -lm ! |
| 2025-03-28 16:47:34 +0100 | <agentultra> | oh weird |
| 2025-03-28 16:47:40 +0100 | <tomsmeding> | that shouldn't matter though |
| 2025-03-28 16:49:08 +0100 | <tomsmeding> | what happens if you compile your C file with `gcc thing.c -o a.out -fuse-ld=gold -Wl,--no-as-needed -lm -no-pie -Wl,--gc-sections -ltb_client`? |
| 2025-03-28 16:49:28 +0100 | <tomsmeding> | (an attempt to manually remove all the superfluous stuff from that long command) |
| 2025-03-28 16:50:12 +0100 | <tomsmeding> | oh perhaps with `-L/home/jking/Projects/tigerbeetle-hs/lib/x86_64-linux-gnu.2.27` |
| 2025-03-28 16:50:39 +0100 | <tomsmeding> | somehow the Relink error should be reproducible without ghc :p |
| 2025-03-28 16:51:12 +0100 | Square2 | (~Square@user/square) Square |
| 2025-03-28 16:52:01 +0100 | <agentultra> | tomsmeding: `cc test.c -Wall -Iinclude -Llib/x86_64-linux-gnu.2.27 -fuse-ld=gold -Wl,--no-as-needed -lm -no-pie -Wl,--gc-sections -ltb_client` |
| 2025-03-28 16:52:08 +0100 | <agentultra> | Creates the relink error when you run it! |
| 2025-03-28 16:52:22 +0100 | <agentultra> | and a segfault |
| 2025-03-28 16:52:27 +0100 | <tomsmeding> | lol |
| 2025-03-28 16:52:27 +0100 | tromp | (~textual@2001:1c00:3487:1b00:6095:11f3:6fa5:fb3d) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 2025-03-28 16:52:29 +0100 | jacopovalanzano | (~jacopoval@cpc151911-cove17-2-0-cust105.3-1.cable.virginm.net) (Quit: Client closed) |
| 2025-03-28 16:52:52 +0100 | <tomsmeding> | now reduce it to figure out what the problem is :) |
| 2025-03-28 16:52:53 +0100 | hattckory | (~hattckory@70.27.118.207) |
| 2025-03-28 16:52:59 +0100 | malte | (~malte@mal.tc) (Ping timeout: 260 seconds) |
| 2025-03-28 16:53:04 +0100 | <agentultra> | yup, excellent. |
| 2025-03-28 16:53:05 +0100 | <tomsmeding> | also, yay progress |
| 2025-03-28 16:58:00 +0100 | <agentultra> | yes, thanks a bunch for narrowing that down... I didn't know about the --ghc-options=-v flag |
| 2025-03-28 16:58:28 +0100 | <merijn> | agentultra: --ghc-options just pass flags as-is on to ghc :) |
| 2025-03-28 17:06:08 +0100 | <agentultra> | tomsmeding: turns out, it's -lm |
| 2025-03-28 17:06:34 +0100 | <tomsmeding> | one cannot use libtb_client.so in a program if you also link in libm? |
| 2025-03-28 17:06:42 +0100 | <tomsmeding> | that... rather sounds like a problem with tb_client. |
| 2025-03-28 17:07:04 +0100 | <tomsmeding> | or at least how it's built |
| 2025-03-28 17:07:21 +0100 | <agentultra> | i suspect they statically link libm or include their own implementation |
| 2025-03-28 17:07:49 +0100 | <tomsmeding> | if they have their own implementation, then internal references to `sin` in tb_client should just refer to the internal symbol, regardless of how many libm's are around |
| 2025-03-28 17:07:50 +0100 | <agentultra> | the ldd output suggests so... is there a way to tell cabal to tell ghc to not link `-lm` when linking this library? |
| 2025-03-28 17:08:09 +0100 | <tomsmeding> | how would you then use `sin` from haskell? |
| 2025-03-28 17:08:29 +0100 | <tomsmeding> | (I don't think so) |
| 2025-03-28 17:09:22 +0100 | <agentultra> | Hm. So creating a static executable wouldn't even work around it? |
| 2025-03-28 17:09:41 +0100 | <merijn> | You can just override the linker flags GHC passes |
| 2025-03-28 17:10:00 +0100 | <tomsmeding> | merijn: GHC already passes -lm 4 times, are you sure you can make it not pass all 4 of thouse? |
| 2025-03-28 17:10:02 +0100 | <tomsmeding> | *those |
| 2025-03-28 17:10:10 +0100 | <merijn> | No :p |
| 2025-03-28 17:10:18 +0100 | <merijn> | Well yes |
| 2025-03-28 17:10:32 +0100 | <merijn> | But the question is "would I be willing to invest that effort?" :p |
| 2025-03-28 17:10:41 +0100 | <tomsmeding> | also, I don't think it's a good idea |
| 2025-03-28 17:10:55 +0100 | <tomsmeding> | e.g. floor(3) is in libm too |
| 2025-03-28 17:11:06 +0100 | <tomsmeding> | so no more floor() for you, I guess, then? |
| 2025-03-28 17:11:36 +0100 | <tomsmeding> | (though on a non-ancient CPU, it's probably translated to a CPU instruction) |
| 2025-03-28 17:12:04 +0100 | hattckory | (~hattckory@70.27.118.207) (Ping timeout: 260 seconds) |
| 2025-03-28 17:13:17 +0100 | tromp | (~textual@2001:1c00:3487:1b00:6095:11f3:6fa5:fb3d) |
| 2025-03-28 17:13:23 +0100 | <agentultra> | oh weird... it might be the link order |
| 2025-03-28 17:13:34 +0100 | <tomsmeding> | link order is significant in general |
| 2025-03-28 17:13:54 +0100 | <merijn> | tomsmeding: not in general |
| 2025-03-28 17:13:58 +0100 | <merijn> | But on linux, certainly |
| 2025-03-28 17:14:04 +0100 | weary-traveler | (~user@user/user363627) (Remote host closed the connection) |
| 2025-03-28 17:14:16 +0100 | <agentultra> | `$ cc test.c -Wall -Iinclude -Llib/x86_64-linux-gnu.2.27 -ltb_client -lm` compiles and runs with no error |
| 2025-03-28 17:14:19 +0100 | <tomsmeding> | I meant that as in: there are situations where link order is significant, I'm not sure if this is one of those |
| 2025-03-28 17:14:41 +0100 | <tomsmeding> | and swapping the -ltb_client and -lm makes it fail? |
| 2025-03-28 17:14:42 +0100 | <agentultra> | but if you put `-lm` before `-ltb_client`, you get the relink error. |
| 2025-03-28 17:14:48 +0100 | <tomsmeding> | merijn: any ideas? |
| 2025-03-28 17:14:58 +0100 | <merijn> | Whisky and crying? |
| 2025-03-28 17:15:04 +0100 | <tomsmeding> | that's what I suspected |
| 2025-03-28 17:15:16 +0100 | <merijn> | All I know about linking is against my will :p |
| 2025-03-28 17:15:41 +0100 | <merijn> | The scary moment you realise that you've become "the person everyone comes to when they hit linker errors" :p |
| 2025-03-28 17:15:53 +0100 | <tomsmeding> | heh |
| 2025-03-28 17:16:15 +0100 | <tomsmeding> | that happened to me with "linux stuff" |
| 2025-03-28 17:16:16 +0100 | <agentultra> | yeah, linkers are pain. |
| 2025-03-28 17:16:58 +0100 | <merijn> | And I'm too distracted trying to learn tree-sitter to think about linkers |
| 2025-03-28 17:17:08 +0100 | <tomsmeding> | agentultra: any chance you can do, well, precisely what the error is saying -- change the tb_client build process to include -lm when building the shared library? |
| 2025-03-28 17:17:08 +0100 | <agentultra> | wonder if this would be ameliorated if ghc had it's own |
| 2025-03-28 17:17:44 +0100 | <agentultra> | tomsmeding: i might try that unless there's an easy way to pass the link flags in the desired order to ghc from cabal |
| 2025-03-28 17:18:23 +0100 | <tomsmeding> | I strongly suspect ghc just unconditionally adds -lm early on the command line, from looking at the structure of that command line in the log you sent |
| 2025-03-28 17:18:49 +0100 | <tomsmeding> | which is overall not a very strange thing to do, tb_client should just declare that it depends on -lm, and it doesn't |
| 2025-03-28 17:21:22 +0100 | lortabac | (~lortabac@2a01:e0a:541:b8f0:55ab:e185:7f81:54a4) (Quit: WeeChat 4.5.2) |
| 2025-03-28 17:22:14 +0100 | <EvanR> | tomsmeding, I can hit you up for any help with "linux stuff" ? cool |
| 2025-03-28 17:22:50 +0100 | tomsmeding | hides |
| 2025-03-28 17:23:19 +0100 | yushyin | makes a note |
| 2025-03-28 17:23:48 +0100 | tomsmeding | despairs |
| 2025-03-28 17:25:18 +0100 | <agentultra> | tomsmeding: agree, I think it's because the link order.. the executable has `sin` first in the elf of the executable and `dlopen` loads this library with it's own `sin` and tries to relink it? So if we change the link order when we call the library it can resolve it's own `sin`. |
| 2025-03-28 17:25:34 +0100 | jespada | (~jespada@2800:a4:231e:8900:903f:fbe:20bf:5608) (Quit: My Mac has gone to sleep. ZZZzzz…) |
| 2025-03-28 17:26:36 +0100 | <agentultra> | I'm going to see if they'll accept a patch from me to to change their linker options, if that's even possible. The library is actually written in Zig :S |
| 2025-03-28 17:27:59 +0100 | <tomsmeding> | agentultra: I think this is what's happening (but take this with a grain of salt): the `sin` symbol is Weak in libtb_client.so (as we saw), which means (man 1 nm) that it's allowed to be undefined at link time. When compiling with -ltb_client -lm, `sin` is first undefined, and then libm provides a definition. When compiling with -lm -tb_client -lm, the first -lm resolves any missing references to |
| 2025-03-28 17:28:01 +0100 | <tomsmeding> | `sin`, but then afterwards, tb_client introduces new ones. The second occurrence of -lm (this is where I'm a bit unsure) is ignored because libm was already specified (?) |
| 2025-03-28 17:28:20 +0100 | <tomsmeding> | hence in the second case, `sin` remains unresolved, which results in an error at runtime |
| 2025-03-28 17:28:34 +0100 | <tomsmeding> | dlopen is not involved here, that is for manually calling into the runtime linker at runtime |
| 2025-03-28 17:28:55 +0100 | <EvanR> | it is indeed difficult to resolve one's own sin |
| 2025-03-28 17:28:56 +0100 | <agentultra> | gotcha... that seems reasonable |
| 2025-03-28 17:29:08 +0100 | <tomsmeding> | it's ld-linux.so, the runtime linker itself, that is relevant here (which is, despite its name, actually an executable) |
| 2025-03-28 17:29:28 +0100 | <tomsmeding> | EvanR: it's not at all, just declare that you depend on libm |
| 2025-03-28 17:29:40 +0100 | <EvanR> | the good news about libm |
| 2025-03-28 17:29:52 +0100 | <agentultra> | well, they'll have a bug report coming soon to get the process started. |
| 2025-03-28 17:29:57 +0100 | <tomsmeding> | :) |
| 2025-03-28 17:30:14 +0100 | <agentultra> | thanks again for all your help :D |
| 2025-03-28 17:30:20 +0100 | <EvanR> | (actually, sin has unlimited radius of convergence so there's that) |
| 2025-03-28 17:30:23 +0100 | <tomsmeding> | cheers :) |
| 2025-03-28 17:30:37 +0100 | <tomsmeding> | EvanR: floating-point numbers only go so far though |
| 2025-03-28 17:30:37 +0100 | <jle`> | that's deep |
| 2025-03-28 17:31:19 +0100 | <EvanR> | it's true "correct rounded result" guarantee doesn't cover the entire domain of sin in ieee754 |
| 2025-03-28 17:31:27 +0100 | <EvanR> | watch yourself |
| 2025-03-28 17:31:31 +0100 | <EvanR> | in the far lands |
| 2025-03-28 17:34:05 +0100 | prasad | (~Thunderbi@c-73-246-138-70.hsd1.in.comcast.net) (Read error: Connection reset by peer) |
| 2025-03-28 17:38:11 +0100 | malte | (~malte@mal.tc) malte |
| 2025-03-28 17:41:48 +0100 | chele | (~chele@user/chele) (Remote host closed the connection) |
| 2025-03-28 17:44:23 +0100 | prasad | (~Thunderbi@c-73-246-138-70.hsd1.in.comcast.net) |
| 2025-03-28 17:46:54 +0100 | <monochrom> | "You must not sin." >:) |
| 2025-03-28 17:51:17 +0100 | pyooque | (~puke@user/puke) puke |
| 2025-03-28 17:51:18 +0100 | puke | (~puke@user/puke) (Killed (erbium.libera.chat (Nickname regained by services))) |
| 2025-03-28 17:51:18 +0100 | pyooque | puke |
| 2025-03-28 17:51:19 +0100 | nitrix | (~nitrix@user/meow/nitrix) (Ping timeout: 260 seconds) |
| 2025-03-28 17:51:40 +0100 | <monochrom> | But I thought you would want to absolve, not resolve, your sin. >:) |
| 2025-03-28 17:55:04 +0100 | acidjnk | (~acidjnk@p200300d6e71c4f71c835c1b6e3010b6c.dip0.t-ipconnect.de) (Ping timeout: 272 seconds) |
| 2025-03-28 17:58:09 +0100 | nitrix | (~nitrix@user/meow/nitrix) nitrix |
| 2025-03-28 17:58:20 +0100 | L29Ah | (~L29Ah@wikipedia/L29Ah) (Ping timeout: 265 seconds) |
| 2025-03-28 18:06:00 +0100 | jespada | (~jespada@2800:a4:231e:8900:903f:fbe:20bf:5608) jespada |
| 2025-03-28 18:06:07 +0100 | <int-e> | :t abs |
| 2025-03-28 18:06:09 +0100 | <lambdabot> | Num a => a -> a |
| 2025-03-28 18:06:17 +0100 | <int-e> | :t abs . sin |
| 2025-03-28 18:06:18 +0100 | <lambdabot> | Floating c => c -> c |
| 2025-03-28 18:12:53 +0100 | acidjnk | (~acidjnk@p200300d6e71c4f71c835c1b6e3010b6c.dip0.t-ipconnect.de) acidjnk |
| 2025-03-28 18:17:35 +0100 | Sgeo | (~Sgeo@user/sgeo) Sgeo |
| 2025-03-28 18:22:00 +0100 | weary-traveler | (~user@user/user363627) user363627 |
| 2025-03-28 18:22:39 +0100 | <EvanR> | :t fix . error |
| 2025-03-28 18:22:40 +0100 | <lambdabot> | [Char] -> c |
| 2025-03-28 18:23:02 +0100 | <absence> | Is there a way to do something like "(\f g h a -> f (g (h a))) <$> f' <*> g' <*> h' <*> a'" without having to manually specify the combining function to the left? |
| 2025-03-28 18:23:47 +0100 | <merijn> | I can't tell if that's trying to be idiom brackets or something else |
| 2025-03-28 18:23:54 +0100 | <EvanR> | are you sure you don't want to reverse the applicative or something |
| 2025-03-28 18:24:14 +0100 | <merijn> | absence: What's it trying to accomplish? |
| 2025-03-28 18:24:24 +0100 | OlzhasYergali | (~OlzhasYer@188.130.156.6) |
| 2025-03-28 18:29:41 +0100 | L29Ah | (~L29Ah@wikipedia/L29Ah) L29Ah |
| 2025-03-28 18:29:52 +0100 | tromp | (~textual@2001:1c00:3487:1b00:6095:11f3:6fa5:fb3d) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 2025-03-28 18:30:39 +0100 | euphores | (~SASL_euph@user/euphores) (Quit: Leaving.) |
| 2025-03-28 18:30:59 +0100 | <absence> | merijn: f' g' and h' are applicative functors that return some operation (e.g. "pure (+1)"), so I just want to apply them. |
| 2025-03-28 18:31:28 +0100 | <merijn> | absence: okay, so how about we simplify this |
| 2025-03-28 18:31:38 +0100 | <merijn> | ah, wait |
| 2025-03-28 18:31:50 +0100 | <merijn> | absence: Are they all Endo functors? |
| 2025-03-28 18:31:56 +0100 | <merijn> | i.e. "a -> a" functions? |
| 2025-03-28 18:32:17 +0100 | <absence> | No, otherwise I guess it would be easier... |
| 2025-03-28 18:32:44 +0100 | <merijn> | yeah, I was thinking just traverse + some fold |
| 2025-03-28 18:35:41 +0100 | euphores | (~SASL_euph@user/euphores) euphores |
| 2025-03-28 18:38:51 +0100 | <absence> | Hm, I guess it's kind of an applicative version of (.)? |
| 2025-03-28 18:39:25 +0100 | tromp | (~textual@2001:1c00:3487:1b00:6095:11f3:6fa5:fb3d) |
| 2025-03-28 18:39:39 +0100 | <merijn> | absence: I mean, you could just define that? :) |
| 2025-03-28 18:39:56 +0100 | ubert1 | (~Thunderbi@2a02:8109:ab8a:5a00:7d86:d0e8:c2d1:2ee3) (Remote host closed the connection) |
| 2025-03-28 18:40:03 +0100 | <haskellbridge> | <Bowuigi> Would some fold/traversal with liftA2 work? |
| 2025-03-28 18:40:19 +0100 | <merijn> | Bowuigi: No, because that only works for Endo |
| 2025-03-28 18:41:02 +0100 | <merijn> | absence: You an just define <.> as custom operator? :) |
| 2025-03-28 18:41:24 +0100 | alp | (~alp@2001:861:8ca0:4940:10d7:35fd:1caf:385) |
| 2025-03-28 18:41:48 +0100 | <merijn> | :t let f <.> g = (.) <$> f <*> g in (<.>) |
| 2025-03-28 18:41:49 +0100 | <lambdabot> | Applicative f => f (b -> c) -> f (a -> b) -> f (a -> c) |
| 2025-03-28 18:42:13 +0100 | <merijn> | Maybe reverse the arguments depending on how you want it to line up |
| 2025-03-28 18:42:27 +0100 | target_i | (~target_i@user/target-i/x-6023099) target_i |
| 2025-03-28 18:45:01 +0100 | OlzhasYergali | (~OlzhasYer@188.130.156.6) (Quit: Client closed) |
| 2025-03-28 18:45:15 +0100 | <absence> | Ugh, "of course" I'm using impredicative types, so that fails in the same way as the regular (.) does, but other than that I guess it would've worked. |
| 2025-03-28 18:46:02 +0100 | <merijn> | absence: Can't you fix it with explicit RankN type annotations? |
| 2025-03-28 18:48:07 +0100 | lxsameer | (~lxsameer@Serene/lxsameer) (Ping timeout: 265 seconds) |
| 2025-03-28 18:50:16 +0100 | <absence> | Is it possible to define a generic (.) that works with RankN, or would it have to be a more specific one for the structures I have? |
| 2025-03-28 18:52:08 +0100 | <monochrom> | I think (.) already works with RankN. It is why the lens library has no type error. |
| 2025-03-28 18:53:42 +0100 | <c_wraith> | Eh. The lens library uses ALens (or whatever) in a lot of contexts where it'd otherwise need RankN |
| 2025-03-28 18:55:16 +0100 | <monochrom> | Does "(\f g h a -> f (g (h a))) <$> f' <*> g' <*> h' <*> a'" simply mean f' <*> (g' <*> (h' <*> a')) ? |
| 2025-03-28 18:56:36 +0100 | aetepe | (~aetepe@188.119.58.34) (Ping timeout: 252 seconds) |
| 2025-03-28 18:56:48 +0100 | <monochrom> | Come to think of it, I probably once used Applicative laws to prove something related. |
| 2025-03-28 19:00:15 +0100 | malte | (~malte@mal.tc) (Remote host closed the connection) |
| 2025-03-28 19:02:35 +0100 | tromp | (~textual@2001:1c00:3487:1b00:6095:11f3:6fa5:fb3d) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 2025-03-28 19:05:18 +0100 | <absence> | You may be right, but I run into the same RankN problem: Couldn't match type: forall a. m a -> n a with: b -> c |
| 2025-03-28 19:09:35 +0100 | malte | (~malte@mal.tc) malte |
| 2025-03-28 19:18:30 +0100 | tromp | (~textual@2001:1c00:3487:1b00:6095:11f3:6fa5:fb3d) |
| 2025-03-28 19:23:05 +0100 | aetepe | (~aetepe@188.119.58.34) aetepe |
| 2025-03-28 19:23:16 +0100 | Googulator | (~Googulato@2a01-036d-0106-01d5-ac5d-24c1-ad5e-7f2b.pool6.digikabel.hu) |
| 2025-03-28 19:31:12 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 244 seconds) |
| 2025-03-28 19:31:13 +0100 | acidjnk | (~acidjnk@p200300d6e71c4f71c835c1b6e3010b6c.dip0.t-ipconnect.de) (Ping timeout: 245 seconds) |
| 2025-03-28 19:39:16 +0100 | euphores | (~SASL_euph@user/euphores) (Remote host closed the connection) |
| 2025-03-28 19:40:09 +0100 | euphores | (~SASL_euph@user/euphores) euphores |
| 2025-03-28 19:44:10 +0100 | slack1256 | (~slack1256@2803:c600:5111:9ab8:84f4:ae24:2907:edab) slack1256 |
| 2025-03-28 19:44:48 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-03-28 19:57:34 +0100 | <tomsmeding> | absence: what about simply "f' <$> g' <$> h' <$> a'"? |
| 2025-03-28 19:57:40 +0100 | <tomsmeding> | % :i <$> |
| 2025-03-28 19:57:40 +0100 | <yahb2> | (<$>) :: Functor f => (a -> b) -> f a -> f b ; -- Defined in ‘GHC.Internal.Data.Functor’ ; infixl 4 <$> |
| 2025-03-28 20:00:01 +0100 | caconym | (~caconym@user/caconym) (Quit: bye) |
| 2025-03-28 20:00:03 +0100 | <tomsmeding> | fun exercise: prove that "(x <$> y) <$> z" and "x <$> (y <$> z)" do exactly the same thin |
| 2025-03-28 20:00:05 +0100 | <tomsmeding> | +g |
| 2025-03-28 20:00:15 +0100 | wildsalander | (~wildsalan@37-33-20-77.bb.dnainternet.fi) |
| 2025-03-28 20:00:44 +0100 | caconym | (~caconym@user/caconym) caconym |
| 2025-03-28 20:00:48 +0100 | zungi | (~tory@user/andrewchawk) (Ping timeout: 264 seconds) |
| 2025-03-28 20:00:54 +0100 | wildsalander | (~wildsalan@37-33-20-77.bb.dnainternet.fi) (Client Quit) |
| 2025-03-28 20:01:23 +0100 | acidjnk | (~acidjnk@p200300d6e71c4f71c835c1b6e3010b6c.dip0.t-ipconnect.de) acidjnk |
| 2025-03-28 20:01:32 +0100 | <tomsmeding> | monochrom: no, (<$>) not (<*>) |
| 2025-03-28 20:02:37 +0100 | <tomsmeding> | (hint for my "fun exercise": first infer the types of x, y and z in both cases) |
| 2025-03-28 20:03:54 +0100 | malte | (~malte@mal.tc) (Ping timeout: 268 seconds) |
| 2025-03-28 20:04:11 +0100 | malte | (~malte@mal.tc) malte |
| 2025-03-28 20:04:18 +0100 | rvalue- | (~rvalue@user/rvalue) rvalue |
| 2025-03-28 20:04:33 +0100 | <haskellbridge> | <Liamzee> tomsmeding: no, the problem is that it's keyed so that Prelude.take 3 and Prelude.Linear.take3 do separate things |
| 2025-03-28 20:04:45 +0100 | rvalue | (~rvalue@user/rvalue) (Ping timeout: 246 seconds) |
| 2025-03-28 20:05:24 +0100 | <tomsmeding> | Liamzee: "keyed"? |
| 2025-03-28 20:05:35 +0100 | <haskellbridge> | <Liamzee> namely, Linear.take 3 takes 4 elements of the list |
| 2025-03-28 20:05:47 +0100 | <tomsmeding> | _what_ |
| 2025-03-28 20:06:06 +0100 | <tomsmeding> | surely that's a bug |
| 2025-03-28 20:06:28 +0100 | <haskellbridge> | <Liamzee> <0, as opposed to <= 0 |
| 2025-03-28 20:06:35 +0100 | <tomsmeding> | that makes 0 sense |
| 2025-03-28 20:06:48 +0100 | sord937 | (~sord937@gateway/tor-sasl/sord937) (Quit: sord937) |
| 2025-03-28 20:08:08 +0100 | <tomsmeding> | Liamzee: any more of such functions? |
| 2025-03-28 20:08:24 +0100 | malte | (~malte@mal.tc) (Ping timeout: 244 seconds) |
| 2025-03-28 20:09:20 +0100 | <haskellbridge> | <Liamzee> only noticed that one |
| 2025-03-28 20:09:23 +0100 | <haskellbridge> | <Liamzee> you want to push the patch? |
| 2025-03-28 20:09:27 +0100 | <tomsmeding> | drop also has it |
| 2025-03-28 20:09:30 +0100 | <[exa]> | O_o |
| 2025-03-28 20:09:38 +0100 | <haskellbridge> | <Liamzee> yeah, i saw |
| 2025-03-28 20:09:46 +0100 | <haskellbridge> | <Liamzee> that's a breaking change to API, though |
| 2025-03-28 20:09:59 +0100 | <tomsmeding> | that's why it'll just be an issue, not a PR yet |
| 2025-03-28 20:10:03 +0100 | <haskellbridge> | <Liamzee> I wonder who's actually using it if drop / take being bugged like this didn't get caught |
| 2025-03-28 20:10:08 +0100 | <tomsmeding> | exactly |
| 2025-03-28 20:10:17 +0100 | <tomsmeding> | I think Data.List.Linear is not what people are using prelude-linear for |
| 2025-03-28 20:10:41 +0100 | rvalue- | rvalue |
| 2025-03-28 20:10:41 +0100 | <tomsmeding> | Data.Array.Mutable.Linear is much more useful |
| 2025-03-28 20:12:21 +0100 | <[exa]> | anyway yeah there's a literal off-by-one error here right? https://hackage.haskell.org/package/linear-base-0.4.0/docs/src/Data.List.Linear.html#take |
| 2025-03-28 20:12:26 +0100 | <absence> | tomsmeding: That doesn't compile, since f' isn't a function... |
| 2025-03-28 20:13:13 +0100 | <tomsmeding> | absence: well, you used it as a function in your original snippet. |
| 2025-03-28 20:13:39 +0100 | <tomsmeding> | Liamzee: https://github.com/tweag/linear-base/issues/484 |
| 2025-03-28 20:14:01 +0100 | <[exa]> | wow, I wanted to check the issue tracker if the bug is there already |
| 2025-03-28 20:14:06 +0100 | <[exa]> | 2 issues "opened just now" |
| 2025-03-28 20:14:08 +0100 | <[exa]> | good job guys. :D |
| 2025-03-28 20:14:24 +0100 | <tomsmeding> | absence: the only difference between the type of what I posted, and the type of what you posted, is that mine has a Functor constraint only |
| 2025-03-28 20:14:30 +0100 | <tomsmeding> | oh oops |
| 2025-03-28 20:14:52 +0100 | <tomsmeding> | Liamzee: shall I close mine? |
| 2025-03-28 20:15:02 +0100 | <absence> | tomsmeding: The type of f' is something like f (a -> b). |
| 2025-03-28 20:15:18 +0100 | <tomsmeding> | [exa]: what's cooler is that my issue has a lower number, but it's higher up in the list |
| 2025-03-28 20:15:41 +0100 | <haskellbridge> | <Liamzee> closed mine |
| 2025-03-28 20:15:44 +0100 | <tomsmeding> | ah I see |
| 2025-03-28 20:15:44 +0100 | <[exa]> | yeah I'm just looking at that |
| 2025-03-28 20:15:48 +0100 | tomku | (~tomku@user/tomku) (Ping timeout: 252 seconds) |
| 2025-03-28 20:16:07 +0100 | <tomsmeding> | absence: _oops_, sorry |
| 2025-03-28 20:16:50 +0100 | hgolden | (~hgolden@2603:8000:9d00:3ed1:6ff3:8389:b901:6363) (Remote host closed the connection) |
| 2025-03-28 20:17:49 +0100 | tomku | (~tomku@user/tomku) tomku |
| 2025-03-28 20:20:33 +0100 | hgolden | (~hgolden@2603:8000:9d00:3ed1:6ff3:8389:b901:6363) hgolden |
| 2025-03-28 20:25:45 +0100 | <[exa]> | tomsmeding Liamzee: you guys clicked it literally at the very same second, and although Liamzee has a little tiny bit higher global ID it still sorts by something different (I guess they sort by opening time in seconds (equal) and then probably by title or something) |
| 2025-03-28 20:26:40 +0100 | <tomsmeding> | cool |
| 2025-03-28 20:27:51 +0100 | sprotte24 | (~sprotte24@p200300d16f1244002c79175af1485053.dip0.t-ipconnect.de) |
| 2025-03-28 20:28:43 +0100 | AlexZenon | (~alzenon@178.34.150.194) (Ping timeout: 245 seconds) |
| 2025-03-28 20:28:59 +0100 | zungi | (~tory@user/andrewchawk) andrewchawk |
| 2025-03-28 20:29:31 +0100 | polyphem | (~rod@p3ee3f49b.dip0.t-ipconnect.de) polyphem |
| 2025-03-28 20:32:56 +0100 | pavonia | (~user@user/siracusa) siracusa |
| 2025-03-28 20:33:41 +0100 | alp | (~alp@2001:861:8ca0:4940:10d7:35fd:1caf:385) (Ping timeout: 248 seconds) |
| 2025-03-28 20:35:54 +0100 | AlexZenon | (~alzenon@178.34.150.194) |
| 2025-03-28 20:41:09 +0100 | remedan | (~remedan@ip-62-245-108-153.bb.vodafone.cz) (Quit: Bye!) |
| 2025-03-28 20:41:39 +0100 | ash3en | (~Thunderbi@185.209.196.192) ash3en |
| 2025-03-28 20:42:10 +0100 | remedan | (~remedan@ip-62-245-108-153.bb.vodafone.cz) remedan |
| 2025-03-28 20:44:07 +0100 | <EvanR> | 1 second is a very long time in computers |
| 2025-03-28 20:44:23 +0100 | <EvanR> | two events within the same 1 second interval might not even be able to see each other xD |
| 2025-03-28 20:45:26 +0100 | Tuplanolla | (~Tuplanoll@91-159-69-59.elisa-laajakaista.fi) Tuplanolla |
| 2025-03-28 20:45:30 +0100 | AlexZenon | (~alzenon@178.34.150.194) (Ping timeout: 252 seconds) |
| 2025-03-28 20:45:52 +0100 | ash3en | (~Thunderbi@185.209.196.192) (Ping timeout: 252 seconds) |
| 2025-03-28 20:48:56 +0100 | <[exa]> | is there any good/recommended way to have a feedable attoparsec parser which can output partial data between the feeds, and has to keep some state information for the whole stream? |
| 2025-03-28 20:49:30 +0100 | <merijn> | [exa]: Yes, it's called "attoparsec"? |
| 2025-03-28 20:50:34 +0100 | <merijn> | [exa]: It has built in methods for incremental feeding. So you just wrap it in a tuple with some extra state? |
| 2025-03-28 20:51:14 +0100 | <[exa]> | merijn: like, I'm doing the lifting manually now (I've got a `parseSomething :: st -> Parser (st, [something])`, feeding it and passing the `st` around manually when one piece finishes |
| 2025-03-28 20:52:06 +0100 | <[exa]> | I hoped for something where I could have a `tell`, `put` and `get` and no other thinking to do :D |
| 2025-03-28 20:52:24 +0100 | tomsmeding | . o O ( `tell`? ) |
| 2025-03-28 20:52:29 +0100 | <merijn> | [exa]: I mean, you can just use `StateT` on top of attoparsec? |
| 2025-03-28 20:52:56 +0100 | <merijn> | [exa]: If you wanna get fancier than that, you'll have to consider swapping to megaparsec |
| 2025-03-28 20:53:00 +0100 | <[exa]> | yes, but then I have to pass the state around that myself anyway |
| 2025-03-28 20:53:06 +0100 | merijn | .o O ( is trifecta still a thing? ) |
| 2025-03-28 20:53:15 +0100 | AlexZenon | (~alzenon@178.34.150.194) |
| 2025-03-28 20:53:25 +0100 | <[exa]> | tomsmeding: the tell from writer, "we parsed out this information, emit it" |
| 2025-03-28 20:53:27 +0100 | ljdarj1 | (~Thunderbi@user/ljdarj) ljdarj |
| 2025-03-28 20:53:28 +0100 | <merijn> | [exa]: megaparsec has an embedded state parser |
| 2025-03-28 20:53:42 +0100 | <merijn> | s/state parser/state monad |
| 2025-03-28 20:53:52 +0100 | <[exa]> | hm let me check |
| 2025-03-28 20:54:04 +0100 | <tomsmeding> | [exa]: that sounds not like how parser combinator parsers work :p |
| 2025-03-28 20:54:11 +0100 | <tomsmeding> | you return the parsed value, you don't `tell` it |
| 2025-03-28 20:54:38 +0100 | <tomsmeding> | wanting to output the parsed values via `tell` sounds like you want a non-Parser that optionally uses Parser inside to parse little chunks |
| 2025-03-28 20:55:02 +0100 | <[exa]> | yeah this is for something like RDF turtle, I was thinking about emitting the triples directly without structure. |
| 2025-03-28 20:55:20 +0100 | <[exa]> | sounds kinda like I want the actual streamy libraries, right. |
| 2025-03-28 20:55:41 +0100 | <tomsmeding> | [exa]: what if the Parser backtracks? Do you keep your writer state? (Flashback to a few days ago) |
| 2025-03-28 20:55:54 +0100 | <merijn> | [exa]: You probably want streaming libraries then, yeah |
| 2025-03-28 20:56:11 +0100 | <[exa]> | tomsmeding: good point, it should hold until it's clear that it won't backtrack |
| 2025-03-28 20:56:21 +0100 | <merijn> | [exa]: conduit works really well with the various parsecs where you just write a parser for one record and emit as you finish them |
| 2025-03-28 20:56:27 +0100 | <[exa]> | ok this actually at least proves that my idea with writer is off |
| 2025-03-28 20:56:39 +0100 | <absence> | What's the best way to deal with forall mismatches after simplified subsumption? I just made some code compile by writing "fmap (\f x -> f x)", which looks a bit silly, and isn't very intuitive... |
| 2025-03-28 20:56:41 +0100 | ljdarj | (~Thunderbi@user/ljdarj) (Ping timeout: 265 seconds) |
| 2025-03-28 20:56:41 +0100 | ljdarj1 | ljdarj |
| 2025-03-28 20:56:50 +0100 | <[exa]> | merijn: yeah I think that will be it |
| 2025-03-28 20:56:52 +0100 | Square2 | (~Square@user/square) (Ping timeout: 252 seconds) |
| 2025-03-28 20:56:52 +0100 | Square | (~Square@user/square) (Ping timeout: 252 seconds) |
| 2025-03-28 20:57:01 +0100 | <tomsmeding> | the standard fix for simplified subsumption breaking your code is indeed eta-expansion |
| 2025-03-28 20:57:17 +0100 | <[exa]> | ok thanks guys for consultation again! :) |
| 2025-03-28 20:57:57 +0100 | AlexZenon | (~alzenon@178.34.150.194) (Ping timeout: 252 seconds) |
| 2025-03-28 20:58:10 +0100 | <absence> | tomsmeding: So I've heard, it just feels extra weird when it's inside a functor. But I guess there's no other way? |
| 2025-03-28 20:59:21 +0100 | CiaoSen | (~Jura@2a02:8071:64e1:da0:5a47:caff:fe78:33db) CiaoSen |
| 2025-03-28 21:00:36 +0100 | AlexZenon | (~alzenon@178.34.150.194) |
| 2025-03-28 21:07:38 +0100 | slack1256 | (~slack1256@2803:c600:5111:9ab8:84f4:ae24:2907:edab) (Remote host closed the connection) |
| 2025-03-28 21:08:55 +0100 | machinedgod | (~machinedg@d108-173-18-100.abhsia.telus.net) machinedgod |
| 2025-03-28 21:09:29 +0100 | j1n37- | (~j1n37@user/j1n37) j1n37 |
| 2025-03-28 21:10:14 +0100 | j1n37 | (~j1n37@user/j1n37) (Ping timeout: 260 seconds) |
| 2025-03-28 21:10:48 +0100 | aetepe | (~aetepe@188.119.58.34) (Remote host closed the connection) |
| 2025-03-28 21:11:29 +0100 | dhil | (~dhil@2a0c:b381:52e:3600:cbb4:807:319f:c7af) (Ping timeout: 248 seconds) |
| 2025-03-28 21:12:48 +0100 | zungi | (~tory@user/andrewchawk) (Ping timeout: 264 seconds) |
| 2025-03-28 21:13:18 +0100 | CiaoSen | (~Jura@2a02:8071:64e1:da0:5a47:caff:fe78:33db) (Ping timeout: 272 seconds) |
| 2025-03-28 21:18:12 +0100 | <haskellbridge> | <Liamzee> hmmm, that's interesting |
| 2025-03-28 21:18:13 +0100 | <haskellbridge> | <Liamzee> Ur isn't a monad? |
| 2025-03-28 21:21:16 +0100 | <EvanR> | instance Prelude.Monad Ur where |
| 2025-03-28 21:21:26 +0100 | <EvanR> | Ur a >>= f = f a |
| 2025-03-28 21:25:55 +0100 | polyphem | (~rod@p3ee3f49b.dip0.t-ipconnect.de) (Ping timeout: 268 seconds) |
| 2025-03-28 21:27:30 +0100 | <haskellbridge> | <Liamzee> i'm not sure what the technical term is, i spoke to a friend who did stuff with Linear Haskell |
| 2025-03-28 21:27:49 +0100 | <haskellbridge> | <Liamzee> but we talked about the possibility of Linear Haskell simply being a concern for library writers, but you called LH for better memory usage or a disabled GC |
| 2025-03-28 21:28:14 +0100 | <haskellbridge> | <Liamzee> having Ur being a monad would be useful for LInear Haskell, so it's interesting to ask why it's not |
| 2025-03-28 21:28:24 +0100 | <haskellbridge> | <Liamzee> "Rust as a monadic eDSL" ;) |
| 2025-03-28 21:30:34 +0100 | <EvanR> | I'm concerned about your premise that Ur is not a moand |
| 2025-03-28 21:30:45 +0100 | <EvanR> | which seems to be plainly false |
| 2025-03-28 21:31:16 +0100 | <EvanR> | disabling of the GC when using linear haskell doesn't sound like a thing |
| 2025-03-28 21:31:42 +0100 | <haskellbridge> | <Liamzee> https://hackage.haskell.org/package/linear-base-0.1.0/docs/Control-Functor-Linear.html |
| 2025-03-28 21:31:51 +0100 | weary-traveler | (~user@user/user363627) (Quit: Konversation terminated!) |
| 2025-03-28 21:31:56 +0100 | <haskellbridge> | <Liamzee> oh, i realize the problem now |
| 2025-03-28 21:32:04 +0100 | <haskellbridge> | <Liamzee> it's up to 0.4.0, and maybe 0.5.0 :) |
| 2025-03-28 21:32:13 +0100 | weary-traveler | (~user@user/user363627) user363627 |
| 2025-03-28 21:32:56 +0100 | <haskellbridge> | <Liamzee> https://hackage.haskell.org/package/linear-base-0.4.0/docs/src/Data.Unrestricted.Linear.Internal.U… |
| 2025-03-28 21:35:58 +0100 | <haskellbridge> | <Liamzee> EvanR: but while doing the computation, you could potentially do free after use, but i'm not sure if the allocator works that way |
| 2025-03-28 21:36:31 +0100 | <EvanR> | what do you mean |
| 2025-03-28 21:37:30 +0100 | <EvanR> | free what |
| 2025-03-28 21:39:21 +0100 | <haskellbridge> | <Liamzee> i mean linear types imply that a value is consumed, meaning that its allocation can be cleared |
| 2025-03-28 21:39:53 +0100 | <haskellbridge> | <Liamzee> you might have a GC for the nonlinear haskell wrapping the computation, but the linear computation doesn't need a GC |
| 2025-03-28 21:40:27 +0100 | <EvanR> | the meaning of "consumed" doesn't necessarily mean "deleted from existence" |
| 2025-03-28 21:40:39 +0100 | <EvanR> | it just means you can't use it again |
| 2025-03-28 21:41:02 +0100 | <haskellbridge> | <Liamzee> "not sure if the allocator works that way" |
| 2025-03-28 21:41:08 +0100 | <EvanR> | in one example, that space was immediately reused by the operation you just did |
| 2025-03-28 21:41:13 +0100 | <EvanR> | freeing it would break things in that case |
| 2025-03-28 21:41:29 +0100 | <EvanR> | in another case, the object's ownership transferred elsewhere |
| 2025-03-28 21:41:38 +0100 | <EvanR> | in another case, it wasn't a real object the begin with |
| 2025-03-28 21:41:59 +0100 | <EvanR> | e.g. it could have been evidence of some sort that's now invalid |
| 2025-03-28 21:43:10 +0100 | <EvanR> | linear anything is often much more general in scope |
| 2025-03-28 21:43:47 +0100 | <haskellbridge> | <Liamzee> at least in theory, though, it should have better performance due to not needing to do as many allocations |
| 2025-03-28 21:43:56 +0100 | <haskellbridge> | <Liamzee> and not needing the GC to be on to cover the data |
| 2025-03-28 21:44:09 +0100 | <EvanR> | calling into a memory management system to "free" stuff constantly sounds like overhead of its own |
| 2025-03-28 21:44:43 +0100 | <EvanR> | that's why Ur/Web waits until the end of the processing program to discard the entire block of memory |
| 2025-03-28 21:45:34 +0100 | <EvanR> | it just sounds like you're conflating "no GC memory management" with linear types |
| 2025-03-28 21:49:57 +0100 | L29Ah | (~L29Ah@wikipedia/L29Ah) (Ping timeout: 248 seconds) |
| 2025-03-28 21:50:15 +0100 | <haskellbridge> | <Liamzee> Web type? |
| 2025-03-28 21:51:42 +0100 | <haskellbridge> | <Liamzee> i'm just being conservative because i was told that there's no automatic mutation implied by linear haskell |
| 2025-03-28 21:51:48 +0100 | <haskellbridge> | <Liamzee> which is a feature that some people want |
| 2025-03-28 21:55:10 +0100 | <EvanR> | "automatic mutation" ? |
| 2025-03-28 21:55:15 +0100 | <merijn> | Liamzee: FYI, GHC's allocator is *stupidly* fast, though |
| 2025-03-28 21:55:24 +0100 | <merijn> | EvanR: In place updates when reference count == 1 |
| 2025-03-28 21:55:32 +0100 | jespada | (~jespada@2800:a4:231e:8900:903f:fbe:20bf:5608) (Quit: My Mac has gone to sleep. ZZZzzz…) |
| 2025-03-28 21:56:07 +0100 | <merijn> | Like, I'd be surprised if allocating memory took more than 5 instructions in GHC |
| 2025-03-28 21:57:18 +0100 | <merijn> | It's basically "increment a number" and a comparison to check if you exceeded the heap |
| 2025-03-28 21:57:29 +0100 | <merijn> | Maybe 1 or 2 instructions for an atomic CAS? |
| 2025-03-28 21:57:31 +0100 | <EvanR> | allocation is fast and easy |
| 2025-03-28 21:57:45 +0100 | jespada | (~jespada@2800:a4:231e:8900:903f:fbe:20bf:5608) jespada |
| 2025-03-28 21:57:45 +0100 | jespada | (~jespada@2800:a4:231e:8900:903f:fbe:20bf:5608) (Client Quit) |
| 2025-03-28 21:58:42 +0100 | <merijn> | Liamzee: FWIW, I've had Haskell programs with allocation rates of over 4 Gb/s (and this is the average over a duration of 2-3 minutes) that never exceeded more than a few 10s of MB of resident memory |
| 2025-03-28 21:59:14 +0100 | <tomsmeding> | one cute trick you can do with LinearTypes that I haven't seen much is `newtype State s a = Staet (s %1-> (Ur a, s))` |
| 2025-03-28 21:59:38 +0100 | <tomsmeding> | you get `modify :: (s %1-> s) -> State s a -> State s a`, and it otherwise works essentially exactly like the normal state monad |
| 2025-03-28 21:59:42 +0100 | <haskellbridge> | <Liamzee> one cute trick you can do with LinearTypes that I haven't seen much is using LinearTypes ;) |
| 2025-03-28 22:00:14 +0100 | <EvanR> | napkin math says that implies you "run out of resident memory" 400 times a second |
| 2025-03-28 22:00:15 +0100 | <tomsmeding> | so if you're using a State monad that you would like to do mutable updates with, it's actually very easy to achieve that now |
| 2025-03-28 22:01:42 +0100 | <haskellbridge> | <Liamzee> I guess, I'll ask directly, is there something wrong with using LinearTypes as something wrapped over by non-linear Haskell to provide a low-cost performance gain without needing FFI? |
| 2025-03-28 22:01:48 +0100 | <merijn> | EvanR: It was a program streaming a few GB worth of data from SQLite via conduit, it actually worked remarkably well in keeping low RES memory for the data size |
| 2025-03-28 22:02:01 +0100 | kimiamania | (~65804703@user/kimiamania) (Quit: PegeLinux) |
| 2025-03-28 22:02:04 +0100 | <tomsmeding> | Liamzee: https://hackage.haskell.org/package/text-builder-linear for example |
| 2025-03-28 22:02:24 +0100 | kimiamania | (~65804703@user/kimiamania) kimiamania |
| 2025-03-28 22:02:29 +0100 | AlexZenon | (~alzenon@178.34.150.194) (Ping timeout: 252 seconds) |
| 2025-03-28 22:02:53 +0100 | <haskellbridge> | <Liamzee> yeah, i saw, I recently did a purview of the LH ecosystem :) |
| 2025-03-28 22:03:28 +0100 | AlexZenon | (~alzenon@178.34.150.194) |
| 2025-03-28 22:03:34 +0100 | <haskellbridge> | <Liamzee> going full embedded with LH, at this time, is probably not a good idea, but developing wrapped linear Haskell libraries is probably a good transition to build up skills within the community and build up support for the LinearTypes extension |
| 2025-03-28 22:04:56 +0100 | <haskellbridge> | <Liamzee> erm, not purview, review |
| 2025-03-28 22:06:29 +0100 | malte | (~malte@mal.tc) malte |
| 2025-03-28 22:09:20 +0100 | <EvanR> | merijn, tens of megabytes sounds pretty good practically speaking |
| 2025-03-28 22:09:44 +0100 | <EvanR> | otoh that would exhaust the first hard drive I had, much less the ram that went with it |
| 2025-03-28 22:11:10 +0100 | <merijn> | EvanR: I mean, the raw data was a database of, like, 8 GB and 2 billion rows. That had a bunch of joins blowing up the data queried even more, then doing a full scan of that data. 10s of megabytes was much less than I was prepared to use :p |
| 2025-03-28 22:11:35 +0100 | <merijn> | Considering the machine running the code had, like, 192 GB RAM :p |
| 2025-03-28 22:15:01 +0100 | Unicorn_Princess | (~Unicorn_P@user/Unicorn-Princess/x-3540542) Unicorn_Princess |
| 2025-03-28 22:20:27 +0100 | malte | (~malte@mal.tc) (Remote host closed the connection) |
| 2025-03-28 22:20:28 +0100 | bsima | (~bsima@143.198.118.179) (Quit: ZNC 1.8.2 - https://znc.in) |
| 2025-03-28 22:21:14 +0100 | bsima | (~bsima@2604:a880:400:d0::19f1:7001) bsima |
| 2025-03-28 22:21:58 +0100 | nitrix | (~nitrix@user/meow/nitrix) (Quit: ZNC 1.9.1 - https://znc.in) |
| 2025-03-28 22:23:54 +0100 | nitrix | (~nitrix@user/meow/nitrix) nitrix |
| 2025-03-28 22:23:59 +0100 | malte | (~malte@mal.tc) malte |
| 2025-03-28 22:29:59 +0100 | wootehfoot | (~wootehfoo@user/wootehfoot) (Read error: Connection reset by peer) |
| 2025-03-28 22:40:39 +0100 | malte | (~malte@mal.tc) (Remote host closed the connection) |
| 2025-03-28 22:42:27 +0100 | L29Ah | (~L29Ah@wikipedia/L29Ah) L29Ah |
| 2025-03-28 22:46:30 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 252 seconds) |
| 2025-03-28 22:47:30 +0100 | j1n37- | (~j1n37@user/j1n37) (Read error: Connection reset by peer) |
| 2025-03-28 22:53:01 +0100 | j1n37 | (~j1n37@user/j1n37) j1n37 |
| 2025-03-28 22:58:14 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-03-28 22:59:52 +0100 | chiselfuse | (~chiselfus@user/chiselfuse) (Remote host closed the connection) |
| 2025-03-28 23:00:26 +0100 | chiselfuse | (~chiselfus@user/chiselfuse) chiselfuse |
| 2025-03-28 23:00:47 +0100 | malte | (~malte@mal.tc) malte |
| 2025-03-28 23:05:12 +0100 | target_i | (~target_i@user/target-i/x-6023099) (Quit: leaving) |
| 2025-03-28 23:07:27 +0100 | malte | (~malte@mal.tc) (Remote host closed the connection) |
| 2025-03-28 23:07:28 +0100 | takuan | (~takuan@d8D86B601.access.telenet.be) (Remote host closed the connection) |
| 2025-03-28 23:08:51 +0100 | tromp | (~textual@2001:1c00:3487:1b00:6095:11f3:6fa5:fb3d) (Ping timeout: 246 seconds) |
| 2025-03-28 23:12:44 +0100 | toby-bro | (~toby-bro@user/toby-bro) (Ping timeout: 260 seconds) |
| 2025-03-28 23:17:45 +0100 | michalz | (~michalz@185.246.207.205) (Remote host closed the connection) |
| 2025-03-28 23:44:52 +0100 | emmanuelux | (~emmanuelu@user/emmanuelux) emmanuelux |
| 2025-03-28 23:50:11 +0100 | dudek | (~dudek@2a02:a312:c9df:bf80:6431:ea:b097:7aad) |
