- Glasgow-haskell-users

New trac policy
by Ian Lynagh 30 Apr '10

30 Apr '10

Hi all, We have made some changes to the way in which we use trac, our bug tracker. The details are all documented here: http://hackage.haskell.org/trac/ghc/wiki/WorkingConventions#TheBugTracker but the highlights are below. We no longer have branch milestones (like 6.12-branch). Instead, we will make better use of the ticket priorities to differentiate tickets: * highest priority tickets are blockers for that release * high priority tickets are those that we also plan to fix before releasing * we will also try to fix as many lower priority tickets as possible Any tickets that are more than 2 major releases old (e.g. filed against 6.10, when 6.14 is about to be released) will be moved to the _|_ milestone, unless there is reason to keep them more visible (e.g. a patch attached for review, or significant support in the CC field). Thanks Ian

1 0

Default value for numCapabilities?
by Dimitry Golubovsky 30 Apr '10

30 Apr '10

Hi, As a followup to the discussion [1] about the portable way to find the number of CPUs/cores: how is the default value of numCapabilities [2] set when +RTS -N is not on the command line? Does GHC runtime figure out the number of cores itself, or it is by default 1 unless specified on the command line? Thanks. --------------------------- [1] http://haskell.org/pipermail/haskell-cafe/2010-April/076911.html [2] http://hackage.haskell.org/packages/archive/base/latest/doc/html/GHC-Conc.h… -- Dimitry Golubovsky Anywhere on the Web

5 9

ANNOUNCE: GHC version 6.12.2
by Ian Lynagh 27 Apr '10

27 Apr '10

============================================================== The (Interactive) Glasgow Haskell Compiler -- version 6.12.2 ============================================================== The GHC Team is pleased to announce a new patchlevel release of GHC. This release contains a number of bugfixes relative to 6.12.1, so we recommend upgrading. Release notes are here: http://haskell.org/ghc/docs/6.12.1/html/users_guide/release-6-12-2.html How to get it ~~~~~~~~~~~~~ The easy way is to go to the web page, which should be self-explanatory: http://www.haskell.org/ghc/ We supply binary builds in the native package format for many platforms, and the source distribution is available from the same place. Packages will appear as they are built - if the package for your system isn't available yet, please try again later. Background ~~~~~~~~~~ Haskell is a standard lazy functional programming language; the current language version is Haskell 98, agreed in December 1998 and revised December 2002. GHC is a state-of-the-art programming suite for Haskell. Included is an optimising compiler generating good code for a variety of platforms, together with an interactive system for convenient, quick development. The distribution includes space and time profiling facilities, a large collection of libraries, and support for various language extensions, including concurrency, exceptions, and foreign language interfaces (C, whatever). GHC is distributed under a BSD-style open source license. A wide variety of Haskell related resources (tutorials, libraries, specifications, documentation, compilers, interpreters, references, contact information, links to research groups) are available from the Haskell home page (see below). On-line GHC-related resources ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Relevant URLs on the World-Wide Web: GHC home page http://www.haskell.org/ghc/ GHC developers' home page http://hackage.haskell.org/trac/ghc/ Haskell home page http://www.haskell.org/ Supported Platforms ~~~~~~~~~~~~~~~~~~~ The list of platforms we support, and the people responsible for them, is here: http://hackage.haskell.org/trac/ghc/wiki/Contributors Ports to other platforms are possible with varying degrees of difficulty. The Building Guide describes how to go about porting to a new platform: http://hackage.haskell.org/trac/ghc/wiki/Building Developers ~~~~~~~~~~ We welcome new contributors. Instructions on accessing our source code repository, and getting started with hacking on GHC, are available from the GHC's developer's site run by Trac: http://hackage.haskell.org/trac/ghc/ Mailing lists ~~~~~~~~~~~~~ We run mailing lists for GHC users and bug reports; to subscribe, use the web interfaces at http://www.haskell.org/mailman/listinfo/glasgow-haskell-users http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs There are several other haskell and ghc-related mailing lists on www.haskell.org; for the full list, see http://www.haskell.org/mailman/listinfo/ Some GHC developers hang out on #haskell on IRC, too: http://www.haskell.org/haskellwiki/IRC_channel Please report bugs using our bug tracking system. Instructions on reporting bugs can be found here: http://www.haskell.org/ghc/reportabug

3 4

FFI calls: is it possible to allocate a small memory block on a stack?
by Denys Rtveliashvili 27 Apr '10

27 Apr '10

Good morning, Yesterday I did a few tests to measure the performance of FFI calls and found that the calls themselves are very quick (1-2 nanosecond). However, there is a kind of FFI calls when one have to allocate a temporary memory block (for a struct, or a temporary buffer). One of examples is a call to "gettimeofday" or "clock_gettime". Unfortunately, the usual way of doing it (using the "alloca" function) is quite slow (~40 nanoseconds). I was wondering, is there any way to allocate a small chunk of data on a thread's stack? That should be cheap, as by large it is just a shift of a pointer and, perhaps, a few other trivial operations. I understand that it is not safe to allocate large blocks on the stack. But we could possibly have a function similar to "alloca" which would allocate small blocks on stack and would use the "alloca" for big ones. With kind regards, Denys Rtveliashvili

7 17

Getting a GHC repository got easier: new instructions
by Simon Marlow 26 Apr '10

26 Apr '10

Our GHC repositories on darcs.haskell.org have now been upgraded to "hashed" format, with some nice consequences: - Using --lazy, getting a GHC repo over the network only takes a few minutes - No need to download tarballs any more - No complicated instructions about how to avoid case-insensitive filesystem issues on Windows and Mac The new simpler instructions are here: http://hackage.haskell.org/trac/ghc/wiki/Building/GettingTheSources We recommend using darcs 2.4 or later for the best performance. Note that there are issues with 2.4 on Windows right now [1], so it might be handy to have an earlier version hanging around too, eg. 2.3.1. comments welcome! Cheers, Simon http://lists.osuosl.org/pipermail/darcs-users/2010-April/023736.html

2 2

three dots of :browse
by Kazu Yamamoto 26 Apr '10

26 Apr '10

Hello, If I use :browse a module with GHC 6.12, it sometimes displays garbage. Here is an example: Prelude> :browse Data.IP data AddrRange a = iproute-0.2.0:Data.IP.Range.AddrRange {addr :: a, mask :: a, mlen :: Int} (snip) data AddrRange a = iproute-0.2.0:Data.IP.Range.AddrRange {..., mask :: a, ...} data AddrRange a = iproute-0.2.0:Data.IP.Range.AddrRange {..., mlen :: Int} "..." is the garbage. Due to this, I cannot parse the output of :browse. This is not displayed with GHC 6.10. Q1) What is the intention of "..."? Q2) How to prevent it so that I can obtain output which I can parse? --Kazu

4 6

index*OffAddr
by Roman Leshchinskiy 23 Apr '10

23 Apr '10

In package vector, primitive vectors (the ones that Data.Vector.Unboxed is built on top of) are represented as follows (ByteArray and friends are wrappers for various GHC primitives provided by package primitive): data Vector a = Vector Int -- offset into the ByteArray Int -- length ByteArray -- data This representation supports cheap slicing which is quite crucial. However, indexing into such vectors is a bit more expensive than necessary: index (Vector i _ arr) j = indexByteArray arr (i+j) Ultimately, this requires 2 additions to get the element's address: <base address off the ByteArray> + ((i + j) * <size of element>) I'd like to always allocate pinned ByteArrays and store the starting address of the vector instead of the offset: data Vector a = Vector Addr Int ByteArray This would make indexing cheaper as it would require only one addition: index (Vector addr i _) = indexOffAddr addr i This is quite a big deal if indexing happens in an inner loop (some algorithms become up to 20% faster). Of course, the backend could optimise the offset-based version by performing partial redundancy elimination but it doesn't and it probably wouldn't get all interesting cases even if it did. So the second version is better. The problem is that I can't implement it because I must touch the ByteArray after accessing the memory. This results in code like this which hides the constructor, breaking various optimisations: case indexIntOffAddr# addr# i# of { n# -> case touch# arr# realWorld# of { _ -> I# n# }} After thinking about this for a while, I came up with two possible solutions. One is to provide a "pure" version of touch#: use# :: o -> o' -> o' such that use# x y = y. This would change the code above to: I# (use# arr# (indexIntOffAddr# addr# i#)) I don't know how to implement this, though, because use# would have to be able to return arbitrary (unboxed) types and the code generator doesn't really seem to support this. A perhaps simpler solution is to add a new set of primitives: indexIntOffAddrUsing# :: o -> Addr# -> Int# -> Int# ... These would take an additional argument which they'd touch and otherwise ignore. The code would then become: I# (indexIntOffAddrUsing# arr# addr# i#) Incidentally, the index*OffAddr# primitives don't seem to be used anywhere. Any thoughts? Roman

2 1

GHC version 6.12.2 - testsuite results
by Jens Petersen 23 Apr '10

23 Apr '10

Hi, FYI I just ran the full testsuite (my first time) on a fedora devel build for Fedora 14 and got the following results: * i686 (all) OVERALL SUMMARY for test run started at gum agd 23 7:20:47 saaku UTC 2010 2375 total tests, which gave rise to 13152 test cases, of which 0 caused framework failures 2787 were skipped 10016 expected passes 322 expected failures 1 unexpected passes 26 unexpected failures Unexpected passes: length001(ghci) Unexpected failures: CPUTime001(optasm,threaded2) T1969(normal) T2486(optc) T3245(optc,profc) T3286(optc,profc) arith008(optc) arr016(optc) arr017(optc) arrowrun002(optc,profc) cgrun034(optc) cholewo-eval(optc,profc) concprog001(ghci) fast2haskell(optc,profc) ffi009(optc,profc) fun_insts(optc,profc) numrun012(optc,profc) signals002(threaded2) since it takes a while to run I thought I would report the results here for the record. :) * x86_64 (all) OVERALL SUMMARY for test run started at gum agd 23 7:38:09 saaku UTC 2010 2375 total tests, which gave rise to 13152 test cases, of which 0 caused framework failures 2772 were skipped 10057 expected passes 321 expected failures 0 unexpected passes 2 unexpected failures Unexpected failures: T3245(threaded2) concprog001(ghci) For full details see: http://koji.fedoraproject.org/koji/taskinfo?taskID=2133402 I am guessing the testsuite is run more on 64bit Linux. :) Thank you, Jens ps With "make fast" on Fedora 13 I got just: * i686 (fast) OVERALL SUMMARY for test run started at gum agd 23 9:09:38 saaku UTC 2010 2375 total tests, which gave rise to 13147 test cases, of which 0 caused framework failures 11024 were skipped 2062 expected passes 59 expected failures 0 unexpected passes 2 unexpected failures Unexpected failures: T1969(normal) T2486(optc) For 64bit there were no unexpected fast results. :) See http://koji.fedoraproject.org/koji/taskinfo?taskID=2133525

2 1

-K in 6.12.2
by Serge D. Mechveliani 23 Apr '10

23 Apr '10

Dear GHC developers, I am trying ghc-6.12.2 on Debian Linux, i386-family, on the DoCon test. There is a difference in memory management, with respect to 6.12.1. For the test compiled under -O, 2300k in "./Main +RTS -K2300k -RTS" is the minimal memory option of this kind for the test to finish without break. In 6.12.2, 90k is sufficient, maybe, GHC ignores this "-K", -"M" ... Could you explain, please? Regards, ----------------- Serge Mechveliani mechvel(a)botik.ru

1 1

Unicode alternative for '..' (ticket #3894)
by Roel van Dijk 21 Apr '10

21 Apr '10

I'm a big fan of the UnicodeSyntax [1] language extension. But I don't particularly like the alternative for the ellipsis '..'. I'm not sure if it was a conscious choice or a mistake to use the '⋯' character. I haven't really encountered that symbol before except for matrices and the like [2]. Therefore I propose to change the character from '⋯' to '…'. I submitted a bug report for this a few weeks ago [3]. Today I attached a patch which implements this change. Here are 4 code snippets for comparison: -- Simple ASCII import Data.Bool ( Bool(..) ) f :: [Int] f = [1, 3 .. 10] ++ [10..100] -- Current situation (MIDLINE HORIZONTAL ELLIPSIS, U+22EF) import Data.Bool ( Bool(⋯) ) f ∷ [Int] f = [1, 3 ⋯ 10] ++ [10⋯100] -- Proposed change (HORIZONTAL ELLIPSIS, U+2026) import Data.Bool ( Bool(…) ) f ∷ [Int] f = [1, 3 … 10] ++ [10…100] -- Another alternative (TWO DOT LEADER, U+2025) import Data.Bool ( Bool(‥) ) f ∷ [Int] f = [1, 3 ‥ 10] ++ [10‥100] The TWO DOT LEADER also looks nice, but I think we must consider more than looks alone (which is a matter of fonts) and take the semantics into account. I would really like some feedback on this since it is a change that breaks backwards compatibility (even though it is a really small change). Regards, Roel van Dijk 1 - http://www.haskell.org/ghc/docs/latest/html/users_guide/syntax-extns.html#u… 2 - http://en.wikipedia.org/wiki/Ellipsis#In_mathematical_notation 3 - http://hackage.haskell.org/trac/ghc/ticket/3894

4 6