GHCI Feature Request: Last Successful Compilation State Saved

Hi all, I would like for the GHCI interpreter to save its environment before reloading a file and allowed the user to revert back to that state if the compilation was unsuccessful. Many times I've changed files, loaded them, hit a compilation error and needed, for example, the inferred type signature of some function. Even though that function hasn't been changed I have to either fix my code, undo a bunch of changes or comment out the last change I made and reload in order to do a ":type" on the function. This really breaks the flow of development. Thanks for considering. -deech

2011/8/27 aditya siram
Hi all, I would like for the GHCI interpreter to save its environment before reloading a file and allowed the user to revert back to that state if the compilation was unsuccessful.
That would be awesome. I would like this too. David.

On Saturday 27 August 2011, 23:10:17, David Virebayre wrote:
2011/8/27 aditya siram
: Hi all, I would like for the GHCI interpreter to save its environment before reloading a file and allowed the user to revert back to that state if the compilation was unsuccessful.
That would be awesome. I would like this too.

That doesn't look very promising :( On Aug 27, 2011, at 5:31 PM, Daniel Fischer wrote:
On Saturday 27 August 2011, 23:10:17, David Virebayre wrote:
2011/8/27 aditya siram
: Hi all, I would like for the GHCI interpreter to save its environment before reloading a file and allowed the user to revert back to that state if the compilation was unsuccessful.
That would be awesome. I would like this too.
http://hackage.haskell.org/trac/ghc/ticket/1896
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

http://www.youtube.com/watch?v=Y_exermAXkU&t=0m6s
-deech
On Sat, Aug 27, 2011 at 4:56 PM, Daniel Patterson
That doesn't look very promising :(
On Aug 27, 2011, at 5:31 PM, Daniel Fischer wrote:
On Saturday 27 August 2011, 23:10:17, David Virebayre wrote:
2011/8/27 aditya siram
: Hi all, I would like for the GHCI interpreter to save its environment before reloading a file and allowed the user to revert back to that state if the compilation was unsuccessful.
That would be awesome. I would like this too.
http://hackage.haskell.org/trac/ghc/ticket/1896
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

Oh, I didn't reply all. Whoops.
On 28 August 2011 13:40, Christopher Done
On 27 August 2011 22:59, aditya siram
wrote: I would like for the GHCI interpreter to save its environment before reloading a file and allowed the user to revert back to that state if the compilation was unsuccessful.
Many times I've changed files, loaded them, hit a compilation error and needed, for example, the inferred type signature of some function. Even though that function hasn't been changed I have to either fix my code, undo a bunch of changes or comment out the last change I made and reload in order to do a ":type" on the function. This really breaks the flow of development.
This has been bugging me for a long time and it's been on my TODO list for haskell-emacs: https://github.com/chrisdone/haskell-emacs
I just implemented it. http://i.imgur.com/A71T5.png
I just run two ghci processes, one for compiling, one for merely loading the code in when the former succeeds.
It's not a very pleasant hack but in conjunction with :set -fobject-code it is fast and does not consume that much more memory. Considering tibbe's report is 4 years old, I think this solution is better than nothing.
Set hs-config-preliminary-load-file to t in hs-config.el and it will do a preliminary load in a separate GHCi process.

Chris, this is amazing! One question - do you have support for tramping in and running ghci remotely (or would that be easy to add)? I primarily develop inside virtual-machines, so while the source code lives where emacs lives, all the libraries are installed inside the virtual-machine (and the source also lives there, of course). On Aug 30, 2011, at 4:46 AM, Christopher Done wrote:
Oh, I didn't reply all. Whoops.
On 28 August 2011 13:40, Christopher Done
wrote: On 27 August 2011 22:59, aditya siram
wrote: I would like for the GHCI interpreter to save its environment before reloading a file and allowed the user to revert back to that state if the compilation was unsuccessful.
Many times I've changed files, loaded them, hit a compilation error and needed, for example, the inferred type signature of some function. Even though that function hasn't been changed I have to either fix my code, undo a bunch of changes or comment out the last change I made and reload in order to do a ":type" on the function. This really breaks the flow of development.
This has been bugging me for a long time and it's been on my TODO list for haskell-emacs: https://github.com/chrisdone/haskell-emacs
I just implemented it. http://i.imgur.com/A71T5.png
I just run two ghci processes, one for compiling, one for merely loading the code in when the former succeeds.
It's not a very pleasant hack but in conjunction with :set -fobject-code it is fast and does not consume that much more memory. Considering tibbe's report is 4 years old, I think this solution is better than nothing.
Set hs-config-preliminary-load-file to t in hs-config.el and it will do a preliminary load in a separate GHCi process.

On 30 August 2011 17:48, Daniel Patterson
Chris, this is amazing! One question - do you have support for tramping in and running ghci remotely (or would that be easy to add)? I primarily develop inside virtual-machines, so while the source code lives where emacs lives, all the libraries are installed inside the virtual-machine (and the source also lives there, of course).
So either 1) You put all your source files on the server, too and then run the GHCi process under tramp and access the files via tramp. 2) Sounds like you'd prefer to keep your files local, which, I suppose means you want to send code to the server when you trigger a compile? Could be done, could be done. I'll ponder it.

On Aug 30, 2011, at 1:15 PM, Christopher Done wrote:
1) You put all your source files on the server, too and then run the GHCi process under tramp and access the files via tramp.
2) Sounds like you'd prefer to keep your files local, which, I suppose means you want to send code to the server when you trigger a compile?
Could be done, could be done. I'll ponder it.
Actually, 1. is what happens, which seems like the easier thing. The folder does exist locally (ie, on the host), but it is shared with the virtualmachine, so it can be edited in either place. The sharing is either done through a a special mechanism provided by the virtualmachine (ie, in virtualbox, "shared folders"), or with plain old NFS (the latter is faster, for unknown reasons). My normal workflow is to have an editor open that edits the files on the "host". Then with a ssh connection to the "client" (the virtualmachine), I build and/or run ghci through that. I'm not sure if this is how other people do work with virtualmachines, but I would imagine it was relatively common. I'd be pretty excited about that working. As an added benefit, the same strategy could be used to jump into a project on an actually remote host.

"Daniel Fischer"
On Saturday 27 August 2011, 23:10:17, David Virebayre wrote:
2011/8/27 aditya siram
: Hi all, I would like for the GHCI interpreter to save its environment before reloading a file and allowed the user to revert back to that state if the compilation was unsuccessful.
That would be awesome. I would like this too.
+1 from me too. How do I go about registering my interest in the ticket? I though there was a way of adding myself on the CC: of the ticket? How does one do this? Does one need some sort of user? Rene.

On Sunday 28 August 2011, 20:43:11, Rene de Visser wrote:
"Daniel Fischer"
schrieb im Newsbeitrag news:201108272331.01371.daniel.is.fischer@googlemail.com... On Saturday 27 August 2011, 23:10:17, David Virebayre wrote:
2011/8/27 aditya siram
: Hi all, I would like for the GHCI interpreter to save its environment before reloading a file and allowed the user to revert back to that state if the compilation was unsuccessful.
That would be awesome. I would like this too.
+1 from me too.
How do I go about registering my interest in the ticket? I though there was a way of adding myself on the CC: of the ticket? How does one do this? Does one need some sort of user?
You need to log in to add yourself to the cc. If you don't have a trac account and don't want one, at the bottom of the page, on the right hand side, there's a pale text telling you how to log in with the guest account. Cheers, Daniel

On 11-08-27 04:59 PM, aditya siram wrote:
Many times I've changed files, loaded them, hit a compilation error and needed, for example, the inferred type signature of some function. Even though that function hasn't been changed I have to either fix my code, undo a bunch of changes or comment out the last change I made and reload in order to do a ":type" on the function. This really breaks the flow of development.
In #haskell, we came up with the idea of running two instances of ghci. Try loading in one instance first; if good, commit to the other instance too; if bad, you still have the other instance in a functional state. Presumably, this should be automated by some middleware. (We were discussing the prospect of auto-reload, i.e., automatically poll source file timestamps and reload.)

On 30 August 2011 06:46, Albert Y. C. Lai
In #haskell, we came up with the idea of running two instances of ghci. Try loading in one instance first; if good, commit to the other instance too; if bad, you still have the other instance in a functional state. Presumably, this should be automated by some middleware.
See my post from two days ago.
participants (7)
-
aditya siram
-
Albert Y. C. Lai
-
Christopher Done
-
Daniel Fischer
-
Daniel Patterson
-
David Virebayre
-
Rene de Visser