June 2014 - ghc-devs - Haskell.org

old-time.git/tests/time004.hs is DST-sensitive :-/
by Herbert Valerio Riedel 26 Oct '14

26 Oct '14

Hi *, if anyone wonders, why TEST=time004 suddenly fails: it's sensitive to DST (and depends on your system's TZ-config): http://git.haskell.org/packages/old-time.git/blob/HEAD:/tests/time004.hs For me, the comparison this unit-test checks now suddenly fails, because the DST-switch occurs on different days in 2012 and 2013 in my TZ, i.e. length "Sun Oct 27 10:56:42 CET 2013" /= length "Sat Oct 27 11:56:42 CEST 2012" Does anyone happen to know what the rationale behind this 'time004' unit test was? Cheers, hvr

1 1

FFI: c/c++ struct on stack as an argument or return value
by Yuras Shumovich 07 Oct '14

07 Oct '14

Hi, Right now ghc's FFI doesn't support c/c++ structures. Whenever we have foreign function that accepts or returns struct by value, we have to create wrapper that accepts or returns pointer to struct. It is inconvenient, but actually not a big deal. But there is no easy workaround when you want to export haskell function to use it with c/c++ API that requires structures to be passed by value (Usually it is a callback in c/c++ API. You can't change it's signature, and if it doesn't provide some kind of "void* userdata", then you are stuck.) I'm interested in fixing that. I'm going to start with 'foreign import "wrapper" ...' stuff. Calling conventions for passing c/c++ structures by value are pretty tricky and platform/compiler specific. So initially I'll use libffi for that (it will work when USE_LIBFFI_FOR_ADJUSTORS is defined, see rts/Adjustor.c). It will allow me to explore design space without bothering about low level implementation details. Later it could be implemented for native (non-libffi) adjustors. Is anybody interested it that? I appreciate any comments/ideas. Right now I don't have clear design. It would be nice to support plain haskell data types that are 1) not recursive, 2) has one constructor and 3) contains only c/c++ types. But it doesn't work with c/c++ unions. Any ideas are welcome. An example how to use libffi with structures: http://www.atmark-techno.com/~yashi/libffi.html#Structures Thanks, Yuras

7 19

Extending fold/build fusion
by Akio Takano 05 Sep '14

05 Sep '14

Hi, I have been thinking about how foldl' can be turned into a good consumer, and I came up with something that I thought would work. So I'd like to ask for opinions from the ghc devs: if this idea looks good, if it is a known bad idea, if there is a better way to do it, etc. The main idea is to have an extended version of foldr: -- | A mapping between @a@ and @b@. data Wrap a b = Wrap (a -> b) (b -> a) foldrW :: (forall e. Wrap (f e) (e -> b -> b)) -> (a -> b -> b) -> b -> [a] -> b foldrW (Wrap wrap unwrap) f z0 list0 = wrap go list0 z0 where go = unwrap $ \list z' -> case list of [] -> z' x:xs -> f x $ wrap go xs z' This allows the user to apply an arbitrary "worker-wrapper" transformation to the loop. Using this, foldl' can be defined as newtype Simple b e = Simple { runSimple :: e -> b -> b } foldl' :: (b -> a -> b) -> b -> [a] -> b foldl' f initial xs = foldrW (Wrap wrap unwrap) g id xs initial where wrap (Simple s) e k a = k $ s e a unwrap u = Simple $ \e -> u e id g x next acc = next $! f acc x The wrap and unwrap functions here ensure that foldl' gets compiled into a loop that returns a value of 'b', rather than a function 'b -> b', effectively un-CPS-transforming the loop. I put preliminary code and some more explanation on Github: https://github.com/takano-akio/ww-fusion Thank you, Takano Akio

5 20

Proposal: run GHC API tests on fast
by Edward Z. Yang 02 Sep '14

02 Sep '14

Currently, most GHC API tests are not run on 'make fast', ostensibly because linking against the GHC API can take a while. I propose that change this, and run GHC API tests by default. Reasons: 1. The GHC API is closely tied a lot of internal structure of GHC, so it's very easy to make a change, track it through the rest of the compiler, but forget to update the tests/documentation. 2. We can boost this into poor man's testable documentation. The idea is to duplicate all GHC API examples in the manual in the test suite, and have a comment on all of the examples asking the developer to update the manual. (Or we could automatically extract the snippets from the manual, but that's work and this I could do in a few minutes.) 3. I don't think running these tests will add that much extra run time to the test suite; certainly interactively the time spent linking is unnoticeable. Let's set a one week discussion period for this proposal. Thanks, Edward

4 9

Can't install 32-bit ghc-7.8.1 on 64-bit xubuntu 14.04
by kyra 30 Aug '14

30 Aug '14

Hi, I have unpacked ghc-7.8.1-i386-unknown-linux-deb7.tar.xz to ~/data/Work/ghc-7.8.1-i386. Now I have the following: awson@awsonvirt:~/data/Work/ghc-7.8.1-i386$ ./configure --prefix=/home/awson/data/ghc-7.8.1-i386 checking for path to top of build tree... utils/ghc-pwd/dist-install/build/tmp/ghc-pwd-bindist: line 3: /home/awson/data/Work/ghc-7.8.1-i386/utils/ghc-pwd/dist-install/build/tmp/ghc-pwd: No such file or directory configure: error: cannot determine current directory ghc-pwd is definitely there but it does not start it seems. Perhaps, the system lacks some shared libs or something. There absolutely no problems with 64-bit ghc. Regards, Kyra

5 8

7.8.1 plan
by Austin Seipp 16 Jul '14

16 Jul '14

Hello all, As I'm sure you're all aware, it's the final countdown. The (final) source distribution will be up within a few hours, and then we'll continue on from there. Yay! I will post an update when that is, so Gabor/Luke/Karel can make binaries from the sources as I do so. Second, there are just two things I want to note: - For people following the Windows debacle in #8834, there has been a bug fixed, but one may still remain. The TL;DR of this is that we currently have a committed workaround in place we'll keep using, but Simon has made some good steps towards finding the bug. - Lots of people, I'm sure, are wondering what's going on with Safe Haskell and the GND story. The TL;DR of this one is that "everything will be the same as in 7.6" - GND is considered an Unsafe feature, and Data.Coerce is behind Unsafe bars. From a safety point of view, nothing should change for library authors I cherry picked these changes into 7.8 last night. In the mean time, the 7.8 branch is effectively closed. If you have something to commit, and I *really* mean something, you can let me know. But your deadline is hours, not days! I'm doing a final review of all the trees before pushing the library tags, and after that I'll begin rolling the sdist. Anyway, the time is finally here, so let's get it over with! -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/

16 41

Proposal: require Haddock comment for every new top-level function and type in GHC source code
by Johan Tibell 13 Jul '14

13 Jul '14

Hi! I found myself exploring new parts of the GHC code base the last few weeks (exciting!), which again reminded me of my biggest frustration when working on GHC: the lack of per-function/type (Haddock) comments. GHC code is sometimes commented with "notes", which are great but tend to (1) mostly cover the exceptional cases and (2) talk about the implementation of a function, not how a caller might use it or why. Lack of documentation, in GHC and other software projects, usually has (at least) two causes: - Programmers comment code they think is "complex enough to warrant a comment". The problem is that the author is usually a poor judge of what's complex enough, because he/she is too familiar with the code and tends to under-document code when following this principle. - Documenting is boring and tends to have little benefit the person writing to documentation. Given lack of incentives we tend to document less than we ought to. I've only seen one successful way to combat the lack of documentation that stems from the above: have the project's style guide mandate that top-level functions and types (or at least those that are exported) have documentation. This works well at Google. Anecdote: we have one code base inside Google that was until recently exempt from this rule and documentation is almost completely absent in that code base, even though hundreds of engineers work on and need to understand it every day. This breeds institutional knowledge problems i.e. if the author of a core piece of code leaves, lots of knowledge is lost. *Proposal: *I propose that we require that new top-level functions and types have Haddock comments, even if they start out as a single, humble sentence. I've found that putting even that one sentence (1) helps new users and (2) establishes a place for improvements to be made. There's a strong "broken window" effect to lack of comments, in that lack of comments breeds more lack of comments as developers follow established practices. We should add this requirement to the style guide. Having it as a written down policy tends to prevent having to re-hash the whole argument about documentation over and over again. This has also helped us a lot at Google, because programmers can spend endless amount of time arguing about comments, placement of curly braces, etc. and having a written policy helps cut down on that. To give an idea of how to write good comments, here are two examples of undocumented code I ran into in GHC and how better comments would have helped. *First example* In compiler/nativeGen/X86/Instr.hs there's a (local) function called mkRUR, which is a helper function use when computing instruction register usage. The first question that I asked upon seeing uses of that function was "what does RUR stand for?" Given the context the function is in, I guessed it stands for read-update-read, because R is used to mean "read" in the enclosing function and "updating" is related to "reading" so that must be what U stands for. It turns out that it stands for RegUsageReadonly. Here's a comment that would have captured, in a single sentence, what this function is for: -- | Create register usage info for instruction that only -- reads registers. mkRUR src = src' `seq` RU src' [] where src' = filter (interesting platform) src That already a big improvement. A note about the register filtering, which means that not all registers you pass to the function will be recorded as being read in the end, could also be useful. Aside: providing a type signature, which would have made it clear that the return type is RU, might also have helped in this particular case. *Second example* In the same file there a function called x86_regUsageOfInstr. It's the function that encloses the local function mkRUR above. I could figure out that this function has something to do with register usage, of the instruction passed as an argument, and that register usage is important for the register allocator. However, trying to understand in more detail what that meant was more of challenge than it needed to be. First, a comment more clearly explaining what computing register usage means in practice would be helpful: -- | Returns which registers are read and written by this -- instruction, as a (read, written) pair. This info is used -- by the register allocator. x86_regUsageOfInstr :: Platform -> Instr -> RegUsage The reason mentioning that the return value is essentially a (read, written) pair is helpful is because the body of the function a big case statement full of lines like this one: GCMP _ src1 src2 -> mkRUR [src1,src2] ... FDIV _ src dst -> usageRM src dst It's not immediately clear that all the various helper functions used here just end up computing a pair of the above form. A top-level comment lets you understand what's going on without understanding exactly what all these helper functions are doing. Thoughts? -- Johan

15 23

GHC silently turns off dynamic output, should this be an error?
by Christopher Rodrigues 08 Jul '14

08 Jul '14

Hello, I’ve investigated an issue (#9176) where ghc with --make -dynamic-too appears to run successfully but doesn’t generate some .dyn_hi files. The cause seems to be that GHC silently turns off dynamic-too output when it finds an inconsistency between the .hi and .dyn_hi interface hashes of an imported module. The symptom, for me, is that some cabal packages will build but fail to install. The real problem is most likely not in the failing package, but in an imported module from a package that’s already installed. I’m inclined to say that GHC should stop with an error in this situation, which would produce a visible error when the file fails to compile. However, since GHC carefully avoids bailing out, I wonder if I’m missing something. Is there a good reason to turn off dynamic-too output instead of reporting an error? Additionally, is it ever valid to have a pair of .hi and .dyn_hi files with different interface hashes? Or is it invalid data, in the same way that a corrupted .hi file is invalid data? I’m inclined to say that it is invalid data, because -dynamic-too promises to generate two different (static and dynamic) implementations of the same Haskell code, taking two different implementations of the same imported Haskell modules as input. If the inputs aren’t really two different implementations of the same Haskell code, you’ve somehow provided invalid input.

5 5

Continuous Integration and Cross Compilation
by William Knop 08 Jul '14

08 Jul '14

Hello all, I’ve seen quite a few comments on the list and elsewhere lamenting the time it takes to compile and validate ghc. It’s troublesome not only because it’s inconvenient, but, more seriously, people are holding off on sending patches in which stifles development. I would like to propose a solution: 1. Implement proper cross-compilation, such that build and host may be different— e.g. a linux x86_64 machine can build ghc that runs on Windows x86. What sort of work would this entail? 2. Batch cross-compiled builds for all OSs/archs on a continuous integration service (e.g. Travis CI) or cloud service, then package up the binaries with the test suite. 3. Send the package to our buildbots, and run the test suite. 4. (optional) If using a CI service, have the buildbots send results back to the CI. This could be useful if we'd use GitHub for pulls in the future *. Cheers, Will * I realize vanilla GitHub currently has certain annoying limitations, though some of them are pretty easy to solve via the github-services and/or webhooks. I don’t think this conflicts with the desire to use Phabricator, either, so I’ll send details and motivations to that thread.

7 12

GHC 7.8.3 release
by Austin Seipp 03 Jul '14

03 Jul '14

Hello all, After a long week, I've finally gotten a little time to reply to emails, and I mainly have one question I'd like to ask. First, please direct your attention to this: https://ghc.haskell.org/trac/ghc/query?status=closed&status=merge&status=pa… This is the 7.8.3 milestone, but it only considers things that are: - 1) Fixed - 2) Going to be merged - 3) Are a patch to be still merged. That is, it is a solid representation of the difference between 7.8.2 and the 7.8 branch tip. The question is: when should we do the release? There are several bugs there that seem quite problematic for users - #9045, #7097, #9001, #8768 and #9078 in particular. If these bugs are really problematic (and I sort of feel they are) then the release can happen soon. I can do it within a week from now, and we could punt more to a 7.8.4 release. I ask this because my time to dedicate to GHC is a bit thin right now, so you must help me decide what's important! So please let me know - just a general vote in favor of doing it within some X timeframe (even 'real soon' or 'a week would be great') would be nice. PS: I apologize for the lack of status updates and brief email - my time for GHC has been in very short order the past two weeks in particular, and I've finally just returned to a computer (not mine) for right now to ask this. PPS: This might also impact the 7.10 schedule, but last Simon and I talked, we thought perhaps shooting for ICFP this time (and actually hitting it) was a good plan. So I'd estimate on that a 7.8.4 might happen a few months from now, after summer. -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/

13 21