Newest at the top
| 2025-05-07 11:22:02 +0200 | Unicorn_Princess | (~Unicorn_P@user/Unicorn-Princess/x-3540542) Unicorn_Princess |
| 2025-05-07 11:14:42 +0200 | lortabac | (~lortabac@2a0d:e487:53f:1bb4:a731:33f3:afa0:8130) |
| 2025-05-07 11:12:07 +0200 | j1n37- | (~j1n37@user/j1n37) (Ping timeout: 276 seconds) |
| 2025-05-07 11:11:42 +0200 | tromp | (~textual@2001:1c00:3487:1b00:d43:3b62:1503:cb84) |
| 2025-05-07 11:11:01 +0200 | j1n37 | (~j1n37@user/j1n37) j1n37 |
| 2025-05-07 11:10:11 +0200 | fp | (~Thunderbi@2001:708:20:1406::1370) fp |
| 2025-05-07 11:02:32 +0200 | sord937 | (~sord937@gateway/tor-sasl/sord937) sord937 |
| 2025-05-07 11:02:13 +0200 | sord937 | (~sord937@gateway/tor-sasl/sord937) (Remote host closed the connection) |
| 2025-05-07 10:59:38 +0200 | j1n37 | (~j1n37@user/j1n37) (Ping timeout: 265 seconds) |
| 2025-05-07 10:59:28 +0200 | xff0x | (~xff0x@fsb6a9491c.tkyc517.ap.nuro.jp) |
| 2025-05-07 10:58:29 +0200 | j1n37- | (~j1n37@user/j1n37) j1n37 |
| 2025-05-07 10:47:47 +0200 | tromp | (~textual@2001:1c00:3487:1b00:d43:3b62:1503:cb84) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 2025-05-07 10:44:47 +0200 | sord937 | (~sord937@gateway/tor-sasl/sord937) sord937 |
| 2025-05-07 10:43:55 +0200 | sord937 | (~sord937@gateway/tor-sasl/sord937) (Remote host closed the connection) |
| 2025-05-07 10:43:36 +0200 | fp | (~Thunderbi@wireless-86-50-140-117.open.aalto.fi) (Ping timeout: 276 seconds) |
| 2025-05-07 10:40:19 +0200 | <tomsmeding> | simple is good |
| 2025-05-07 10:40:07 +0200 | <haskellbridge> | <magic_rb> yeah its very simple currently |
| 2025-05-07 10:39:51 +0200 | <tomsmeding> | which is largely what parser combinators are anyway |
| 2025-05-07 10:39:43 +0200 | <tomsmeding> | just "useful helper functions" |
| 2025-05-07 10:39:37 +0200 | <tomsmeding> | though it's just peek/skip I'm not sure one can really call this "parser combinators" :p |
| 2025-05-07 10:39:34 +0200 | lortabac | (~lortabac@2a01:e0a:541:b8f0:55ab:e185:7f81:54a4) (Ping timeout: 272 seconds) |
| 2025-05-07 10:39:16 +0200 | <tomsmeding> | because the assumption is that you proceed forward during parsing, not backward |
| 2025-05-07 10:39:07 +0200 | <tomsmeding> | this parser combinator approach may fail if you need to read a value towards the end of a structure and based on that decide how to parse the start of that structure |
| 2025-05-07 10:38:20 +0200 | <haskellbridge> | <magic_rb> yeah i have it as Ptr () |
| 2025-05-07 10:37:48 +0200 | <tomsmeding> | (I suspect you'll want to hard-code that p to Ptr ()) |
| 2025-05-07 10:37:27 +0200 | <tomsmeding> | right |
| 2025-05-07 10:37:15 +0200 | <tomsmeding> | peek :: (Storable a, Monad m) => PeekT (Ptr ()) m a; skip :: Monad m => Int -> PeekT (Ptr ()) m () |
| 2025-05-07 10:37:09 +0200 | <haskellbridge> | <magic_rb> ill have to if it instead of a Alternative instance |
| 2025-05-07 10:36:55 +0200 | <haskellbridge> | <magic_rb> think it sholud be fine? |
| 2025-05-07 10:36:07 +0200 | <tomsmeding> | but it might be okay for your purposes! |
| 2025-05-07 10:35:52 +0200 | <tomsmeding> | by using just StateT you're skipping the 2nd and 3rd options |
| 2025-05-07 10:35:38 +0200 | <tomsmeding> | which is "success, here is the new state (Addr#)", or "failure, backtrack", or "fatal failure, error" |
| 2025-05-07 10:35:22 +0200 | <tomsmeding> | e.g. in flatparse, the basic result of the function inside the monad is https://hackage.haskell.org/package/flatparse-0.5.2.1/docs/FlatParse-Basic.html#t:ResI-35- |
| 2025-05-07 10:34:56 +0200 | <haskellbridge> | <magic_rb> dont think so |
| 2025-05-07 10:34:40 +0200 | <tomsmeding> | I'm not sure if you need those here |
| 2025-05-07 10:34:36 +0200 | <tomsmeding> | in a parser monad you usually not only have state, but also error handling (an ExceptT effect) and some kind of backtracking support |
| 2025-05-07 10:34:00 +0200 | <haskellbridge> | <magic_rb> is there a reason why not to base it on StateT? |
| 2025-05-07 10:33:50 +0200 | <haskellbridge> | <magic_rb> tomsmeding: i think "newtype PeekT p m a = PeekT (StateT p m a)" is sufficient, holds the pointer and returns a peeked result |
| 2025-05-07 10:33:20 +0200 | __monty__ | (~toonn@user/toonn) toonn |
| 2025-05-07 10:31:18 +0200 | <haskellbridge> | <magic_rb> ill try to get a parser combinator into the codebase |
| 2025-05-07 10:30:16 +0200 | <haskellbridge> | <sm> +1 for separating all the things that can be separated |
| 2025-05-07 10:29:38 +0200 | <tomsmeding> | even if effectful, "collect all these chunks and concatenate them into a filename" feels more functional-style than "at every found chunk, enlarge the filename allocation and write a chunk there" |
| 2025-05-07 10:28:57 +0200 | <tomsmeding> | both of these things allow you to separate the things that _must_ happen procedurally (parsing) and the things that can happen more functionally (albeit with effects) |
| 2025-05-07 10:28:27 +0200 | <haskellbridge> | <magic_rb> didnt think of deferring it to later with the [] idea, dont know why that didnt occur to me |
| 2025-05-07 10:27:57 +0200 | <tomsmeding> | that sounds like O(n^2) because presumably that grow operation is O(n) |
| 2025-05-07 10:27:55 +0200 | <haskellbridge> | <magic_rb> yeah will also do that one |
| 2025-05-07 10:27:43 +0200 | <tomsmeding> | similar question for `s ^. output`; it's a VM-something that you manually unsafeGrow by 1 every time you find an entry |
| 2025-05-07 10:25:50 +0200 | <haskellbridge> | <magic_rb> thanks |
| 2025-05-07 10:25:49 +0200 | <haskellbridge> | <sm> 👍️ |
| 2025-05-07 10:25:40 +0200 | <haskellbridge> | <magic_rb> oh thats a great idea |