Re: Question about initializing the run-time system
I looked at RtsStartup.c but I didn't see any code that was obviously enforcing this (have you tried it?)rts/RtsStartup.c However, at a guess, I bet the reason is related to the reason why we can't have multiple copies of the RTS in the same memory address space: the way we handle CAFs scribbles over data pages that we loaded in from objects. I last looked at this when working on https://ghc.haskell.org/trac/ghc/wiki/Commentary/Rts/Storage/HeapAlloced#Method2:copystaticclosuresintoaspecialareaatstartup Edward Excerpts from Iavor Diatchki's message of 2016-08-15 11:02:54 -0700: > Hello, > > GHC's user guide says that the run-time system cannot re-initialize itself, > after it was shut-down (i.e., you can't call `hs_init` after calling > `hs_exit`). > > Could anyone shed some light on why that is? > > -Iavor ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
RE: RdrName and decorations
I think it belongs in the HsSyn syntax tree. The RdrName for (say) Prelude.map is the same RdrName, whether or not it looks like `Prelude.map`. Simon From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of Alan & Kim Zimmerman Sent: 05 August 2016 14:40 To: ghc-devs@haskell.org Subject: RdrName and decorations Hi all At the moment I am working through ghc-exactprint, adding a feature to add standard API annotations to any constructed AST so that it can be (pretty)-printed. One of the major headaches is the decorations on a RdrName. What I mean by this is that an item appearing in the AST as a RdrName may have parens or backquotes around it, and may have a preceding keyword out of [forall, pattern, type]. I am slowly teasing out the contextual requirements to determine these, but it seems that they should be captured directly in the AST already. And not as API Annotations. So the question is, does it make sense to do this? Does it belong in the OccName or the RdrName if so? Alan ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Behavior of GHC_PACKAGE_PATH
Hi, As per the GHC manual (https://downloads.haskell. org/~ghc/master/users-guide/packages.html#the-ghc-package- path-environment-variable), packages which come earlier in the GHC_PACKAGE_PATH supersede the ones which come later. But that does not seem to be the case always. I am dealing with a case where I have multiple versions of a package in different databases. I am passing the list of package dbs via GHC_PACKAGE_PATH and ghc is picking the one which comes later. I expect it to pick the one which comes earlier in the path. In one case the package being picked from a package db which comes later is a newer version which makes me wonder if GHC always prefers a newer version. In another case both the versions are same but still GHC is using the one which come later in the package path. Are there any undocumented factors into play here? None of the packages is broken (as reported by ghc-pkg check). See https://github.com/commercialhaskell/stack/issues/1957#issuecomment- 239655912 for more details on where it is coming from. Thanks, Harendra ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
