- Glasgow-haskell-users

Re: GHC 7.0.1 (or very strange dimensional-0.8.0.1) bug
by Pavel Perikov 26 Jan '11

26 Jan '11

Hi, Jeremy. Probably I didn't read your message carefully enough. Sorry for that. In my case there's no recursive code sqrt calls nroot that calls Prelude.nroot and Prelude./. Does that qualify? pavel >> On 25.01.2011, at 22:35, Jeremy Shaw wrote: >> >>> There is a weird type-checking bug in 7.0.1 that causes loopy behavior: >>> >>> http://hackage.haskell.org/trac/ghc/ticket/4809 >>> >>> Not sure if that is what is happening to you or not. Though in my experience it did not actually print <<loop>>, it just hung. > My understanding of the bug is that the type-checker failed to properly detect and handle super classes in recursive dictionaries. As a result the dictionaries call each other in a loop and nothing ever happens.. > You mentioned that the 'let' trick sometimes fixed things. In the code I had trouble with, subtle changes would make the code magically start working. For example, changing *unused* functions in 'where' clauses would cause code to suddenly start working :) > > Anyway, since you are certain your issue is not related, you can just ignore my message. > > - jeremy > > On Jan 25, 2011, at 1:43 PM, Pavel Perikov wrote: > >> It is NOT type checking bug. It causes Rec {} in core and _|_ in runtime :) >> >

1 0

backward compatibility
by Kazu Yamamoto 25 Jan '11

25 Jan '11

Hello, I have been using GHC HEAD for some months and am suffering from the breaks of backward compatibility. 1) MANY packages cannot be complied with GHC HEAD because of lack of FlexibleInstances and BangPatterns. 2) The network package on github cannot be compiled because the layout handling of GHC HEAD became more severe. For instance, here is such code from Network/Socket.hsc. allocaBytes (2 * sizeOf (1 :: CInt)) $ \ fdArr -> do _ <- throwSocketErrorIfMinus1Retry "socketpair" $ c_socketpair (packFamily family) (packSocketType stype) protocol fdArr Of course, indentation is necessary before "_". But this can be compiled with GHC 7.0.1 but cannot with GHC HEAD. I sent feedback to some maintainers of packages. Some quickly fixed it and registered it again. But others did not respond. That is reality. So, my question is why GHC HEAD does not maintain backward compatibility? What are befits for giving it up? --Kazu

11 21

RFC: Compiler plugins for GHC (was: Release/git plans)
by austin seipp 23 Jan '11

23 Jan '11

(moved into g-h-u mainline to avoid cluttering discussion around new GHC plans. Anybody who has comments on the plugins work is encouraged to reply here, not there.) Neil, Preemptive TL;DR: I don't quite know, but I'd be willing to work on it. I seem to remember at the time Max originally did his work (2008,) dynamic linking outside of the home-grown linker inside GHCi (a rather ad-hoc, special-use linker) was not available for any platforms GHC supported. I wouldn't know what windows support lacked at the time it was initially written, and I'm not sure about the state of it now is the main thing I'm getting at I suppose. I didn't know enough about GHC at the time. If my memory serves correctly, Clemens Fruhwirth initally wrote the patches for dynamic linking as we know it for GHC in 2007, although they were only for linux. Later on, Simon M and Duncan Coutts did the remaining work to get it release-quality ready on linux sometime around when the new build system for GHC hit. I seem to remember Well-Typed LLC *also* doing work on also supporting that form of dynamic linking on windows. As a feature it seems to touch several parts of GHC for every supported platform, if it is to support the use-cases we would expect (like writing DLL/shared objects, or also having the compiler being able to dynamically link objects - like plugins.) I can't for the life of me remember if any of this work went into mainline GHC, or what the current state of dynamic linking on windows is. At this exact moment, I do not have a windows machine to test or develop GHC HEAD on - although we're in luck, as I should have a local windows instance to use as a personal machine within the week. I have only tested the patch on Linux and OS X Snow Leopard against GHC HEAD - I am honestly not even aware of what is necessary to build a development version of GHC on windows. But, I would be more than willing and happy to work on it and work with GHC HQ to support it if you're a potential user. I wouldn't want to shaft Windows users anyway. So, if anybody can point out how to get GHC development on windows up and running, I think I can point myself in the right direction. I'll be sure to get back to you on how things go, Neil. On Sat, Jan 22, 2011 at 11:20 AM, Neil Mitchell <ndmitchell(a)gmail.com> wrote: > Hi Austin, > > The compiler plugins work is a great, and I'd be a likely user. The > original version wasn't supported on Windows, because GHC on Windows > lacked various forms of dynamic linking. Does the current patch you've > prepared work on Windows? > > Thanks, Neil > > On Sat, Jan 22, 2011 at 10:29 AM, Max Bolingbroke > <batterseapower(a)hotmail.com> wrote: >> On 21 January 2011 23:59, austin seipp <as(a)hacks.yi.org> wrote: >>> Perhaps Max can >>> elaborate on why this design was rejected in favor of the current one, >>> so we can see how and where it falls down, and what we really want. >> >> The only reason really is that it added a lot of mechanism. From the >> top of my head: >> * Parsing etc for PHASE pragmas that declared phase objects >> * A new namespace for phases >> * Stuff to gather declared phases from all imported modules during compilation >> * A built-in phase for each core pass >> * A solver that ordered core passes and plugin passes according to the phases >> >> So it was a lot of trouble for relatively little gain. In an effort to >> keep the delta against GHC small I threw it out in favour of the much, >> much simpler design we have today. >> >>> Thomas pointed out the Scala compiler plugin design document, so I'll >>> be sure to read over it this weekend when I get the chance to cook up >>> ideas. >> >> The Scala plugins project was just starting when I was working on GHC >> plugins so there was no design doc I could refer to at that time. >> Shame :-( >> >> Thanks for taking the lead on resurrecting plugins, Austin! >> >> Cheers, >> Max >> >> _______________________________________________ >> Glasgow-haskell-users mailing list >> Glasgow-haskell-users(a)haskell.org >> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users >> > -- Regards, Austin -- Regards, Austin

2 1

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