October 2014 - ghc-devs

msys2 python2 for running tests
by Gintautas Miliauskas 12 Oct '14

12 Oct '14

Hi Herbert, I saw your comment on the Windows build page about msys2's python2. It used to be broken, a patch of mine recently went through to fix the problem. If you can verify that msys2's python2 works correctly for the entire test suite, feel free to update the instructions <https://ghc.haskell.org/trac/ghc/wiki/Building/Preparation/Windows> accordingly. Also, it looks like you added a section for setting up sshd on msys2. I think it's great, but I don't think it should be on the main ghc build page, it's just a separate concern (and it's also interesting not just to people building ghc). Would you mind moving that text off to a separate wikipage and adding a link to it instead? -- Gintautas Miliauskas

1 0

Curious Windows GHCi linker behaviour .o vs. .dll
by Herbert Valerio Riedel 12 Oct '14

12 Oct '14

Hello *, I assume this is a well known issue to MSYS2/Windows developers, so I hope somebody may be able to provide more insight for me to better understand the underlying problem of https://github.com/haskell/time/issues/2 So the prototype for tzset() is simply void tzset(void); and it's defined in `msvcrt.dll` as far as I can tell; Consider the following trivial program: module Main where foreign import ccall unsafe "time.h tzset" c_tzset :: IO () main :: IO() main = c_tzset When compiled with GHC 7.8.3, the resulting executable works and has the following tzset-symbols: $ nm tz.o | grep tzset U tzset $ nm tz.exe | grep tzset 000000000050e408 I __imp_tzset 00000000004afc40 T tzset However, when loaded into GHCi, the RTS linker fails to find `tzset`: $ ghci tz.hs WARNING: GHCi invoked via 'ghci.exe' in *nix-like shells (cygwin-bash, in particular) doesn't handle Ctrl-C well; use the 'ghcii.sh' shell wrapper instead GHCi, version 7.8.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. [1 of 1] Compiling Main ( tz.hs, interpreted ) ByteCodeLink: can't find label During interactive linking, GHCi couldn't find the following symbol: tzset ... However, when I prefix a `_` to the symbol-name in the FFI import, i.e. foreign import ccall unsafe "time.h tzset" c_tzset :: IO () Now, GHCi happily loads the module and is apparently able to resolve the `tzset` symbol: $ ghci tz.hs WARNING: GHCi invoked via 'ghci.exe' in *nix-like shells (cygwin-bash, in particular) doesn't handle Ctrl-C well; use the 'ghcii.sh' shell wrapper instead GHCi, version 7.8.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. [1 of 1] Compiling Main ( tz.hs, interpreted ) Ok, modules loaded: Main. *Main> Moreover, compiling and running the program still works, and the additional underscore is visible in `nm` as well: $ nm tz.o | grep tzset U _tzset $ nm tz.exe | grep tzset 000000000050e558 I __imp__tzset 00000000004b8050 T _tzset What's going on here? Why does one need to add an artificial underscore to FFI imported symbols for GHCi to resolve symbols? Is this a bug? Cheers, hvr

3 6

Re: [GHC] #9628: Add Annotations to the AST to simplify source to source conversions
by Alan & Kim Zimmerman 10 Oct '14

10 Oct '14

Ok, then I think the middle ground is keyword-specific annotations, as proposed by Neil. What should happen is that the raw annotations are used by a tool layer such as ghc-exactprint or HaRe, and other more casual users will not have to worry about the internal detail. On Fri, Oct 10, 2014 at 9:13 PM, GHC <ghc-devs(a)haskell.org> wrote: > #9628: Add Annotations to the AST to simplify source to source conversions > -------------------------------------+------------------------------------- > Reporter: alanz | Owner: alanz > Type: feature | Status: new > request | Milestone: > Priority: normal | Version: 7.9 > Component: Compiler | Keywords: > Resolution: | Architecture: Unknown/Multiple > Operating System: | Difficulty: Unknown > Unknown/Multiple | Blocked By: > Type of failure: | Related Tickets: > None/Unknown | > Test Case: | > Blocking: | > Differential Revisions: D297 | > -------------------------------------+------------------------------------- > > Comment (by simonpj): > > I don't have data, but people are already complaining about the amount of > code generated by data type declarations #9669. Have you counted how many > data constructors there are in `HsSyn`? It's a LOT. > > It just feels like a sledgehammer to crack a nut. > > Simon > > -- > Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9628#comment:21> > GHC <http://www.haskell.org/ghc/> > The Glasgow Haskell Compiler >

1 0

Capturing commas in Api Annotations (D297)
by Alan & Kim Zimmerman 10 Oct '14

10 Oct '14

I am currently working annotations into the parser, provided them as a separate structure at the end of the parse, indexed to the original by SrcSpan and AST element type. The question I have is how to capture commas and semicolons in lists of items. There are at least three ways of doing this 1. Make sure each of the items is Located, and add the possible comma location to the annotation structure for it. This has the drawback that all instances of the AST item annotation have the possible comma location in them, and it does not cope with multiple separators where these are allowed. 2. Introduce a new hsSyn structure to explicitly capture comma-separated lists. This is the current approach I am taking, modelled on the OrdList implementation, but with an extra constructor to capture the separator location. Thus ``` data HsCommaList a = Empty | Cons a (HsCommaList a) | ExtraComma SrcSpan (HsCommaList a) -- ^ We need a SrcSpan for the annotation | Snoc (HsCommaList a) a | Two (HsCommaList a) -- Invariant: non-empty (HsCommaList a) -- Invariant: non-empty ``` 3. Change the lists to be of type `[Either SrcSpan a]` to explicitly capture the comma locations in the list. 4. A fourth way is to add a list of SrcSpan to the annotation for the parent structure of the list, simply tracking the comma positions. This will make working with the annotations complicated though. I am currently proceeding with option 2, but would appreciate some comment on whether this is the best approach to take. Option 2 will allow the AST to capture the extra commas in record constructors, as suggested by SPJ in the debate on that feature. Regards Alan

2 3

Again: Uniques in GHC
by p.k.f.holzenspies＠utwente.nl 10 Oct '14

10 Oct '14

Dear all, I *finally* had some time again to look at how to properly redo Uniques in GHC. A few things stood out to me: - The export-list of Unique has some comments stating that function X is only exported for module Y, yet is used elsewhere. This may be because these comments do not show up in haddock etc. leading some people to think they're up for general use. In my refactoring, I'm sticking the restriction in the function name, so it's no longer mkUniqueGrimily, but rather mkUniqueOnlyForUniqSupply (making the name even longer should discourage their use more). If at all possible, these should be removed altogether asap. - The implementation is based on FastInts, which, on most machines nowadays, is a 64-bit thing. The serialisation in BinIface is explicitly based on Word32s. Aside from the obvious potential (albeit with a low probability) for errors, this lead me to wonder about 32/64-bitness. Is there a reason for 64-bit versions of GHC to write Word32s, or is this a historic thing? Must the interface-files be bit-compatible between different versions (32/64-bits) of the compiler? Lastly, is the choice of whether "this" is a 32 or 64-bit version completely determined by WORD_SIZE_IN_BITS (MachDeps.h)? - There are a few libraries that are explicitly dependent on GHC, yet have their own versions of Unique. So far, I've seen this for Hoopl and Template Haskell. They have unboxed ints to do the job. I have not researched whether they manipulate them in any way, or just store things. If the former; I would like to call to reconsider this, because it seems like a poor separation of concerns toe me. If the latter, I think refactoring them to use Unique instead of Int# should be straightforward. ? The point of refactoring Unique is to no longer have low-level optimisations of manually unpacking (and repacking using the MkUnique constructor), which should serve as a lovely test of how far the optimisations have come. Furthermore, it seemed that the use of characters to encode the domain was somewhat awkward, but I refer anyone interested to earlier posts on this list. Thoughts? Comments? Suggestions? Objections? Regards, Philip

7 18

heres a 32bit OS X 7.8.3 build
by Carter Schonwald 09 Oct '14

09 Oct '14

hey all, I know all of you wish you could run 32bit ghc 7.8.3 on your snazzy mac OS 10.9, so here you are! http://www.wellposed.com.s3.amazonaws.com/opensource/ghc/releasebuild-unoff… $ shasum -a256 ghc-7.8.3-i386-apple-darwin.tar.bz2 1268ce020b46b0b459b8713916466cb92ce0c54992a76b265db203e9ef5fb5e5 ghc-7.8.3-i386-apple-darwin.tar.bz2 is the relevant SHA 256 digest NB: I believe I managed to build it with intree-gmp too! So it wont' need GMP installed in the system (but I could be wrong, in which case brew install gmp will suffice) cheers -Carter

2 4

Re: [GHC] #9628: Add Annotations to the AST to simplify source to source conversions
by Alan & Kim Zimmerman 09 Oct '14

09 Oct '14

Yes, I was thinking last night I need to update the GhcAstAnnotations wiki page. Will do so and clean up. On Thu, Oct 9, 2014 at 5:20 PM, GHC <ghc-devs(a)haskell.org> wrote: > #9628: Add Annotations to the AST to simplify source to source conversions > -------------------------------------+------------------------------------- > Reporter: alanz | Owner: alanz > Type: feature | Status: new > request | Milestone: > Priority: normal | Version: 7.8.3 > Component: Compiler | Keywords: > Resolution: | Architecture: Unknown/Multiple > Operating System: | Difficulty: Unknown > Unknown/Multiple | Blocked By: > Type of failure: | Related Tickets: > None/Unknown | > Test Case: | > Blocking: | > Differential Revisions: D246 | > -------------------------------------+------------------------------------- > > Comment (by simonpj): > > I'm afraid I'm very confused by this thread. > > * There are two different Phab tickets: Phab:D246 is linked to this > ticket, but Phab:D297 (I believe) may supercede it. If so please let's > redirect the "Differential revision" field of this ticket, and explicit > mark the moribund one as moribund. > > * The wiki page GhcAstAnnotations does not appear to reflect any of the > discussion. Indeed it appears to describe only the first bullet from > comment:3 > > * comment:3 identifies two issues, which Alan (in comment:4) agreed were > separate. Yet [http://www.haskell.org/pipermail/ghc- > devs/2014-October/006487.html Neil certainly thinks] that the new > Phab:D297 is exclusively about issue 1. So maybe the new design > encompasses both issue 1 and issue 2? I have no idea. > > * There has been quite a lot of [http://www.haskell.org/pipermail/ghc- > devs/2014-October/006482.html traffic on ghc-devs] that is not captured > anywhere. That's fine: an email list is good for discussion. But my > input bandwidth is low and struggle to make sense of it all. And the > conclusions from the discussion may be useful. > > * Alan has posted a [http://www.haskell.org/pipermail/haskell- > cafe/2014-October/116267.html useful summary] to Haskell Cafe, which isn't > captured on a wiki anywhere. > > * Alan has done some work identifying users for the new features, and > written some email notes about that; again this would be useful to > capture. > > I am too slow to take a big patch and try to reverse-engineer the thought > process that went into it. Would be possible to update the wiki page > (presumably GhcAstAnnotations) to state > * The problem we are trying to solve > * The user-visible (or at least visible-to-client-of-GHC-API) design > * Other notes about the implementation. > > Covering the larger picture about the GHC API improvements you are making > (eg no landmines) would be helpful. Maybe you need more than one page. > > I'm delighted you are doing this. But I don't want to throw a lot of code > into GHC without a clear, shared consensus about what it is we are trying > do to, and how we are doing it. > > Thanks. > > Simon (drowning in review requests) PJ > > -- > Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9628#comment:12> > GHC <http://www.haskell.org/ghc/> > The Glasgow Haskell Compiler >

1 0

Tentative high-level plans for 7.10.1
by Austin Seipp 09 Oct '14

09 Oct '14

Hi *, Today, Mikolaj and I discussed and plotted out a quick, high-level roadmap for the 7.10.1 release, based on our earlier plans. Consider this the 10,000 foot view (the last one was like a view from space). **The TL;DR** - We think the freeze and branching for major things will happen in _5 to 6 weeks from now_, in early/mid November. The release will happen in Feburary. Developers, please read some code (see below), and get your stuff in! The initial bug list will come next week for you to look at. --------------------------- The not-quite-TL;DR version: We'll get about 4 months of fixes into STABLE. This stability period will come at a typically low-point during the year, when many people will be preoccupied with Holidays. So, we're trying to aim far ahead, and try to give STABLE a long, official 'cooking period'. Feature inclusions after the freeze _are_ negotiable, but not large changes. Expect us to say "No" more often this time around. The STABLE branch will only be touchable by me and Herbert. We do not believe we will ship a 7.8.4 at all, contrary to what you may have seen on Trac - we never decided definitively, but there is likely not enough time. Over the next few days, I will remove the defunct 7.8.4 milestone, and re-triage the assigned tickets. We don't have any expected time for an RC just yet. I will spend the next few days culling the 7.10.1 milestone to contain appropriate tickets. Expect a list of these tickets early next week, with more info. Developers: if you have time, **please** review some code, and get your stuff in too! Petition people to review things of yours. Review things other people wrote, and learn new stuff. High five each other afterwords. Here are the major patches on Phabricator still needing review, that I think we'd like to see for 7.10.1: - D168: Partial type signatures - D72: New rebindable syntax for arrows. - D155: LLVM 3.5 compatibility - D169: Source code note infrastructure - D202: Injective type families - Edward Yang's HEAP_ALLOCED saga, D270 through D293 - D130: Implementation of hsig (module signatures) It is possible not all of these will make it. But I think they're solid priorities to try and land soon. Please let me know if you disagree with this. After I publish the bug list, please also take a look, and use your judgement to include or remove things you think are sensible for 7.10.1 (I trust your judgement, and we can always talk it out later). I think that's all. Here's a full roadmap below from our notes: ----------------------------------- - Expected ETA for 7.10.1: - Roughly Feburary 2015. - Expected code freeze ~5wks - Entails making the stable branch - Tentatively create branch on Nov. 7th. - ~3-4mo's of freeze time for STABLE. - Empirically a low-point in development due to Holidays, but gives us a lot of time. - Cull and probably remove the 7.8.4 milestone. - Simply not enough time to address almost any of the tickets in any reasonable timeframe before 7.10.1, while also shipping them. - Only one, probably workarouadble, not game-changing bug (#9303) marked for 7.8.4. - No particular pressure on any outstanding bugs to release immediately. - ANY release would be extremely unlikely, but if so, only backed by the most critical of bugs. - We will move everything in 7.8.4 milestone to 7.10.1 milestone. - To accurately catalogue what was fixed. - To eliminate confusion. - Cull the 7.10.1 milestone - Currently ~700 tickets. - 31 high tickets. - 1 highest priority ticket. - Bulk of them will need moved out to 7.12.1. - Ask developers/users to move things back in. - Demote any old tickets out of highest according to bug tracker policy. - Alert people these are our priorities. - Go through ONLY high/highest priority tickets for 7.10.1. - Email ghc-devs with plans. - Major tentative patches for 7.10 - D168: Partial type signatures - D72: New rebindable syntax for arrows. - D155: LLVM 3.5 compatibility (not big, but important for users!) - D169: Source code note infrastructure (partially reviewed, Austin to review) - D202: Injective type families - Edward Yang's HEAP_ALLOCED saga, D270 through D293 - D130: Implementation of hsig (module signatures) -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/

18 35

Warning when deriving Foldable/Traversable using -Wall
by Alan & Kim Zimmerman 08 Oct '14

08 Oct '14

I am not sure how to report bugs against the current development version of GHC. Should this go into Trac? The current HEAD gives a spurious unused declaration when deriving Typable/Traversable Details Compiling against current HEAD (0ed9a2779a2adf0347088134fdb9f60ae9f2735b) Adding test('T9069w', extra_clean(['T9069.o', 'T9069.hi']), multimod_compile, ['T9069', '-Wall']) to testsuite/tests/deriving/should_compile/all.T results in +[1 of 1] Compiling T9069 ( T9069.hs, T9069.o ) + +T9069.hs:5:1: Warning: + The import of ‘Data.Foldable’ is redundant + except perhaps to import instances from ‘Data.Foldable’ + To import instances alone, use: import Data.Foldable() + +T9069.hs:6:1: Warning: + The import of ‘Data.Traversable’ is redundant + except perhaps to import instances from ‘Data.Traversable’ + To import instances alone, use: import Data.Traversable() *** unexpected failure for T9069w(optasm) The file being compiled is -------------------------------------------- {-# LANGUAGE DeriveTraversable #-} module T9069 where import Data.Foldable import Data.Traversable data Trivial a = Trivial a deriving (Functor,Foldable,Traversable) ---------------------------------------------

4 4

Re: [commit: ghc] master: Make Data.List.takeWhile fuse: fix #9132 (d14d3f9)
by Joachim Breitner 08 Oct '14

08 Oct '14

Hi, Am Mittwoch, den 08.10.2014, 06:53 +0000 schrieb git(a)git.haskell.org: > commit d14d3f92d55a352db7faf62939127060716c4694 > Author: Joachim Breitner <mail(a)joachim-breitner.de> > Date: Wed Oct 8 08:53:26 2014 +0200 > > Make Data.List.takeWhile fuse: fix #9132 > > Summary: > Rewrites takeWhile to a build/foldr form; fuses repeated > applications of takeWhile. > > Reviewers: nomeata, austin > > Reviewed By: nomeata > > Subscribers: thomie, carter, ezyang, simonmar > > Projects: #ghc > > Differential Revision: https://phabricator.haskell.org/D322 > > GHC Trac Issues: #9132 nofib’s fft2’s allocs -23%, nice! (otherwise no differences worth mentioning). Greetings, Joachim -- Joachim “nomeata” Breitner mail(a)joachim-breitner.de • http://www.joachim-breitner.de/ Jabber: nomeata(a)joachim-breitner.de • GPG-Key: 0xF0FBF51F Debian Developer: nomeata(a)debian.org

1 0