June 2011 - Glasgow-haskell-users

Wiki page about new memcpy/memmove/memset primops need a home
by Johan Tibell 14 Jun '11

14 Jun '11

Hi, I intend to write a short wiki page explaining the design and use of the new memcpy/memmove/memset primops we added recently. Where would be a good place to put such a page? Cheers, Johan

3 3

Re: How to install GhC on a Mac without registering?
by Malcolm Wallace 14 Jun '11

14 Jun '11

On 6 Jun 2011, at 13:49, Lyndon Maydwell wrote: > I would be fantastic if XCode wasn't a dependency. ... > > Not to detract at all from the work of the wonderful GHC and Haskell > Platform contributors in any way. For me it would just make it that > much easier to convince mac-using friends to give Haskell a try. The ghc team already bundle a copy of gcc in their Windows distribution, precisely because it can be fiddly to get a working copy of gcc for that platform otherwise. I wonder if they would consider the possibility of shipping gcc on Mac too? (There may be good reasons not to do that, but let's have the discussion.) Regards, Malcolm

10 17

Re: How to install GhC on a Mac without registering?
by Lars Viklund 10 Jun '11

10 Jun '11

On Fri, Jun 10, 2011 at 11:31:01PM +1000, Manuel M T Chakravarty wrote: > Lars Viklund: > > On Fri, Jun 10, 2011 at 09:24:41PM +1000, Manuel M T Chakravarty wrote: > >> Well, then get the DVDs bundled with your Mac and install Xcode from those, or sign up at developer.apple.com and get it there. BTW, Mac users (and esp devs) upgrade very quickly, much faster than, say, Windows users. > > > > I disagree with the assumption that OS X people are quick to upgrade. > > The last set of figures I saw on adoption were something along the lines > > of 15% on 10.6, with almost a third of the users on 10.4 and below, > > taken from some article I read the other week on the rising wave of OS X > > viruses and countermeasures. > > Those numbers sound completely wrong and I'd like to see a credible source before I believe them. As just one data point on Snow Leopard adoption, have a look at > > http://daringfireball.net/2009/09/snow_leopard_adoption_rate > > I would say that readers of Daring Fireball are fairly tech savvy people with an above average percentage of developers. But consider this, > > "it took about five days for 10.6 to pass 10.5" > > Five days from the release of the OS for 50% of the DF readers to upgrade to Snow Leopard. My browser history had it, with what I assume is a much better sample size than "the DF readers", and being much more current: http://www.zdnet.com/blog/hardware/apples-mac-defender-update-allows-users-… Re-visiting the URI, I notice that the low percentages I vaguely recalled were total OS marketshare, not OS X alone. Normalizing 10.6 v. 10.5 v. 10.4 yields this, which aligns with data mentioned in the thread: * 10.6 - 68.6% * 10.5 - 24.4% * 10.4 - 7.0% That's a solid 30% or so not on current OS X. I do have a problem with your "developers are more up to date" argument, as everyone who wants to build any package with native bits needs a toolchain installed. There's a fair amount of such packages on Hackage. This counter-argument is of course void and null if there's popular sane ways to deploy binary application bundles on OS X akin to Bamse, but to my knowledge no such beast exists. -- Lars Viklund | zao(a)acc.umu.se

1 0

Using CPP in Cmm
by Johan Tibell 09 Jun '11

09 Jun '11

Hi, I'm trying to write a test case to make sure memset gets unrolled correctly by the backend. Unrolling only happens when the alignment and size is statically known so writing a simple Cmm loop that calls memset won't work as the sizes won't be statically known. I want to test memset with a large (e.g. 10-20) different variations of alignments and sizes and I don't want to cut-n-paste large chunks of code so I tried the following (best viewed with a fixed-width font): #define TEST_MEMSET(ALIGN,SIZE) \ W_ size, src, dst, off, alignV, set; \ bits8 set8; \ \ // Need two versions as memset takes a word for historical reasons \ // but really its a bits8. We check that setting has ben done \ // correctly at the bits8 level, so need bits8 version for \ // checking. \ set = 4; \ set8 = 4::bits8; \ \ size = SIZE; \ alignV = ALIGN; \ ("ptr" src) = foreign "C" malloc(size); \ ("ptr" dst) = foreign "C" malloc(size); \ prim %memset(src "ptr", set, size, alignV) []; \ \ // Check memset worked \ off = 0; \ while1: \ if (off == size) { \ goto while1_end; \ } \ if (bits8[src + off] != set8) { \ foreign "C" printf(memsetErr "ptr") []; \ goto while1_end; \ } \ off = off + 1; \ goto while1; \ while1_end: \ foreign "C" free(src); \ foreign "C" free(dst); unrollintrinTest { // Test many different combinations here. TEST_MEMSET(8,8); TEST_MEMSET(4,8); jump %ENTRY_CODE(Sp(0)); } This seems to work (i.e. the test passes) but it shouldn't! I'd expect the fact that we generate several labels (and temp registers) with the same name to lead to problems, but it doesn't seem to. I initially tried to use the CPP ## string concatenation operator to create unique names (tedious, but works) but GHC runs CPP in traditional mode so that doesn't work. I also tried to introduce local {} blocks in the Cmm to deal with the scoping of identifiers (like you would in C) but that's not supported. Any idea of how I can generate the same piece of Cmm code (that contains labels and locally defined identifiers) multiple times without name capturing? Cheers, Johan

2 1

RE: The role of INLINE and INLINABLE on recursive functions
by Simon Peyton-Jones 09 Jun '11

09 Jun '11

INLINE: - no effect for a recursive function - for a non-recursive function, always inline a call that (a) is applied to as many args as the LHS of the defn (b) has some interesting context. Ie (\y x-> f x y) doesn't inline f INLINEABLE a) For type-class overloaded functions (including recursive ones) - makes them auto-specialise at call sites in other modules - allows SPECIALISE pragmas for them in other modules b) For non-recursive functions, makes GHC willing, but not super-eager, to inline at call sites. Ie just use GHC's usual inlining rules. The difference from not having the pragma is that the *original* RHS is inlined (if GHC decides to) rather than the optimised RHS. Does that help? The dual role of INLINEABLE is a bit confusing. And the utility of (b) isn't clear to me. Simon | -----Original Message----- | From: Johan Tibell [mailto:johan.tibell@gmail.com] | Sent: 09 June 2011 12:06 | To: Simon Peyton-Jones | Subject: The role of INLINE and INLINABLE on recursive functions | | Hi, | | This comment on Trac got me curious: | | "Ok, we looked at this, and it turns out that 6.12.3 desugars `forever` | differently: in 6.12, a local recursive `let` was introduced, which meant | that `forever` could be inlined (and hence specialised) at every call | site, whereas in 7.0 the desugarer leaves the function as a top-level | recursive function which cannot be inlined. | | The solution is to add an `INLINABLE` pragma for `forever`, which will | allow it to be specialised at a call site." | | What's the meaning of INLINE or INLINABLE on a recursive function? | Normally we don't inline recursive functions (when would we stop | inlining?) so it's unclear to me what the meaning of the pragmas would | be in this cases. I know that INLINABLE on a recursive function that | takes a type class dictionary leads to call site specialization of | that function (but not "inlining"). | | People often use this transformation to get recursive functions inlined: | | f = ... f ... | | f_transformed = go | where go = ... go ... | {-# INLINE f_transformed #-} | | Could we get the same result by just adding an INLINE pragma to the original f? | | Cheers, | Johan

3 2

crash caused by generic visitor (?)
by Ranjit Jhala 09 Jun '11

09 Jun '11

Hi all, I'm trying to extract the set of identifiers that are read in given source file. To this end, I wrote the following code (full source at end.) ------------------------------------------------------------------------ main = do fname <- (!! 0) `fmap` getArgs tcm <- loadTypecheckedSource fname putStrLn $ showPpr tcm -- this works fine putStrLn $ showPpr $ allIds tcm -- this causes the crash return () allIds :: Data a => a -> [Id] allIds = listify (\x -> case (x :: Id) of _ -> True) ------------------------------------------------------------------------ and where: loadTypecheckedSource :: FilePath -> IO TypecheckedSource unfortunately, when I compile and run it, I get the dreaded: Bug: Bug: panic! (the 'impossible' happened) (GHC version 7.0.3 for i386-unknown-linux): placeHolderNames Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug Turns out that the problem is when the file contains a type annotation. That is, ./Bug Test00.hs crashes, when Test00.hs is: module Test where x :: Int x = 0 but does not crash when the file is: module Test where x = 0 Can anyone tell me why listify chokes in the latter case? (And how one might get around the problem?) I include the full source below (compiled with: ghc --make Bug, using ghc 7.0.3) Thanks! Ranjit. ------------------------------------------------------------------------------------------------------ import GHC import Outputable import DynFlags (defaultDynFlags) import GHC.Paths (libdir) import System.Environment (getArgs) import Control.Monad import qualified Data.List as L import Data.Data import Data.Generics.Schemes (listify) main = do fname <- (!! 0) `fmap` getArgs tcm <- loadTypecheckedSource fname putStrLn $ showPpr tcm -- this works fine putStrLn $ showPpr $ allIds tcm -- this causes the crash return () allIds :: Data a => a -> [Id] allIds = listify (\x -> case (x :: Id) of _ -> True) loadTypecheckedSource :: FilePath -> IO TypecheckedSource loadTypecheckedSource fname = defaultErrorHandler defaultDynFlags $ runGhc (Just libdir) $ do df <- getSessionDynFlags setSessionDynFlags df tgt <- guessTarget fname Nothing setTargets [tgt] load LoadAllTargets res <- load LoadAllTargets if failed res then pprPanic "Load Failed!!" (text "AAARGH!") else tm_typechecked_source `fmap` getTypecheckedModule fname findModSummary :: GhcMonad m => FilePath -> m ModSummary findModSummary fname = do msums <- depanal [] False case L.find ((fname ==) . ms_hspp_file) msums of Just msum -> return msum Nothing -> pprPanic "ModuleName Lookup Failed!!" (text "AARGHC!") getTypecheckedModule :: GhcMonad m => FilePath -> m TypecheckedModule getTypecheckedModule = findModSummary >=> parseModule >=> typecheckModule

2 2

getCPUTime implementation incorrect?
by Evan Laforge 06 Jun '11

06 Jun '11

I've just noticed that getCPUTime is returning erratic results for me: GHCi, version 7.0.3: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer-gmp ... linking ... done. Loading package base ... linking ... done. Loading package ffi-1.0 ... linking ... done. Loading package filepath-1.2.0.0 ... linking ... done. Prelude> :m System.CPUTime Prelude System.CPUTime> getCPUTime 9696631700340362000000 Prelude System.CPUTime> getCPUTime 1333572622260398592000000 Prelude System.CPUTime> getCPUTime 21577331579851694000000 Prelude System.CPUTime> getCPUTime 21577331579861838000000 Prelude System.CPUTime> getCPUTime 1061231477620269514000000 Prelude System.CPUTime> getCPUTime 9965140170836829000000 This is ghc 7.0.3, OS X 10.6.7, and it's the x86_64 version downloaded from http://www.haskell.org/ghc/download_ghc_7_0_3 So, I looked at the CPUTime.hsc source in the base library, and it uses CTime to get tv_sec and tv_usec fields from the struct timeval. Unfortunately, and I never knew this, tv_usec is not time_t, but is suseconds_t. On my OS X, these are different types: time_t is 64 bits but suseconds_t is 32 bits. After writing my own getCPUTime that uses Int32 for tv_usec it's back to working again. But the proper way to do this is probably to introduce CSUSeconds (I'm guessing it stands for signed microseconds), which I guess means editing the autoconfig to put a new define in HsBaseConfig.h. I dont know anything about autoconfig, but it's probably easy enough for someone is :)

2 2

Compiling 32-bit GHC on a 64-bit Mac
by Johan Tibell 06 Jun '11

06 Jun '11

Hi, I need to reproduce a bug that only appears on 32-bit machines. I don't own such a machine but I was hoping I could compile a 32-bit GHC on my Mac and debug using that. What changes do I need to make (e.g. to build/mk) to build a 32-bit GHC? Cheers, Johan

3 3

ANNOUNCE: GHC 7.0.4 Release Candidate 1
by Ian Lynagh 04 Jun '11

04 Jun '11

We are pleased to announce the first release candidate for GHC 7.0.4: http://www.haskell.org/ghc/dist/7.0.4-rc1/ This includes the source tarball, installers for OS X and Windows, and bindists for amd64/Linux, i386/Linux, amd64/FreeBSD and i386/FreeBSD. Please test as much as possible; bugs are much cheaper if we find them before the release! Release notes: * A floating point regression in 7.0.3 affecting x86 has been fixed (#5149). * The GHCi linker now handles partially stripped object files (#5004). This fixes loading the ghc package in ghci when it's been stripped, which is often the case in Linux distribution packages. * A runtime system bug with large heaps has been fixed (#5086). * A runtime system bug when heap profiling has been fixed (#5127). * A runtime system bug when heap profiling has been fixed (#5127). * A runtime system bug, which caused incorrect results and segfaults when using FFI callbacks, has been fixed. * A runtime system bug, which occasionally caused parallel programs to <<loop>> when using -feager-blackholing, has been fixed (#5226). * Incorrect directory permissions when installing have been fixed (#4982). * Some improvements have been made to the new Cabal testsuite support. * Cabal is now 1.10.2.0 (was 1.10.1.0). Thanks Ian, on behalf of the GHC team

2 1

Re: ld weirdness in unstable
by Joachim Breitner 02 Jun '11

02 Jun '11

Dear Joey, strange observation... for more eyes looking at it, I’m replying with full-quote to the GHC mailing list as well. (That list is subscriber-only, AFAIK, in case you want to follow up there). Am Mittwoch, den 01.06.2011, 19:09 -0400 schrieb Joey Hess: > I've noticed this problem with ld process size recently while doing > edit-compile-debug development cycles with git-annex on unstable. > > Normally, ld runs in seconds, using maybe 170 mb or memory according to > top, but I suspect real memory is somewhat less. > > Sometimes I get into a state where every link takes minutes, and > apparently uses somewhat more memory and typically triggers the OOM > killer. > > Whenever this happens, I have to `make clean; make` and then it seems > back to normal. > > The build is being driven by ghc --make. And the best way to trigger it > seems to be to make changes to types, or other changes to core > modules that cause a fan-out effect where ghc needs to rebuild lots of > other modules. Greetings, Joachim -- Joachim "nomeata" Breitner Debian Developer nomeata(a)debian.org | ICQ# 74513189 | GPG-Keyid: 4743206C JID: nomeata(a)joachim-breitner.de | http://people.debian.org/~nomeata

1 0