Hacking on GHC interactively with GHCi
Hello everyone, I would like to hack on GHC interactively. My aim is to load ghc into ghci and start hacking a source file in one emacs buffer, while the other hosts an inferior-haskell session connected to GHCi. I really like this kind of development style and found it to be way more productive than "edit/compile/test/restart from edit". To context of the following is the compiler/ subtree, as I'm primarily interested in that. I tried to: * load all GHC compiler source files into ghci, fails because of occassional unboxed types (bytecode generated can't deal with them) * load all .o files (with unboxed types) and load a modified source in interpreted mode. This doesn't work well because for that approach you need to mix the source with the object in the same directory (copy compiler/**/*.[l]hs to stage1 or stage2). This, fails because there seem to be some sources missing, I have not investiged where the .o-boot files come from like compiler/stage2/basicTypes/OccName.o-boot. With source files, GHCi just ignores the existing .o file (resumable because it can't check whether the .o file is more recent than the source file) * load "ghci -package ghc" and load main/Main.hs. This work pretty well, but only in comparsion to the other approaches -- that means loading does not fail. Invoking ":main -c foobar.hs" freezes the ghci session. With this approach I can not change any module withing the packaged ghc. Is that true? But that's what I want to do (in particular to the parser part). So, before I start to work towards a particular end of these 3 approaches, is there anyone how develops ghc in an interactive way using ghci with partial :reload-ing of modules? The GHC user guide has a good illustration of what I'm looking for http://www.haskell.org/ghc/docs/latest/html/users_guide/ghci-compiled.html Any hint is appreciated. -- Fruhwirth Clemens - http://clemens.endorphin.org for robots: sp4mtrap@endorphin.org
Clemens Fruhwirth wrote:
Hello everyone,
I would like to hack on GHC interactively. My aim is to load ghc into ghci and start hacking a source file in one emacs buffer, while the other hosts an inferior-haskell session connected to GHCi. I really like this kind of development style and found it to be way more productive than "edit/compile/test/restart from edit".
To context of the following is the compiler/ subtree, as I'm primarily interested in that. I tried to:
* load all GHC compiler source files into ghci, fails because of occassional unboxed types (bytecode generated can't deal with them)
* load all .o files (with unboxed types) and load a modified source in interpreted mode. This doesn't work well because for that approach you need to mix the source with the object in the same directory (copy compiler/**/*.[l]hs to stage1 or stage2). This, fails because there seem to be some sources missing, I have not investiged where the .o-boot files come from like compiler/stage2/basicTypes/OccName.o-boot. With source files, GHCi just ignores the existing .o file (resumable because it can't check whether the .o file is more recent than the source file)
This is something we haven't tried, although if you get all the files in the right places I don't see any reason why it shouldn't work.
* load "ghci -package ghc" and load main/Main.hs. This work pretty well, but only in comparsion to the other approaches -- that means loading does not fail. Invoking ":main -c foobar.hs" freezes the ghci session. With this approach I can not change any module withing the packaged ghc. Is that true? But that's what I want to do (in particular to the parser part).
It should be possible to do this, except that I'm fairly certain you'll run into trouble if you try to run GHCi within itself due to the global state of the RTS linker. But just doing ordinary compilation in GHC loaded into GHCi should work. We have done some simple experiments using the GHC API from inside GHCi. It sounds like there's a straightforward way to show the problem, so could you submit a ticket detailing what you did to reproduce it? Thanks. Simon
At Tue, 17 Oct 2006 10:26:15 +0100,
Simon Marlow
Clemens Fruhwirth wrote:
* load all .o files (with unboxed types) and load a modified source in interpreted mode. This doesn't work well because for that approach you need to mix the source with the object in the same directory (copy compiler/**/*.[l]hs to stage1 or stage2). This, fails because there seem to be some sources missing, I have not investiged where the .o-boot files come from like compiler/stage2/basicTypes/OccName.o-boot. With source files, GHCi just ignores the existing .o file (resumable because it can't check whether the .o file is more recent than the source file)
This is something we haven't tried, although if you get all the files in the right places I don't see any reason why it shouldn't work.
Any easy ways to do this :) ?
* load "ghci -package ghc" and load main/Main.hs. This work pretty well, but only in comparsion to the other approaches -- that means loading does not fail. Invoking ":main -c foobar.hs" freezes the ghci session. With this approach I can not change any module withing the packaged ghc. Is that true? But that's what I want to do (in particular to the parser part).
It should be possible to do this, except that I'm fairly certain you'll run into trouble if you try to run GHCi within itself due to the global state of the RTS linker. But just doing ordinary compilation in GHC loaded into GHCi should work. We have done some simple experiments using the GHC API from inside GHCi.
It sounds like there's a straightforward way to show the problem, so could you submit a ticket detailing what you did to reproduce it? Thanks.
Here is my session. I didn't noticed on the first run that it doesn't freeze first, but only after multiple invokations. So, this puts the thing in a different perspective. It works in principal but maybe there are some leftovers from the previous runs. ___ ___ _ / _ \ /\ /\/ __(_) / /_\// /_/ / / | | GHC Interactive, version 6.6, for Haskell 98. / /_\\/ __ / /___| | http://www.haskell.org/ghc/ \____/\/ /_/\____/|_| Type :? for help. Loading package base ... linking ... done. Prelude> :cd ~/ther-devel/ghc-6.6/compiler Prelude> :set -I. -Istage1 -cpp -fglasgow-exts -package ghc ...[remark, stage1 is populated from a compile run, in particular with ghc_boot_plattform.h] Loading package template-haskell ... linking ... done. ...[cutted] Loading package ghc-6.6 ... linking ... done. Prelude> :load "/home/clemens/ther-devel/ghc-6.6/compiler/main/Main.hs" [1 of 1] Compiling Main ( /home/clemens/ther-devel/ghc-6.6/compiler/main/Main.hs, interpreted ) Ok, modules loaded: Main. *Main> :main -B/usr/lib/ghc-6.6 --help Usage: ghci [command-line-options-and-input-files] ...[removed]... *** Exception: exit: ExitSuccess *Main> :main -B/usr/lib/ghc-6.6 --help ...[freeze here .. pressed C-c] *** Exception: exit: ExitFailure 1 *Main> Unless you tell me that I made some mistakes here, I will file this as a bug with GHC trac. Thanks, -- Fruhwirth Clemens - http://clemens.endorphin.org for robots: sp4mtrap@endorphin.org
On Tue, Oct 17, 2006 at 09:54:26AM +0000, Clemens Fruhwirth wrote:
*Main> :main -B/usr/lib/ghc-6.6 --help ...[freeze here .. pressed C-c] *** Exception: exit: ExitFailure 1 *Main>
I could reproduce this with stage2/ghc-inplace --interactive :set -I. -Istage1 -cpp -fglasgow-exts -package ghc :load main/Main.hs :main -B/home/ian/ghc/6.6-branch/build --help -- sometimes more than once in an old 6.6 branch compiler/, but having updated it I no longer can. I can't reproduce it in the HEAD either. I haven't seen a reply to your message, but it looks like the problem is now fixed regardless. Thanks Ian
participants (3)
-
Clemens Fruhwirth -
Ian Lynagh -
Simon Marlow