Newest at the top
2024-12-22 06:09:37 +0100 | <haskellbridge> | <Bowuigi> Strict evaluation would evaluate the value once and possibly duplicate other computations inside that value |
2024-12-22 06:08:37 +0100 | <haskellbridge> | <Bowuigi> Space leaks are caused by duplication of code, code is duplicated wherever variables are duplicated in lazy evaluation |
2024-12-22 06:07:52 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
2024-12-22 06:07:30 +0100 | <orangeflu> | and why is the laziness causing me space leaks while strictness wouldn't? |
2024-12-22 06:06:35 +0100 | <haskellbridge> | <Bowuigi> "Eager" is "fully evaluate", "Strict" is "evaluate only what I'm directly responsible for" and "Lazy" is "evaluate only what I will pattern match on, as I pattern match on it". Or at least that seems to be the general consensus |
2024-12-22 06:05:55 +0100 | peterbecich | (~Thunderbi@syn-047-229-123-186.res.spectrum.com) peterbecich |
2024-12-22 06:05:41 +0100 | ChaiTRex | (~ChaiTRex@user/chaitrex) ChaiTRex |
2024-12-22 06:05:35 +0100 | califax | (~califax@user/califx) califx |
2024-12-22 06:05:18 +0100 | ChaiTRex | (~ChaiTRex@user/chaitrex) (Remote host closed the connection) |
2024-12-22 06:05:18 +0100 | califax | (~califax@user/califx) (Remote host closed the connection) |
2024-12-22 06:05:18 +0100 | <orangeflu> | c_wraith: what do you think about the project? |
2024-12-22 06:04:16 +0100 | <haskellbridge> | <Bowuigi> Yes, but not eagerly either |
2024-12-22 06:03:41 +0100 | <orangeflu> | when you say 'strict', do you mean not lazily? |
2024-12-22 06:03:41 +0100 | housemate | (~housemate@124.187.109.206) housemate |
2024-12-22 06:02:43 +0100 | <haskellbridge> | <Bowuigi> Passing state around in a strict way, along with nice syntax sugar is what this is supposed to do |
2024-12-22 06:01:02 +0100 | <orangeflu> | anyway) |
2024-12-22 06:00:55 +0100 | <orangeflu> | i know what a state monad is, i think. like, if i have a function, that takes a container and returns a modified container and a result, i can chain them together with do notation. that's what i understand anyway. But how is that different from what i'm doing now? except for the fact that i don't chain them in a do block (which wouldn't be useful anyway, cause i don't execute instructions that way |
2024-12-22 05:58:10 +0100 | housemate | (~housemate@124.187.109.206) (Quit: Nothing to see here. I wasn't there. I take IRC seriously.) |
2024-12-22 05:58:10 +0100 | <haskellbridge> | <Bowuigi> Hmmm moving to a strict state monad to handle your emulator state could also help. It attacks space leaks more directly and is a smaller change |
2024-12-22 05:57:03 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 252 seconds) |
2024-12-22 05:56:33 +0100 | rvalue | (~rvalue@user/rvalue) rvalue |
2024-12-22 05:56:06 +0100 | <haskellbridge> | <Bowuigi> MVector is a somewhat extreme solution, mutable stuff is fairly common in heavily optimized programs/libraries like smalltt or flatparse (there are a lot more examples but I know those two more in depth than anything else) |
2024-12-22 05:56:01 +0100 | rvalue | (~rvalue@user/rvalue) (Read error: Connection reset by peer) |
2024-12-22 05:55:39 +0100 | xff0x | (~xff0x@p3704193-ipxg12201sapodori.hokkaido.ocn.ne.jp) (Ping timeout: 265 seconds) |
2024-12-22 05:55:02 +0100 | <orangeflu> | thing is, this is both a learning project and something that i want to be useful |
2024-12-22 05:54:35 +0100 | <orangeflu> | i'm sure i did a horrible job of writing this and there are a bunch of stuff that make no sense or could be optimized heavily |
2024-12-22 05:53:42 +0100 | <haskellbridge> | <Bowuigi> There might be a more obvious refactor that we missed tho |
2024-12-22 05:52:47 +0100 | <haskellbridge> | <Bowuigi> Just like optimization in other languages ofc |
2024-12-22 05:52:31 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
2024-12-22 05:52:25 +0100 | <haskellbridge> | <Bowuigi> With MVector you need something like IO everywhere yes. Haskell optimization is not for begginners |
2024-12-22 05:51:38 +0100 | <orangeflu> | This seems more trouble than its worth considering I don't even understand how to use, let alone modify all my pure functions into using it atop of my InputT IO stuff |
2024-12-22 05:51:38 +0100 | <haskellbridge> | <Bowuigi> c_wraith you might be able to help more with this, the codebase is in https://github.com/Flu/avr-emulator and the profiling results are in https://paste.tomsmeding.com/b9owLIrr |
2024-12-22 05:51:18 +0100 | peterbecich | (~Thunderbi@syn-047-229-123-186.res.spectrum.com) (Ping timeout: 265 seconds) |
2024-12-22 05:50:50 +0100 | <orangeflu> | Does that mean now I will need to have IO everywhere? |
2024-12-22 05:50:33 +0100 | <orangeflu> | well, the idea is to transition to mvectors, but i thought it would be easier. I am also using InputT IO (EmulatorState) in my REPL because i am using haskeline, so not sure how that is going to affect things with mvector. Also, there is also the functionality for reading a file and then ditching the IO after that, before executing |
2024-12-22 05:49:10 +0100 | xff0x | (~xff0x@p3704193-ipxg12201sapodori.hokkaido.ocn.ne.jp) |
2024-12-22 05:45:26 +0100 | housemate | (~housemate@124.187.109.206) housemate |
2024-12-22 05:43:35 +0100 | <haskellbridge> | <Bowuigi> The Array here was used as if it was a mutable one (it was the original idea, but the name Array was somewhat misleading since it isn't a C array) |
2024-12-22 05:41:47 +0100 | <c_wraith> | (It's likely to not avoid space leaks) |
2024-12-22 05:41:18 +0100 | <c_wraith> | That's a kind of bad way to avoid space leaks. It's better to write code that uses space invariants properly. But it has enough other benefits that it's still worth doing. |
2024-12-22 05:41:13 +0100 | <haskellbridge> | <Bowuigi> orangeflu the idea is to run the modifications on IO only (ST also works but it's not what we want here), that's what the "PrimMonad" stuff means |
2024-12-22 05:40:24 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 246 seconds) |
2024-12-22 05:39:41 +0100 | <haskellbridge> | <Bowuigi> c_wraith Some context, orangeflu is writing an emulator. This emulator has a fixed memory, which used to be in an Array. This caused space leaks, so I and [exa] suggested using an MVector because it provides benefits on this use case |
2024-12-22 05:37:37 +0100 | <orangeflu> | c_wraith said "you return an immutable value". So i go in ST or IO, mutate it however i wish based on what the instruction needs to do, then when i remove it from IO, it becomes immutable? |
2024-12-22 05:37:37 +0100 | <c_wraith> | If you're using IO mutable vectors, ignore everything about ST. |
2024-12-22 05:36:43 +0100 | <c_wraith> | Eh, I started answering questions starting from "what's the eliminator for ST" |
2024-12-22 05:36:30 +0100 | <haskellbridge> | <Bowuigi> What |
2024-12-22 05:36:02 +0100 | <orangeflu> | how do i return an immutable value? |
2024-12-22 05:36:01 +0100 | <haskellbridge> | <Bowuigi> The idea was to have an MVector on IO, not on ST |
2024-12-22 05:36:00 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |