December 2009 - Libraries

Re: Re: ANN: Happstack 0.4.1
by Antoine Latter 01 Jan '10

01 Jan '10

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. > > > >

3 2

Re: template haskell (Debian & chart)
by Brian Denheyer 31 Dec '09

31 Dec '09

Tim Docker writes: > Brian Denheyer wrote: > > I need template haskell for chart. > > > > I installed the libghc6-src-ext-devs which supposedly provides > > template haskell, but I get the following error. > > > Language/Haskell/TH/Syntax/Internals.hs:20:7: > > Could not find module `Data.Data': > > it is a member of the hidden package `base' > > locations searched: > > dist/build/Data/Data.hs > > dist/build/Data/Data.lhs > > Data/Data.hs > > Data/Data.lhs > > dist/build/autogen/Data/Data.hs > > dist/build/autogen/Data/Data.lhs > > I had this problem also. I was able to work around it by explicitly > requesting an older version of data-accessor-template: > > cabal install data-accessor-template-0.2.1.1 > > Henning: do you know why the above build fails when using v0.2.1.2 and > ghc-10.1.4? > > Tim Yes ! That works for me too. Thank you. I got confused, I though that data-accessor was part of the template library and so therefore maybe there was a problem with the versions being used in debian. Looks like data-accessor stands on it's own, and that it's really a problem with chart not being able to use the most recent version of data-accessor, is that right ? Brian

1 0

template haskell (Debian & chart)
by Brian Denheyer 29 Dec '09

29 Dec '09

I need template haskell for chart. I installed the libghc6-src-ext-devs which supposedly provides template haskell, but I get the following error. *** Chasing dependencies: Chasing modules from: *Language.Haskell.TH.Syntax.Internals,*Language.Haskell.TH.Syntax,*Language.Haskell.TH.PprLib,*Language.Haskell.TH.Ppr,*Language.Haskell.TH.Lib,*Language.Haskell.TH.Quote,*Language.Haskell.TH Language/Haskell/TH/Syntax/Internals.hs:20:7: Could not find module `Data.Data': it is a member of the hidden package `base' locations searched: dist/build/Data/Data.hs dist/build/Data/Data.lhs Data/Data.hs Data/Data.lhs dist/build/autogen/Data/Data.hs dist/build/autogen/Data/Data.lhs I get the same error if I try cabal install template-haskell also. I can't tell if this is because there is a version problem or the library really isn't installed. Brian

1 0

ANN: time-extras 1.1.4
by Ashley Yakeley 29 Dec '09

29 Dec '09

time-extras 1.1.4 contains Data instances for types defined in time-1.1.4. They are in a separate package because they require RankNTypes, which is not Haskell 2010. Get it from Hackage. http://hackage.haskell.org/package/time-extras -- Ashley Yakeley

7 9

darcs patch: lower base requirement down to base-2
by Sergei Trofimovich 28 Dec '09

28 Dec '09

Wed Dec 16 23:34:21 EET 2009 Sergei Trofimovich <slyfox(a)community.haskell.org> * lower base requirement down to base-2 At least ghc-6.6.1 is able to build it without problems. (package can be used in cabal-1.8, which is known to work on ghc-6.4+)

1 0

darcs patch: fixed 'cabal sdist'
by Sergei Trofimovich 28 Dec '09

28 Dec '09

Tue Dec 15 00:56:45 EET 2009 Sergei Trofimovich <slyfox(a)community.haskell.org> * fixed 'cabal sdist' It actually fixes './configure' regeneration for such distros, like gentoo, wich had to patch configure.ac and regenerate script toolchain.

1 0

Default install locations on Windows
by Duncan Coutts 27 Dec '09

27 Dec '09

All, For Cabal packages our default install locations on Windows are a bit of a mess. Firstly we do global installs by default. This used to make sense on Windows XP when everyone had admin permissions. It no longer makes sense for Vista or Windows 7. See this recent horror story from a new user: http://haskell.org/pipermail/haskell-cafe/2009-December/071310.html I've talked for a while about switching the default to per-user installs on Windows: http://hackage.haskell.org/trac/hackage/ticket/465 Now I'm not a regular Windows user so I would like some expert advice from Windows Haskell hackers. Specifically, are the default locations and layout for per-user installs OK? A related problem is that historically we tried to fudge things so that packages could be mostly relocatable by default. This is because Windows tends to make greater use of relocatable packages (giving users a choice of location at install time). There is a problem with relocatable packages that depend on libraries that contain data files: http://hackage.haskell.org/trac/hackage/ticket/466 My proposed solution for this is to not do anything special about data files for windows and use the same directory layout as on Unix. That is, change: datadir = case buildOS of Windows | hasLibs -> windowsProgramFilesDir </> "Haskell" | otherwise -> "$prefix" _other -> "$prefix" </> "share", to datadir = case buildOS of Windows -> "$prefix" _other -> "$prefix" </> "share", BTW, why do we not want the "share" subdir? It means currently we end up with a per-package directory at the top level containing the data files for that package. So then the per-user install locations on Windows 7 would be: prefix: C:\Users\${USER}\AppData\Roaming\cabal bindir: $prefix\bin libdir: $prefix libsubdir: $pkgid\$compiler libexecdir: $prefix\$pkgid datadir: $prefix datasubdir: $pkgid docdir: $prefix\doc\$pkgid htmldir: $docdir\html haddockdir: $htmldir Then separately I think we need explicit support for constructing prefix independent packages which could check for these issues. eg: cabal configure --prefix-independent Duncan

1 0

Adding Network.URI.escape
by Gwern Branwen 25 Dec '09

25 Dec '09

Network.URI.escapeURIString is pretty much always used to make a String a URL or a part of a URL. The existing definition http://www.haskell.org/ghc/docs/6.10.4/html/libraries/network/Network-URI.h… forces one to do extra work by having to specify a `Char -> Bool`. More than a few packages & libraries simply define an 'escape' function `escapeURIString isAllowedInURI` (either inline or as a named function). This sort of repetition is unfortunate. The name 'escape' is commonly used to express exactly that functionality: http://holumbus.fh-wedel.de/hayoo/hayoo.html#0:escape What would people say to adding such a function? -- gwern

2 1

Replacing Data.List.sort
by Gwern Branwen 24 Dec '09

24 Dec '09

Thought I'd mention http://hackage.haskell.org/trac/ghc/ticket/2143 as being in libraries@ bailiwick. It's been a while since http://neilmitchell.blogspot.com/2008/03/sorting-at-speed.html and http://haskell.org/pipermail/haskell-cafe/2008-March/thread.html#40164 but I hope with some Criterion benchmarks, the case for replacing the current GHC Data.List.sort with the YHC Data.List.sort becomes a no-brainer. (If people want to improve the Criterion benchmark and run it themselves to verify that YHC is always faster, that'd be great also!) -- gwern

1 0

darcs patch: lower base requirement down to base-2
by Sergei Trofimovich 23 Dec '09

23 Dec '09

Wed Dec 16 23:34:21 EET 2009 Sergei Trofimovich <slyfox(a)community.haskell.org> * lower base requirement down to base-2 At least ghc-6.6.1 is able to build it without problems. (package can be used in cabal-1.8, which is known to work on ghc-6.4+)

1 0