Newest at the top
| 2024-09-21 04:58:56 +0200 | <geekosaur> | and re "large parameters", if they are boxed, you're passing a pointer |
| 2024-09-21 04:58:44 +0200 | <Inst> | i thought the main reason unsafePerformIO was considered unsafe was because Haskell gives very weak guarantees on evaluation order of pure functions? |
| 2024-09-21 04:58:10 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) |
| 2024-09-21 04:58:09 +0200 | <geekosaur> | it's the unsafeCoerce part, however you got it, that is problematic |
| 2024-09-21 04:57:56 +0200 | <Inst> | iirc i used unsafePerformIO as an optimization pass |
| 2024-09-21 04:57:34 +0200 | <geekosaur> | unsafePerformIO only matters insofar as it can give you a polymorphic IORef, which implicitly unsafeCoerces anything taken out of it |
| 2024-09-21 04:56:51 +0200 | <Inst> | i mean without coercion in unsafePerformIO, i.e, a way to avoid passing large parameters around |
| 2024-09-21 04:56:50 +0200 | <geekosaur> | if (a) all types are boxed (b) all types have at least as many constructors as the starting type does, you can generally get away with it |
| 2024-09-21 04:55:50 +0200 | <lambdabot> | monochrom says: isTrue = (unsafeCoerce :: Either a b -> Bool) . (unsafeCoerce :: Maybe c -> Either a b) . (unsafeCoerce :: Bool -> Maybe c) |
| 2024-09-21 04:55:50 +0200 | <geekosaur> | @quote monochrom unsafeCoerce.*Either |
| 2024-09-21 04:55:24 +0200 | <geekosaur> | because reading it will follow what it thinks is a pointer |
| 2024-09-21 04:54:54 +0200 | <geekosaur> | even read-only is unsafe if you coerced an unboxed value into a boxed one |
| 2024-09-21 04:54:26 +0200 | <Inst> | i'm more trying to figure out when it's safe to use unsafeCoerce |
| 2024-09-21 04:54:05 +0200 | <Inst> | iirc it should be safe to use unsafePerformIO for read-only operations, right? as long as you ensure the write is done beforehand |
| 2024-09-21 04:53:33 +0200 | <geekosaur> | that's more or less what you're inviting with unsafeCoerce in any form |
| 2024-09-21 04:53:12 +0200 | <geekosaur> | that's not too surprising, it very likely depends on the internal GMP representation |
| 2024-09-21 04:49:43 +0200 | morb | (~morb@pool-108-41-100-120.nycmny.fios.verizon.net) (Ping timeout: 265 seconds) |
| 2024-09-21 04:47:36 +0200 | terrorjack4 | (~terrorjac@static.48.15.202.116.clients.your-server.de) |
| 2024-09-21 04:47:18 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 265 seconds) |
| 2024-09-21 04:46:01 +0200 | <Inst> | okay, Integers (mostly) seem to produce the desired crash on unsafeCoerce to System.IO.Handle (using unsafePerformIO) |
| 2024-09-21 04:45:20 +0200 | terrorjack4 | (~terrorjac@2a01:4f8:c17:dc9f::) (Quit: The Lounge - https://thelounge.chat) |
| 2024-09-21 04:45:08 +0200 | morb | (~morb@pool-108-41-100-120.nycmny.fios.verizon.net) |
| 2024-09-21 04:44:43 +0200 | JuanDaugherty | (~juan@user/JuanDaugherty) |
| 2024-09-21 04:44:08 +0200 | morb | (~morb@pool-108-41-100-120.nycmny.fios.verizon.net) (Remote host closed the connection) |
| 2024-09-21 04:43:50 +0200 | <Inst> | but other integers don't produce the same effects |
| 2024-09-21 04:43:43 +0200 | <Inst> | 234288 unsafeCoerce-ed to System.IO.Handle gets you the crash I'm looking for |
| 2024-09-21 04:43:13 +0200 | <Inst> | this is weird |
| 2024-09-21 04:42:23 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) |
| 2024-09-21 04:40:48 +0200 | machinedgod | (~machinedg@d50-99-47-73.abhsia.telus.net) (Ping timeout: 246 seconds) |
| 2024-09-21 04:36:21 +0200 | td_ | (~td@i5387092D.versanet.de) |
| 2024-09-21 04:34:30 +0200 | td_ | (~td@i53870926.versanet.de) (Ping timeout: 246 seconds) |
| 2024-09-21 04:31:55 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 264 seconds) |
| 2024-09-21 04:26:35 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) |
| 2024-09-21 04:19:23 +0200 | peterbecich | (~Thunderbi@syn-047-229-123-186.res.spectrum.com) |
| 2024-09-21 04:17:03 +0200 | morb | (~morb@pool-108-41-100-120.nycmny.fios.verizon.net) |
| 2024-09-21 04:15:27 +0200 | <geekosaur> | the example code may now be too simplistic to demonstrate the problem, but I'm sure it won't need much tweaking to reveal it again |
| 2024-09-21 04:13:35 +0200 | <geekosaur> | as the discussion says, if you have unsafePerformIO, you have unsafeCoerce and what happens if you use it as such will be up to the whim of the RTS |
| 2024-09-21 04:13:05 +0200 | morb | (~morb@pool-108-41-100-120.nycmny.fios.verizon.net) (Remote host closed the connection) |
| 2024-09-21 04:12:41 +0200 | <geekosaur> | the problem they're talking about can't be fixed as such (it might be made slightly less likely to happen in certain specific cases, but the general problem is not fixable) |
| 2024-09-21 04:11:59 +0200 | <Inst> | iirc it does crash in windows, but i sort of lost my windows drive :( |
| 2024-09-21 04:09:25 +0200 | <geekosaur> | keep in mind that I'm on Ubuntu 22.04, so my kernel is practically ancient |
| 2024-09-21 04:08:55 +0200 | <Inst> | still fails to crash, I suspect it's something to do with linux kernel updates |
| 2024-09-21 04:07:52 +0200 | <Inst> | i swapped to 8.x via ghcup |
| 2024-09-21 04:07:46 +0200 | <geekosaur> | (it didn't core here) |
| 2024-09-21 04:07:40 +0200 | <geekosaur> | but that's just a suspicion |
| 2024-09-21 04:07:25 +0200 | <geekosaur> | I think the example code was "broken" by ghc's runtime representations changing in 8.10.5+ to support Apple AArch64 |
| 2024-09-21 04:06:08 +0200 | <Inst> | undefined behavior depending on platform and kernel version |
| 2024-09-21 04:06:00 +0200 | <Inst> | I used to get it to crash, but I guess that's why it's unsafe |
| 2024-09-21 04:05:49 +0200 | <Inst> | thanks anyways |
| 2024-09-21 04:05:01 +0200 | <Inst> | it's weird, but probably why it's just unsafe, i.e, might be platform specific |