Newest at the top
| 2024-11-14 18:57:17 +0100 | <bailsman> | They totally can. I'm being called from javascript, that JSFFI function is in IO, currently I'm faking a global variable by doing unsafePerformIO (newIOREf ...) then reading/writing to the IORef |
| 2024-11-14 18:56:41 +0100 | <tomsmeding> | then you can just put the IOVector wherever |
| 2024-11-14 18:56:35 +0100 | <tomsmeding> | I don't recall the JS FFI well, but can't exported haskell functions run in IO? |
| 2024-11-14 18:56:17 +0100 | <tomsmeding> | make it an IOVector instead of an STVector? |
| 2024-11-14 18:56:05 +0100 | <tomsmeding> | okay that changes the picture |
| 2024-11-14 18:56:01 +0100 | <tomsmeding> | O.o |
| 2024-11-14 18:55:51 +0100 | <bailsman> | I need to store it somewhere between invocations from javascript :P |
| 2024-11-14 18:55:45 +0100 | <tomsmeding> | (think: there's already an "IORef" (ish) inside the MVector type) |
| 2024-11-14 18:55:27 +0100 | <tomsmeding> | no code needs to _return_ an MVector, just create one, then pass it _to_ everything |
| 2024-11-14 18:55:09 +0100 | <bailsman> | this part isn't safe. This is the fast part. The rest of my code I want to write idiomatically/pure. |
| 2024-11-14 18:55:06 +0100 | <tomsmeding> | a mutable array is a _reference_, you only need a read-only reference to the MVector to be able to modify the underlying storage |
| 2024-11-14 18:54:39 +0100 | <tomsmeding> | that's the whole point of the interface, and what makes it safe |
| 2024-11-14 18:54:32 +0100 | <tomsmeding> | the point is that a mutable array _must_ live inside the monad :p |
| 2024-11-14 18:54:30 +0100 | housemate | (~housemate@146.70.66.228) housemate |
| 2024-11-14 18:54:18 +0100 | housemate | (~housemate@146.70.66.228) (Read error: Connection reset by peer) |
| 2024-11-14 18:54:17 +0100 | <tomsmeding> | that would save the introduced copy |
| 2024-11-14 18:54:16 +0100 | <bailsman> | The 'challenge' I have is I'm not sure how to store a mutable array outside the monad. Currently I'm freezing it, then doing writeIORef, then when it runs again I do readIORef followed by thaw. |
| 2024-11-14 18:54:10 +0100 | <tomsmeding> | perhaps you can ensure that you don't create the initial vector as immutable, but instead as mutable, so that you never have to thaw it |
| 2024-11-14 18:53:20 +0100 | <tomsmeding> | then change the unsafeThaw to thaw, because with the unsafeThaw + unsafeFreeze you're still in unsafe world |
| 2024-11-14 18:53:01 +0100 | <tomsmeding> | bailsman: try putting the whole mutable part in ST, so that you only have one unsafeThaw and one unsafeFreeze; presumably that should still be fast |
| 2024-11-14 18:52:12 +0100 | <tomsmeding> | I would still not do this |
| 2024-11-14 18:51:51 +0100 | <tomsmeding> | yes IO sequences, so that's fine |
| 2024-11-14 18:51:50 +0100 | <geekosaur> | evaluate has to be in IO |
| 2024-11-14 18:51:47 +0100 | <tomsmeding> | (evaluate runs in IO) |
| 2024-11-14 18:51:42 +0100 | <bailsman> | sure |
| 2024-11-14 18:51:35 +0100 | peterbecich | (~Thunderbi@syn-047-229-123-186.res.spectrum.com) (Ping timeout: 255 seconds) |
| 2024-11-14 18:51:32 +0100 | <tomsmeding> | in IO? |
| 2024-11-14 18:51:29 +0100 | <bailsman> | evaluate $ force |
| 2024-11-14 18:51:26 +0100 | <tomsmeding> | (again depending on the precise code) |
| 2024-11-14 18:51:15 +0100 | <tomsmeding> | GHC may just decide that "fully evaluating" the values can also happen a bit later |
| 2024-11-14 18:50:58 +0100 | <tomsmeding> | bailsman: yes, depending on how you ensure that it is fully evaluated |
| 2024-11-14 18:47:10 +0100 | housemate | (~housemate@146.70.66.228) housemate |
| 2024-11-14 18:46:27 +0100 | tzh | (~tzh@c-76-115-131-146.hsd1.or.comcast.net) tzh |
| 2024-11-14 18:44:03 +0100 | ft | (~ft@p4fc2a216.dip0.t-ipconnect.de) ft |
| 2024-11-14 18:39:30 +0100 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 2024-11-14 18:38:56 +0100 | housemate | (~housemate@146.70.66.228) (Quit: "I saw it in a tiktok video and thought that it was the most smartest answer ever." ~ AnonOps Radio [some time some place] | I AM THE DERIVATIVE I AM GOING TANGENT TO THE CURVE!) |
| 2024-11-14 18:37:43 +0100 | <bailsman> | Replacing the code with the safe versions of freeze and thaw makes it 3x slower |
| 2024-11-14 18:37:26 +0100 | <geekosaur> | ST will ensure that for you |
| 2024-11-14 18:36:47 +0100 | <bailsman> | I actually really like the performance now - I'd like to fully understand the dragons on my path. |
| 2024-11-14 18:35:42 +0100 | <bailsman> | Even if I make sure that the code with mutable reference has fully evaluated before any code with immutable references tries to read? |
| 2024-11-14 18:34:51 +0100 | wootehfoot | (~wootehfoo@user/wootehfoot) wootehfoot |
| 2024-11-14 18:34:19 +0100 | <tomsmeding> | work in ST and keep the thing mutable while you're mutating it |
| 2024-11-14 18:33:54 +0100 | <tomsmeding> | please don't do this :p |
| 2024-11-14 18:33:35 +0100 | <tomsmeding> | GHC assumes that immutable values don't change and sometimes optimises quite aggressively based on that assumption |
| 2024-11-14 18:33:32 +0100 | peterbecich | (~Thunderbi@syn-047-229-123-186.res.spectrum.com) peterbecich |
| 2024-11-14 18:33:13 +0100 | <tomsmeding> | bailsman: yes, mutating an immutable vector is sure to produce very strange issues |
| 2024-11-14 18:32:55 +0100 | <bailsman> | I should probably find a way to keep it mutable permanently rather than thawing and freezing |
| 2024-11-14 18:31:59 +0100 | <bailsman> | more readable on multiple lines |
| 2024-11-14 18:31:34 +0100 | <bailsman> | https://paste.tomsmeding.com/yaTzqQA3 |
| 2024-11-14 18:27:04 +0100 | alexherbo2 | (~alexherbo@2a02-8440-3313-668b-a9ec-921f-0511-ee3f.rev.sfr.net) alexherbo2 |