August 2014 - Haskell-Cafe

Unable to build a mingw cross compiler.
by Sven Bartscher 05 Oct '14

05 Oct '14

Greetings, I'm trying to build GHC to cross compile to windows. GCC and friends are in /usr/bin/x86_64-w64-mingw32-*, libraries and headers are in /usr/x86_64-w64-mingw32/{include,lib}. I configured with: ./configure --target=x86_64-w64-mingw32 \ --with-gcc=/usr/bin/x86_64-w64-mingw32-gcc # Needed because # otherwise /usr/bin/gcc # would be used Building fails with the following error: utils/hsc2hs/dist/build/Main.o: In function `s2nI_info': (.text+0x5c5): undefined reference to `GetModuleFileNameW' collect2: error: ld returned 1 exit status (The GHC invocation line is included in the attached file) So it seems that GHC either uses the wrong linker or invokes it with the wrong search path. However, the configure script detects the right linker (/usr/bin/x86_64-w64-mingw32). Is this a bug, or a feature? System data: OS: Debian jessie Linux/GNU i386 Installed GHC (for bootstrapping): version 7.6.3 GHC I'm trying to build: version 7.8.3 Regards Sven

2 1

2014 haskell cabal update hangs on mac
by Madhu Babu 09 Sep '14

09 Sep '14

I initially installed haskell platform ( 2013 version; 7.6.3 ghc ) on my mac. Everything was working great. Just now saw the haskell platform website again and found new version was released ( Haskell Platform 2014.2.0.0 for Mac OS X, 64bit ). I installed it, and un-installed the older version using uninstall-hs. Now when i type "cabal" or "cabal update" on my terminal, it hangs. Actually when i look into Activity Monitor, i can see that it is invoking some "sh script & possibly some find command" infinitely. I initially guess may be it is building some indexes. but it has been running for an hr or so. I have Xcode 5, gcc and other command line tools installed properly Please advice. I cannot install any other package using cabal.

5 5

[ANN] haddock-2.15-0, haddock-api-2.15-0, haddock-library-1.1.1
by Mateusz Kowalczyk 07 Sep '14

07 Sep '14

Hello, I'd like to announce the release of Haddock 2.15.0. Before we dive in, I'd like to announce that Haddock development has moved out of the GHC tree and is now done against the latest compiler release. If in the past you wanted to contribute but were intimidated by having to make sure it works against GHC HEAD then here's your chance. Additionally, it now should also work with GHC 7.8.2 so if for whatever reason you're forced to use that, you can now get the latest Haddock features. If you want to contribute then please let us know, we're understaffed! Come chat at #haddock or send us an e-mail. If you have been using 2.14.x, you should be good to simply ‘cabal install haddock’. Now the changes: This is an API-breaking bugfix release so any tickets originally scheduled for 2.15.0 were pushed towards 2.16. Perhaps the biggest change is that ‘cabal install haddock’ will now only give you the Haddock binary. To use Haddock API, please depend on ‘haddock-api’ from now on. I have sent out an e-mail about this couple of weeks in advance to any reverse dependencies of ‘haddock’. This is to workaround cabal's inability to pass flags to dependencies from the cabal file. ‘haddock-library’ only got a minor bump, 1.1.0 → 1.1.1 improving its output. The Monoid instance for DocH is gone however as it was ill-formed to begin with. Changes in version 2.15.0 * Always read in prologue files as UTF8 (#286 and Cabal #1721) * parser: don't wrap headers in DocParagraph (#307) * parser: don't mangle append order for nested lists (pandoc #1346) * parser: preserve list ordering in certain scenarios (#313) * parser: update the attoparsec version used internally giving slight parsing performance boost. * Move development to be against latest GHC release and not GHC HEAD. * Further split up the package to separate the executable from the library, necessary by things like GHCJS. We now have ‘haddock-library’ which are the parts that don't use GHC API, ‘haddock-api’ which are (some of) the parts that do use GHC API and ‘haddock’ which merely provides the executable. * Export few extra functions in the API. * Add compatibility with GHC 7.8.2. * Omit unnecessary ‘forall’s (#315 and #86) * Remove some files which were really old or did not belong in the repository in the first place. Once again, we'd love to have more people on board be it for the HTML backend, refactoring, LaTeX/Hoogle backend, parser improvements, test writing, new feature implementation or bug fixing. Our issue tracker[1] is up to date if you are interested. Thanks! [1]: https://github.com/haskell/haddock/issues -- Mateusz K.

3 5

Maintaining test-suite dependencies with cabal
by Bram Neijt 06 Sep '14

06 Sep '14

Dear reader, I have a single executable package in Cabal[1] and I have added a test for it using an example configuration from the ltc package[2]. With my test on my executable I can't depend on the main package, but I seem to have to repeat the dependencies of my executable, or split off functionality into a library. [3] Can I easily depend on the dependencies of another package or should I create a library and depend on that in my test and executable? All source is at: https://github.com/bneijt/after/ Greetings, Bram [1] https://github.com/bneijt/after/blob/master/after.cabal [2] https://github.com/scvalex/ltc/blob/master/ltc.cabal [3] A part of my cabal file added below executable after main-is: Main.hs build-depends: base >=4.7 && <4.8, options ==1.*, directory ==1.2.*, parallel-io ==0.3.*, filepath ==1.3.*, unix ==2.7.* hs-source-dirs: src ghc-options: -Wall default-language: Haskell2010 test-suite afterTests hs-source-dirs: test src main-is: AfterTest.hs type: exitcode-stdio-1.0 build-depends: base >=4.7 && <4.8, unix ==2.7.*, -- Here because of after depending on it directory ==1.2.*, -- Here because of after depending on it filepath ==1.3.*, -- Here because of after depending on it test-framework, test-framework-hunit, HUnit default-language: Haskell2010

6 6

ANNOUNCE: hemokit 0.6.3 - Now with OpenVibe compatibility
by Niklas Hambüchen 02 Sep '14

02 Sep '14

Heya, out is Hemokit 0.6.3, which can now be connected to the OpenVibe EEG framework. OpenVibe allows fancy stuff like spelling words with your mind: Video: https://www.youtube.com/watch?v=08GNE6OdNcs Docs: http://openvibe.inria.fr/coadapt-p300-stimulator-tutorial There is a new tutorial on how to set up Hemokit+OpenVibe at: https://github.com/nh2/hemokit/wiki/OpenVibe If you set up something cool with that, don't forget to tell me about it! Grab Hemokit: https://hackage.haskell.org/package/hemokit Stand-alone Linux and Windows binaries are also available: https://github.com/nh2/hemokit/releases

2 1

LFM for Haskell bittorrent effort
by Mateusz Kowalczyk 01 Sep '14

01 Sep '14

Hi, For this or another reason, no bittorrent libraries/clients available today seem to suit my needs: they are either too slow, too memory inefficient, bundled with a client which often can't run in a headless environment or broken in some other way or don't implement all the common BEPs. I came to the conclusion that I'll probably have to write one. Happily, whenever I mentioned the topic in #haskell, there was quite a bit of interest each time so I'm looking to recruit people to join me in this effort. First a brief overlook of what's already available in the Haskell environment: * Combinatorrent[1] – a rather old client, no longer maintained with the last Hackage upload in 2010. Only supports few BEPs and was not able to load in the .torrent file provided by Ubuntu. I have spoken to jlouis who wrote this, you can read the conversation at [2]. He himself says that nowadays you can do better performance wise with available libraries. Additionally, this comes with a client on top rather than just being a library. * conjure – not touched since 2008 * bittorrent – seems to be the closest to what I'd like but it is still incomplete and the library is in limbo. There is a lot of stuff that does not work or is commented out and for various reasons the maintainer is unavailable to help out. I have spoken to the maintainer and he himself would like to redesign the library. That's about it. There seem to be a few related tools for bencoding &c but nothing huge. I think the best way to go about this is to learn from Combinatorrent and bittorrent and start something fresh. I'll outline the goals I personally am looking for even though they might be obvious: * efficient, scalable – the library needs to be able to handle tens of thousands of active (announcing, not necessarily downloading) torrents at once. For reference, libtorrent-rakshasa + rtorrent is able to run about ~10k torrents in about 1GB of memory with low CPU usage. The downside is that the library crashes like no tomorrow and the client itself sucks. A slow library is useless to me but so is a fast but unstable one. * implements all the common BEPs – no use for a library if it doesn't work for a lot of cases. It needs to implement everything from [3] maybe except BEP 8. * sane interface – in the end we need to be able to build clients on top. Fortunately we can leverage Haskell's types to do this whereas the existing C/C++ bittorrent libraries seems to suffer badly here. * resilient – if I wanted a fast library which crashes every ten minutes I'd stick with libtorrent Basically, I'm looking to build a fully usable bittorrent library. Notably, I'm not looking for people to help to write a client (yet!). I plan to start as soon as time allows but it'd be great if there was more than just myself on board. Let me know one way another if you're interested in contributing. If you're just interested in the final product then that's fine too, I could always use more motivation! [1]: https://github.com/jlouis/combinatorrent [2]: http://ircbrowse.net/browse/haskell?id=18701612&timestamp=1406738464#t14067… [3]: http://www.bittorrent.org/beps/bep_0000.html -- Mateusz K.

1 1

Set (Set a) like container - but more efficient?
by Marc Weber 01 Sep '14

01 Sep '14

Does a Set (Set a) like container exist already but which is represented as tree internally, eg A ` - B - C ` - D ` - X - Y which would represent ABC ABD and AXY ? If it does not what would be a nice name to create such container? Marc Weber

3 3

cabal sdist and auto-generated modules
by Marios Titas 31 Aug '14

31 Aug '14

I am trying to run cabal sdist on a package where one of exposed modules does not exists because it is automatically generated by setup.hs. cabal refuses to do that because it cannot find the file corresponding to that module. Is there a solution to that problem? The package builds just fine.

3 5

RTS options to control name of eventlog file.
by Serguey Zefirov 31 Aug '14

31 Aug '14

Is there any? Because when running and profiling two same programs they will write into same eventlog file. Not a good situation.

1 0

[ANN] igrf-0.2
by Douglas McClean 31 Aug '14

31 Aug '14

igrf is a library that provides an implementation of the International Geomagnetic Reference Field, which is just what it sounds like. I've tested it against NOAA's online calculator, but use it at your own risk. Note that the input is in geocentric and not geodetic coordinates. There is haddock documentation, I'm working on figuring out why it isn't on hackage and how to fix it. -Doug McClean

2 1