- Haskell-Cafe - Haskell.org

Cabal install fails due to recent HUnit
by Erik Hesselink 03 Sep '12

03 Sep '12

Hi all, All cabal installs using cabal-install-0.10.2 are currently failing for us. This is due to the cabal file for HUnit-1.2.5.0, which was recently uploaded to hackage. The ouput I'm getting from cabal is just: Reading available packages... Resolving dependencies... cabal: Couldn't read cabal file "HUnit/1.2.5.0/HUnit.cabal" If I unpack HUnit-1.2.5.0 and call 'cabal configure', I get: cabal: HUnit.cabal:57: The 'type' field is required for test suites. The available test types are: exitcode-stdio-1.0 The relevant lines from the cabal file are: Test-Suite hunit-tests-optimize-0 Type: exitcode-stdio-1.0 These look fine to me. Does anyone have any idea how to go about fixing this (on hackage at least)? Could this package temporarily be removed, to avoid breaking everyone's cabal? Erik

12 26

hstats median algorithm
by David Feuer 03 Sep '12

03 Sep '12

The median function in the hstats package uses a naive O(n log n) algorithm. Is there another package providing an O(n) option? If not, what would it take to get the package upgraded?

6 11

hellno - a somewhat different approach to tackling cabal hell
by Danny B 03 Sep '12

03 Sep '12

Like many of us, I've suffered from cabal dependency hell and sought relief. I wasn't exactly happy with sandboxes - because using per-project ones meant package duplication and shared sandboxes suffer from the same issues as the GHC package database itself, i.e. reinstalls can break other projects, etc. So I wrote hellno, which is so named because that's the expression one makes when seeing cabal hell suddenly manifest itself and that's also the expression one makes upon encountering yet ANOTHER cabal wrapper. To quote the README: > Generally, with hellno you'll get the same result as for blowing away your user > package database and doing a nice clean install but without having to recompile > everything and with ability to easily revert back and change between projects. Hellno works by keeping all the compiled packages to itself in a database, so that when you ask it to bring in the dependencies of a project, it will use the precompiled packages if available or install the deps and save them for later reuse. Hellno puts symlinks in the user package database pointing to packages in its storage to make them visible. Mutating the user db is hardly elegant, although shouldn't result in much trouble. It's been working fine for me, so I figured it may be useful to others. You can get hellno from GitHub: https://github.com/db81/hellno I don't mean to say that sandboxing is inherently bad or should not be used, but I guess it's better to consider more than one way.

5 6

Installation issues with Centos
by Manish Trivedi 03 Sep '12

03 Sep '12

# uname -a Linux <<hosename>> 2.6.32-220.2.1.el6.centos.plus.x86_64 #1 SMP Thu Dec 22 23:32:31 GMT 2011 x86_64 x86_64 x86_64 GNU/Linux # cat /proc/version Linux version 2.6.32-220.2.1.el6.centos.plus.x86_64 ( mockbuild(a)c6b18n3.bsys.dev.centos.org) (gcc version 4.4.6 20110731 (Red Hat 4.4.6-3) (GCC) ) #1 SMP Thu Dec 22 23:32:31 GMT 2011 I am trying to install Haskell framework on this server. - Installation for GHC went ok. no error - Installed ghc-7.4.1 from "ghc-7.4.1-x86_64-unknown-linux.tar" then while trying to install (in configure step) Haskell platform version 2012.2.0.0. I get following error: [root@qa-engine1 haskell-platform-2012.2.0.0]# ./configure ************************************************** * * Haskell Platform Source Installer * * For the Haskell Platform 2012.2.0.0 and GHC 7.4.1 * ************************************************** checking build system type... x86_64-unknown-linux-gnu checking host system type... x86_64-unknown-linux-gnu checking target system type... x86_64-unknown-linux-gnu checking for ghc... /usr/local/lib/ghc-7.4.1/ghc checking for ghc-pkg... /usr/local/lib/ghc-7.4.1/ghc-pkg checking for hsc2hs... /usr/local/lib/ghc-7.4.1/hsc2hs checking version of ghc... 7.4.1 checking version of ghc-pkg matches... yes checking ghc actually works... no configure: error: Your installation of ghc does not appear to work. It cannot compile a simple program (see config.log for the details). If you installed ghc from a generic binary tarball then it is worth checking that you have the 'gmp' C library and header files installed. (On Debian-based systems this package is called libgmp3-dev.) ==================================== I have made sure that libc and gmp are indeed installed. while trying use yum to make sure I have gmp installed. ==================================== [root@qa-engine1 haskell-platform-2012.2.0.0]# yum install gmp Loaded plugins: fastestmirror Loading mirror speeds from cached hostfile * base: mirror.stanford.edu * extras: centos.mirror.facebook.net * updates: mirror.stanford.edu Setting up Install Process Package gmp-4.3.1-7.el6_2.2.x86_64 already installed and latest version Nothing to do ======================================== Any help is appreciated. Btw, I could make haskell latest version work on my mac osx. -Manish

5 10

Compiling a haskell project as a shared library and loading it in C/C++
by Farid Neshat 03 Sep '12

03 Sep '12

So I'm trying to follow [this blog][1]. So I tried the code, couldn't compile the haskell part, probably due to the fact the guide uses version 6, but I have version 7 of ghc. By changing the paramaters I could compile it with the following: ghc --make -dynamic -shared -fPIC -no-hs-main -optl '-shared' -optc '-DMODULE=Test' -o Test.so Test.hs module_init.c But the when trying to load it, on dlopen, I get the following error: /usr/lib/ghc/ghc-prim-0.2.0.0/libHSghc-prim-0.2.0.0-ghc7.4.1.so: undefined symbol: stg_forkOnzh I suspect it's because the haskell runtime is not linked to the shared library but adding -L/usr/lib/ghc/ didn't really help. I searched a lot, but couldn't find anymore example that somebody have done this. [Here's also some docs][2] for compiling shared libraries: [1]: http://weblog.haskell.cz/pivnik/building-a-shared-library-in-haskell [2]: http://www.haskell.org/ghc/docs/7.4.1/html/users_guide/using-shared-libs.ht…

2 1

Vector: blit'ing a source into a destination
by Nicolas Trangez 02 Sep '12

02 Sep '12

All, For some code I need to alter an (unboxed or storable) vector by blit'ing (copying) data from another (smaller) vector into it, overwriting the existing data. I couldn't find a function for this in the vector API, so I hacked something up which cuts the jobs (see below), but it feels really ugly/dirty. Any ideas about a better way to tackle this, and wouldn't this be a useful addition to the standard API? Thanks, Nicolas import Data.Vector.Unboxed (Unbox, Vector) import qualified Data.Vector.Unboxed as UV import qualified Data.Vector.Unboxed.Mutable as MUV blit :: Unbox a => Vector a -> Vector a -> Int -> Vector a blit src dest offset = UV.modify act dest where act dest' = do let slice = MUV.slice offset len dest' src' <- UV.unsafeThaw src MUV.copy slice src' len = UV.length src main :: IO () main = do let v = UV.fromList [0 :: Int .. 10] b = UV.fromList [20, 30, 40] putStrLn $ "v = " ++ show v putStrLn $ "b = " ++ show b putStrLn $ "blit b v 2 = " ++ show (blit b v 2) -- v = fromList [0,1,2,3,4,5,6,7,8,9,10] -- b = fromList [20,30,40] -- blit b v 2 = fromList [0,1,20,30,40,5,6,7,8,9,10]

1 0

Is there a tool for automatic update of other-extensions and other-modules sections in a .cabal file?
by Tsuyoshi Ito 01 Sep '12

01 Sep '12

Hello, I have a *.cabal file which contains a package description for several executables (which share some of the source files). Is there a tool which updates other-extensions section and other-modules section in the .cabal file automatically to synchronize them to the source files? If it matters, I am using Haskell Platform 2012.2.0.0 on Windows. (I am aware that neither “cabal configure” nor “cabal build” requires these sections, and therefore it is not strictly necessary to update them during development of a program. But when I use a version control system such as Git, I find it ugly to store a .cabal file which is not synchronized to the latest source files… this is the primary reason why I would like such a tool.) Best regards, Tsuyoshi

1 0

Re: [Haskell-cafe] [Haskell] ANNOUNCE: Perdure
by Felipe Almeida Lessa 01 Sep '12

01 Sep '12

[moving discussion to haskell-cafe] Congratulations and thanks for your new open source contribution! I hope you feel at home =). Your library looks really interesting but I'm completely overwhelmed by its size. Its Cabal description is huge and there's no example of how to use the library (it actually took me some time to understand what the library tries to accomplish). I took a quick look at the modules but there are so many that I couldn't really make sense of anything in a short time. So, could you perhaps write a full example of how to use the library? It looks like a nice library but I need a starting point =). Cheers! -- Felipe.

2 1

Yesod a href render issue
by Thiago Negri 01 Sep '12

01 Sep '12

I'm following Yesod tutorial that gives this as the first example for "type-safe URLs": | getHomeR = defaultLayout [whamlet|<a href=@{Page1R}>Go to page 1!|] Worked fine, the "a href" generated looks perfect. Then I tried this: | getHomeR = defaultLayout [whamlet|Hello!<a href=@{Page1R}>Go to page 1!|] And got a "a href" referecing a URL without quotes and with no end tag for "a", something like this: | <html><head><title></title></head><body>Hello<a href=/page1>Go to page 1!</body></html> I tried in many different ways, and the only way to get it working properly was to set the "a" tag in a line by itself: | getHomeR = defaultLayout [whamlet|Hello! | <a href=@{Page1R}>Go to page 1! | |] Is this a failure of Yesod quasiquotation or am I missing something? I know Yesod clearly states that the best approach is to use external files instead of quasiquotes, but as I'm making my first steps into Yesod, I would like to use the practical embedded quasiquotes.

3 2

Build regressions due to GHC 7.6
by Bryan O'Sullivan 01 Sep '12

01 Sep '12

Since the release of the GHC 7.6 RC, I've been going through my packages and fixing up build problems so that people who upgrade to 7.6 will have a smooth ride. Sad to say, my experience of 7.6 is that it has felt like a particularly rough release for backwards incompatibility. I wanted to quantify the pain, so I did some research, and here's what I found. I maintain 25 open source Haskell packages. Of these, the majority have needed updates due to the GHC 7.6 release: - base16-bytestring - blaze-textual - bloomfilter - configurator - criterion - double-conversion - filemanip - HDBC-mysql - mwc-random - pcap - pool - riak-haskell-client - snappy - text - text-format - text-icu That's 16 out of 25 packages I've had to update. I've also either reported bugs on, or had to fix, several other people's packages along the way (maybe four?). So let's say I've run into problems with 20 out of the combined 29 packages of mine and my upstreams. The reasons for these problems fall into three bins: - Prelude no longer exports catch, so a lot of "import Prelude hiding (catch)" had to change. - The FFI now requires constructors to be visible, so "CInt" has to be imported as "CInt(..)". - bytestring finally got bumped to 0.10, so many upper bounds had to be relaxed (*cf* my suggestion that the upper-bounds-by-default policy is destructive). It has been a lot of work to test 29 packages, and then modify, rebuild, and release 20 of them. It has consumed most of my limited free time for almost two weeks. Worse, this has felt like make-work, of no practical benefit to anyone beyond scrambling to restore the status quo ante. If over half of my packages needed fixing, I'm alarmed at the thought of the effects on the rest of Hackage. I'm torn over this. I understand and agree with the impetus to improve the platform by tidying things up, and yet just two seemingly innocuous changes (catch and FFI) have forced me to do a bunch of running to stand still. I don't have any suggestions about what to do; I know that it's hard to estimate the downstream effects of what look like small changes. And so I'm not exactly complaining. Call this an unhappy data point.

10 15