Re: Remote GHCi

[Andrew Gibiansky]

Simon,

I'd like to hear how we can support what IHaskell does with remote GHCi.

One core functionality that we use dynCompileExpr for (not quite
dynCompileExpr, but similar) is getting the standard output of code that is
being run. Any time code is run, we

1. Create a unix pipe.
2. Set stdout to point to that pipe using dupTo.
3. Use hscStmt with unsafeCoerce to get the other end of the pipe in the
compiled context.
4. Run the statement in the interpreted context in a separate thread;
meanwhile, read from the pipe to get the stdout of the code running in the
interpreted context.
5. When it is done running, move stdout back to point to the read stdout
and close the unix pipe file handle.
6. Send the stdout (both intermediate values and the final value) to the
frontend to display to the user.

The key here is that we can access directly the file handle created by the
interpreted code. If the interpreted code is remote, we clearly cannot read
from a pipe it creates. In your remote GHCi, how could we solve this
problem?

In general, how would stdin and stdout work? Would there be a clean way to
feed the remote process its stdin and receive its stdout and stderr? That
would effectively mean stdin/stdout/stderr are configurable which would be
a godsend for IHaskell.

-- Andrew

On Wed, Nov 18, 2015 at 1:45 AM, Simon Marlow  wrote:

> On 18/11/2015 01:41, Manuel M T Chakravarty wrote:
>
>> Hi Simon,
>>
>> While this is an interesting proposal, Haskell for Mac strongly
>> relies on running interpreted code in the same process. I’m using
>> ’dynCompileExpr’ as well as ’hscStmtWithLocation’ and some other
>> stuff.
>>
>
> Let me say first of all that I'm not going to remove anything, so there's
> no need to worry.  But I'd like to explore exactly what you need, so that
> we can see whether there's a way to accommodate it with a separate-process
> implementation.
>
> hscStmtWithLocation is part of the core GHCi functionality, it is
> definitely supported.  It has a slightly different signature:
>
> hscStmtWithLocation :: HscEnv
> -> String -- ^ The statement
> -> String -- ^ The source
> -> Int-- ^ Starting line
> -> IO ( Maybe ([Id]
>   , RemoteHValue {- IO [HValue] -}
>   , FixityEnv))
>
> RemoteHValue is a reference to a value in the interpreter's context. These
> have to be evaluated via an explicit API, rather than just unsafeCoercing
> HValue as we do now.  (this is not strictly speaking part of the GHC API,
> so a separate but interesting question is: why did you need to use this
> directly, and what should we add to the GHC API?)
>
> I believe that many uses of dynCompileExpr can be changed so that the code
> using the resulting value is moved into the interpreter's context, and then
> there's no problem.
>
> This is quite crucial for some of the interactive
>> functionality. Imagine a game where the game engine is in Swift
>> linked into the main application and the game logic is in
>> *interpreted* Haskell code. The engine calls into the Haskell code
>> multiple times per frame of the animation and for all
>> keyboard/mouse/etc input (using StablePtr and ForeignPtr to construct
>> the scene graph across the Swift and Haskell heap).
>>
>
> So my question is, why wouldn't you run the whole game engine in the
> interpreter's context?  That's what would happen if you were to load the
> program into GHCi and run it.  Directly calling back and forth between the
> client of the GHC API and the program being interpreted is arguably a
> strange thing to do, and it's kind of accidental that we allow it.
>
> I actually also might have a use for the architecture that you are
>> proposing. However, I really would like to keep the ability to, at
>> least, optionally run interpreted code in the same process (without
>> profiling etc). Do you think we could have both?
>>
>
> We can certainly have both, it's straightforward to implement, but I don't
> get to throw away some of the hacks we have to support same-process
> execution, which would be a shame.  We just add more code rather than
>
>
> Cheers,
>> Manuel
>>
>> Simon Marlow :
>>>
>>> Hi folks - I've been thinking about changing the way we run interpreted
>>> code so that it would be run in a separate process.  It turns out this has
>>> quite a few benefits, and would let us kill some of the really awkward
>>> hacks we have in GHC to work around problems that arise because we're
>>> running interpreted code and the compiler on the same runtime.
>>>
>>> I summarised the idea here:
>>> https://ghc.haskell.org/trac/ghc/wiki/RemoteGHCi
>>>
>>> I'd be interested to hear if anyone has any thoughts around this,
>>> particularly if doing this would make your life difficult in some way. Are
>>> people relying on dynCompileExpr for anything?
>>>
>>> Cheers,
>>> Simon
>>> 

Re: Explanation of a core-lint warning (Bad getNth)

[Jan Bracker]

As far as I understand your explanation this should not lead to an error,
although it is not the most obvious coercion. Is that right?

Do you or anybody else have a suggestion on how to resolve this issue?

2015-11-18 17:13 GMT+00:00 Richard Eisenberg :

> Ah yes. I looked too quickly. Note that there are two NthCo's listed. Its
> the outermost that's the problem, which is deconstructing the Union. But
> it's doing so to prove that '["thres" :-> Int] ~ '["thres" :-> Int] which
> is rather easy to prove without NthCo. I'm not sure why GHC is doing this.
>
> Richard
>
> On Nov 18, 2015, at 12:11 PM, Jan Bracker 
> wrote:
>
> Hi Richard,
>
> No "Split" is a class and is defined here:
> http://hackage.haskell.org/package/effect-monad-0.6.1/docs/Control-Effect-State.html#t:Split
> "Union" is a type function (synonym that refers to a type function call):
> http://hackage.haskell.org/package/effect-monad-0.6.1/docs/Control-Effect-Writer.html#t:Union
>
> thank you for your quick reply!
>
> Best,
> Jan
>
> 2015-11-18 17:05 GMT+00:00 Richard Eisenberg :
>
>> I took just a quick look at this. Is Split a type family? The NthCo
>> coercion form takes apart a composite equality into its pieces. For
>> example, if we know (Maybe a ~ Maybe b), then NthCo:0 will tell us that (a
>> ~ b). In your case, it looks like GHC is trying to deduce (Union '["thres"
>> :-> Int] []) ~ (Union '["thres" :-> Int] (Unit Reader)) from an equality of
>> two (Split ...) types. If Split is a type family, this deduction is
>> unsound. That may be what Core Lint is worried about.
>>
>> I'm not surprised that the executable would run with an error. But it
>> might not in the future. If -dcore-lint fails, it means that there is a
>> potential type safety issue in the Core code, and this should be taken
>> seriously.
>>
>> I hope this helps!
>> Richard
>>
>> On Nov 18, 2015, at 11:35 AM, Jan Bracker 
>> wrote:
>>
>> Hi,
>>
>> I am using the type checker plugin interface and I am trying to produce
>> some evidence for type class instances. During compilation of one of my
>> examples I get this core-lint error:
>>
>> *** Core Lint errors : in result of Simplifier ***
>> : Warning:
>> [RHS of ds_a6bY :: (Set '["thres" :-> Int], Set (Unit Reader))]
>> Bad getNth:
>>   Nth:0
>> (Nth:2
>>(Sub (Sym (TFCo:R:Inv[]Readerfg[0] <'["thres" :-> Int]>_N
>> <'[]>_N))
>> ; (Inv
>>  _N <'["thres" :-> Int]>_N (Sym
>> TFCo:R:Unit[]Reader[0]))_R
>> ; Sub
>> (TFCo:R:Inv[]Readerfg[0] <'["thres" :-> Int]>_N > Reader>_N)))
>>   Split '["thres" :-> Int] '[] (Union '["thres" :-> Int] '[])
>>   Split
>> '["thres" :-> Int]
>> (Unit Reader)
>> (Union '["thres" :-> Int] (Unit Reader))
>>
>> I suppose "getNth" refers to the constructor "EvTupleSel" from "EvTerm",
>> "TcNthCo" from "TcCoercion" or to "NthCo" from "Coercion". But I never
>> produce evidence of the shape "getNth".  My evidence production code can be
>> found at [1] and the only place where evidence of this shape can come
>> from is my "evaluateType" function [2] that calls "normaliseType" from the
>> GHC module "FamInstEnv". You can reproduce the error by checking out
>> commit 144525886ec107af6f1283b26b19f8125c980aa4 from [3] and running "make
>> effect-example" in the top directory of the repository (GHC 7.10 or better
>> is required and a sandbox is automatically created).
>>
>> The core-lint error does not seem to have any negative consequences when
>> ignored. The produced executable works fine. Can somebody explain why it
>> appears and maybe how I can fix it?
>>
>> Thank you!
>> Jan
>>
>> [1]
>> https://github.com/jbracker/polymonad-plugin/blob/144525886ec107af6f1283b26b19f8125c980aa4/src/Control/Polymonad/Plugin/Evidence.hs#L177
>> [2]
>> https://github.com/jbracker/polymonad-plugin/blob/144525886ec107af6f1283b26b19f8125c980aa4/src/Control/Polymonad/Plugin/Evaluate.hs#L29
>> [3] https://github.com/jbracker/polymonad-plugin
>> ___
>> 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: Explanation of a core-lint warning (Bad getNth)

[Richard Eisenberg]

On Nov 18, 2015, at 12:19 PM, Jan Bracker  wrote:

> As far as I understand your explanation this should not lead to an error, 
> although it is not the most obvious coercion. Is that right?

That's what it seems to be, in this particular case. But I'd be nervous with 
this result and would want further examination. My next port of call in your 
shoes would be to run with -ddump-tc-trace. I'm afraid I don't have the time 
right now to walk through that with you, though -- sorry!

Richard

> 
> Do you or anybody else have a suggestion on how to resolve this issue?
> 
> 2015-11-18 17:13 GMT+00:00 Richard Eisenberg :
> Ah yes. I looked too quickly. Note that there are two NthCo's listed. Its the 
> outermost that's the problem, which is deconstructing the Union. But it's 
> doing so to prove that '["thres" :-> Int] ~ '["thres" :-> Int] which is 
> rather easy to prove without NthCo. I'm not sure why GHC is doing this.
> 
> Richard
> 
> On Nov 18, 2015, at 12:11 PM, Jan Bracker  wrote:
> 
>> Hi Richard,
>> 
>> No "Split" is a class and is defined here: 
>> http://hackage.haskell.org/package/effect-monad-0.6.1/docs/Control-Effect-State.html#t:Split
>> "Union" is a type function (synonym that refers to a type function call): 
>> http://hackage.haskell.org/package/effect-monad-0.6.1/docs/Control-Effect-Writer.html#t:Union
>> 
>> thank you for your quick reply!
>> 
>> Best,
>> Jan
>> 
>> 2015-11-18 17:05 GMT+00:00 Richard Eisenberg :
>> I took just a quick look at this. Is Split a type family? The NthCo coercion 
>> form takes apart a composite equality into its pieces. For example, if we 
>> know (Maybe a ~ Maybe b), then NthCo:0 will tell us that (a ~ b). In your 
>> case, it looks like GHC is trying to deduce (Union '["thres" :-> Int] []) ~ 
>> (Union '["thres" :-> Int] (Unit Reader)) from an equality of two (Split ...) 
>> types. If Split is a type family, this deduction is unsound. That may be 
>> what Core Lint is worried about.
>> 
>> I'm not surprised that the executable would run with an error. But it might 
>> not in the future. If -dcore-lint fails, it means that there is a potential 
>> type safety issue in the Core code, and this should be taken seriously.
>> 
>> I hope this helps!
>> Richard
>> 
>> On Nov 18, 2015, at 11:35 AM, Jan Bracker  wrote:
>> 
>>> Hi,
>>> 
>>> I am using the type checker plugin interface and I am trying to produce 
>>> some evidence for type class instances. During compilation of one of my 
>>> examples I get this core-lint error:
>>> 
>>> *** Core Lint errors : in result of Simplifier ***
>>> : Warning:
>>> [RHS of ds_a6bY :: (Set '["thres" :-> Int], Set (Unit Reader))]
>>> Bad getNth:
>>>   Nth:0
>>> (Nth:2
>>>(Sub (Sym (TFCo:R:Inv[]Readerfg[0] <'["thres" :-> Int]>_N 
>>> <'[]>_N))
>>> ; (Inv
>>>  _N <'["thres" :-> Int]>_N (Sym 
>>> TFCo:R:Unit[]Reader[0]))_R
>>> ; Sub
>>> (TFCo:R:Inv[]Readerfg[0] <'["thres" :-> Int]>_N >> Reader>_N)))
>>>   Split '["thres" :-> Int] '[] (Union '["thres" :-> Int] '[])
>>>   Split
>>> '["thres" :-> Int]
>>> (Unit Reader)
>>> (Union '["thres" :-> Int] (Unit Reader))
>>> 
>>> I suppose "getNth" refers to the constructor "EvTupleSel" from "EvTerm", 
>>> "TcNthCo" from "TcCoercion" or to "NthCo" from "Coercion". But I never 
>>> produce evidence of the shape "getNth".  My evidence production code can be 
>>> found at [1] and the only place where evidence of this shape can come from 
>>> is my "evaluateType" function [2] that calls "normaliseType" from the GHC 
>>> module "FamInstEnv". You can reproduce the error by checking out commit 
>>> 144525886ec107af6f1283b26b19f8125c980aa4 from [3] and running "make 
>>> effect-example" in the top directory of the repository (GHC 7.10 or better 
>>> is required and a sandbox is automatically created).
>>> 
>>> The core-lint error does not seem to have any negative consequences when 
>>> ignored. The produced executable works fine. Can somebody explain why it 
>>> appears and maybe how I can fix it?
>>> 
>>> Thank you!
>>> Jan
>>> 
>>> [1] 
>>> https://github.com/jbracker/polymonad-plugin/blob/144525886ec107af6f1283b26b19f8125c980aa4/src/Control/Polymonad/Plugin/Evidence.hs#L177
>>> [2] 
>>> https://github.com/jbracker/polymonad-plugin/blob/144525886ec107af6f1283b26b19f8125c980aa4/src/Control/Polymonad/Plugin/Evaluate.hs#L29
>>> [3] https://github.com/jbracker/polymonad-plugin
>>> ___
>>> 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: Explanation of a core-lint warning (Bad getNth)

[Richard Eisenberg]

Ah yes. I looked too quickly. Note that there are two NthCo's listed. Its the 
outermost that's the problem, which is deconstructing the Union. But it's doing 
so to prove that '["thres" :-> Int] ~ '["thres" :-> Int] which is rather easy 
to prove without NthCo. I'm not sure why GHC is doing this.

Richard

On Nov 18, 2015, at 12:11 PM, Jan Bracker  wrote:

> Hi Richard,
> 
> No "Split" is a class and is defined here: 
> http://hackage.haskell.org/package/effect-monad-0.6.1/docs/Control-Effect-State.html#t:Split
> "Union" is a type function (synonym that refers to a type function call): 
> http://hackage.haskell.org/package/effect-monad-0.6.1/docs/Control-Effect-Writer.html#t:Union
> 
> thank you for your quick reply!
> 
> Best,
> Jan
> 
> 2015-11-18 17:05 GMT+00:00 Richard Eisenberg :
> I took just a quick look at this. Is Split a type family? The NthCo coercion 
> form takes apart a composite equality into its pieces. For example, if we 
> know (Maybe a ~ Maybe b), then NthCo:0 will tell us that (a ~ b). In your 
> case, it looks like GHC is trying to deduce (Union '["thres" :-> Int] []) ~ 
> (Union '["thres" :-> Int] (Unit Reader)) from an equality of two (Split ...) 
> types. If Split is a type family, this deduction is unsound. That may be what 
> Core Lint is worried about.
> 
> I'm not surprised that the executable would run with an error. But it might 
> not in the future. If -dcore-lint fails, it means that there is a potential 
> type safety issue in the Core code, and this should be taken seriously.
> 
> I hope this helps!
> Richard
> 
> On Nov 18, 2015, at 11:35 AM, Jan Bracker  wrote:
> 
>> Hi,
>> 
>> I am using the type checker plugin interface and I am trying to produce some 
>> evidence for type class instances. During compilation of one of my examples 
>> I get this core-lint error:
>> 
>> *** Core Lint errors : in result of Simplifier ***
>> : Warning:
>> [RHS of ds_a6bY :: (Set '["thres" :-> Int], Set (Unit Reader))]
>> Bad getNth:
>>   Nth:0
>> (Nth:2
>>(Sub (Sym (TFCo:R:Inv[]Readerfg[0] <'["thres" :-> Int]>_N 
>> <'[]>_N))
>> ; (Inv
>>  _N <'["thres" :-> Int]>_N (Sym 
>> TFCo:R:Unit[]Reader[0]))_R
>> ; Sub
>> (TFCo:R:Inv[]Readerfg[0] <'["thres" :-> Int]>_N > Reader>_N)))
>>   Split '["thres" :-> Int] '[] (Union '["thres" :-> Int] '[])
>>   Split
>> '["thres" :-> Int]
>> (Unit Reader)
>> (Union '["thres" :-> Int] (Unit Reader))
>> 
>> I suppose "getNth" refers to the constructor "EvTupleSel" from "EvTerm", 
>> "TcNthCo" from "TcCoercion" or to "NthCo" from "Coercion". But I never 
>> produce evidence of the shape "getNth".  My evidence production code can be 
>> found at [1] and the only place where evidence of this shape can come from 
>> is my "evaluateType" function [2] that calls "normaliseType" from the GHC 
>> module "FamInstEnv". You can reproduce the error by checking out commit 
>> 144525886ec107af6f1283b26b19f8125c980aa4 from [3] and running "make 
>> effect-example" in the top directory of the repository (GHC 7.10 or better 
>> is required and a sandbox is automatically created).
>> 
>> The core-lint error does not seem to have any negative consequences when 
>> ignored. The produced executable works fine. Can somebody explain why it 
>> appears and maybe how I can fix it?
>> 
>> Thank you!
>> Jan
>> 
>> [1] 
>> https://github.com/jbracker/polymonad-plugin/blob/144525886ec107af6f1283b26b19f8125c980aa4/src/Control/Polymonad/Plugin/Evidence.hs#L177
>> [2] 
>> https://github.com/jbracker/polymonad-plugin/blob/144525886ec107af6f1283b26b19f8125c980aa4/src/Control/Polymonad/Plugin/Evaluate.hs#L29
>> [3] https://github.com/jbracker/polymonad-plugin
>> ___
>> 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: Explanation of a core-lint warning (Bad getNth)

[Richard Eisenberg]

I took just a quick look at this. Is Split a type family? The NthCo coercion 
form takes apart a composite equality into its pieces. For example, if we know 
(Maybe a ~ Maybe b), then NthCo:0 will tell us that (a ~ b). In your case, it 
looks like GHC is trying to deduce (Union '["thres" :-> Int] []) ~ (Union 
'["thres" :-> Int] (Unit Reader)) from an equality of two (Split ...) types. If 
Split is a type family, this deduction is unsound. That may be what Core Lint 
is worried about.

I'm not surprised that the executable would run with an error. But it might not 
in the future. If -dcore-lint fails, it means that there is a potential type 
safety issue in the Core code, and this should be taken seriously.

I hope this helps!
Richard

On Nov 18, 2015, at 11:35 AM, Jan Bracker  wrote:

> Hi,
> 
> I am using the type checker plugin interface and I am trying to produce some 
> evidence for type class instances. During compilation of one of my examples I 
> get this core-lint error:
> 
> *** Core Lint errors : in result of Simplifier ***
> : Warning:
> [RHS of ds_a6bY :: (Set '["thres" :-> Int], Set (Unit Reader))]
> Bad getNth:
>   Nth:0
> (Nth:2
>(Sub (Sym (TFCo:R:Inv[]Readerfg[0] <'["thres" :-> Int]>_N <'[]>_N))
> ; (Inv
>  _N <'["thres" :-> Int]>_N (Sym 
> TFCo:R:Unit[]Reader[0]))_R
> ; Sub
> (TFCo:R:Inv[]Readerfg[0] <'["thres" :-> Int]>_N  Reader>_N)))
>   Split '["thres" :-> Int] '[] (Union '["thres" :-> Int] '[])
>   Split
> '["thres" :-> Int]
> (Unit Reader)
> (Union '["thres" :-> Int] (Unit Reader))
> 
> I suppose "getNth" refers to the constructor "EvTupleSel" from "EvTerm", 
> "TcNthCo" from "TcCoercion" or to "NthCo" from "Coercion". But I never 
> produce evidence of the shape "getNth".  My evidence production code can be 
> found at [1] and the only place where evidence of this shape can come from is 
> my "evaluateType" function [2] that calls "normaliseType" from the GHC module 
> "FamInstEnv". You can reproduce the error by checking out commit 
> 144525886ec107af6f1283b26b19f8125c980aa4 from [3] and running "make 
> effect-example" in the top directory of the repository (GHC 7.10 or better is 
> required and a sandbox is automatically created).
> 
> The core-lint error does not seem to have any negative consequences when 
> ignored. The produced executable works fine. Can somebody explain why it 
> appears and maybe how I can fix it?
> 
> Thank you!
> Jan
> 
> [1] 
> https://github.com/jbracker/polymonad-plugin/blob/144525886ec107af6f1283b26b19f8125c980aa4/src/Control/Polymonad/Plugin/Evidence.hs#L177
> [2] 
> https://github.com/jbracker/polymonad-plugin/blob/144525886ec107af6f1283b26b19f8125c980aa4/src/Control/Polymonad/Plugin/Evaluate.hs#L29
> [3] https://github.com/jbracker/polymonad-plugin
> ___
> 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: Explanation of a core-lint warning (Bad getNth)

[Jan Bracker]

Hi Richard,

No "Split" is a class and is defined here:
http://hackage.haskell.org/package/effect-monad-0.6.1/docs/Control-Effect-State.html#t:Split
"Union" is a type function (synonym that refers to a type function call):
http://hackage.haskell.org/package/effect-monad-0.6.1/docs/Control-Effect-Writer.html#t:Union

thank you for your quick reply!

Best,
Jan

2015-11-18 17:05 GMT+00:00 Richard Eisenberg :

> I took just a quick look at this. Is Split a type family? The NthCo
> coercion form takes apart a composite equality into its pieces. For
> example, if we know (Maybe a ~ Maybe b), then NthCo:0 will tell us that (a
> ~ b). In your case, it looks like GHC is trying to deduce (Union '["thres"
> :-> Int] []) ~ (Union '["thres" :-> Int] (Unit Reader)) from an equality of
> two (Split ...) types. If Split is a type family, this deduction is
> unsound. That may be what Core Lint is worried about.
>
> I'm not surprised that the executable would run with an error. But it
> might not in the future. If -dcore-lint fails, it means that there is a
> potential type safety issue in the Core code, and this should be taken
> seriously.
>
> I hope this helps!
> Richard
>
> On Nov 18, 2015, at 11:35 AM, Jan Bracker 
> wrote:
>
> Hi,
>
> I am using the type checker plugin interface and I am trying to produce
> some evidence for type class instances. During compilation of one of my
> examples I get this core-lint error:
>
> *** Core Lint errors : in result of Simplifier ***
> : Warning:
> [RHS of ds_a6bY :: (Set '["thres" :-> Int], Set (Unit Reader))]
> Bad getNth:
>   Nth:0
> (Nth:2
>(Sub (Sym (TFCo:R:Inv[]Readerfg[0] <'["thres" :-> Int]>_N
> <'[]>_N))
> ; (Inv
>  _N <'["thres" :-> Int]>_N (Sym
> TFCo:R:Unit[]Reader[0]))_R
> ; Sub
> (TFCo:R:Inv[]Readerfg[0] <'["thres" :-> Int]>_N  Reader>_N)))
>   Split '["thres" :-> Int] '[] (Union '["thres" :-> Int] '[])
>   Split
> '["thres" :-> Int]
> (Unit Reader)
> (Union '["thres" :-> Int] (Unit Reader))
>
> I suppose "getNth" refers to the constructor "EvTupleSel" from "EvTerm",
> "TcNthCo" from "TcCoercion" or to "NthCo" from "Coercion". But I never
> produce evidence of the shape "getNth".  My evidence production code can be
> found at [1] and the only place where evidence of this shape can come
> from is my "evaluateType" function [2] that calls "normaliseType" from the
> GHC module "FamInstEnv". You can reproduce the error by checking out
> commit 144525886ec107af6f1283b26b19f8125c980aa4 from [3] and running "make
> effect-example" in the top directory of the repository (GHC 7.10 or better
> is required and a sandbox is automatically created).
>
> The core-lint error does not seem to have any negative consequences when
> ignored. The produced executable works fine. Can somebody explain why it
> appears and maybe how I can fix it?
>
> Thank you!
> Jan
>
> [1]
> https://github.com/jbracker/polymonad-plugin/blob/144525886ec107af6f1283b26b19f8125c980aa4/src/Control/Polymonad/Plugin/Evidence.hs#L177
> [2]
> https://github.com/jbracker/polymonad-plugin/blob/144525886ec107af6f1283b26b19f8125c980aa4/src/Control/Polymonad/Plugin/Evaluate.hs#L29
> [3] https://github.com/jbracker/polymonad-plugin
> ___
> 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

Explanation of a core-lint warning (Bad getNth)

[Jan Bracker]

Hi,

I am using the type checker plugin interface and I am trying to produce
some evidence for type class instances. During compilation of one of my
examples I get this core-lint error:

*** Core Lint errors : in result of Simplifier ***
: Warning:
[RHS of ds_a6bY :: (Set '["thres" :-> Int], Set (Unit Reader))]
Bad getNth:
  Nth:0
(Nth:2
   (Sub (Sym (TFCo:R:Inv[]Readerfg[0] <'["thres" :-> Int]>_N
<'[]>_N))
; (Inv
 _N <'["thres" :-> Int]>_N (Sym
TFCo:R:Unit[]Reader[0]))_R
; Sub
(TFCo:R:Inv[]Readerfg[0] <'["thres" :-> Int]>_N _N)))
  Split '["thres" :-> Int] '[] (Union '["thres" :-> Int] '[])
  Split
'["thres" :-> Int]
(Unit Reader)
(Union '["thres" :-> Int] (Unit Reader))

I suppose "getNth" refers to the constructor "EvTupleSel" from "EvTerm",
"TcNthCo" from "TcCoercion" or to "NthCo" from "Coercion". But I never
produce evidence of the shape "getNth".  My evidence production code can be
found at [1] and the only place where evidence of this shape can come
from is my "evaluateType" function [2] that calls "normaliseType" from the
GHC module "FamInstEnv". You can reproduce the error by checking out
commit 144525886ec107af6f1283b26b19f8125c980aa4 from [3] and running "make
effect-example" in the top directory of the repository (GHC 7.10 or better
is required and a sandbox is automatically created).

The core-lint error does not seem to have any negative consequences when
ignored. The produced executable works fine. Can somebody explain why it
appears and maybe how I can fix it?

Thank you!
Jan

[1]
https://github.com/jbracker/polymonad-plugin/blob/144525886ec107af6f1283b26b19f8125c980aa4/src/Control/Polymonad/Plugin/Evidence.hs#L177
[2]
https://github.com/jbracker/polymonad-plugin/blob/144525886ec107af6f1283b26b19f8125c980aa4/src/Control/Polymonad/Plugin/Evaluate.hs#L29
[3] https://github.com/jbracker/polymonad-plugin
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

RE: [commit: ghc] master: Remove PatSynBuilderId (2208011)

[Simon Peyton Jones]

Done!

|  -Original Message-
|  From: Ben Gamari [mailto:b...@well-typed.com]
|  Sent: 17 November 2015 16:41
|  To: Simon Peyton Jones; Matthew Pickering
|  Cc: ghc-devs@haskell.org
|  Subject: RE: [commit: ghc] master: Remove PatSynBuilderId (2208011)
|  
|  Simon Peyton Jones  writes:
|  
|  > |  I don't think this would work in the case where there are no fields
|  > | initialised?
|  >
|  > Oh yes, silly me. I was thinking that then we wouldn’t need to look at
|  > 'labels' at all, but that's not true.
|  >
|  > Well, at least then I'd replace [PostTc id [FieldLabel] with (PostTc
|  > ConLike). This makes it like ConPatOut in HsPat. Then the (Located id)
|  > field is redundant (we can get it from the ConLike), but that’s only
|  > true after typechecking, so maybe simpler to keep both.
|  >
|  > It amounts to moving the call to conLikeFieldLabels from tcExpr
|  > (RecordCon ...) to dsExpr (RecordCon ...). A small thing but I think
|  > it'd be better.
|  >
|  Mathew, did you ever get to this?
|  
|  Cheers,
|  
|  - Ben
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Wildcard refactor

[Simon Peyton Jones]

Alan
I'm really close on wip/spj-wildcard-refactor, that I really want to get into 
HEAD asap.
Could you possibly checkout wip/spj-wildcard-refactor, and validate?  I get two 
failures I don't understand:
   ghc-api/annotations  listcomps [bad stdout] (normal)
   ghc-api/landmineslandmines [bad stderr] (normal)
The output is not wildly different but I just don't know how to interpret it, 
so I don't even know what the problem is exactly.
NB: you''ll need to do a 'git submodule update' because the haddock submodule 
changes.
Thank you!
Simon

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

Re: Window build broken

[Matej Borovec]

I'm getting similar error on my 32-bit Windows 10:

GHCi, version 7.11.20151114: http://www.haskell.org/ghc/  :? for help
ghc.exe: C:\ghc-8.0_git\usr\local\lib\ghc-prim-0.5.0.0\HSghc-prim-0.5.0.0.o: 
Not x86 PEi386
ghc.exe: panic! (the 'impossible' happened)
(GHC version 7.11.20151114 for i386-unknown-mingw32):
  loadObj 
"C:\\ghc-8.0_git\\usr\\local\\lib\\ghc-prim-0.5.0.0\\HSghc-prim-0.5.0.0.o": 
failed

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

And running `file lib\ghc-prim-0.5.0.0\HSghc-prim-0.5.0.0.o` I get:

lib\ghc-prim-0.5.0.0\HSghc-prim-0.5.0.0.o: PE Unknown PE signature 0x342f Intel 
80386 (stripped to external PDB), for MS Windows


-Original Message- 
From: Simon Peyton Jones 
Sent: Wednesday, November 18, 2015 12:25 AM 
To: David Macek ; ghc-devs@haskell.org 
Subject: RE: Window build broken 

It says this:

bash$ file libraries/ghc-prim/dist-install/build/HSghc-prim-0.5.0.0.o 
libraries/ghc-prim/dist-install/build/HSghc-prim-0.5.0.0.o: PE Unknown PE 
signature 0x742e x86-64 (stripped to external PDB), for MS Windows

| -Original Message-
| From: David Macek [mailto:david.mace...@gmail.com]
| Sent: 17 November 2015 22:45
| To: Simon Peyton Jones ; ghc-devs@haskell.org
| Subject: Re: Window build broken
| 
| On 17. 11. 2015 23:31, Simon Peyton Jones wrote:
| > Sigh.  My Windows build is broken.  See below.  Any ideas?  The stage2
| complier in non-interactive mode works ok. It’s just ghci fails.  What does
| “Not x86_64 PEi386” mean?  What can I do to fix?
| 
| Maybe it's obvious and you already checked, but could it be that the object
| file is for a different architecture? What does `file` say about it?
| 
| --
| David Macek

___
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: Wildcard refactor

[Simon Peyton Jones]

It does, yes. It’s on 0d157fe, which is the head of wip/spj-wildcard-refactor 
in the haddock repo
Is that what get checked out by ‘git submodule update”?

Simon

From: Alan & Kim Zimmerman [mailto:alan.z...@gmail.com]
Sent: 18 November 2015 10:57
To: Simon Peyton Jones
Subject: Re: Wildcard refactor

I found the haddock library did not compile, but I am skipping straight to the 
tests.
Does it compile for you at the moment?

On Wed, Nov 18, 2015 at 12:51 PM, Simon Peyton Jones 
> wrote:
Thank you!

From: Alan & Kim Zimmerman 
[mailto:alan.z...@gmail.com]
Sent: 18 November 2015 10:04
To: Simon Peyton Jones
Cc: ghc-devs@haskell.org
Subject: Re: Wildcard refactor

ok.
I have been waiting to jump in and help.
Alan

On Wed, Nov 18, 2015 at 12:02 PM, Simon Peyton Jones 
> wrote:
Alan
I’m really close on wip/spj-wildcard-refactor, that I really want to get into 
HEAD asap.
Could you possibly checkout wip/spj-wildcard-refactor, and validate?  I get two 
failures I don’t understand:
   ghc-api/annotations  listcomps [bad stdout] (normal)
   ghc-api/landmineslandmines [bad stderr] (normal)
The output is not wildly different but I just don’t know how to interpret it, 
so I don’t even know what the problem is exactly.
NB: you’’ll need to do a ‘git submodule update’ because the haddock submodule 
changes.
Thank you!
Simon



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

RE: Wildcard refactor

[Simon Peyton Jones]

Oh sorry, no I think I’d been skipping it too.  I’ll fix that!  Meanwhile, skip!

From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of Simon Peyton 
Jones
Sent: 18 November 2015 11:18
To: Alan & Kim Zimmerman
Cc: ghc-devs@haskell.org
Subject: RE: Wildcard refactor

It does, yes. It’s on 0d157fe, which is the head of wip/spj-wildcard-refactor 
in the haddock repo
Is that what get checked out by ‘git submodule update”?

Simon

From: Alan & Kim Zimmerman [mailto:alan.z...@gmail.com]
Sent: 18 November 2015 10:57
To: Simon Peyton Jones
Subject: Re: Wildcard refactor

I found the haddock library did not compile, but I am skipping straight to the 
tests.
Does it compile for you at the moment?

On Wed, Nov 18, 2015 at 12:51 PM, Simon Peyton Jones 
> wrote:
Thank you!

From: Alan & Kim Zimmerman 
[mailto:alan.z...@gmail.com]
Sent: 18 November 2015 10:04
To: Simon Peyton Jones
Cc: ghc-devs@haskell.org
Subject: Re: Wildcard refactor

ok.
I have been waiting to jump in and help.
Alan

On Wed, Nov 18, 2015 at 12:02 PM, Simon Peyton Jones 
> wrote:
Alan
I’m really close on wip/spj-wildcard-refactor, that I really want to get into 
HEAD asap.
Could you possibly checkout wip/spj-wildcard-refactor, and validate?  I get two 
failures I don’t understand:
   ghc-api/annotations  listcomps [bad stdout] (normal)
   ghc-api/landmineslandmines [bad stderr] (normal)
The output is not wildly different but I just don’t know how to interpret it, 
so I don’t even know what the problem is exactly.
NB: you’’ll need to do a ‘git submodule update’ because the haddock submodule 
changes.
Thank you!
Simon



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

Re: Wildcard refactor

[Alan & Kim Zimmerman]

This is what I get locally

unexpected results from:
TEST="landmines listcomps T7861 T5837 T4896 T3064"

OVERALL SUMMARY for test run started at Wed Nov 18 10:48:00 2015 UTC
 0:27:16 spent to go through
4802 total tests, which gave rise to
   18143 test cases, of which
   13285 were skipped

  77 had missing libraries
4667 expected passes
 108 expected failures

   0 caused framework failures
   0 unexpected passes
   5 unexpected failures
   1 unexpected stat failures

Unexpected failures:
   deriving/should_compile  T4896 [exit code non-0] (normal)
   ghc-api/annotations  listcomps [bad stdout] (normal)
   ghc-api/landmineslandmines [bad stderr] (normal)
   perf/compilerT5837 [stderr mismatch] (normal)
   typecheck/should_run T7861 [bad stderr] (normal)

Unexpected stat failures:
   perf/compiler  T3064 [stat not good enough] (normal)



I will look into the two ghc-api ones.


On Wed, Nov 18, 2015 at 1:19 PM, Simon Peyton Jones 
wrote:

> Oh sorry, no I think I’d been skipping it too.  I’ll fix that!  Meanwhile,
> skip!
>
>
>
> *From:* ghc-devs [mailto:ghc-devs-boun...@haskell.org] *On Behalf Of *Simon
> Peyton Jones
> *Sent:* 18 November 2015 11:18
> *To:* Alan & Kim Zimmerman
> *Cc:* ghc-devs@haskell.org
> *Subject:* RE: Wildcard refactor
>
>
>
> It does, yes. It’s on 0d157fe, which is the head of
> wip/spj-wildcard-refactor in the haddock repo
>
> Is that what get checked out by ‘git submodule update”?
>
>
>
> Simon
>
>
>
> *From:* Alan & Kim Zimmerman [mailto:alan.z...@gmail.com
> ]
> *Sent:* 18 November 2015 10:57
> *To:* Simon Peyton Jones
> *Subject:* Re: Wildcard refactor
>
>
>
> I found the haddock library did not compile, but I am skipping straight to
> the tests.
>
> Does it compile for you at the moment?
>
>
>
> On Wed, Nov 18, 2015 at 12:51 PM, Simon Peyton Jones <
> simo...@microsoft.com> wrote:
>
> Thank you!
>
>
>
> *From:* Alan & Kim Zimmerman [mailto:alan.z...@gmail.com]
> *Sent:* 18 November 2015 10:04
> *To:* Simon Peyton Jones
> *Cc:* ghc-devs@haskell.org
> *Subject:* Re: Wildcard refactor
>
>
>
> ok.
>
> I have been waiting to jump in and help.
>
> Alan
>
>
>
> On Wed, Nov 18, 2015 at 12:02 PM, Simon Peyton Jones <
> simo...@microsoft.com> wrote:
>
> Alan
>
> I’m really close on wip/spj-wildcard-refactor, that I really want to get
> into HEAD asap.
>
> Could you possibly checkout wip/spj-wildcard-refactor, and validate?  I
> get two failures I don’t understand:
>
>ghc-api/annotations  listcomps [bad stdout] (normal)
>
>ghc-api/landmineslandmines [bad stderr] (normal)
>
> The output is not wildly different but I just don’t know how to interpret
> it, so I don’t even know what the problem is exactly.
>
> NB: you’’ll need to do a ‘git submodule update’ because the haddock
> submodule changes.
>
> Thank you!
>
> Simon
>
>
>
>
>
>
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Feature status for GHC 8.0

[Ben Gamari]

"Edward Z. Yang"  writes:

> Excerpts from Ben Gamari's message of 2015-11-17 07:22:22 -0800:
>>  * Backpack workEdward Z. Yang
>>   How is this coming along?
>
> Had a chat with SPJ about this and we've decided that Backpack still
> needs stabilizing, and there is not much gain to be had shipping it
> until it is very nearly done, so we are not going to be targeting
> this patch for GHC 8.0
>
Sounds good; that is consistent with my own discussions with Simon on
this matter.

What about the compacts work? I know that Simon Marlow has some
questions about the implementation.

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: Window build broken

[Tamar Christina]

Hmm,

Presumably Simon didn't change this. Maybe the msys2 install is broken?

TamarFrom: David Macek
Sent: ‎18/‎11/‎2015 09:35
To: Simon Peyton Jones; loneti...@gmail.com; ghc-devs@haskell.org
Subject: Re: Window build broken
On 18. 11. 2015 9:29, Simon Peyton Jones wrote:
> It’s msys2.  I don’t have Cygwin on this machine.  I have no idea where that 
> prompt comes from, but I agree it’s suspicious.

Looks like your /etc/fstab is wrong. There should be a line like this
one, that removes the `cygdrive` prefix from Windows drive/letter
mounts:

none / cygdrive binary,posix=0,noacl,user 0 0

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

Re: Wildcard refactor

[Alan & Kim Zimmerman]

ok.

I have been waiting to jump in and help.

Alan

On Wed, Nov 18, 2015 at 12:02 PM, Simon Peyton Jones 
wrote:

> Alan
>
> I’m really close on wip/spj-wildcard-refactor, that I really want to get
> into HEAD asap.
>
> Could you possibly checkout wip/spj-wildcard-refactor, and validate?  I
> get two failures I don’t understand:
>
>ghc-api/annotations  listcomps [bad stdout] (normal)
>
>ghc-api/landmineslandmines [bad stderr] (normal)
>
> The output is not wildly different but I just don’t know how to interpret
> it, so I don’t even know what the problem is exactly.
>
> NB: you’’ll need to do a ‘git submodule update’ because the haddock
> submodule changes.
>
> Thank you!
>
> Simon
>
>
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

RE: Window build broken

[Simon Peyton Jones]

I’m happy to do experiments to help narrow it down, but I haven’t the foggiest 
idea where to start, and am utterly stalled on GHC

Thanks

Simon

From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of 
loneti...@gmail.com
Sent: 17 November 2015 23:51
To: Ryan Scott; ghc-devs@haskell.org
Subject: RE: Window build broken

Well the error is correct, it’s just checking against the machine type in the 
PE spec:

IMAGE_FILE_MACHINE_AMD64

0x8664

x64


So somewhere along the line an invalid PE file was generated (or for the wrong 
architecture).

From: Ryan Scott
Sent: Wednesday, November 18, 2015 00:44
To: ghc-devs@haskell.org
Subject: Re: Window build broken


Wow, I happened to try building GHC on Windows for the first time ever
today, and I also experienced this error :)

Interestingly, someone reported a very similar error to this on Trac,
but for GHC 7.8.3 [1]. Here's where the error message comes from [2]
in Linker.c:

static int verifyCOFFHeader
(COFF_header *hdr, pathchar *fileName)
{
  if (hdr->Machine != 0x8664) {
errorBelch("%" PATH_FMT ": Not x86_64 PEi386", fileName);
return 0;
  }
  ...
}

Ryan S.
-
[1] https://ghc.haskell.org/trac/ghc/ticket/10437
[2] 
https://github.com/ghc/ghc/blob/233d1312bf15940fca5feca6884f965e7944b555/rts/Linker.c#L3355
___
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: Remote GHCi

[Simon Marlow]

On 18/11/2015 00:53, Edward Z. Yang wrote:

I like it.

Let me make sure that I've understand this correctly:

 - While GHC doesn't need to be built with profiling if you
   want to use profiling in the interpeter, you will need
   multiple versions of the "server binary" for each way
   you want to implement.  This should be pretty reasonable,
   because the server binary is a lot smaller than GHC.


Yes, exactly.


 - It seems that GHC will ship bytecode and object code
   to the server binary.  In this case, the interpeted
   code and compiled code CAN share data among each other;
   it is just when you want to share data with GHC that
   you must implement serialization.  (Also, external
   bytecode format?!)


We need to ship bytecode, but not necessarily object code.  The idea is 
to implement the linker API via an RPC protocol to the server binary. 
It's pretty straightforward actually, I have a prototype running already.


We would only need to ship object code if the server were running on a 
separate machine, that's something for later (if ever).



 - Many people have commented that their extensions use
   dynCompileExpr.  I think these cases can be accommodated,
   by making the server binary not a standalone application,
   but a LIBRARY which can be linked against a custom
   application (e.g. IHaskell).  The messages to be sent
   should not be the values/file descriptors, but the
   invocations that are being requested of GHC. Unfortunately,
   this does seem to imply that most things would have to
   be rewritten from scratch to not use the ghc-api, but
   use whatever this new library's interface over the message
   passing is.


Hmm, the thing is that it is *already* a library (the GHC API) and I 
want to make it a separate process, to decouple the runtime that is 
running the compiler from the one running the interpreted code.



Honestly, it seems like the hard part is defining the message-passing
protocol, esp. since the GHC API is as overgrown as it is today.


What I have in mind is much lower level than the GHC API.  Here's what I 
have so far:


data Message a where
 -- linker API
  LookupSymbol :: String -> Message (Maybe RemotePtr)
  LoadDLL :: String -> Message (Maybe String)
  LoadArchive :: String -> Message () -- error?
  LoadObj :: String -> Message () -- error?
  UnloadObj :: String -> Message () -- error?
  AddLibrarySearchPath :: String -> Message RemotePtr
  RemoveLibrarySearchPath :: RemotePtr -> Message Bool
  ResolveObjs :: Message Bool
  -- creating and evaluating bytecode
  CreateBCO :: ResolvedBCO -> Message RemoteHValue
  FreeHValue :: RemoteHValue -> Message ()
  Eval :: RemoteHValue {- IO [a] -}  -> Message [RemoteHValue] {- [a] -}

this is enough to support basic GHCi operations.

Cheers,
Simon



Edward

Excerpts from Simon Marlow's message of 2015-11-17 02:10:55 -0800:

Hi folks - I've been thinking about changing the way we run interpreted
code so that it would be run in a separate process.  It turns out this
has quite a few benefits, and would let us kill some of the really
awkward hacks we have in GHC to work around problems that arise because
we're running interpreted code and the compiler on the same runtime.

I summarised the idea here: https://ghc.haskell.org/trac/ghc/wiki/RemoteGHCi

I'd be interested to hear if anyone has any thoughts around this,
particularly if doing this would make your life difficult in some way.
Are people relying on dynCompileExpr for anything?

Cheers,
Simon

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

Re: Feature status for GHC 8.0

[Edward Z. Yang]

Excerpts from Ben Gamari's message of 2015-11-17 07:22:22 -0800:
>  * Backpack workEdward Z. Yang
>   How is this coming along?

Had a chat with SPJ about this and we've decided that Backpack still
needs stabilizing, and there is not much gain to be had shipping it
until it is very nearly done, so we are not going to be targeting
this patch for GHC 8.0

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

RE: Window build broken

[Simon Peyton Jones]

It’s msys2.  I don’t have Cygwin on this machine.  I have no idea where that 
prompt comes from, but I agree it’s suspicious.

Simon

From: loneti...@gmail.com [mailto:loneti...@gmail.com]
Sent: 17 November 2015 23:44
To: Simon Peyton Jones; David Macek; ghc-devs@haskell.org
Subject: RE: Window build broken

Hi Simon,

I’m wondering what environment you’re coming in, is it msys2? The prompt you 
showed earlier

/cygdrive/c/code/HEAD-1$
Looks like cygwin.

Tamar

From: Simon Peyton Jones
Sent: Wednesday, November 18, 2015 00:25
To: David Macek;ghc-devs@haskell.org
Subject: RE: Window build broken


It says this:

bash$ file libraries/ghc-prim/dist-install/build/HSghc-prim-0.5.0.0.o
libraries/ghc-prim/dist-install/build/HSghc-prim-0.5.0.0.o: PE Unknown PE 
signature 0x742e x86-64 (stripped to external PDB), for MS Windows

| -Original Message-
| From: David Macek [mailto:david.mace...@gmail.com]
| Sent: 17 November 2015 22:45
| To: Simon Peyton Jones >; 
ghc-devs@haskell.org
| Subject: Re: Window build broken
|
| On 17. 11. 2015 23:31, Simon Peyton Jones wrote:
| > Sigh.  My Windows build is broken.  See below.  Any ideas?  The stage2
| complier in non-interactive mode works ok. It’s just ghci fails.  What does
| “Not x86_64 PEi386” mean?  What can I do to fix?
|
| Maybe it's obvious and you already checked, but could it be that the object
| file is for a different architecture? What does `file` say about it?
|
| --
| David Macek

___
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: Remote GHCi

[Simon Marlow]

On 18/11/2015 01:41, Manuel M T Chakravarty wrote:

Hi Simon,

While this is an interesting proposal, Haskell for Mac strongly
relies on running interpreted code in the same process. I’m using
’dynCompileExpr’ as well as ’hscStmtWithLocation’ and some other
stuff.


Let me say first of all that I'm not going to remove anything, so 
there's no need to worry.  But I'd like to explore exactly what you 
need, so that we can see whether there's a way to accommodate it with a 
separate-process implementation.


hscStmtWithLocation is part of the core GHCi functionality, it is 
definitely supported.  It has a slightly different signature:


hscStmtWithLocation :: HscEnv
-> String -- ^ The statement
-> String -- ^ The source
-> Int-- ^ Starting line
-> IO ( Maybe ([Id]
  , RemoteHValue {- IO [HValue] -}
  , FixityEnv))

RemoteHValue is a reference to a value in the interpreter's context. 
These have to be evaluated via an explicit API, rather than just 
unsafeCoercing HValue as we do now.  (this is not strictly speaking part 
of the GHC API, so a separate but interesting question is: why did you 
need to use this directly, and what should we add to the GHC API?)


I believe that many uses of dynCompileExpr can be changed so that the 
code using the resulting value is moved into the interpreter's context, 
and then there's no problem.



This is quite crucial for some of the interactive
functionality. Imagine a game where the game engine is in Swift
linked into the main application and the game logic is in
*interpreted* Haskell code. The engine calls into the Haskell code
multiple times per frame of the animation and for all
keyboard/mouse/etc input (using StablePtr and ForeignPtr to construct
the scene graph across the Swift and Haskell heap).


So my question is, why wouldn't you run the whole game engine in the 
interpreter's context?  That's what would happen if you were to load the 
program into GHCi and run it.  Directly calling back and forth between 
the client of the GHC API and the program being interpreted is arguably 
a strange thing to do, and it's kind of accidental that we allow it.



I actually also might have a use for the architecture that you are
proposing. However, I really would like to keep the ability to, at
least, optionally run interpreted code in the same process (without
profiling etc). Do you think we could have both?


We can certainly have both, it's straightforward to implement, but I 
don't get to throw away some of the hacks we have to support 
same-process execution, which would be a shame.  We just add more code 
rather than



Cheers,
Manuel


Simon Marlow :

Hi folks - I've been thinking about changing the way we run interpreted code so 
that it would be run in a separate process.  It turns out this has quite a few 
benefits, and would let us kill some of the really awkward hacks we have in GHC 
to work around problems that arise because we're running interpreted code and 
the compiler on the same runtime.

I summarised the idea here: https://ghc.haskell.org/trac/ghc/wiki/RemoteGHCi

I'd be interested to hear if anyone has any thoughts around this, particularly 
if doing this would make your life difficult in some way. Are people relying on 
dynCompileExpr for anything?

Cheers,
Simon
___
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: Window build broken

[David Macek]

On 18. 11. 2015 9:29, Simon Peyton Jones wrote:
> It’s msys2.  I don’t have Cygwin on this machine.  I have no idea where that 
> prompt comes from, but I agree it’s suspicious. 

Looks like your /etc/fstab is wrong. There should be a line like this one, that 
removes the `cygdrive` prefix from Windows drive/letter mounts:

none / cygdrive binary,posix=0,noacl,user 0 0

-- 
David Macek



smime.p7s
Description: S/MIME Cryptographic Signature
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Remote GHCi

[Simon Marlow]

Ok, it seems that (1) is easy to support in a remote GHCi, (2) is not, 
and (3) I'm not sure about.


GHCi itself does something very similar to (3): when we compile a 
statement it becomes a value of type IO [HValue], that we can evaluate 
and get back a list of the values that were bound to variables by the 
statement.  In remote GHCi I can support this by having an RPC to 
evaluate the IO action and the returned HValues are remote references 
(StablePtrs) to values in the interpreter context.


In any case I don't plan to break anything unless we have alternative 
ways to support everything without major upheaval.  In the meantime 
there will probably be a flag to select remote GHCi, and existing use 
cases will continue to be supported.


Cheers
Simon

On 17/11/2015 17:11, Andrew Gibiansky wrote:

Simon,

As Sumit said, we use dynCompileExpr for core functionality of IHaskell.
I am not really sure how the change you are proposing affects that, though.

We use dynCompileExpr in several places for evaluation inside the
interpreter context:

1. Evaluating a Haskell expression in the interpreter context,
converting the result to a ByteString, then using fromDynamic to extract
the bytestring and convert it to a value in the compiled context.
2. Getting a file handle from the interpreter context to the compiled
context; this does not actually use dynCompileExpr because there were
some bugs with dynCompileExpr and so I had to literally copy source from
InteractiveEval to reimplement parts of dynCompileExpr (unrelated: the
issue was that dyncompileexpr imported and then unimported Data.Dynamic,
and this messed with data declarations that had already been created in
the interpreter context)
3. Extracting IO a values from the interpreted context to the compiled
context so that they could be run; this is necessary to get displayed
values from the interpreter back to the compiled code.

I think two of our uses, which are both very central to the way IHaskell
works, would be impacted by requiring a Binary instance (or similar),
which is what I think you are proposing (since we have two uses at least
where we marshall `IO x` values via dynCompileExpr, which cannot be
serialized, I believe.)

I am sure that there are alternative ways to do what we are doing, but
they are probably not simple and would take quite a bit of work.

-- Andrew

On Tue, Nov 17, 2015 at 6:29 AM, Richard Eisenberg > wrote:

How does this interact with typechecker plugins? I assume they would
still happen in GHC's process.

I've also been thinking about designing and implementing a
mechanisms where programmers could specify custom pretty-printers
for their types, and GHC would use these pretty-printers in error
messages. This action would also probably need to be in the same
process.

Would either of these ideas be affected? My guess is "no", because
we should be able to be selective in what gets farmed out to the
second process and what stays locally.

Richard

On Nov 17, 2015, at 5:10 AM, Simon Marlow > wrote:

 > Hi folks - I've been thinking about changing the way we run
interpreted code so that it would be run in a separate process.  It
turns out this has quite a few benefits, and would let us kill some
of the really awkward hacks we have in GHC to work around problems
that arise because we're running interpreted code and the compiler
on the same runtime.
 >
 > I summarised the idea here:
https://ghc.haskell.org/trac/ghc/wiki/RemoteGHCi
 >
 > I'd be interested to hear if anyone has any thoughts around this,
particularly if doing this would make your life difficult in some
way. Are people relying on dynCompileExpr for anything?
 >
 > Cheers,
 > Simon
 > ___
 > 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: Feature status for GHC 8.0

[Richard Eisenberg]

On Nov 17, 2015, at 10:22 AM, Ben Gamari  wrote:

> * Kind equality Richard Eisenberg
>  Patches coming soon?

Yes yes yes. Coming soon!

I'll post an update to D808 presently if anyone wants to watch from home.

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

RE: Window build broken

[lonetiger]

➢  Perhaps it is.  Should I blow it away and re-install?

I’d hold on that this. I have just tried building myself and also hit it.

Taking a closer look, it seems that the .o file being produces isn’t an object 
file but an image file. It contains the standard image headers and a PE 
signature.

GHC is doing the right thing in error out here. I think this is coming from 
D1242, there’s a linker script in there driver/utils/merge_sections.ld that’s 
causing ld on windows to output an image file instead of an object file.

I’m afraid I am not familiar enough with ld to offer a proper fix, but to get 
you working again:

In rules/build-package-way.mk on line 154, remove the “$(if $(filter 
YES,$(LdIsGNULd)),-T $$($1_$2_LD_SCRIPT))” bit.

That should get It working again.

Regards,
Tamar


From: Simon Peyton Jones
Sent: Wednesday, November 18, 2015 14:39
To: Tamar Christina;David Macek;ghc-devs@haskell.org
Subject: RE: Window build broken


|  Presumably Simon didn't change this. Maybe the msys2 install is broken?

Perhaps it is.  Should I blow it away and re-install?

One other difficulty is that (before my machine change) I tried to follow the 
instructions on 
https://ghc.haskell.org/trac/ghc/wiki/Building/Preparation/Windows to install 
64-bit msys2; but I had a series of problems that Ben G was unable to get to 
the bottom of.  Particularly I could not run bash from emacs; the emacs shell 
window never got as far as a prompt.  So I backed off.  As far as I know that 
is still broken.

I think I have not tried the "32-bit msys2 installer" on that page.  Maybe that 
should be my next step?

Regardless, it's hard to see how any of this concerns the error message I was 
getting.  As lonetiger said, it looks very similar to 
https://ghc.haskell.org/trac/ghc/ticket/10437

What next?

Simon

|  -Original Message-
|  From: Tamar Christina [mailto:loneti...@gmail.com]
|  Sent: 18 November 2015 09:14
|  To: David Macek; Simon Peyton Jones; ghc-devs@haskell.org
|  Subject: RE: Window build broken
|  
|  Hmm,
|  
|  Presumably Simon didn't change this. Maybe the msys2 install is broken?
|  
|  TamarFrom: David Macek
|  Sent: ‎18/‎11/‎2015 09:35
|  To: Simon Peyton Jones; loneti...@gmail.com; ghc-devs@haskell.org
|  Subject: Re: Window build broken
|  On 18. 11. 2015 9:29, Simon Peyton Jones wrote:
|  > It’s msys2.  I don’t have Cygwin on this machine.  I have no idea where
|  that prompt comes from, but I agree it’s suspicious.
|  
|  Looks like your /etc/fstab is wrong. There should be a line like this one,
|  that removes the `cygdrive` prefix from Windows drive/letter
|  mounts:
|  
|  none / cygdrive binary,posix=0,noacl,user 0 0
|  
|  --
|  David Macek


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

Re: [ANNOUNCE] 7.10.3 release candidate 3

[Manuel M T Chakravarty]

> Ben Gamari :

> Lastly, I'd like to take a moment to acknowledge Futureice [2], who have
> donated a brand new Mac Mini for use by GHC developers to help support
> this platform. Their generosity is the reason we are able to offer OS X
> builds to you today.
> 
> Many thanks to Futureice for this donation!

> [2] http://futurice.com/

Wow — that is generous! Many thanks to them!

Manuel

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

Re: [ANNOUNCE] 7.10.3 release candidate 3

[Gershom B]

The link provided for rc3 (https://downloads.haskell.org/~ghc/7.10.3-rc3/) 
appears to be empty at the moment.

However I have had success with a different link: 
https://downloads.haskell.org/~ghc/ghc-7.10.3-rc3/

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

HEADS UP: Phabricator will be moving to a new server soon.

[Austin Seipp]

Hi *,

After talking with Ben today, I'll be moving the Phabricator server to
a new host Real Soon.

Our current load has outgrown the very basic server we've been using
for the past year. It's worked fine, but occasionally it cuts into
swap space, causing things like request timeouts or errors. This is
particularly noticeable on things like extremely large diffs, which we
tend to have a handful of.

This is also the first step in a two-part upgrade to the system, which
I'd like to carry out sometime within the next week. The next step
will be to upgrade our Phabricator to the latest version available
upstream.

Why have we held off on this? The primary reason is that Harbormaster,
the component that does our builds, has undergone a very large
rewrite. This was expected to happen, and for the most part the new
implementation is *far* better in many measurable ways. It has taken
some time, but I think it's now in a usable state for replacing our
current system. I didn't want to upgrade it and take away one of the
more useful features in the mean time.

I will reply to this email with an exact time slot on the server
migration. I'll have to push over a few gigs of data and resync it
after taking down the HTTP server, so I imagine the downtime window
will be small (< 1hr).

The upgrade to Phabricator itself will come with many benefits, including:

  - The patch-build process will be more robust - buildbots should no
longer need 'arc patch'. Phabricator will stage diffs in a special
'staging area' repository it manages, and you will be able to 'git
pull' patches people post, directly into your tree!

  - More scalable build machine management. We will transparently be
able to add new devices into a 'pool' of machines. For example, there
could be 3 ARM devices in the 'ARM pool' and 10 x86 machines in the
'x86 pool'. These pools have machines leased out appropriately to
build jobs. That means if you have *any* internet-addressable machine
with some spare disk space/CPU, it can be added easily at a low cost,
expanding our infrastructure.

  - A Mac Mini is now available for us to do builds on! I'll be
turning it on along with this. And if you have your *own*,
internet-addressable Mac - we can use that too!

  - Better build security, and CI builds for 'master' will be
separated (on different machines) from (possibly hostile) patch
builds.

  - We should be able to afford a significantly better set of Linux
build machines. Harbormaster can do patches and commits in about ~30
minutes. Why not go for ~10min in the common case? :)

 - Remarkup now supports 'figlet' and 'cowsay' syntax, allowing you to
Moo to your hearts desire, or give someone advice with large, 8-bit
retro-style ASCII font rendering.

There will be some other fun stuff coming down the pipe soon (a 'merge
this patch' button directly in Phabricator, and on-demand build
machines for even better performance are two examples).

That's all for now!

-- 
Regards,

Austin Seipp, Haskell Consultant
Well-Typed LLP, http://www.well-typed.com/
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs