Newest at the top
| 2025-02-07 13:10:53 +0100 | remedan | (~remedan@ip-62-245-108-153.bb.vodafone.cz) (Quit: Bye!) |
| 2025-02-07 13:03:42 +0100 | jespada | (~jespada@2800:a4:2309:e700:64a6:7448:7cfa:894d) jespada |
| 2025-02-07 12:58:56 +0100 | AlexNoo_ | AlexNoo |
| 2025-02-07 12:57:43 +0100 | jespada | (~jespada@2800:a4:2309:e700:64a6:7448:7cfa:894d) (Client Quit) |
| 2025-02-07 12:57:27 +0100 | remedan | (~remedan@ip-62-245-108-153.bb.vodafone.cz) remedan |
| 2025-02-07 12:56:59 +0100 | jespada | (~jespada@2800:a4:2309:e700:64a6:7448:7cfa:894d) jespada |
| 2025-02-07 12:56:17 +0100 | remedan | (~remedan@ip-62-245-108-153.bb.vodafone.cz) (Quit: Bye!) |
| 2025-02-07 12:53:27 +0100 | MyNetAz | (~MyNetAz@user/MyNetAz) MyNetAz |
| 2025-02-07 12:53:19 +0100 | sprotte24 | (~sprotte24@p200300d16f162e0095bcbd8ff54bb672.dip0.t-ipconnect.de) (Read error: Connection reset by peer) |
| 2025-02-07 12:50:51 +0100 | sprotte24 | (~sprotte24@p200300d16f162e0095bcbd8ff54bb672.dip0.t-ipconnect.de) |
| 2025-02-07 12:50:48 +0100 | alfiee | (~alfiee@user/alfiee) (Ping timeout: 252 seconds) |
| 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. |