Newest at the top
| 2025-01-22 11:09:01 +0100 | j1n37 | (~j1n37@user/j1n37) j1n37 |
| 2025-01-22 11:07:49 +0100 | j1n37 | (~j1n37@user/j1n37) (Ping timeout: 248 seconds) |
| 2025-01-22 11:07:26 +0100 | <homo> | even cross-compiled I won't bother doing work necessary to port ghc neither to different os nor to different processor instruction set |
| 2025-01-22 11:06:55 +0100 | sprotte24 | (~sprotte24@p200300d16f084200f435cd8a7bac203a.dip0.t-ipconnect.de) (Quit: Leaving) |
| 2025-01-22 11:05:43 +0100 | <homo> | merijn if it doesn't use those, how do you explain that ghc 4 can't directly build latest version of ghc? can ghc 5 do that? ghc 6? ghc 7? ghc 8? |
| 2025-01-22 11:05:41 +0100 | tnt2 | (~Thunderbi@user/tnt1) (Ping timeout: 248 seconds) |
| 2025-01-22 11:05:40 +0100 | <merijn> | homo: Generally you'd want to bootstrap by simply cross-compiling at least a semi-recent GHC to whatever platform |
| 2025-01-22 11:05:28 +0100 | alfiee | (~alfiee@user/alfiee) alfiee |
| 2025-01-22 11:04:37 +0100 | tnt1 | (~Thunderbi@user/tnt1) tnt1 |
| 2025-01-22 11:03:50 +0100 | <homo> | also my interest is getting haskell to plan9, I am not insane to port not just elephant, but a freaking blue whale called ghc |
| 2025-01-22 11:03:47 +0100 | <merijn> | homo: I mean, the REAL answer to your bootstrap question is: You'd go through the LLVM backend |
| 2025-01-22 11:03:10 +0100 | fmira | (~user@user/fmira) fmira |
| 2025-01-22 11:03:04 +0100 | <haskellbridge> | <sm> unless you've all been saying that already, in which case carry on |
| 2025-01-22 11:02:42 +0100 | <haskellbridge> | <sm> start with say microhs, build progressively more featureful variants of ghc |
| 2025-01-22 11:02:34 +0100 | fmira | (~user@user/fmira) (Remote host closed the connection) |
| 2025-01-22 11:02:20 +0100 | <merijn> | homo: I mean, GHC doesn't use most of the advanced stuff of itself |
| 2025-01-22 11:01:57 +0100 | tnt1 | (~Thunderbi@user/tnt1) (Ping timeout: 248 seconds) |
| 2025-01-22 11:01:16 +0100 | tnt2 | (~Thunderbi@user/tnt1) tnt1 |
| 2025-01-22 11:01:10 +0100 | <homo> | and for self-hosted implementation to be bootstrappable, best practice is that it uses small subset of it's own features, not almost entire set of features |
| 2025-01-22 10:58:17 +0100 | <homo> | bootstrappable is not about getting archives of all historical laggage, if there is alternative and maintained implementation capable of doing bootstrap it's more preferable path than going back in history |
| 2025-01-22 10:57:04 +0100 | <homo> | that assumes I must have an emulator for that platform or I must buy specific hardware |
| 2025-01-22 10:56:49 +0100 | hellwolf | not being serious here |
| 2025-01-22 10:56:41 +0100 | <hellwolf> | ultimate bootstrap goal was build everything from a FORTH compiler |
| 2025-01-22 10:56:20 +0100 | <hellwolf> | I guess you just need to build an old one from one platform? |
| 2025-01-22 10:55:28 +0100 | <homo> | older ghc path is what Googulator from #bootstrappable channel prefers |
| 2025-01-22 10:54:23 +0100 | sprotte24 | (~sprotte24@p200300d16f084200f435cd8a7bac203a.dip0.t-ipconnect.de) |
| 2025-01-22 10:54:18 +0100 | <[exa]> | homo: well, true |
| 2025-01-22 10:54:17 +0100 | <homo> | hellwolf how do you get older ghc working on riscv and arm without running x86 instruction emulator? |
| 2025-01-22 10:54:15 +0100 | JuanDaugherty | ColinRobinson |
| 2025-01-22 10:53:51 +0100 | <hellwolf> | and GHC compiles itself version by version |
| 2025-01-22 10:53:41 +0100 | <hellwolf> | the idea was bootstrap from a older GHC |
| 2025-01-22 10:53:29 +0100 | <haskellbridge> | <sm> a dramatically simpler, cleaner and more portable new haskell compiler actively maintained by a top haskell developer - valuable |
| 2025-01-22 10:53:10 +0100 | <[exa]> | sm: because there's never enough compiler alternatives |
| 2025-01-22 10:51:23 +0100 | lxsameer | (~lxsameer@Serene/lxsameer) lxsameer |
| 2025-01-22 10:49:36 +0100 | JuanDaugherty | (~juan@user/JuanDaugherty) JuanDaugherty |
| 2025-01-22 10:48:03 +0100 | <homo> | [exa] I'm afraid without cooperation from ghc developers, ghc will never be buildable by alternative implementations, because ghc depends too much on its own extensions and internal quirks, and 7.x bugs show there is no guarantee that ghc can build itself, alternative option is to fork ghc to reduce those requirements |
| 2025-01-22 10:48:01 +0100 | <haskellbridge> | <sm> why microhs exists at all ? |
| 2025-01-22 10:44:49 +0100 | xff0x | (~xff0x@fsb6a9491c.tkyc517.ap.nuro.jp) (Ping timeout: 248 seconds) |
| 2025-01-22 10:42:14 +0100 | cy7 | (~yt@pool-99-238-69-14.cpe.net.cable.rogers.com) (Ping timeout: 252 seconds) |
| 2025-01-22 10:40:36 +0100 | alexherbo2 | (~alexherbo@2a02-8440-350e-d10b-25a2-ca7e-51a0-4409.rev.sfr.net) alexherbo2 |
| 2025-01-22 10:40:17 +0100 | alexherbo2 | (~alexherbo@2a02-8440-350e-d10b-25a2-ca7e-51a0-4409.rev.sfr.net) (Remote host closed the connection) |
| 2025-01-22 10:39:55 +0100 | <hellwolf> | I am missing the "why" clearly stated for the MicroHs. But it's exciting if we could bootstrap GHC from it. |
| 2025-01-22 10:18:43 +0100 | alfiee | (~alfiee@user/alfiee) (Ping timeout: 245 seconds) |
| 2025-01-22 10:14:23 +0100 | alfiee | (~alfiee@user/alfiee) alfiee |
| 2025-01-22 10:06:02 +0100 | <kqr> | opqdonut, Wait, yeah, that does exactly what I need. I think when I tested it I accidentally gave it the wrong boolean and then never stopped to think it through again. Thanks! |
| 2025-01-22 10:02:05 +0100 | merijn | (~merijn@77.242.116.146) merijn |
| 2025-01-22 09:57:46 +0100 | merijn | (~merijn@77.242.116.146) (Quit: leaving) |
| 2025-01-22 09:56:10 +0100 | machinedgod | (~machinedg@d108-173-18-100.abhsia.telus.net) machinedgod |
| 2025-01-22 09:54:45 +0100 | Square | (~Square@user/square) (Ping timeout: 248 seconds) |
| 2025-01-22 09:53:35 +0100 | alexherbo2 | (~alexherbo@2a02-8440-350e-d10b-25a2-ca7e-51a0-4409.rev.sfr.net) alexherbo2 |