2025/02/07

Newest at the top

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 +0100alp__(~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 +0100alp_(~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 +0100remedan(~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 +0100remedan(~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 +0100alp__(~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 +0100alp_(~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 +0100alp_(~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 +0100alp_(~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 +0100alp_(~alp@2001:861:8ca0:4940:14f3:ef88:5d72:946) (Remote host closed the connection)
2025-02-07 12:20:08 +0100 <dminuoso> Of course this introduces some coherence questions, but that's really a cabal problem.
2025-02-07 12:19:53 +0100 <dminuoso> If we pick say `text`, and link against its for TH purposes, just build a separate `text` to run on what the compiler perceives as target, link it to the TH code, and done.