On Mon, Dec 21, 2009 at 6:31 AM, <jeremy(a)n-heptane.com> wrote:
> Hello,
>
> That sort of missing symbol error at link time is often (but not always) a
> sign that some libraries got recompiled but not others. So there are
> references to the old symbol names hanging around.
>
> I would try to ghc-pkg unregister syb-with-class and everything that depends
> on it, and then try cabal install happstack again.
>
I'm pretty well stumped at this point. I've cleared off everything and
gone up to GHC 6.12 HEAD, and a 'cabal install happstack-data' gives
me the same symbol not defined error in Happstack.Data.Xml.Base.
But here's the spooky part, if I run it by hand like so:
ghc --make src/Happstack/Data/Xml/Base.hs
src/Happstack/Data/Default.hs src/Happstack/Data/
DeriveAll.hs src/Happstack/Data/Normalize.hs src/Happstack/Data/Migrate.hs
after resolving issues due to CPP not being run, everything runs to
completion, no errors. Also, the list of things we're pulling in
during the template-haskell execution is much smaller (see bellow).
Has anyone seen this, where template-haskell behaves different when
run from cabal-install (or Setup.hs) than from ghc --make (or ghci)?
>>>>>
2 of 5] Compiling Happstack.Data.Migrate (
src/Happstack/Data/Migrate.hs, src/Happstack/Data/Migrate.o )
[3 of 5] Compiling Happstack.Data.Default (
src/Happstack/Data/Default.hs, src/Happstack/Data/Default.o )
[4 of 5] Compiling Happstack.Data.DeriveAll (
src/Happstack/Data/DeriveAll.hs, src/Happstack/Data/DeriveAll.o )
[5 of 5] Compiling Happstack.Data.Xml.Base (
src/Happstack/Data/Xml/Base.hs, src/Happstack/Data/Xml/Base.o )
Loading package ghc-prim ... linking ... done.
Loading package integer-gmp ... linking ... done.
Loading package base ... linking ... done.
Loading package ffi-1.0 ... linking ... done.
Loading package array-0.3.0.0 ... linking ... done.
Loading package bytestring-0.9.1.5 ... linking ... done.
Loading package containers-0.3.0.0 ... linking ... done.
Loading package pretty-1.0.1.1 ... linking ... done.
Loading package syb-0.1.0.2 ... linking ... done.
Loading package template-haskell ... linking ... done.
Loading package syb-with-class-0.6.1 ... linking ... done.
mkUsageInfo: internal name? Element{tc a4av}
<<<<<
That was the successful build, using ghc --make. The error for te
failing build is quoted bellow.
Antoine
>
>
>
> On Sun 12/20/2009 2:06 AM , Antoine Latter aslatter(a)gmail.com sent:
>
> 2009/12/19 Jeremy Shaw <jeremy(a)n-heptane.com>:
>> Happstack 0.4.1 STABLE is now available.
>
> At some point I was able to get happstack to build on GHC 6.12, but now I
> can't.
>
> I'm getting errors in happstack-data, specifically it looks like
> errors when I'm running TemplateHaskell during compile-time:
>
>>>>>>
> [ 7 of 16] Compiling Happstack.Data.Xml.Base (
> src/Happstack/Data/Xml/Base.hs, dist/build/Happstack/Data/Xml/Base.o )
> Loading package ghc-prim ... linking ... done.
> Loading package integer-gmp ... linking ... done.
> Loading package base ... linking ... done.
> Loading package array-0.3.0.0 ... linking ... done.
> Loading package bytestring-0.9.1.5 ... linking ... done.
> Loading package containers-0.3.0.0 ... linking ... done.
> Loading package pretty-1.0.1.1 ... linking ... done.
> Loading package template-haskell ... linking ... done.
> Loading package syb-with-class-0.6.1 ... linking ... done.
> Loading package HUnit-1.2.2.1 ... linking ... done.
> Loading package syb-0.1.0.2 ... linking ... done.
> Loading package base-3.0.3.2 ... linking ... done.
> Loading package old-locale-1.0.0.2 ... linking ... done.
> Loading package time-1.1.4 ... linking ... done.
> Loading package random-1.0.0.2 ... linking ... done.
> Loading package QuickCheck-1.2.0.0 ... linking ... done.
> Loading package extensible-exceptions-0.1.1.1 ... linking ... done.
> Loading package mtl-1.1.0.2 ... linking ... done.
> Loading package old-time-1.0.0.3 ... linking ... done.
> Loading package parsec-2.1.0.1 ... linking ... done.
> Loading package hsemail-1.3 ... linking ... done.
> Loading package network-2.2.1.5 ... linking ... done.
> Loading package SMTPClient-1.0.1 ... linking ... done.
> Loading package filepath-1.1.0.3 ... linking ... done.
> Loading package unix-2.4.0.0 ... linking ... done.
> Loading package directory-1.0.1.0 ... linking ... done.
> Loading package process-1.0.1.2 ... linking ... done.
> Loading package hslogger-1.0.7 ... linking ... done.
> Loading package deepseq-1.1.0.0 ... linking ... done.
> Loading package parallel-2.2.0.1 ... linking ... done.
> Loading package strict-concurrency-0.2.2 ... linking ... done.
> Loading package unix-compat-0.1.2.1 ... linking ... done.
> Loading package happstack-util-0.4.1 ... linking ... done.
> Loading package binary-0.5.0.2 ... linking ... done.
> Loading package haskell98 ... linking ... done.
> Loading package HaXml-1.13.3 ... linking ... done.
> Loading package ffi-1.0 ... linking ... done.
> ghc:
> unknown symbol
> `_sybzmwithzmclasszm0zi6zi1_DataziGenericsziSYBziWithClassziInstances_dataTypeZMad6eZN_closure'
> <<<<<
>
> If you check the load-list, we are loading syb-with-class.
>
> This is on Mac OS X 10.6 on a 64-bit intel chip, if that makes any
> difference.
>
> Has anyone seen anything like this? Is it likely I've screwed up my
> GHC install somehow?
>
> Antoine
>
> --
>
> You received this message because you are subscribed to the Google Groups
> "HAppS" group.
> To post to this group, send email to happs(a)googlegroups.com.
> To unsubscribe from this group, send email to
> happs+unsubscribe(a)googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/happs?hl=en.
>
>
>
>
Hello,
I've recently been irritated with (what I consider to be) broken
versions of nubBy in GHC 6.10.4 and 6.12.1. For a while, groupBy was
broken in the same way, but it seems to be fixed at least in 6.10.4.
The problem is roughly caused by nubBy being specified only for
symmetric relations, where this is actually a rather silly constraint,
given that it captures a very common pattern of sieving (that at least
I'd personally not want to have to write recursively every time).
My most common usage of nubBy is actually probably nubBy (>=), (which
has to be changed to nubBy (<=) for recent GHCs), and variations on
it. This is extremely useful as a kind of lazier approximation of
maximum or minimum. I occasionally use nubBy with equivalence
relations (after these, I'd say (==) `on` foo is probably my next most
common use case), but it's surprising how often that's actually not
quite the right thing. Of course, there's also the inefficient but
pretty example of constructing the list of primes using the
divisibility relation and nubBy, which getting this wrong also breaks.
What do people think of the following spec?
nubBy f xs produces a subsequence ys of xs which satisfies:
1) f x y is False whenever x occurs before y in ys.
2) ys is maximal with respect to containment subject to condition 1.
3) The sequence of indices of selected elements is lexicographically
minimal subject to conditions 1 and 2. (That is, the selections are
made greedily.)
Similarly, I think groupBy f xs should be specified as:
groupBy f xs produces a list of lists yss of contiguous elements of xs
such that:
1) concat yss = xs
2) Each element of yss is a nonempty list (y:ys) such that all (f y) ys.
3) The sequence of lengths of elements of ys is lexicographically
maximal subject to conditions 1 and 2. (Again, this just means it
greedily prefers to put elements in earlier lists rather than later
ones.)
Note that the code given in the Haskell 98 spec does the right thing
with respect to these specifications, but Haskell 98 says that they're
not specified for non-equivalence relations, while I think that they
actually should be.
A general policy that I think we should try to adopt is that the
expression graph produced by a higher order function on lists, in
terms of the supplied functions, should as far as reasonably possible
maintain the left-to-right order of occurrences of elements as they
occurred in the list. This makes the precise behaviour easy to
remember, and tends to keep expression graphs easy to draw. foldr,
foldl, scanr, scanl, mapAccumL, nubBy and groupBy (as specified
above), all follow this rule (of course, many simpler HOFs do as
well). mapAccumR as specified strangely does not, which makes it
another thing I'd like to change. (See:
http://cale.yi.org/index.php/Fold_Diagrams)
cheers!
- Cale