- Glasgow-haskell-users

Release/git plans
by Simon Marlow 22 Jan '11

22 Jan '11

As promised, here are our plans for forthcoming GHC releases and the git switchover: - do a 7.0.2 RC as soon as possible, followed shortly by a release. Currently blocking this is a problem with Cabal that shows up on OS X 10.6, we hope to have this resolved soon. - switch the GHC repo to git (this is ready to go, we just need to flip the switch and do some work on the wiki build documentation) - switch the libraries and other repositories to git, once we have decided on the strategy (mirror or convert) for each one. - make a new stable branch for 7.2, and release 7.2.1 shortly after. So we'll be doing a 7.2.1 release much earlier than planned. Our motivation for doing this is: - the 7.0 branch is darcs, but the HEAD will be git, so the longer this situation persists the more difficult it is to merge changes. Hence we want to fork a new STABLE branch as soon as possible. - one of the fixes we need to make soon, to fix equality superclasses, is too large a change to put in the 7.0 branch. We also have some pending changes to the internal representation of coercions that will be disruptive in HEAD, and will make future merging to 7.0 difficult. - 7.0.2 should be a nice stable release, and HEAD is actually in pretty good shape right now too. FYI, the git repo is now attached to our Trac instance, so you can browse the source tree and history here: http://hackage.haskell.org/trac/ghc/browser it's not terribly fast, but it works. With git we'll be able to link directly to commits from tickets and vice-versa. The GHC git repo that we'll be using is here: http://darcs.haskell.org/ghc.git (note different from the URL for the testing repo, although it's the same repo). I'm mirroring this manually from the darcs repo, so it might lag a bit at times. Cheers, Simon

8 10

Re: [Haskell-cafe] Splittable random numbers
by Ryan Newton 22 Jan '11

22 Jan '11

Hi cafe, I want to add the ability to use AES-NI instructions on Intel architectures to GHC. Mainly I'd like to do splittable random number generators based on AES as was suggested at the outset of this email. (I met Burton Smith last week and this topic came up.) I was just reading the below thread about the plugin architecture which got me thinking about what the right way to add AES-NI is. (Disregarding for a moment portability and the issue of where to test cpuid...) http://www.haskell.org/pipermail/glasgow-haskell-users/2011-January/019874.… The FFI is always an option. But after reading the first N pages I could come across from google I'm still not totally clear on whether "unsafe" foreign calls can happen simultaneously from separate Haskell threads (and with sufficiently low overhead for this purpose). I also ran across the phrase "compiler primitive" somewhere wrt GHC: http://hackage.haskell.org/trac/ghc/wiki/AddingNewPrimitiveOperations Is that the right way to go? Or would the compiler plugin mechanism possibly allowing doing this without modifying mainline GHC? Thanks, -Ryan On Fri, Nov 12, 2010 at 6:26 PM, wren ng thornton <wren(a)freegeek.org> wrote: > On 11/12/10 5:33 AM, Richard Senington wrote: > >> It does not give the results you would want. This may have something to >> do with picking "good" parameters for the mkLehmerTree function. >> For example, using a random setup, I just got these results >> result expected range >> 16.814 expected = 16.0 (1,31) >> 16.191 expected = 16.5 (1,32) >> 16.576 expected = 17.0 (1,33) >> 17.081 expected = 17.5 (1,34) >> 17.543 expected = 18.0 (1,35) >> > > Have you run any significance tests? I wouldn't be surprised to see +/-0.5 > as within the bounds of expected randomness. I'm more worried about it > seeming to be consistently on the -0.5 end of things, than I am about it not > matching expectation (how many samples did you take again?). For small > ranges like this, a consistent -0.5 (or +0.5) tends to indicate off-by-one > errors in the generator. > > -- > Live well, > ~wren > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe(a)haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe >

2 2

Cleaning up after the Close button is pressed
by Colin Hume 21 Jan '11

21 Jan '11

Hi everyone, I posted previously on haskell-beginners about an issue which would have been better directed to this list. Since then, I have revisited the issue and am now even less certain of its cause. I have to perform cleanup when my application terminates. GHC.ConsoleHandler handles cleanup from Ctrl-C and Ctrl-Break very nicely under Windows. My sample handler and main function are shown at [1]. When I press Ctrl-C and Ctrl-Break during threadDelay, messages are written to console_event.log as I expected. When I press the Close button during threadDelay, no message is written to console_event.log. Am I missing something fundamental about handling the Close button or installing handlers? In case it makes a difference, I'm using GHC 6.12.3 under Windows XP. Thanks, Colin [1] module Main where import Control.Concurrent (threadDelay) import GHC.ConsoleHandler import System.IO onConsoleEventReceived :: ConsoleEvent -> IO () onConsoleEventReceived event = withFile "console_event.log" AppendMode $ \ file -> do hPutStrLn file $ case event of ControlC -> "Received Ctrl-C event" Break -> "Received Ctrl-Break event" Close -> "Received X button event" _ -> "Received other console event" hFlush file main :: IO () main = installHandler (Catch onConsoleEventReceived) >> threadDelay (20*1000000)

2 1

Re: Release/git plans
by Christian Höner zu Siederdissen 21 Jan '11

21 Jan '11

This is Haskell. One should abstract away the system used. Call it vcs-ghc@ and vcs.haskell.org ;-) Gruss, Christian * austin seipp <as(a)hacks.yi.org> [20.01.2011 22:19]: > Point taken, I personally think it's rather minor although it was > brought up before like I said, so perhaps others think differently. > > Either way, I, for one, welcome our new version control overlord. > > On Thu, Jan 20, 2011 at 3:09 PM, Isaac Dupree > <ml(a)isaac.cedarswampstudios.org> wrote: > > On 01/20/11 11:57, austin seipp wrote: > >>> > >>> The GHC git repo that > >>> we'll be using is here: > >>> > >>> http://darcs.haskell.org/ghc.git > >> > >> This is an incredibly minor note in my opinion (that was brought up > >> before IIRC) but, isn't it a little strange for ghc's git repository > >> to exist on darcs.haskell.org? Not that it's a problem, just slightly > >> confusing I guess. > > > > Yes, and the commits mailing-list is still called "cvs-ghc(a)haskell.org". > > The niceness of sounding right tends to be outweighed by the inconvenience > > of switching :) > > > > -Isaac > > > > _______________________________________________ > > Glasgow-haskell-users mailing list > > Glasgow-haskell-users(a)haskell.org > > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > > > > > > -- > Regards, > Austin > > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users(a)haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

1 0

Can't make sense of newArray# docs
by Johan Tibell 18 Jan '11

18 Jan '11

Hi, The docs for newArray# states: "Create a new mutable array of specified size (in bytes), in the specified state thread, with each element containing the specified initial value." Why is the size in bytes? Is Array# meant to be used both for boxed and unboxed values? For arrays of boxed values I'd expect the size to be the number of elements and the allocated size the number of elements multiplied by the size of a pointer. Are the docs correct? If so, how do I allocate an Array# of pointers? I'm trying to implement the following array type: data MurableArray s a = Array { unArray :: !(MutableArray# s a) } i.e. an array of boxed values. I can't figure out how to write new :: Int -> a -> ST s (MutableArray s a) where the first argument is the number of elements (of type a). Johan

4 3

ltrace on FFI calls
by Henning Thielemann 17 Jan '11

17 Jan '11

I want to trace calls from a Haskell program to LLVM. I tried ltrace and latrace. latrace didn't trace anything useful and ltrace shows at least the call to one function (LLVMBuildRetVoid), but not the other ones. I'm quite confident that I linked to LLVM dynamically, since the executable is small (35 KB, not 60 MB as when linking statically). Do GHC-generated programs call a foreign library in a way that bypasses ltrace?

1 1

New codegen failing test-cases
by Edward Z. Yang 14 Jan '11

14 Jan '11

I fired up the new codegen and ran make fast on the regression suite and the following new tests started failing: 3207(normal) 4030(normal) cgrun016(normal) cgrun045(normal) cgrun051(normal) dsrun005(normal) dsrun007(normal) dsrun008(normal) exceptionsrun001(normal) exceptionsrun002(normal) ffi021(normal) simplrun010(optc) strun002(optc) I plan on investigating them in further detail. Cheers, Edward

9 30

Re: [Haskell] ANN: extcore 1.0
by Scott Turner 14 Jan '11

14 Jan '11

On 2011-01-13 14:45, Tim Chevalier wrote: > Documentation for the External Core format itself lives at > http://www.haskell.org/ghc/docs/latest/html/ext-core/core.pdf Didn't find it there, but did find it at http://www.haskell.org/ghc/docs/latest/core.pdf

1 0

Re: RFC: migrating to git
by Malcolm Wallace 13 Jan '11

13 Jan '11

On 10 Jan 2011, at 14:02, Gregory Collins wrote: > +1. I don't have a lot of skin in this particular game (I'm not > currently a GHC contributor and am unlikely to become one in the near > future), but I can offer some anecdotal evidence: As another non-GHC contributor, my opinion should probably also count for little, but my experience with git has been poor. I have used git daily in my job for the last year. Like Simon PJ, I struggle to understand the underlying model of git, despite reading quite a few tutorials. I have a high failure rate with attempting anything beyond the equivalents of darcs record, push, and pull. When I use darcs, my local workflow typically involves lots of amend- record, cherry-picking, and multiple repos/branches. I have tried to do these things in git a few times and failed miserably. I am an old- fashioned unix command-line lover, but I find using the git command- line is next to impossible, and as a consequence do almost everything in git gui. If the gui interface does not let me do an action, then I often can't work out how to do it at all, even after googling. Mind you, some other people at work somehow manage to use git's support for branching reasonably successfully. But we have occasional mishaps where a repo is made totally unusable by somebody making a tiny mistake with their branching commands. Our standard advice at work for people who get their repo muddled is to throw it away, re- clone the master, and manually re-code their local changes from scratch (with the help of diff). If I were considering contributing minor patches to a project, the use of git would probably not deter me too much - I can cope with the simple stuff. But if I wanted more major involvement, git would definitely cause me to think twice about whether to bother. Regards, Malcolm

7 7

RE: Fwd:
by Jane Ren 10 Jan '11

10 Jan '11

Hi, I need to be able to take a piece of Haskell source code and get an simplified, typed, intermediate representation of the AST, which means I need to use compiler/coreSyn/CoreSyn.lhs So I'm first trying to get the desguaredModule of the source code with ... modSum <- getModSummary $ mkModuleName "..." p <- parseModule modSum t <- typecheckModule p d <- desugarModule t Now I'm really stuck on figuring out how to connect the variable d of type desugaredModule to compiler/coreSyn/CoreSyn.lhs to get Expr patterns like App, Let, Case, etc. Also, is it correct to get the deguaredModule first? At least CoreSyn.lhs seems to suggest this. Any suggestions would be greatly appreciated.

1 0