Newest at the top
| 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) |
| 2025-02-07 12:22:05 +0100 | <dminuoso> | We compile text twice, one for host and once for target. TH links against the host object files, final program against the target object files. |
| 2025-02-07 12:22:03 +0100 | alp_ | (~alp@2001:861:8ca0:4940:2887:5196:3f2d:f111) (Remote host closed the connection) |
| 2025-02-07 12:21:53 +0100 | <tomsmeding> | ghc cares, when generating assembly code. |
| 2025-02-07 12:21:37 +0100 | <dminuoso> | Who cares what the target is? |
| 2025-02-07 12:21:11 +0100 | <tomsmeding> | you cannot compile any code if you don't yet know whether to do so for x64 or for riscv! |
| 2025-02-07 12:20:53 +0100 | <tomsmeding> | so there is definitely a well-defined target at all times |
| 2025-02-07 12:20:45 +0100 | <tomsmeding> | all code that is compiled is compile for a particular target environment/architecture/etc. |
| 2025-02-07 12:20:38 +0100 | alp_ | (~alp@2001:861:8ca0:4940:2887:5196:3f2d:f111) |
| 2025-02-07 12:20:29 +0100 | <tomsmeding> | the target is decided at the point where you build a final executable |
| 2025-02-07 12:20:21 +0100 | alp_ | (~alp@2001:861:8ca0:4940:14f3:ef88:5d72:946) (Remote host closed the connection) |