Re: Remote GHCi

Yes, I used the GHCJS code as a starting point for Remote GHCi - the implementation of TH in Remote GHCi is very similar to GHCJS. Luite and I have chatted about this in person, and I believe he intends to try to merge them at some point. Remote GHCi should make it possible to do TH with a

Re: Remote GHCi

I was reviewing some history here, and I realized that the GHCJS folks had previous implemented this: https://mail.haskell.org/pipermail/ghc-devs/2015-November/010478.html What ever happened to this line of work? Does remote GHCi subsume it? Edward Excerpts from Simon Marlow's message of

Re: Remote GHCi

I’m not sure how much I can actually contribute to this, but I’ll just add a few pointers to nothing gets lost. I’m not very familiar with remote ghci, but I think that there is some overlap between remote ghci and out of process template haskell compilation[1][2]. Most of ghcjs’s TH code is in

Re: Remote GHCi

I want to get it done within the next few weeks. Currently GHCi is mostly working, and the main missing pieces are TH and the debugger. I plan to backport it to the 7.10 branch so that I can have it in our local GHC builds at Facebook. My WIP branch is here:

Re: Remote GHCi

What kind of timescale can we expect on this, and will it be possible to backport it (via a ghci-ng or similar)? We are currently wrestling with ghci stdio issues in haskell-ide-engine. If this will be out soon we can wait for it. Alan On Tue, Nov 24, 2015 at 2:25 AM, Manuel M T Chakravarty <

Re: Remote GHCi

Hi Simon, Sounds great! This may very well what you have got in mind anyway, but I could imagine to run the interpreter on a different thread in the -fno-external-interpreter case and arrange communication through the same messaging API that you outlined for the seperate-process interpreter.

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’

Re: Remote GHCi

Hi Andrew - Since the interpreted code is running in a separate process that we spawn using createProcess, we can set stdin/stdout/stderr to be whatever we like, including new pipes. GHC itself needs two pipes to communicate with the sub-process, but those use separate file descriptors from

Re: Remote GHCi

Simon, That's good to hear. That addresses one of the complex use cases for dynCompileExpr that we have. I'd like to present two more and see how we can address them. They both follow the same pattern so I will just describe the first one. In order to let interpreted Haskell code display images

Re: Remote GHCi

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

Re: Remote GHCi

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

Re: Remote GHCi

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

Re: Remote GHCi

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

Re: Remote GHCi

CC Daniel Corin, maintainer of hint. On 17/11/2015 11:49, Luite Stegeman wrote: I like this idea, and it overlaps very much with the work that still needs to be done for GHCJSi. I think that for Template Haskell, the restriction that everything has to be marshalled via Binary is not too

Re: Remote GHCi

I think there will be ways to do what you want in the context of a remote interpreter, but I'll need to understand more about the way in which you use dynCompileExpr. What do you do with the result of dynCompileExpr? Can you run that code in the context of the interpreter instead? Cheers

Re: Remote GHCi

Hi Simon, IHaskell makes use of dynCompileExpr to evaluate code provided by the user, so that the result can be sent to the frontend to be displayed. I don't think we can make it work without using dynCompileExpr, Andrew would have more to say about this.

Re: Remote GHCi

So the remote GHCi server I had in mind would be too dumb to support this - it would be at a much lower level, with support for linking object code and bytecode and evaluation only. What you probably want for this is a remote interface to the GHC API, similar to what ide-backend provides.

Re: Remote GHCi

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

Re: Remote GHCi

The use-case which I've worked on deals with widget messages. Widgets are stored inside the kernel, and can recieve signals from user code, frontend events etc. To capture messages sent by the user code, the messages are queued in a TChan inside the interpreter environment. Messages from this

Re: Remote GHCi

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

Re: Remote GHCi

This fits in directly with what I am trying to do for the haskell-ide-engine, where the intention is to expose ghci via an asynchronous process with communication via message passing. A bonus would be to have two separate interfaces, one for REPL interaction for the user, the other to be able to

Re: Remote GHCi

I like this idea, and it overlaps very much with the work that still needs to be done for GHCJSi. I think that for Template Haskell, the restriction that everything has to be marshalled via Binary is not too problematic, although it'd require a bit of care if Richard's pre-proposal to expose more

Re: Remote GHCi

I've been thinking of these applications before, in the context of cross compilers, and of how to deal with these things as dependencies. Custom error message formatting could be done in the same way as Template Haskell I think, since there appears to be a reasonably well-defined place where

Re: Remote GHCi

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. This is quite crucial for some of the interactive functionality. Imagine a game

Re: Remote GHCi

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