<rekado>Hagfish: hard to say. The big idea of STGHugs was to combine Hugs with the GHC RTS so that Hugs could load *compiled* GHC modules. <rekado>the ``…'' syntax is only found in GHC source files, and it’s called a “literal literal” for C code that is to be passed through as is to the C-generating compiler. <rekado>so it’s not something that Hugs would ever be able to parse anyway <rekado>there may be a way to change Hugs even further so that it reads the “literal literals” somehow — and in the case of variables looks them up in the RTS <rekado>so far it looks like literal literals are primarily used for “stderr”, “stdout”, “NULL”, complicated ways of expressing “NULL”, and simple identifiers. <rekado>I’ll read the Hugs sources some more to see if there’s any kind of escape hatch; or maybe the Hugs FFI extension could be used. <rekado>in any case, this will require quite a bit of work on STGhugs <oriansj>stikonas: well I must say debugging forking code is a real pain, especially under virtualization. <Hagfish>yeah, i like the idea of an escape hatch, and FFI would be a clever way to do that <Hagfish>hopefully there is a more efficient / simpler path that doesn't need an escape hatch, though ***ChanServ sets mode: +o rekado
<rekado>ghc/interpreter/interface.c might be the key to our problems <rekado>it keeps a list of symbols that are provided externally, and it has infrastructure to resolve these symbols <rekado>it is only used by the machinery for loading GHC modules, though <stikonas>oriansj: I think that your last paste actually fixes riscv32, so maybe try pushing it <siraben>stikonas: just saw your ping from a while ago, I'm not familiar enough with GHC's bootstrapping process <stikonas>well, so far rekado is making some progress... <siraben>That's good to hear. I'm currently busy with uni related things, but I'd be happy to replicate the builds if I have time