Incompatibility between Yi and GHC 6.8 (rc)
Hello,
I spent some time to make Yi work with 6.8, and failed up to now.
Before I go into details, let's see what I'm trying to do with Yi.
The idea is to have a fully dynamic application where the user is
allowed to run arbitrary haskell code on the command line. This can be
used to quickly test new code, etc. In particular, one needs to be
able to "reload" the configuration in that manner.
This is achieved basically by having everything running inside a
specially made "GHC Session". The dynamic code is able to "reload
itself" because it is passed a pointer to the GHC session.
The GHC experts will see here that this cannot work :) Indeed, GHC has
a number of "global variables", which, if accessed through code loaded
in a GHC session, will be instanciated again. This means that
accessing a "level 1" session with "level 2" code is normally not
possible.
However, I found a workaround: encapsulate all calls to the GHC API in
a data structure in "level 1" code, which is then passed to "level 2".
(A haskell version of C-style callbacks). While this worked
beautifully with GHC 6.6, it fails with 6.8rc. with
exception :: GhcException
yi: panic! (the 'impossible' happened)
(GHC version 6.8.0.20071019 for i386-unknown-linux):
a static opt was looked at too early!
This happens at a seemingly unrelated point in the code. (inside the
bytecode interpreter?)
I can't really report a bug here, because what I'm trying to do is
probably fairly unsupported by GHC. However, I'd appreciate some sort
of advice. Is my workaround the correct approach? How would GHC people
implement a dynamic application? Should I drop the idea completely?
...
Thanks in advance for your help :)
-- JP
Attached: a darcs patch to the Yi repo to (try to) support 6.8.
New patches:
[adapt to GHC 6.8
[EMAIL PROTECTED] {
hunk ./Makefile 13
- dist/build/yi/yi -B. -f$(frontend)
+ cp --preserve=timestamps -R Yi dist/build
+ dist/build/yi/yi -Bdist/build -f$(frontend)
hunk ./Setup.hs 4
-import Control.Monad(when, filterM, unless)
-import Data.List (intersect)
+import Control.Monad
hunk ./Setup.hs 7
-import Distribution.Setup
+import Distribution.Simple.Setup
hunk ./Setup.hs 9
+import Distribution.Simple.GHC as GHC
hunk ./Setup.hs 11
-import Distribution.Simple.Utils
+import Distribution.Simple.Program
+import Distribution.Verbosity
hunk ./Setup.hs 14
-import System.Exit
hunk ./Setup.hs 15
-import System.Info
-import System.Process
hunk ./Setup.hs 16
+import Control.Applicative
hunk ./Setup.hs 22
-getLibDir ghcPath = do
- (_, out, _, pid) <- runInteractiveProcess ghcPath ["--print-libdir"]
- Nothing Nothing
- libDir <- hGetLine out
- waitForProcess pid
- return libDir
-
hunk ./Setup.hs 24
-bHook :: PackageDescription -> LocalBuildInfo -> Maybe UserHooks -> BuildFlags -> IO ()
-bHook pd lbi hooks bfs = do
- let ghc = compilerPath . compiler $ lbi
+-- TODO: add a configuration hook that does not want to build for
+-- certain combination of flags
+
+bHook :: PackageDescription -> LocalBuildInfo -> UserHooks -> BuildFlags -> IO ()
+bHook pd lbi hooks flags = do
+ let verbosity = buildVerbose flags
hunk ./Setup.hs 31
+ ghcOut = rawSystemProgramStdoutConf verbosity ghcProgram (withPrograms lbi)
hunk ./Setup.hs 33
- libdir <- getLibDir ghc
+ libdir <- head . lines <$> ghcOut ["--print-libdir"]
+ putStrLn $ "GHC libdir = " ++ show libdir
hunk ./Setup.hs 39
- buildHook defaultUserHooks pd' lbi hooks bfs
+ buildHook defaultUserHooks pd' lbi hooks flags
hunk ./Setup.hs 41
- res <- mapM (precompile ghc) precompiles
- let sucessfuls = [m | (m,code) <- res, code == ExitSuccess]
- nok = null $ intersect sucessfuls ["Yi.Vty.UI", "Yi.Gtk.UI"]
- putStrLn $ "Sucessfully compiled: " ++ show sucessfuls
- when nok $ do
- putStrLn "No frontend was compiled sucessfully. Giving up."
- exitWith (ExitFailure 1)
+ mapM_ (precompile pd' lbi verbosity) precompiles
hunk ./Setup.hs 43
-precompile ghc (moduleName, dependencies) = do
+dependencyName (Dependency name _) = name
+
+precompile pd lbi verbosity (moduleName, dependencies) = when ok $ do
+ -- just pretend that we build a library with the given modules
hunk ./Setup.hs 48
- exitCode <- rawSystemVerbose 0 ghc (precompArgs ++ map ("-package "++) dependencies ++ [moduleName])
- when (exitCode /= ExitSuccess) $
- putStrLn $ "Precompiling failed: " ++ moduleName
- return (moduleName, exitCode)
+ let [Executable "yi" _ yiBuildInfo] = executables pd
+ pd' = pd {executables = [],
+library = Just (Library {exposedModules = [moduleName],
+ libBuildInfo = yiBuildInfo})}
+ GHC.build pd' lbi verbosity
+ where availablePackages = map dependencyName $ buildDepends pd
+ ok = all (`elem` availablePackages) dependencies
+
hunk ./Setup.hs 61
- ("Yi.Gtk.UI", ["gtk",
Re: ANNOUNCE: GHC 6.8.1 Second Release Candidate
Hi On 10/24/07, Ian Lynagh <[EMAIL PROTECTED]> wrote: > > Hi, > > On Wed, Oct 24, 2007 at 09:28:51AM +0200, Jean-Philippe Bernardy wrote: > > > > I ran into this problem with the GHC API (GHC 6.8.1 Second Release > > Candidate) > > > > upon doing: > > > > session <- GHC.newSession (Just path) > > > > I run into: > > > > yi: Can't find package.conf as /home/jp/usr//lib/ghc-6.8.0.20071019 > > /driver/package.conf.inplace > > Thanks for the report; however, I can't reproduce this. Somehow I got a carriage return inserted in the libdir that I passed to newSession. So the only problem on GHC side is that the error message is slightly misleading. (Nothing to worry about I would say) Thanks -- JP ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ANNOUNCE: GHC 6.8.1 Second Release Candidate
> adding more status/next action/deadline/actor fields would help, if trac > supports that (could be simple free-form text > fields, or selections), FYI, Trac is bringing us "customised workflows", which will allow us to do some of this: http://trac.edgewall.org/wiki/WorkFlow In particular we'll be able to add new ticket states to indicate that the ticket is waiting for feedback from the submitter, or some other dependency. I wouldn't be in favour of just adding new fields to do this right now, we already have too many fields. that looks promising. although the idea still seems to be to have few states, leaving it to custom fields to specify details. so there might be a single "waiting" state, with an action field specifying what one is waiting for (someone getting an definite interpretation of a spec, someone contacting the gcc/ cygwin/whatever team, someone implementing a newer, better language feature that will make the issue obsolete or easier to deal with, etc), a date field specifying when results from that action are expected (or a reminder should be sent), and an actor field specifying who is looking after that action. and if the actor finishes the action, a click on the "done" button would take the ticket to "idle" (waiting for the next action to be determined) or, better, the next action to specify would be obvious, going directly back to "waiting". this combination of two extra states+three one-line fields would be more flexible and less complex than trying to capture all eventualities in pre-designed fields/states, as trac currently aims to do. you name one part of the current problem: too many fields not relevant to every ticket; i named another: too few relevant fields. having more general fields could address both parts. i can understand if you want to hold back until the next trac release, as that seems to switch a few things around. it is just that if i think of the current state of ghc's trac as wasting your time: - if you wanted to go through all tickets to figure out their state and adjust their milestones, i estimate that could take anything up to a full day; so long, in fact, that you decided not to do it for this release - if you wanted to figure out which tickets are pending full implementation of open type functions, you'd have to go through all type-system tickets - etc. etc. if, instead, all the information relevant to organisation (as opposed to information relevant to fixing) were available in ticket fields, one could go through all tickets in an hour (without ever having to wade into the ticket history/comments), and many things one might want to figure out could become a simple trac-query instead of a full search. an overview page translating states to colour could tell at a glance which tickets are actively waiting, and which are idling or overdue (hence need attention). in fact, since all information about a ticket state would be visible to everyone, from the ticket fields, there would no longer be a need to go through all tickets at every release just to reassure submitters that their tickets weren't overlooked. in other words, i'd classify this meta-ticket as both urgent and important: urgent because the current system is becoming unwieldy, important because a reorganised system should save you a lot of time. claus ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
