Newest at the top
| 2025-02-07 12:49:57 +0100 | sprotte24 | (~sprotte24@p200300d16f162e0095bcbd8ff54bb672.dip0.t-ipconnect.de) (Client Quit) |
| 2025-02-07 12:48:37 +0100 | sprotte24 | (~sprotte24@p200300d16f162e0095bcbd8ff54bb672.dip0.t-ipconnect.de) |
| 2025-02-07 12:48:18 +0100 | vanishingideal | (~vanishing@user/vanishingideal) (Ping timeout: 268 seconds) |
| 2025-02-07 12:47:38 +0100 | merijn | (~merijn@77.242.116.146) merijn |
| 2025-02-07 12:47:34 +0100 | <tomsmeding> | there's build-tool-depends, not sure if that is flexible enough |
| 2025-02-07 12:46:26 +0100 | MyNetAz | (~MyNetAz@user/MyNetAz) (Remote host closed the connection) |
| 2025-02-07 12:46:26 +0100 | alfiee | (~alfiee@user/alfiee) alfiee |
| 2025-02-07 12:42:23 +0100 | lortabac | (~lortabac@2a01:e0a:541:b8f0:55ab:e185:7f81:54a4) |
| 2025-02-07 12:39:24 +0100 | <dminuoso> | Which is why I explored some solution similar to zeroth |
| 2025-02-07 12:38:55 +0100 | <dminuoso> | One thing I had wanted before, is to keep runtime dependencies smaller. I once had something akin to an openapi.json and needed to generate stub code - now I dont want aeson in my runtime dependency, large dependency closures lead to version bounds being overly restrictive especially if some of those transitive packages have tight bounds and are not updated regularly. |
| 2025-02-07 12:36:52 +0100 | neiluj | (~julien@90.121.75.121) (Quit: WeeChat 4.4.3) |
| 2025-02-07 12:35:24 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 252 seconds) |
| 2025-02-07 12:34:13 +0100 | <tomsmeding> | https://gitlab.haskell.org/ghc/ghc/-/wikis/template-haskell/cross-compilation |
| 2025-02-07 12:33:05 +0100 | <tomsmeding> | I don't know what happens if you try to cross-compile for a different architecture that is not JS or wasm. :P |
| 2025-02-07 12:32:32 +0100 | <dminuoso> | Okay I see! Then all we need is qemu to run in GHC. :-) |
| 2025-02-07 12:32:22 +0100 | <tomsmeding> | (if I remember correctly) |
| 2025-02-07 12:31:40 +0100 | <tomsmeding> | dminuoso: when compiling for JS, GHC literally spins up a nodejs executable to run your TH code |
| 2025-02-07 12:31:39 +0100 | <dminuoso> | Given that parsing tends to not happen on target. |
| 2025-02-07 12:31:24 +0100 | <dminuoso> | Not sure what TH running on target in cross-compilation would even mean |
| 2025-02-07 12:31:21 +0100 | <int-e> | It's so that most user code doesn't have to worry about cross-compilation. |
| 2025-02-07 12:31:10 +0100 | <dminuoso> | TH runs during parse time on host. |
| 2025-02-07 12:30:53 +0100 | <tomsmeding> | though I'm not actively following that space |
| 2025-02-07 12:30:45 +0100 | <tomsmeding> | the above-mentioned, I'd guess |
| 2025-02-07 12:30:44 +0100 | <dminuoso> | Dont quite see how this makes sense |
| 2025-02-07 12:30:34 +0100 | <dminuoso> | Why would it need to run on the target? |
| 2025-02-07 12:30:05 +0100 | <tomsmeding> | so this choice has already been made :p |
| 2025-02-07 12:29:56 +0100 | <tomsmeding> | particularly around the wasm and js backends |
| 2025-02-07 12:29:46 +0100 | <tomsmeding> | GHC is actively doing lots of work to ensure that TH can run on the target when cross-compiling, with the whole external-interpreter stuff |
| 2025-02-07 12:29:19 +0100 | <dminuoso> | Whether any breakage if we limited availability in TH is even worth discussing. |
| 2025-02-07 12:29:11 +0100 | alp__ | (~alp@2001:861:8ca0:4940:817d:397a:310b:59bd) (Ping timeout: 268 seconds) |
| 2025-02-07 12:29:07 +0100 | <dminuoso> | For this discussion, a thorough analysis of hackage would be interesting. |
| 2025-02-07 12:28:46 +0100 | <tomsmeding> | (There's more than just sizeOf that returns system information. There's everything in the System.Info module, for starters, and also anything in IO is system-dependent) |
| 2025-02-07 12:28:35 +0100 | <dminuoso> | Or maybe not exist at all. |
| 2025-02-07 12:28:22 +0100 | <dminuoso> | Something equivalent to a separate Foreign.Storable.Target module would make more sense. |
| 2025-02-07 12:28:06 +0100 | <tomsmeding> | I agree. But it's not the status quo, so changing that would be breaking |
| 2025-02-07 12:27:57 +0100 | alp_ | (~alp@2001:861:8ca0:4940:1362:b30:65a6:8bf) (Ping timeout: 268 seconds) |
| 2025-02-07 12:27:51 +0100 | <dminuoso> | So after pondering some, I think that `sizeOf` in TH should not give you target information. |
| 2025-02-07 12:27:12 +0100 | remedan | (~remedan@ip-62-245-108-153.bb.vodafone.cz) remedan |
| 2025-02-07 12:27:12 +0100 | <dminuoso> | Yeah just hypothetical. |
| 2025-02-07 12:26:37 +0100 | <tomsmeding> | I hope it's the former |
| 2025-02-07 12:26:17 +0100 | <tomsmeding> | just double-checking |
| 2025-02-07 12:26:11 +0100 | <tomsmeding> | dminuoso: "We compile text twice" -- is this a hypothetical, or do you actually compile TH this way at your workplace? |
| 2025-02-07 12:25:25 +0100 | remedan | (~remedan@ip-62-245-108-153.bb.vodafone.cz) (Quit: Bye!) |
| 2025-02-07 12:24:29 +0100 | <dminuoso> | This is an intriguing example. |
| 2025-02-07 12:24:04 +0100 | alp__ | (~alp@2001:861:8ca0:4940:817d:397a:310b:59bd) |
| 2025-02-07 12:23:14 +0100 | <tomsmeding> | (for better or for worse) |
| 2025-02-07 12:23:09 +0100 | <tomsmeding> | and this is explicitly supported |
| 2025-02-07 12:22:55 +0100 | <tomsmeding> | also, some people write TH code that explicitly assumes it's running on the target machine, so that it can use stuff like `sizeOf (undefined :: Int)` in TH and have that return appropriate values |
| 2025-02-07 12:22:48 +0100 | <dminuoso> | Problems only arise if you insist on compiling text only once to use for both TH and the final executable. |
| 2025-02-07 12:22:21 +0100 | alp_ | (~alp@2001:861:8ca0:4940:1362:b30:65a6:8bf) |