Re: Is there a way to avoid time limit when using travis?

[Takenobu Tani]

Hi Joachim,

Thank you for the advice.

I'll try to correspond as follows:

 * To use Travis for simple build check
 * To use Phab or (slow) local machine for validation
 * To use Phab for review
 * To use Github PR for getting advice and confirm

I'll enjoy it carefully:)

Regards,
Takenobu


2017-02-04 12:45 GMT+09:00 Joachim Breitner :

> Hi,
>
> ghc has an exception in place from travis; I fear it does not carry
> over to forks.
>
> If you have commit rights to GHC, you can develop in a branch.
>
> Maybe a pull request works as well, not sure whether that uses the time
> limit of the official repo or yours. Worth a try! Just write tin the PR
> that you don not want this to be merged :-)
>
> Greetings,
> Joachim
>
>
> Am Samstag, den 04.02.2017, 11:07 +0900 schrieb Takenobu Tani:
> >
> > Hi Edward, devs,
> >
> > Thank you for kind explanation.
> > I understood the situation.
> >
> > Is it common to use paid plans when building GHC [1]?
> >
> > [1]: https://travis-ci.org/ghc/ghc
> >
> > Regards,
> > Takenobu
> >
> >
> > 2017-02-04 10:41 GMT+09:00 Edward Z. Yang :
> > > Even with a paid plan, you only have 120 min to run your build.
> > > That might be enough in your case but in Cabal's Travis project
> > > I've started playing tricks where I upload the build products
> > > somewhere, and then redownload them in a new job before running
> > > tests.
> > >
> > > Edward
> > >
> > > Excerpts from Takenobu Tani's message of 2017-02-04 10:37:21 +0900:
> > > > Dear devs,
> > > >
> > > > Is there a way to avoid time limit when using travis?
> > > >
> > > > I started using travis [1]. It is very convenient :)
> > > > But timeout occurs [2].
> > > > The log messages are as follows:
> > > >
> > > > => InstEqContext2(normal) 1806 of 5700 [0, 0, 0]
> > > > => InstEqContext3(normal) 1807 of 5700 [0, 0, 0]
> > > > => InstContextNorm(normal) 1808 of 5700 [0, 0, 0]
> > > > The job exceeded the maximum time limit for jobs, and has
> > > been
> > > > terminated.
> > > >
> > > > How do you avoid this?
> > > > Paid plan or something?
> > > >
> > > > [1]: https://ghc.haskell.org/trac/ghc/wiki/Travis
> > > > [2]: https://travis-ci.org/takenobu-hs/ghc/builds/197987055
> > > >
> > > > Regards,
> > > > Takenobu
> > >
> >
> > ___
> > ghc-devs mailing list
> > ghc-devs@haskell.org
> > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
> --
> Joachim “nomeata” Breitner
>   m...@joachim-breitner.de • https://www.joachim-breitner.de/
>   XMPP: nome...@joachim-breitner.de • OpenPGP-Key: 0xF0FBF51F
>   Debian Developer: nome...@debian.org
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Is there a way to avoid time limit when using travis?

[Joachim Breitner]

Hi,

ghc has an exception in place from travis; I fear it does not carry
over to forks.

If you have commit rights to GHC, you can develop in a branch.

Maybe a pull request works as well, not sure whether that uses the time
limit of the official repo or yours. Worth a try! Just write tin the PR
that you don not want this to be merged :-)

Greetings,
Joachim


Am Samstag, den 04.02.2017, 11:07 +0900 schrieb Takenobu Tani:
> 
> Hi Edward, devs,
> 
> Thank you for kind explanation.
> I understood the situation.
> 
> Is it common to use paid plans when building GHC [1]?
> 
> [1]: https://travis-ci.org/ghc/ghc
> 
> Regards,
> Takenobu
> 
> 
> 2017-02-04 10:41 GMT+09:00 Edward Z. Yang :
> > Even with a paid plan, you only have 120 min to run your build.
> > That might be enough in your case but in Cabal's Travis project
> > I've started playing tricks where I upload the build products
> > somewhere, and then redownload them in a new job before running
> > tests.
> > 
> > Edward
> > 
> > Excerpts from Takenobu Tani's message of 2017-02-04 10:37:21 +0900:
> > > Dear devs,
> > >
> > > Is there a way to avoid time limit when using travis?
> > >
> > > I started using travis [1]. It is very convenient :)
> > > But timeout occurs [2].
> > > The log messages are as follows:
> > >
> > >     => InstEqContext2(normal) 1806 of 5700 [0, 0, 0]
> > >     => InstEqContext3(normal) 1807 of 5700 [0, 0, 0]
> > >     => InstContextNorm(normal) 1808 of 5700 [0, 0, 0]
> > >     The job exceeded the maximum time limit for jobs, and has
> > been
> > > terminated.
> > >
> > > How do you avoid this?
> > > Paid plan or something?
> > >
> > > [1]: https://ghc.haskell.org/trac/ghc/wiki/Travis
> > > [2]: https://travis-ci.org/takenobu-hs/ghc/builds/197987055
> > >
> > > Regards,
> > > Takenobu
> > 
> 
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
-- 
Joachim “nomeata” Breitner
  m...@joachim-breitner.de • https://www.joachim-breitner.de/
  XMPP: nome...@joachim-breitner.de • OpenPGP-Key: 0xF0FBF51F
  Debian Developer: nome...@debian.org

signature.asc
Description: This is a digitally signed message part
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Is there a way to avoid time limit when using travis?

[Takenobu Tani]

Hi Edward, devs,

Thank you for kind explanation.
I understood the situation.

Is it common to use paid plans when building GHC [1]?

[1]: https://travis-ci.org/ghc/ghc

Regards,
Takenobu


2017-02-04 10:41 GMT+09:00 Edward Z. Yang :

> Even with a paid plan, you only have 120 min to run your build.
> That might be enough in your case but in Cabal's Travis project
> I've started playing tricks where I upload the build products
> somewhere, and then redownload them in a new job before running tests.
>
> Edward
>
> Excerpts from Takenobu Tani's message of 2017-02-04 10:37:21 +0900:
> > Dear devs,
> >
> > Is there a way to avoid time limit when using travis?
> >
> > I started using travis [1]. It is very convenient :)
> > But timeout occurs [2].
> > The log messages are as follows:
> >
> > => InstEqContext2(normal) 1806 of 5700 [0, 0, 0]
> > => InstEqContext3(normal) 1807 of 5700 [0, 0, 0]
> > => InstContextNorm(normal) 1808 of 5700 [0, 0, 0]
> > The job exceeded the maximum time limit for jobs, and has been
> > terminated.
> >
> > How do you avoid this?
> > Paid plan or something?
> >
> > [1]: https://ghc.haskell.org/trac/ghc/wiki/Travis
> > [2]: https://travis-ci.org/takenobu-hs/ghc/builds/197987055
> >
> > Regards,
> > Takenobu
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Is there a way to avoid time limit when using travis?

[Edward Z. Yang]

Even with a paid plan, you only have 120 min to run your build.
That might be enough in your case but in Cabal's Travis project
I've started playing tricks where I upload the build products
somewhere, and then redownload them in a new job before running tests.

Edward

Excerpts from Takenobu Tani's message of 2017-02-04 10:37:21 +0900:
> Dear devs,
> 
> Is there a way to avoid time limit when using travis?
> 
> I started using travis [1]. It is very convenient :)
> But timeout occurs [2].
> The log messages are as follows:
> 
> => InstEqContext2(normal) 1806 of 5700 [0, 0, 0]
> => InstEqContext3(normal) 1807 of 5700 [0, 0, 0]
> => InstContextNorm(normal) 1808 of 5700 [0, 0, 0]
> The job exceeded the maximum time limit for jobs, and has been
> terminated.
> 
> How do you avoid this?
> Paid plan or something?
> 
> [1]: https://ghc.haskell.org/trac/ghc/wiki/Travis
> [2]: https://travis-ci.org/takenobu-hs/ghc/builds/197987055
> 
> Regards,
> Takenobu
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

RE: Panic from rewritableTyVarsOfType

[Simon Peyton Jones via ghc-devs]

|  Typeable1.hs:22:5: error:
|  • Couldn't match kind ‘* -> (* -> *) -> (* -> *) -> * -> *’
|  with ‘forall k. (* -> *) -> (k -> *) -> k -> *’

I still don't see why we end up equating a polykind with a kind.

|  Anyways, hopefully this will be resolved with the fix to Simon's second
|  issue. Otherwise I just need to look at two performance regressions and I
|  think I'm done.

I'm validating a patch that uses tyCoVarsOfType, but a bit more selectively. So 
you'll get the same error.

S   

|  -Original Message-
|  From: Ben Gamari [mailto:b...@smart-cactus.org]
|  Sent: 03 February 2017 16:01
|  To: Simon Peyton Jones ; Richard Eisenberg
|  
|  Cc: ghc-devs@haskell.org
|  Subject: RE: Panic from rewritableTyVarsOfType
|  
|  Ben Gamari  writes:
|  
|  > Simon Peyton Jones  writes:
|  >
|  >> Meanwhile to get you rolling, you can replace rewritableTyVars with
|  >> tyCoVarsOfType and it'll all work, just a bit less efficiently.
|  >>
|  > Thanks Simon! Indeed that allows things to proceed and in the process,
|  > confirms that there is a bug in my solver logic.
|  >
|  I should clarify: the bug is in fact not in the Typeable solver. The problem
|  is that we have a type with some kind polymorphism. For instance,
|  
|  data Proxy (a :: k) = Proxy
|  
|  Note that in order to be `Typeable` Proxy needs to have its `k` kind
|  argument instantiated. Consequently this program is perfectly fine,
|  
|  ty :: TypeRep (Proxy Int)
|  ty = typeRep
|  
|  We can even decompose this into a type application,
|  
|  case ty of
|TRApp a b  -> ...
|  
|  where `a :: TypeRep Proxy` (with `k ~ Type`) and `b :: TypeRep Int`.
|  However, if we attempt to decompose `a` again (which is what the
|  Typeable1 testcase described in this thread tests), we run into trouble,
|  
|  case a of
|TRApp x y -> ...
|  
|  After changing rewritableTyVars with tyCoVarsOfType, the testcase
|  Typeable1 fails with the following correct, albeit not terribly readable,
|  error message,
|  
|  Typeable1.hs:22:5: error:
|  • Couldn't match kind ‘* -> (* -> *) -> (* -> *) -> * -> *’
|  with ‘forall k. (* -> *) -> (k -> *) -> k -> *’
|Inaccessible code in
|  a pattern with pattern synonym:
|TRApp :: forall k2 (t :: k2).
|() =>
|forall k1 (a :: k1 -> k2) (b :: k1).
|t ~ a b =>
|TypeRep (k1 -> k2) a -> TypeRep k1 b -> TypeRep k2 t,
|  in a pattern binding in
|  'do' block
|  • In the pattern: TRApp x y
|In a stmt of a 'do' block: TRApp x y <- pure x
|In the expression:
|  do let x :: ComposeK Maybe Maybe Int
|x = undefined
|TRApp x y <- pure $ typeOf x
|print (x, y)
|TRApp x y <- pure x
|
|  • Relevant bindings include
|  y :: TypeRep k3 b2 (bound at Typeable1.hs:19:13)
|  x :: TypeRep (k3 -> k2 -> k1 -> *) a2 (bound at
|  Typeable1.hs:19:11)
|  
|  This might be a place where GHC could hold the user's hand a bit more
|  gently.
|  
|  Anyways, hopefully this will be resolved with the fix to Simon's second
|  issue. Otherwise I just need to look at two performance regressions and I
|  think I'm done.
|  
|  Cheers,
|  
|  - Ben
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Disable messages with GHC API

[Alan & Kim Zimmerman]

Here [1] is the tweak we do in HaRe to get the right dynflags

Alan

[1]
https://github.com/alanz/HaRe/blob/master/src/Language/Haskell/Refact/Utils/Utils.hs#L224

On 3 Feb 2017 5:59 p.m., "Matthew Pickering" 
wrote:

> You are right. I looked more closely now and it looks like
> "parseModule" and so on overwrite the DynFlags with a cached version
> before running the relevant piece of the pipeline.
>
>  857hsc_env <- getSession
>  858let hsc_env_tmp = hsc_env { hsc_dflags = ms_hspp_opts ms }
>  859hpm <- liftIO $ hscParse hsc_env_tmp ms
>
>
> I think this is symptom of the fact that DynFlags is not very well
> structured and a lot of different compiler options are lumped
> together. It makes sense that we need to use the right DynFlags to run
> the module but this shouldn't overwrite things which are irrelevant
> like log_action.
>
> Matt
>
>
> On Fri, Feb 3, 2017 at 3:30 PM, Christopher Done 
> wrote:
> > Adding `handleSourceError` around it makes no difference.
> >
> > Which makes sense, as I don't think warnings count as exceptions,
> > otherwise my code would never have completed in the first place.
> >
> > On 3 February 2017 at 12:50, Matthew Pickering
> >  wrote:
> >> The errors are eventually caught and printed by "handleSourceError"
> >> which is used a few times in your code. You could either modify one of
> >> these to not print out any errors or try something more intelligent
> >> like is in `parUpsweep_one` which does use the `log_action` in order
> >> to print the errors out.
> >>
> >> On Fri, Feb 3, 2017 at 12:21 PM, Christopher Done 
> wrote:
> >>> In Intero, after loading modules, for each one I run the following
> >>> function: https://github.com/commercialhaskell/intero/blob/
> 300ac5a/src/GhciInfo.hs#L75..L85
> >>>
> >>> If there are warnings or any output, they get outputted. As they are
> >>> already outputted by regular :load, I don’t need the same output
> >>> twice.
> >>>
> >>> How do I disable non-severe output for any GhcMonad m => m a? I’m
> >>> using GHC 8.0.1 presently.
> >>>
> >>> I tried the following before calling getModInfo, expecting there to be
> >>> no output anymore:
> >>>
> >>> +  GHC.setSessionDynFlags
> >>> +df {log_action = \ref dflags severity srcSpan style msg ->
> return ()}
> >>>
> >>> And this had no effect. I tried some other things but ran out of
> >>> patience to keep a record of them all.
> >>>
> >>> Ciao!
> >>> ___
> >>> 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
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

RE: Panic from rewritableTyVarsOfType

[Ben Gamari]

Ben Gamari  writes:

> Simon Peyton Jones  writes:
>
>> Meanwhile to get you rolling, you can replace rewritableTyVars with
>> tyCoVarsOfType and it'll all work, just a bit less efficiently.
>>
> Thanks Simon! Indeed that allows things to proceed and in the process,
> confirms that there is a bug in my solver logic.
>
I should clarify: the bug is in fact not in the Typeable solver. The
problem is that we have a type with some kind polymorphism. For
instance,

data Proxy (a :: k) = Proxy

Note that in order to be `Typeable` Proxy needs to have its `k` kind
argument instantiated. Consequently this program is perfectly fine,

ty :: TypeRep (Proxy Int)
ty = typeRep

We can even decompose this into a type application,

case ty of
  TRApp a b  -> ...

where `a :: TypeRep Proxy` (with `k ~ Type`) and `b :: TypeRep Int`.
However, if we attempt to decompose `a` again (which is what the
Typeable1 testcase described in this thread tests), we run into trouble,

case a of
  TRApp x y -> ...

After changing rewritableTyVars with tyCoVarsOfType, the testcase
Typeable1 fails with the following correct, albeit not terribly
readable, error message,

Typeable1.hs:22:5: error:
• Couldn't match kind ‘* -> (* -> *) -> (* -> *) -> * -> *’
with ‘forall k. (* -> *) -> (k -> *) -> k -> *’
  Inaccessible code in
a pattern with pattern synonym:
  TRApp :: forall k2 (t :: k2).
  () =>
  forall k1 (a :: k1 -> k2) (b :: k1).
  t ~ a b =>
  TypeRep (k1 -> k2) a -> TypeRep k1 b -> TypeRep k2 t,
in a pattern binding in
'do' block
• In the pattern: TRApp x y
  In a stmt of a 'do' block: TRApp x y <- pure x
  In the expression:
do let x :: ComposeK Maybe Maybe Int
  x = undefined
  TRApp x y <- pure $ typeOf x
  print (x, y)
  TRApp x y <- pure x
  
• Relevant bindings include
y :: TypeRep k3 b2 (bound at Typeable1.hs:19:13)
x :: TypeRep (k3 -> k2 -> k1 -> *) a2 (bound at Typeable1.hs:19:11)

This might be a place where GHC could hold the user's hand a bit more gently.

Anyways, hopefully this will be resolved with the fix to Simon's second
issue. Otherwise I just need to look at two performance regressions and
I think I'm done.

Cheers,

- Ben


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

Re: Disable messages with GHC API

[Matthew Pickering]

You are right. I looked more closely now and it looks like
"parseModule" and so on overwrite the DynFlags with a cached version
before running the relevant piece of the pipeline.

 857hsc_env <- getSession
 858let hsc_env_tmp = hsc_env { hsc_dflags = ms_hspp_opts ms }
 859hpm <- liftIO $ hscParse hsc_env_tmp ms


I think this is symptom of the fact that DynFlags is not very well
structured and a lot of different compiler options are lumped
together. It makes sense that we need to use the right DynFlags to run
the module but this shouldn't overwrite things which are irrelevant
like log_action.

Matt


On Fri, Feb 3, 2017 at 3:30 PM, Christopher Done  wrote:
> Adding `handleSourceError` around it makes no difference.
>
> Which makes sense, as I don't think warnings count as exceptions,
> otherwise my code would never have completed in the first place.
>
> On 3 February 2017 at 12:50, Matthew Pickering
>  wrote:
>> The errors are eventually caught and printed by "handleSourceError"
>> which is used a few times in your code. You could either modify one of
>> these to not print out any errors or try something more intelligent
>> like is in `parUpsweep_one` which does use the `log_action` in order
>> to print the errors out.
>>
>> On Fri, Feb 3, 2017 at 12:21 PM, Christopher Done  
>> wrote:
>>> In Intero, after loading modules, for each one I run the following
>>> function: 
>>> https://github.com/commercialhaskell/intero/blob/300ac5a/src/GhciInfo.hs#L75..L85
>>>
>>> If there are warnings or any output, they get outputted. As they are
>>> already outputted by regular :load, I don’t need the same output
>>> twice.
>>>
>>> How do I disable non-severe output for any GhcMonad m => m a? I’m
>>> using GHC 8.0.1 presently.
>>>
>>> I tried the following before calling getModInfo, expecting there to be
>>> no output anymore:
>>>
>>> +  GHC.setSessionDynFlags
>>> +df {log_action = \ref dflags severity srcSpan style msg -> return 
>>> ()}
>>>
>>> And this had no effect. I tried some other things but ran out of
>>> patience to keep a record of them all.
>>>
>>> Ciao!
>>> ___
>>> 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: Disable messages with GHC API

[Daniel Gröber]

On Fri, Feb 03, 2017 at 12:21:38PM +, Christopher Done wrote:
> I tried the following before calling getModInfo, expecting there to be
> no output anymore:
> 
> +  GHC.setSessionDynFlags
> +df {log_action = \ref dflags severity srcSpan style msg -> return ()}

That is pretty much exactly what I do in ghc-mod to suppress all
output (other than the SourceError exceptions) so it's strange that
wouldn't work.

Have you tried making a small self contained test case for your
problem, maybe it's something intero specific? How far has it diverged
from it's GHCi roots these days anyways?

Here's[1] a small testcase I usually modify to test various GHC oddities
when I'm not sure if my ghc-mod monad magic is doing something werid
or not, might be helpful:

[1]: 
https://github.com/DanielG/ghc-mod/blob/master/test/manual/not-interpreted-error/GhcTestcase.hs

--Daniel


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

Re: Disable messages with GHC API

[Christopher Done]

Adding `handleSourceError` around it makes no difference.

Which makes sense, as I don't think warnings count as exceptions,
otherwise my code would never have completed in the first place.

On 3 February 2017 at 12:50, Matthew Pickering
 wrote:
> The errors are eventually caught and printed by "handleSourceError"
> which is used a few times in your code. You could either modify one of
> these to not print out any errors or try something more intelligent
> like is in `parUpsweep_one` which does use the `log_action` in order
> to print the errors out.
>
> On Fri, Feb 3, 2017 at 12:21 PM, Christopher Done  wrote:
>> In Intero, after loading modules, for each one I run the following
>> function: 
>> https://github.com/commercialhaskell/intero/blob/300ac5a/src/GhciInfo.hs#L75..L85
>>
>> If there are warnings or any output, they get outputted. As they are
>> already outputted by regular :load, I don’t need the same output
>> twice.
>>
>> How do I disable non-severe output for any GhcMonad m => m a? I’m
>> using GHC 8.0.1 presently.
>>
>> I tried the following before calling getModInfo, expecting there to be
>> no output anymore:
>>
>> +  GHC.setSessionDynFlags
>> +df {log_action = \ref dflags severity srcSpan style msg -> return 
>> ()}
>>
>> And this had no effect. I tried some other things but ran out of
>> patience to keep a record of them all.
>>
>> Ciao!
>> ___
>> 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: Panic from rewritableTyVarsOfType

[Ben Gamari]

Simon Peyton Jones  writes:

> Ben, Richard
>
> rewritableTyVarsOfType is used when deciding whether to split a [WD]
> constraint into [W] and [D]. For example, if we are adding
>[WD] C a
> and there is an inert
>[WD] a ~ Int
> then we want to split the [WD] into
>[W] C a
>[D] C a
> so that the [D] one can be rewritten and perhaps yield improvement etc.
>
> There is no point in rewriting coercions or cases in t, because they
> won't help (C t) to reduce. That's why rewriteableTyVarsOfType differs
> from tyVarsOfType. And indeed the arg of a class C should be a
> monotype.
>
Ahh, I see.

> So rewriteableTyVarsOfType doesn't expect foralls, hence the panic.
> But it's seeing a forall in an /equality/ constraint.
>
> FIRST ISSUE: I'm a bit surprised about that (smacks of impredicative
> polymorphism) so the first thing to check is that this is really
> supposed to happen in this program. Richard should be able to help.
>
Indeed this test is meant to fail, just not with a panic. I suspect this
means that my solver logic isn't catching requests for polytypes as
early as it needs to.

> SECOND ISSUE: But regardless, I now realise that shouldSplitWD only
> needs to split a [WD] equality if the LHS matches. If we have
>[WD] a ~ ty   -- work item
>[D] a ~ ty2   -- inert
> then we want to split the [WD] so we can get [D] ty ~ ty2. But
> otherwise there is no point.
>
> Richard do you agree?
>
> I'll try that out.
>
> Meanwhile to get you rolling, you can replace rewritableTyVars with
> tyCoVarsOfType and it'll all work, just a bit less efficiently.
>
Thanks Simon! Indeed that allows things to proceed and in the process,
confirms that there is a bug in my solver logic.

Cheers,

- Ben



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

Re: Disable messages with GHC API

[Matthew Pickering]

The errors are eventually caught and printed by "handleSourceError"
which is used a few times in your code. You could either modify one of
these to not print out any errors or try something more intelligent
like is in `parUpsweep_one` which does use the `log_action` in order
to print the errors out.

On Fri, Feb 3, 2017 at 12:21 PM, Christopher Done  wrote:
> In Intero, after loading modules, for each one I run the following
> function: 
> https://github.com/commercialhaskell/intero/blob/300ac5a/src/GhciInfo.hs#L75..L85
>
> If there are warnings or any output, they get outputted. As they are
> already outputted by regular :load, I don’t need the same output
> twice.
>
> How do I disable non-severe output for any GhcMonad m => m a? I’m
> using GHC 8.0.1 presently.
>
> I tried the following before calling getModInfo, expecting there to be
> no output anymore:
>
> +  GHC.setSessionDynFlags
> +df {log_action = \ref dflags severity srcSpan style msg -> return ()}
>
> And this had no effect. I tried some other things but ran out of
> patience to keep a record of them all.
>
> Ciao!
> ___
> 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

Disable messages with GHC API

[Christopher Done]

In Intero, after loading modules, for each one I run the following
function: 
https://github.com/commercialhaskell/intero/blob/300ac5a/src/GhciInfo.hs#L75..L85

If there are warnings or any output, they get outputted. As they are
already outputted by regular :load, I don’t need the same output
twice.

How do I disable non-severe output for any GhcMonad m => m a? I’m
using GHC 8.0.1 presently.

I tried the following before calling getModInfo, expecting there to be
no output anymore:

+  GHC.setSessionDynFlags
+df {log_action = \ref dflags severity srcSpan style msg -> return ()}

And this had no effect. I tried some other things but ran out of
patience to keep a record of them all.

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