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
On Sat, May 23, 2009 at 3:58 PM, Dean Herington
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> :m + Graphics.UI.Grapefru
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 entir
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 whil
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 tha
On Wed, 2009-05-27 at 21:17 +0100, Duncan Coutts wrote:
> To be clear, here's what I'm imagining:
>
> blah/package.conf
> blah/lib/foo-1.0/libfoo-1.0.a
>
> and package.conf would contain foo-1.0 with paths looking like
> "$dbdir/lib/foo-1.0". That is, we interpret $dbdir (or whatever var name
>
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 paths
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
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 tri
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 a
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: glasgow
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 $(fo
12 matches
Mail list logo
