Tyson Whitehead wrote:
I have a program that seems to me to be exhibiting strange behaviour.
Basically, it looks like something somewhere is not being updated, and this is
resulting in (very expensive) computation being repeated.
Just a hunch - try recompiling your modules with
You already have splicing for top level decls. Splicing for local decls is a
whole different ball game because it brings new *binders* into scope. For
example
f = ...g...
g = let $(foo) in ...f...
Is the 'f' inside 'g' the same 'f' as the one bound at top level? Not
necessarily, because
That certainly sounds odd to me. As Jules says, try -fno-state-hack (a bit of
a shot in the dark, because we don't have the full context). I hope someone
can help you characterise it a bit more accurately, so you can report it as a
Trac bug.
Simon
| -Original Message-
| From:
Currently, there seem to be $topdir and $httptopdir.
And I can't see a justification for there being two.
Each variable provides an indirection that decouples the installation
from one source of _independent_ relocations (btw, I've always imagined
that it is called 'http' instead of 'html' to
On 23/05/2009 14:53, Claus Reinke wrote:
JHC has had this for a while, but it calls the pragma 'SRCLOC_ANNOTATE'.
It is actually mentioned on this page:
http://hackage.haskell.org/trac/ghc/wiki/ExplicitCallStack
Yes, I know, but the discussion on that page wanted to go beyond this
(possibly
On Thu, 2009-05-28 at 11:16 +0100, Claus Reinke wrote:
How about this: a way to specify paths in the package registration info
that
are relative to the location of the package db they are in.
ahem. That sounds like a backwards step, being dependent on two
locations instead of one.
But if you're registering global packages that are installed outside of
the GHC tree then you wouldn't register them using relative paths. I'm
not saying everything must use relative paths.
Please don't move your windmills while I'm fighting them!-)
If you don't want to move from absolute
One thing that wasn't available when this discussion was last active
is 'mapException' (btw, similar to 'catch'/'catches', a 'mapExceptions'
would be useful). For instance, appended below is the example from that
wiki page, with entirely local transformations to add source locations
and to use
On Thu, 2009-05-28 at 14:12 +0100, Claus Reinke wrote:
But if you're registering global packages that are installed outside of
the GHC tree then you wouldn't register them using relative paths. I'm
not saying everything must use relative paths.
Please don't move your windmills while I'm
Here are the +RTS -xc and mapException outputs together (when I
remove the mapError annotations, only the first .. is printed, so
that is the part to focus on, the rest is confusion)
Actually, it looks as if the implementation of mapException modifies
the stack that +RTS -xc prints. Not
On Sat, May 23, 2009 at 3:58 PM, Dean Herington
heringtonla...@mindspring.com wrote:
GHCi, version 6.10.1: http://www.haskell.org/ghc/ :? for help
Loading package ghc-prim ... linking ... done.
Loading package integer ... linking ... done.
Loading package base ... linking ... done.
Prelude
If you don't want to move from absolute paths for non-core packages,
the current system should just work, right?
Yes.
The current system being the $topdir one.
Though it also allows for the possibility of relocatable sets of
packages that are not installed relative to the compiler. But more
12 matches
Mail list logo
