Re: ghc vs ghci: why can't ghci do everything ghc can do?
btw, it would still be nice to have ghci limitations (vs ghc)
summarized on a wiki page. i've seen fragments here and
there, but no complete list answering my questions.
:set -fobject-code
:reload
ah, thanks! i had forgotten about that one. it doesn't solve
my main problem but i guess what i'm asking for could be
rephrased as:
an _implied_ {-# OPTIONS_GHC -fobject-code #-}
for only those modules which ghci can't handle itself.
:load M.hs N.hs
i also liked the suggestion that ':m *M' should always
use the source, from the same thread.
take darcs stable as a medium sized example that already
has a 'make ghci' target. by default, that target loads object
code built by 'make' and it falls over at various places if
one adds '-fforce-recomp' to the ghci call. using a general
'-fobject-code' doesn't help, and having to figure out which
modules cause ghci headaches is no fun, either.
what i'm looking for is a way to let ghci pretend as far as
possible that it has no limitations (compared with ghc), so
that i can simply load a project's main module, have no
failures because of ffi, etc. while still having as many of
the dependencies as possible loaded in source form.
is there a way to do that that works with the darcs stable
repo example?
claus
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ghc vs ghci: why can't ghci do everything ghc can do?
Claus Reinke wrote:
btw, it would still be nice to have ghci limitations (vs ghc) summarized
on a wiki page. i've seen fragments here and
there, but no complete list answering my questions.
:set -fobject-code
:reload
ah, thanks! i had forgotten about that one. it doesn't solve my main
problem but i guess what i'm asking for could be rephrased as:
an _implied_ {-# OPTIONS_GHC -fobject-code #-}
for only those modules which ghci can't handle itself.
:load M.hs N.hs
i also liked the suggestion that ':m *M' should always
use the source, from the same thread.
take darcs stable as a medium sized example that already
has a 'make ghci' target. by default, that target loads object
code built by 'make' and it falls over at various places if
one adds '-fforce-recomp' to the ghci call. using a general
'-fobject-code' doesn't help, and having to figure out which
modules cause ghci headaches is no fun, either.
what i'm looking for is a way to let ghci pretend as far as possible
that it has no limitations (compared with ghc), so that i can simply
load a project's main module, have no failures because of ffi, etc.
while still having as many of the dependencies as possible loaded in
source form.
is there a way to do that that works with the darcs stable
repo example?
Not right now. But I think the right way would be to allow `-fobject-code`
to be used in an OPTIONS_GHC pragma to indicate that the module *must* be
loaded as object code. That way GHC can take it into account during the
planning stage before starting to compile anything, because it might force
other modules to be compiled to .o too.
http://hackage.haskell.org/trac/ghc/ticket/1365
Cheers,
Simon
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ghc vs ghci: why can't ghci do everything ghc can do?
Claus Reinke wrote: 3) suggestions: a) could we have a :make command in ghci that doesa 'ghc --make' while reusing the information fromthe current session? Doesn't :set -fobject-code :reload do that? b) could we have a --prefer-source option for ghci, so that 'ghc --make; ghci --prefer-source' will try to load all modules from source, but will fallback to the existing object files if necessary (instead of failing, as -fforce-recomp does)? c) allow selective switching between source and object files loaded into ghci (:prefer source M,N,..; :prefer object O,P,Q,..). one important restriction (I'm not sure if you forgot this, but I'll point it out anyway), is that native-code modules can only depend on other native-code modules. So falling back to native-code compilation might mean throwing away multiple modules already compiled to bytecode. I don't like the sound of that - it would be better to put a flag in the module's OPTIONS pragma to indicate object code is required. There are other proposals for specifying which modules get loaded as bytecode btw. One is that the modules you name by filename get loaded as bytecode, the others get loaded as normal. This seems the lightest solution to me, you would say :load M.hs N.hs the application i have in mind is trying to use ghci on non-trivial projects, such as darcs, or even ghc itself: - it isn't possible to load all sources into ghci - loading all object files is possible, but prevents use of ghci features such as ':m *Module', ':browse *Module', breakpoints, tags, .. - ghci -fforce-recomp fails because it applies to allmodules - there is substantial setup to do before one can call ghc or ghci, so dropping out of a sessionand trying to figure out dependencies and flags for compiling individual modules by hand isn't practical :set -fobject-code :load GHC.hs (with the above extension) Cheers, Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
ghc vs ghci: why can't ghci do everything ghc can do?
1) is there a single place/wiki/ticket that collects all the deficiencies of ghci, compared to ghc? things like: a) which platforms have ghc, but not ghci b) which features are available in ghc, but not in ghci c) does ghci encounter bugs where ghc would succeed d) which of these deficiencies are temporary, which are likely to stay 2) given that ghci is ghc --interactive, why are there any cases of b/c above at all? wouldn't it be possible for ghci to try its stuff, but to fall back to ghc only for those modules which it can't handle from source itself (yet)? - we can do ghc --make; ghci, to get around issues - we can do ghci -fforce-recomp, to get to sources but those two are rather coarse-grained, and require too much manual tweaking to get the effect of creating a ghci session with as many modules from source as possible, and all others from object files. 3) suggestions: a) could we have a :make command in ghci that does a 'ghc --make' while reusing the information from the current session? b) could we have a --prefer-source option for ghci, so that 'ghc --make; ghci --prefer-source' will try to load all modules from source, but will fall back to the existing object files if necessary (instead of failing, as -fforce-recomp does)? c) allow selective switching between source and object files loaded into ghci (:prefer source M,N,..; :prefer object O,P,Q,..). the application i have in mind is trying to use ghci on non-trivial projects, such as darcs, or even ghc itself: - it isn't possible to load all sources into ghci - loading all object files is possible, but prevents use of ghci features such as ':m *Module', ':browse *Module', breakpoints, tags, .. - ghci -fforce-recomp fails because it applies to all modules - there is substantial setup to do before one can call ghc or ghci, so dropping out of a session and trying to figure out dependencies and flags for compiling individual modules by hand isn't practical - there is often a configurable makefile, so that one can use the same setup for calling either 'ghc --make' or 'ghc --interactive'; but, within the latter, one cannot simply switch to full :make or to selective --prefer-source, without losing the setup ideally, ghci would simply work whereever ghc works, and would provide its additional features for as many modules as it can. but in the interim, having 3a and especially 3b would help me a lot. 3c would also be nice, too, but not as urgent as 3b. i find it sad that, currently, there is this gap that doesn't allow me to make full use of ghci's features for larger projects such as darcs or ghc. is hoping for 3b realistic? claus ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
