Re: Interpreter thread in ghc-8.10.6 in macOS
Thanks Zubin! That looks very much on the mark. We might not need to change GHC after all if we can avoid calling the R runtime from Template Haskell [4]. [4] https://github.com/tweag/HaskellR/issues/369 On Tue, Nov 16, 2021 at 3:11 PM Zubin Duggal wrote: > A patch to run Template Haskell code in a forked thread was included in > ghc-8.10.6: https://gitlab.haskell.org/ghc/ghc/-/merge_requests/5042 > > This was chosen as the only robust way to avoid reporting any > asynchronous exceptions thrown to the compilation process during TH > evaluation as a user error in TH code. If you cancel a compile by > throwing the compilation thread an exception, we don't want to catch > that error in GHC and report it as if the TH code had a regular > exception. By running the TH code in a forked thread and not sharing > the ThreadId, we ensure that any exception caught during the evaluation > of TH code either originated from the code itself or was thrown by the > RTS directly to the TH code (BlockedIndefinetelyOnMVar,... etc.). > > There may be alternative solutions to this or ways to make this > behaviour configurable. I would urge you to open an ticket on the GHC > tracker detailing your use case. > > On 21/11/16 11:26, Domínguez, Facundo wrote: > >Dear devs, > > > >I found recently that ghc-8.10.6 and ghc-8.10.7 might be behaving > >differently than previous compilers when running Template Haskell code. > > > >When upgrading HaskellR to use a newer ghc I found that it would work fine > >with ghc-8.10.4, but not ghc-8.10.6 or ghc-8.10.7. HaskellR, and the R > >runtime in particular, is sensitive to local state in the threads that are > >used to execute the runtime. HaskellR is arranging to run the R runtime > >when running TemplateHaskell splices, and this stopped working in MacOS > >with ghc-8.10.6. > > > >The error I got is not new. It comes from R and we would get it in ghci if > >we try to use HaskellR without passing the command line flag > >-fno-ghci-sandbox. But this is the first time we get the error when using > >TemplateHaskell. > > > >Does anyone know if there have been changes to the threads in which the TH > >splices are run? And were there any changes specific to TH in MacOS? > > > >Thanks in advance, > >Facundo > > > >[1] https://github.com/tweag/HaskellR/pull/368#issuecomment-968864170 > > >___ > >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
request for comments: foreign calls (#20693)
I'd like it to be easier to extend GHC with support for new species of foreign calls. Existing support makes it easy to *replace* GHC's implementation of foreign calls but not to *extend* it. Details in #20693 (https://gitlab.haskell.org/ghc/ghc/-/issues/20693). I'd welcome comments, especially from anyone involved with GHCJS. Norman ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: Interpreter thread in ghc-8.10.6 in macOS
A patch to run Template Haskell code in a forked thread was included in ghc-8.10.6: https://gitlab.haskell.org/ghc/ghc/-/merge_requests/5042 This was chosen as the only robust way to avoid reporting any asynchronous exceptions thrown to the compilation process during TH evaluation as a user error in TH code. If you cancel a compile by throwing the compilation thread an exception, we don't want to catch that error in GHC and report it as if the TH code had a regular exception. By running the TH code in a forked thread and not sharing the ThreadId, we ensure that any exception caught during the evaluation of TH code either originated from the code itself or was thrown by the RTS directly to the TH code (BlockedIndefinetelyOnMVar,... etc.). There may be alternative solutions to this or ways to make this behaviour configurable. I would urge you to open an ticket on the GHC tracker detailing your use case. On 21/11/16 11:26, Domínguez, Facundo wrote: Dear devs, I found recently that ghc-8.10.6 and ghc-8.10.7 might be behaving differently than previous compilers when running Template Haskell code. When upgrading HaskellR to use a newer ghc I found that it would work fine with ghc-8.10.4, but not ghc-8.10.6 or ghc-8.10.7. HaskellR, and the R runtime in particular, is sensitive to local state in the threads that are used to execute the runtime. HaskellR is arranging to run the R runtime when running TemplateHaskell splices, and this stopped working in MacOS with ghc-8.10.6. The error I got is not new. It comes from R and we would get it in ghci if we try to use HaskellR without passing the command line flag -fno-ghci-sandbox. But this is the first time we get the error when using TemplateHaskell. Does anyone know if there have been changes to the threads in which the TH splices are run? And were there any changes specific to TH in MacOS? Thanks in advance, Facundo [1] https://github.com/tweag/HaskellR/pull/368#issuecomment-968864170 ___ 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: Interpreter thread in ghc-8.10.6 in macOS
Hello Carter, thanks for taking a look. > Rather than a ghc or linker error There is no such error. The error is produced instead by the R runtime when it finds it is running in a thread not quite like it expects. Here's a failing job [2]. And the error message looks like: HaskellR-examples> Error: C stack usage 17587399033768 is too close to the limit 5246 HaskellR-examples> Error: C stack usage 17587399033816 is too close to the limit 5247 HaskellR-examples> Error: C stack usage 17587399033352 is too close to the limit 5248 HaskellR-examples> Fatal error: unable to initialize the JIT 5249 HaskellR-examples> Here's [3] where the FAQ of HaskellR suggests using -fno-ghci-sandbox. > How would I replicate the build failure locally? Would cabal get haskellR ; cd haskelR* ; cabal build ; cabal test suffice ? I think it will depend on how you have installed the R runtime. It should be possible to install with cabal-install, but I don't have any up-to-date instructions to share. The readme [4] goes with the stack tool instead. Best, Facundo [2] https://github.com/tweag/HaskellR/runs/4224936110?check_suite_focus=true [3] https://tweag.github.io/HaskellR/docs/faq.html [4] https://github.com/tweag/HaskellR#the-haskellr-project On Tue, Nov 16, 2021 at 2:21 PM Carter Schonwald wrote: > Hey Facundo: can you share a link to the underlying error ? I tried to > find the error output in the linked ticket, but I only see a failure > message at the stack_build_tool level. Rather than a ghc or linker error > > How would I replicate the build failure locally? Would cabal get haskellR > ; cd haskelR* ; cabal build ; cabal test suffice ? > > On Tue, Nov 16, 2021 at 9:27 AM Domínguez, Facundo < > facundo.doming...@tweag.io> wrote: > >> Dear devs, >> >> I found recently that ghc-8.10.6 and ghc-8.10.7 might be behaving >> differently than previous compilers when running Template Haskell code. >> >> When upgrading HaskellR to use a newer ghc I found that it would work >> fine with ghc-8.10.4, but not ghc-8.10.6 or ghc-8.10.7. HaskellR, and the R >> runtime in particular, is sensitive to local state in the threads that are >> used to execute the runtime. HaskellR is arranging to run the R runtime >> when running TemplateHaskell splices, and this stopped working in MacOS >> with ghc-8.10.6. >> >> The error I got is not new. It comes from R and we would get it in ghci >> if we try to use HaskellR without passing the command line flag >> -fno-ghci-sandbox. But this is the first time we get the error when using >> TemplateHaskell. >> >> Does anyone know if there have been changes to the threads in which the >> TH splices are run? And were there any changes specific to TH in MacOS? >> >> Thanks in advance, >> Facundo >> >> [1] https://github.com/tweag/HaskellR/pull/368#issuecomment-968864170 >> ___ >> 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: Interpreter thread in ghc-8.10.6 in macOS
Hey Facundo: can you share a link to the underlying error ? I tried to find the error output in the linked ticket, but I only see a failure message at the stack_build_tool level. Rather than a ghc or linker error How would I replicate the build failure locally? Would cabal get haskellR ; cd haskelR* ; cabal build ; cabal test suffice ? On Tue, Nov 16, 2021 at 9:27 AM Domínguez, Facundo < facundo.doming...@tweag.io> wrote: > Dear devs, > > I found recently that ghc-8.10.6 and ghc-8.10.7 might be behaving > differently than previous compilers when running Template Haskell code. > > When upgrading HaskellR to use a newer ghc I found that it would work fine > with ghc-8.10.4, but not ghc-8.10.6 or ghc-8.10.7. HaskellR, and the R > runtime in particular, is sensitive to local state in the threads that are > used to execute the runtime. HaskellR is arranging to run the R runtime > when running TemplateHaskell splices, and this stopped working in MacOS > with ghc-8.10.6. > > The error I got is not new. It comes from R and we would get it in ghci if > we try to use HaskellR without passing the command line flag > -fno-ghci-sandbox. But this is the first time we get the error when using > TemplateHaskell. > > Does anyone know if there have been changes to the threads in which the TH > splices are run? And were there any changes specific to TH in MacOS? > > Thanks in advance, > Facundo > > [1] https://github.com/tweag/HaskellR/pull/368#issuecomment-968864170 > ___ > 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
Interpreter thread in ghc-8.10.6 in macOS
Dear devs, I found recently that ghc-8.10.6 and ghc-8.10.7 might be behaving differently than previous compilers when running Template Haskell code. When upgrading HaskellR to use a newer ghc I found that it would work fine with ghc-8.10.4, but not ghc-8.10.6 or ghc-8.10.7. HaskellR, and the R runtime in particular, is sensitive to local state in the threads that are used to execute the runtime. HaskellR is arranging to run the R runtime when running TemplateHaskell splices, and this stopped working in MacOS with ghc-8.10.6. The error I got is not new. It comes from R and we would get it in ghci if we try to use HaskellR without passing the command line flag -fno-ghci-sandbox. But this is the first time we get the error when using TemplateHaskell. Does anyone know if there have been changes to the threads in which the TH splices are run? And were there any changes specific to TH in MacOS? Thanks in advance, Facundo [1] https://github.com/tweag/HaskellR/pull/368#issuecomment-968864170 ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
