Re: GHC 9.3 API panics with "No home unit"; need advice on what next

[Norman Ramsey]

Followup: I managed to get things configured to work with `cabal v2-build`,
and with this build, the app dumps STG code as expected.  I am
unblocked!


Norman


 >   nr@homedog ~/a/sandbox> cabal v1-build
 >   Resolving dependencies...
 >   Configuring sandbox-0.1.0.0...
 >   Preprocessing executable 'sandbox' for sandbox-0.1.0.0..
 >   Building executable 'sandbox' for sandbox-0.1.0.0..
 >   [1 of 1] Compiling Main ( app/Main.hs,
 >   dist/build/sandbox/sandbox-tmp/Main.o ) [Source file changed]
 >   Linking dist/build/sandbox/sandbox ...
 >   nr@homedog ~/a/sandbox> ./dist/build/sandbox/sandbox programs/Church.hs
 >   libdir == /home/nr/asterius/ghc/_build/stage1/lib
 >   ModSummary {
 >  ms_hs_hash = 8ed607a72dd3968f1e65123b865b8572
 >  ms_mod = Church,
 >  ms_textual_imps = [(Nothing, Prelude)]
 >  ms_srcimps = []
 >   }
 >   ..
 >   sandbox: panic! (the 'impossible' happened)
 > GHC version 9.3.20210918:
 >   unsafeGetHomeUnit: No home unit
 > 
 >   Please report this as a GHC bug:  https://www.haskell.org/ghc/reportabug
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

GHC 9.3 API panics with "No home unit"; need advice on what next

[Norman Ramsey]

All,

I tried Alfredo's suggestion of building with the stage1 compiler.
(Sticking with the bootstrap compiler for HLS support, which seems
to be working OK.)  I've gotten a bit further.

I have a small app that loads .hs files, translates to STG,
and dumps the results.  It also dumps the `ModSummary` for each
module in the graph.

The code worked in the 9.0 API, but using the 9.3 API causes a panic:

  nr@homedog ~/a/sandbox> cabal v1-build
  Resolving dependencies...
  Configuring sandbox-0.1.0.0...
  Preprocessing executable 'sandbox' for sandbox-0.1.0.0..
  Building executable 'sandbox' for sandbox-0.1.0.0..
  [1 of 1] Compiling Main ( app/Main.hs, 
dist/build/sandbox/sandbox-tmp/Main.o ) [Source file changed]
  Linking dist/build/sandbox/sandbox ...
  nr@homedog ~/a/sandbox> ./dist/build/sandbox/sandbox programs/Church.hs
  libdir == /home/nr/asterius/ghc/_build/stage1/lib
  ModSummary {
 ms_hs_hash = 8ed607a72dd3968f1e65123b865b8572
 ms_mod = Church,
 ms_textual_imps = [(Nothing, Prelude)]
 ms_srcimps = []
  }
  ..
  sandbox: panic! (the 'impossible' happened)
GHC version 9.3.20210918:
  unsafeGetHomeUnit: No home unit

  Please report this as a GHC bug:  https://www.haskell.org/ghc/reportabug

I poked around, but I expected the home unit to be set by
`setSessionDynFlags`, and I don't know why it isn't.

Everything needed to reproduce the problem can be found (I hope!) at

  https://github.com/nrnrnr/ghc-api-sandbox 

I'm a bit reluctant to simply report a bug as I'm afraid I might be
doing something wacky.

What should I look at next?


Norman
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: help needed configuring GHC API client

[Norman Ramsey]

Alfredo,

I've confirmed that I can use the stage1 compiler and it doesn't
panic.

It occurs to me that I might be able to *compile* my code with the
stage1 compiler while using the bootstrap compiler and Haskell
Language Server.   I'll give that a shot.


Norman


 > Hi Norman,
 > 
 > in addition to what Ben already said: is there any particular reason you
 > wanted to use the stage0 compiler? I have written a small program against
 > HEAD which used the GHC API fairly recently, and I have simply used the
 > `stage1` compiler. An excerpt from my little code snippet:
 > 
 > ```
 > -- This is just the output of '_build/stage1/bin/ghc --print-libdir'
 > myGhcLibDir :: FilePath
 > myGhcLibDir = "./_build/stage1/lib"
 > 
 > playground :: FilePath -> IO ()
 > playground fn = do
 >   res <- runGhc (Just myGhcLibDir) $ do
 >   ...
 > ```
 > 
 > As you can see that's exactly what you are doing, modulo the fact I was
 > using the `stage1` (where _build is the default directory for Hadrian
 > builds).
 > 
 > Hope this helps in some way!
 > 
 > A.
 > 
 > 
 > 
 > 
 > On Fri, 24 Sept 2021 at 03:37, Ben Gamari  wrote:
 > 
 > > Norman Ramsey  writes:
 > >
 > > > I'm writing client code against the GHC API in HEAD (version 9.3),
 > > > using 9.0.1 as my bootstrap compiler.  To make it possible to build
 > > > this code, I've set up cabal using
 > > >
 > > >cabal v1-configure \
 > > >   --package-db clear \
 > > >   --package-db $STAGE0/lib/package.conf.d/  # stage0 libraries
 > > >
 > > > In my Haskell code I'm invoking `runGhc (Just thelibdir)` where
 > > >
 > > >thelibir = "/home/nr/asterius/ghc/_build/stage0/lib"
 > > >
 > > > which is my `$STAGE0/lib`.
 > > >
 > > > Unfortunuately, when I launch my app, `setSessionDynFlags` panics.
 > > > The output, along with some diagnostic information about some dflags
 > > > that seemed relevant, looks like this:
 > > >
 > > >   libdir = /home/nr/asterius/ghc/_build/stage0/lib
 > > >   includePaths = IncludeSpecs {includePathsQuote = [],
 > > includePathsGlobal = [], includePathsQuoteImplicit = []}
 > > >   libraryPaths = []
 > > >   packageDBFlags = []
 > > >   packageEnv = Nothing
 > > >   panic! (the 'impossible' happened)
 > > > GHC version 9.3.20210918:
 > > >   GHC couldn't find the RTS constants (#define HS_CONSTANTS ")
 > > in /home/nr/.ghcup/ghc/9.0.1/lib/ghc-9.0.1/include/DerivedConstants.h: the
 > > RTS package you are trying to use is perhaps for another GHC version(e.g.
 > > you are using the wrong package database) or the package database is
 > > broken.
 > > >
 > > >   CallStack (from HasCallStack):
 > > > error, called at
 > > _build/stage0/compiler/build/GHC/Platform/Constants.hs:143:20 in
 > > ghc:GHC.Platform.Constants
 > > >
 > > >   Please report this as a GHC bug:
 > > https://www.haskell.org/ghc/reportabug
 > > >
 > > > I'm a little suprprised that my app is hunting for 9.3 information in
 > > > the tree that belongs to the bootstrap compiler.
 > > >
 > > I suspect that the stages are getting mixed up here. Would it be
 > > possible to post a full reproducer? I'd be happy to investigate further,
 > > but without being able to reproduce locally it's a bit hard to say
 > > anything useful. My recollection is that we look for DerivedConstants.h
 > > in the usual include paths, so there are many ways in which things could
 > > go wrong.
 > >
 > > Cheers,
 > >
 > > - Ben
 > > ___
 > > ghc-devs mailing list
 > > ghc-devs@haskell.org
 > > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
 > >
 > 
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: [Haskell-cafe] Numerics (was: Re: Trouble with asinh)

[Carter Schonwald]

Hey David,
Create a tracking ticket on the ghc for the set of changes / issues you
wanna address and how, and @ me on it  (I’ll then make sure to at other
applicable Dolan )and I’ll try to help you get oriented and make sure it
has the right visibility so we can help you out!

On Sat, Sep 18, 2021 at 12:00 PM David James  wrote:

> Hi thanks for the comments. I actually have draft rewrites of the Haskell
> complex functions with (I think) the correct behaviour, including branch
> cuts. But I discovered the errors in the underlying real functions while
> testing them. I’d like to try fixing all of these, but will probably need
> some help.
>
> Are there instructions somewhere on the process to fix a bug (presumably
> forking in GitHub, fixing code, adding test cases, running some CI, both
> for Linux and Windows, etc)? (And is there something similar for fixing
> mingle-w64 bugs?)
>
> I’ve been developing more test cases (esp for infinities +/-0, etc), but
> if there are any ideas/references on how to thoroughly test real or complex
> functions, that would also be useful.
>
> I’m currently away (and struggling to type on a phone) but will send more
> details (and pictures based on those in Common Lisp The Language 2nd
> edition) when I’m back.
>
> Thanks! David.
>
>
>
> > On 17 Sep 2021, at 22:06, Barak A. Pearlmutter 
> wrote:
> >
> > I suspect that most implementations of Common Lisp just call the C
> > standard library catan(3) etc, which are well tuned.
> >
> > $ clisp
> > Welcome to GNU CLISP 2.49.92 (2018-02-18) 
> > [1]> (atan #c(0 1d-40))
> > #C(0 1.0d-40)
> >
> > In this particular case, the problem is that the Haskell Data.Complex
> > code has its own implementation of atan, which uses a log(1 + x) in
> > calculating the imaginary part. A foreign function call to the
> > appropriate libm routine would robustly address this, but that would
> > be difficult because it's trying to be generic over RealFloat a =>
> > Complex a, instead of special casing Complex Float / Complex Double.
> > Anyway, the Standard Prelude code for this is naïve: it should call
> > log1p, at the very least—which it actually goes to the trouble of
> > defining correctly, but not exporting.
> > ___
> > Haskell-Cafe mailing list
> > To (un)subscribe, modify options or view archives go to:
> > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
> > Only members subscribed via the mailman list are allowed to post.
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: help needed configuring GHC API client

[Norman Ramsey]

 > I suspect that the stages are getting mixed up here. Would it be
 > possible to post a full reproducer?

I think so.  I'm thinking a source tree for my client, plus step-by-step
instructions.  Would that do the job?


Norman
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: help needed configuring GHC API client

[Norman Ramsey]

 > in addition to what Ben already said: is there any particular reason you
 > wanted to use the stage0 compiler? 

Yes!  I want to use the Haskell Language Server with my code.  I am
given to understand that HLS does not work with GHC HEAD, so if I want
to use HLS with my own code, it needs to be compiled with the
bootstrap compiler, which *does* support HLS.  Therefore I am using
stage0 so that my own code and the GHC library are compiled with the
same compiler.

I will, however, repeat my experiment using stage1.  It would be good
to confirm your experience.



Norman

___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: help needed configuring GHC API client

[Norman Ramsey]

 > Hi Norman,
 > 
 > I think you are overcomplicating things quite a bit.
 > 
 > 1. Build a HEAD (9.3) compiler
 > 2. Setup a normal cabal project to depend on the `ghc` library
 > 3. Use the cabal -w option to point to your HEAD compiler to build the
 > project (`cabal build -w /path/to/head`)
 > 
 > That will work reliably rather than messing around with package databases.

My understanding is that if I do things this way, I give up the
Haskell Language Server.  I am in the middle of learning a large,
unfamiliar API, and the HLS is a lifeline to the documentation.
Am I wrong?  Is there another fast path to the documentation?


Norman
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: help needed configuring GHC API client

[Matthew Pickering]

Hi Norman,

I think you are overcomplicating things quite a bit.

1. Build a HEAD (9.3) compiler
2. Setup a normal cabal project to depend on the `ghc` library
3. Use the cabal -w option to point to your HEAD compiler to build the
project (`cabal build -w /path/to/head`)

That will work reliably rather than messing around with package databases.

Matt

On Thu, Sep 23, 2021 at 7:31 PM Norman Ramsey  wrote:
>
> I'm writing client code against the GHC API in HEAD (version 9.3),
> using 9.0.1 as my bootstrap compiler.  To make it possible to build
> this code, I've set up cabal using
>
>cabal v1-configure \
>   --package-db clear \
>   --package-db $STAGE0/lib/package.conf.d/  # stage0 libraries
>
> In my Haskell code I'm invoking `runGhc (Just thelibdir)` where
>
>thelibir = "/home/nr/asterius/ghc/_build/stage0/lib"
>
> which is my `$STAGE0/lib`.
>
> Unfortunuately, when I launch my app, `setSessionDynFlags` panics.
> The output, along with some diagnostic information about some dflags
> that seemed relevant, looks like this:
>
>   libdir = /home/nr/asterius/ghc/_build/stage0/lib
>   includePaths = IncludeSpecs {includePathsQuote = [], includePathsGlobal = 
> [], includePathsQuoteImplicit = []}
>   libraryPaths = []
>   packageDBFlags = []
>   packageEnv = Nothing
>   panic! (the 'impossible' happened)
> GHC version 9.3.20210918:
>   GHC couldn't find the RTS constants (#define HS_CONSTANTS ") in 
> /home/nr/.ghcup/ghc/9.0.1/lib/ghc-9.0.1/include/DerivedConstants.h: the RTS 
> package you are trying to use is perhaps for another GHC version(e.g. you are 
> using the wrong package database) or the package database is broken.
>
>   CallStack (from HasCallStack):
> error, called at 
> _build/stage0/compiler/build/GHC/Platform/Constants.hs:143:20 in 
> ghc:GHC.Platform.Constants
>
>   Please report this as a GHC bug:  https://www.haskell.org/ghc/reportabug
>
>
> I'm a little suprprised that my app is hunting for 9.3 information in
> the tree that belongs to the bootstrap compiler.
>
> I could start tinkering with `packageEnv` or other dflags, but I'm on
> thin ice here, and I thought it made more sense to ask for advice.
>
> What is going on in my configuration, and how can I set up my app so
> it is using the library in my `libdir` rather than the library that
> belongs to the bootstrap compiler?
>
>
> Norman
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: help needed configuring GHC API client

[Alfredo Di Napoli]

Hi Norman,

in addition to what Ben already said: is there any particular reason you
wanted to use the stage0 compiler? I have written a small program against
HEAD which used the GHC API fairly recently, and I have simply used the
`stage1` compiler. An excerpt from my little code snippet:

```
-- This is just the output of '_build/stage1/bin/ghc --print-libdir'
myGhcLibDir :: FilePath
myGhcLibDir = "./_build/stage1/lib"

playground :: FilePath -> IO ()
playground fn = do
  res <- runGhc (Just myGhcLibDir) $ do
  ...
```

As you can see that's exactly what you are doing, modulo the fact I was
using the `stage1` (where _build is the default directory for Hadrian
builds).

Hope this helps in some way!

A.




On Fri, 24 Sept 2021 at 03:37, Ben Gamari  wrote:

> Norman Ramsey  writes:
>
> > I'm writing client code against the GHC API in HEAD (version 9.3),
> > using 9.0.1 as my bootstrap compiler.  To make it possible to build
> > this code, I've set up cabal using
> >
> >cabal v1-configure \
> >   --package-db clear \
> >   --package-db $STAGE0/lib/package.conf.d/  # stage0 libraries
> >
> > In my Haskell code I'm invoking `runGhc (Just thelibdir)` where
> >
> >thelibir = "/home/nr/asterius/ghc/_build/stage0/lib"
> >
> > which is my `$STAGE0/lib`.
> >
> > Unfortunuately, when I launch my app, `setSessionDynFlags` panics.
> > The output, along with some diagnostic information about some dflags
> > that seemed relevant, looks like this:
> >
> >   libdir = /home/nr/asterius/ghc/_build/stage0/lib
> >   includePaths = IncludeSpecs {includePathsQuote = [],
> includePathsGlobal = [], includePathsQuoteImplicit = []}
> >   libraryPaths = []
> >   packageDBFlags = []
> >   packageEnv = Nothing
> >   panic! (the 'impossible' happened)
> > GHC version 9.3.20210918:
> >   GHC couldn't find the RTS constants (#define HS_CONSTANTS ")
> in /home/nr/.ghcup/ghc/9.0.1/lib/ghc-9.0.1/include/DerivedConstants.h: the
> RTS package you are trying to use is perhaps for another GHC version(e.g.
> you are using the wrong package database) or the package database is broken.
> >
> >   CallStack (from HasCallStack):
> > error, called at
> _build/stage0/compiler/build/GHC/Platform/Constants.hs:143:20 in
> ghc:GHC.Platform.Constants
> >
> >   Please report this as a GHC bug:
> https://www.haskell.org/ghc/reportabug
> >
> > I'm a little suprprised that my app is hunting for 9.3 information in
> > the tree that belongs to the bootstrap compiler.
> >
> I suspect that the stages are getting mixed up here. Would it be
> possible to post a full reproducer? I'd be happy to investigate further,
> but without being able to reproduce locally it's a bit hard to say
> anything useful. My recollection is that we look for DerivedConstants.h
> in the usual include paths, so there are many ways in which things could
> go wrong.
>
> Cheers,
>
> - Ben
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs