- ghc-devs - Haskell.org

deleting branches
by Simon Peyton Jones 10 Sep '14

10 Sep '14

I accidentally created a branch (in the main repo) called origin/origin/wip/new-flatten-skolems-Aug14 I was trying to make a local branch to track the existing origin/wip/new-flatten-skolems-Aug14, but only succeeded in creating a local branch called origin/wip/new-flatten-skolems-Aug14, which I then pushed, creating the one above. It's quite confusing to me that branches (listed with git branch -av) have names like wip/rae and remotes/origin/wip/rae I suspect that the "remotes/origin" part isn't really part of the name of the branch at all, even though it is not syntactically distinguished. Anyway, I'd like to delete that branch from the main repo on the server, but I don't know how to do so. I tried git branch -D origin/origin/wip/new-flatten-skolems-Aug14 error: branch 'origin/origin/wip/new-flatten-skolems-Aug14' not found. My model of branch naming is not working well. Can anyone advise? Simon

3 2

No context in error messages
by Corentin Dupont 09 Sep '14

09 Sep '14

Hi everybody, I am working with Hint, after some discussion with Daniel Gorin, I decided to post here, I hope it's the right place. My problem with Hint is that I cannot get context in error messages while interpreting a string. If you run the attached file example.hs, you get: GhcError {errMsg = "No instance for (GHC.Num.Num GHC.Base.String)\n arising from a use of `GHC.Num.+'\nPossible fix:\n add an instance declaration for (GHC.Num.Num GHC.Base.String)"} There is no context (line number, code snippets...), plus the error message uses fully qualified names, which is not very readable. It's very hard to figure out where the problem is when interpreting a long string. But the same error in a file that is loaded with Hint gives the correct message (uncomment the putStrLn in SomeModule.hs to get it): GhcError {errMsg = "<no location info>:\n [1 of 1] Compiling SomeModule ( SomeModule.hs, interpreted )"},GhcError {errMsg = "SomeModule.hs:5:22:\n No instance for (Num String) arising from a use of `+'\n Possible fix: add an instance declaration for (Num String)\n In the second argument of `($)', namely `\"bar\" + 1'\n In a stmt of a 'do' block: putStrLn $ \"bar\" + 1\n In the expression:\n do { putStrLn \"bar\";\n putStrLn $ \"bar\" + 1 }"} This error is much better: it gives line number plus some code snippets ("In the second argument of..."). There might be a flag that is not correctly set in GHC? After a quick look I'm thinking of GHC.DynFlags (I'm no expert). Now it is configured with: configureDynFlags :: GHC.DynFlags -> GHC.DynFlags configureDynFlags dflags = dflags{GHC.ghcMode = GHC.CompManager, GHC.hscTarget = GHC.HscInterpreted, GHC.ghcLink = GHC.LinkInMemory, GHC.verbosity = 0} Thanks, Corentin

1 1

Trying to fix an efficiency issue noted in a TODO in SAT.hs
by David Feuer 09 Sep '14

09 Sep '14

compiler/simplCore/SAT.hs has a TODO comment about the fact that it does a fair bit of appending onto the ends of lists, and that should be done differently. I made an attempt to fix it. The complexity of the recursion, however, leaves me uncertain as to whether I really did or not. I've attached a diff and I hope someone will be able to take a look at it. The only use of Sequence.fromList is source line 172, and the only significant use of Foldable.toList (aside from pretty-printing) is on source line 402. Note that the use of Sequence may be temporary—I want to get the right code structure down before choosing the best data structure. Thanks, David Feuer

3 2

What is testsuite/tests/rename/should_fail/rnfail018.hs supposed to test?
by David Feuer 09 Sep '14

09 Sep '14

When I compile this with 7.8.3, it gives an error message saying that type variables a and m are not in scope. If I add them to the forall, it tells me I need FlexibleContexts. If I add that, then it gives me an error about an ambiguous type variable. Clearly, something crashed ghc-4.04proto, but there's no indication of what that was. If this test is still at all relevant, it probably needs to be updated to target something more narrowly. The program: {-# LANGUAGE MultiParamTypeClasses, ExplicitForAll #-} module ShouldFail where -- !!! For-all with parens -- This one crashed ghc-4.04proto; the parens after the for-all fooled it class Monad m => StateMonad s m where getState :: m s setState0 :: forall b. (StateMonad (a,b) m => m a) setState0 = getState >>= \ (l,_r) -> return l David Feuer

2 1

NOTE: Minor downtime for Trac/ghc/git.haskell.org today
by Austin Seipp 07 Sep '14

07 Sep '14

Hi *, In about 1 hour from now (12:30pm CDT), Trac, git.haskell.org, and ghc.haskell.org may be temporarily unavailable for 5 to 10 minutes or so. We're moving the server to a new dedicated host as a result of all the availability problems the past few days. The downtime will mostly accommodate the time needed for DNS switchover to a new IP. As a bonus, the new server should keep us going for a very long time, and has a nice amount of bandwidth dedicated to it, as well as IPv6. Please DO NOT push things to the git repositories; it will be blocked. Don't edit Trac; we'll be revoking ACL write permissions most likely for a short window. Note that I have set the DNS TTLs for Haskell.org to a very low value to facilitate the IP change. If you have connectivity problems after that, let me know. I'll email again when the expected downtime is starting/completed. You can also check http://status.haskell.org for more. -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/

1 2

Re: Trying to fix an efficiency issue noted in a TODO in SAT.lhs
by David Feuer 07 Sep '14

07 Sep '14

Joachim Breitner wrote: > Did you profile first, and did it show up there? You know, premature > optimization... so it might be that your fix is a nice improvement and > useful exercise (and very welcome as such), but without much real-world > effect. You're right, of course. I read the comment and figured it made sense, but it may not really make much. In particular, the lists involved will usually be short, so O(n^2) may not actually be bad. It would probably be more valuable for me to start by trying to make it easier to follow what's going on (and I've submitted one patch to do so for one of the functions) and think about efficiency later or not at all. > BTW, code review is easier on Phabricator. Maybe you want to get started > using that? See https://ghc.haskell.org/trac/ghc/wiki/Phabricator for > instructions. I'll take a look. There are a million tools to learn.

1 0

Re: GHC AST Annotations
by Alan & Kim Zimmerman 07 Sep '14

07 Sep '14

If this is done right it can enable this sort of thing : http://www.davidchristiansen.dk/2014/09/06/pretty-printing-idris/ On Fri, Sep 5, 2014 at 5:11 PM, Alan & Kim Zimmerman <alan.zimm(a)gmail.com> wrote: > Hi Neil > > Thanks for the feedback. > > I am going to start putting together a proof of concept, aiming to > identify what annotations are needed to roundtrip source. > > The first version will make use of the index into a separate structure > scheme, so that it can be used with existing GHC ASTs. Hopefully the > information gained will help in understanding what is needed for the > changes to the future AST. > > The concept I will be working with is a pretty-printer, where relative > spacing for the particular elements is derived from the initial SrcSpan > information. Any new elements added or changed in the AST can then have > only relative information, and the final render should honour the layout > from the original. > > It may be possible to harmonise this with Chris Done's hindent package, > which is a code-specific pretty printer for haskell-src-exts. > > Alan > > > On Sat, Aug 30, 2014 at 11:18 PM, Neil Mitchell <ndmitchell(a)gmail.com> > wrote: > >> Since Alan is trying to do something for HaRe that I want for HLint on >> top of haskell-src-exts, he asked me for my opinions on the proposal. >> There seem to be two approaches to take: >> >> * Add SrcSpan's throughout. The HSE approach of having a list of inner >> source spans is nasty - the details of which source space goes where >> is entirely undocumented and hard to discover. Even worse, for things >> like instance, which may or may not have a where after, the number of >> inner SrcSpan's changes. Simon's idea of hsdo_do_loc is much cleaner, >> and easily extends to Maybe SrcSpan if the keyword is optional. >> >> * Having the annotation be a type parameter gives much greater >> flexibility. In particular, it would let you mark certain nodes as >> being added/deleted. However, since SrcSpan has an Int in it, you can >> always pass around a separate IntMap and make the SrcSpan really be an >> index into more detailed information. It's nasty, but only the people >> who use it pay for it. >> >> Both approaches have disadvantages. You could always combine both >> ideas, and have a SrcSpan and entirely separately an annotation (which >> defaults to (), rather than SrcSpanInfo), but maybe that's too much >> extra baggage on the AST. >> >> Thanks, Neil >> >> >> On Sat, Aug 30, 2014 at 3:32 PM, Alan & Kim Zimmerman >> <alan.zimm(a)gmail.com> wrote: >> > A further use case would be to be able to convert all the locations to >> be >> > relative, or include a relative portion, so that as tools manipulate >> the AST >> > by adding or removing parts the layout can be preserved. >> > >> > I think I may need to make a wip branch for this and experiment, it is >> > always easier to comment on concrete things. >> > >> > Alan >> > >> > >> > On Thu, Aug 28, 2014 at 10:38 PM, Simon Peyton Jones < >> simonpj(a)microsoft.com> >> > wrote: >> >> >> >> I thiink the key question is whether it is acceptable to sprinkle this >> >> kind of information throughout the AST. For someone interested in >> >> source-to-source conversions (like me) this is great, others may find >> it >> >> intrusive. >> >> >> >> It’s probably not too bad if you use record syntax; thus >> >> >> >> | HsDo { hsdo_do_loc :: SrcSpan -- of the word "do" >> >> >> >> , hsdo_blocks :: BlockSrcSpans >> >> >> >> , hsdo_ctxt :: HsStmtContext Name >> >> >> >> , hsdo_stmts :: [ExprLStmt id] >> >> >> >> , hsdo_type :: PostTcType } >> >> >> >> >> >> >> >> Simon >> >> >> >> >> >> >> >> From: Alan & Kim Zimmerman [mailto:alan.zimm@gmail.com] >> >> Sent: 28 August 2014 19:35 >> >> To: Richard Eisenberg >> >> Cc: Simon Peyton Jones; ghc-devs(a)haskell.org >> >> Subject: Re: GHC AST Annotations >> >> >> >> >> >> >> >> This does have the advantage of being explicit. I modelled the initial >> >> proposal on HSE as a proven solution, and I think that they were >> trying to >> >> keep it non-invasive, to allow both an annotated and non-annoted AST. >> >> >> >> I thiink the key question is whether it is acceptable to sprinkle this >> >> kind of information throughout the AST. For someone interested in >> >> source-to-source conversions (like me) this is great, others may find >> it >> >> intrusive. >> >> >> >> The other question, which is probably orthogonal to this, is whether we >> >> want the annotation to be a parameter to the AST, which allows it to be >> >> overridden by various tools for various purposes, or fixed as in >> Richard's >> >> suggestion. >> >> >> >> A parameterised annotation allows the annotations to be manipulated via >> >> something like for HSE: >> >> >> >> -- |AST nodes are annotated, and this class allows manipulation of the >> >> annotations. >> >> class Functor ast => Annotated ast where >> >> >> >> -- |Retrieve the annotation of an AST node. >> >> ann :: ast l -> l >> >> >> >> -- |Change the annotation of an AST node. Note that only the >> annotation >> >> of the node itself is affected, and not >> >> -- the annotations of any child nodes. if all nodes in the AST tree >> are >> >> to be affected, use fmap. >> >> >> >> amap :: (l -> l) -> ast l -> ast l >> >> >> >> >> >> >> >> Alan >> >> >> >> >> >> >> >> On Thu, Aug 28, 2014 at 7:11 PM, Richard Eisenberg <eir(a)cis.upenn.edu> >> >> wrote: >> >> >> >> For what it's worth, my thought is not to use SrcSpanInfo (which, to >> me, >> >> is the wrong way to slice the abstraction) but instead to add SrcSpan >> fields >> >> to the relevant nodes. For example: >> >> >> >> | HsDo SrcSpan -- of the word "do" >> >> BlockSrcSpans >> >> (HsStmtContext Name) -- The parameterisation is >> >> unimportant >> >> -- because in this context we >> never >> >> use >> >> -- the PatGuard or ParStmt variant >> >> [ExprLStmt id] -- "do":one or more stmts >> >> PostTcType -- Type of the whole expression >> >> >> >> ... >> >> >> >> data BlockSrcSpans = LayoutBlock Int -- the parameter is the >> indentation >> >> level >> >> ... -- stuff to track the appearance >> of >> >> any semicolons >> >> | BracesBlock ... -- stuff to track the braces and >> >> semicolons >> >> >> >> >> >> The way I understand it, the SrcSpanInfo proposal means that we would >> have >> >> lots of empty SrcSpanInfos, no? Most interior nodes don't need one, I >> think. >> >> >> >> Popping up a level, I do support the idea of including this info in the >> >> AST. >> >> >> >> Richard >> >> >> >> >> >> On Aug 28, 2014, at 11:54 AM, Simon Peyton Jones < >> simonpj(a)microsoft.com> >> >> wrote: >> >> >> >> > In general I’m fine with this direction of travel. Some specifics: >> >> > >> >> > · You’d have to be careful to document, for every data >> >> > constructor in HsSyn, what the association between the [SrcSpan] in >> the >> >> > SrcSpanInfo and the “sub-entities” >> >> > · Many of the sub-entities will have their own SrcSpanInfo >> >> > wrapped around them, so there’s some unhelpful duplication. Maybe >> you only >> >> > want the SrcSpanInfo to list the [SrcSpan]s for the sub-entities >> (like the >> >> > syntactic keywords) that do not show up as children in the syntax >> tree? >> >> > Anyway do by all means create a GHC Trac wiki page to describe your >> >> > proposed design, concretely. >> >> > >> >> > Simon >> >> > >> >> > From: ghc-devs [mailto:ghc-devs-bounces@haskell.org] On Behalf Of >> Alan & >> >> > Kim Zimmerman >> >> > Sent: 28 August 2014 15:00 >> >> > To: ghc-devs(a)haskell.org >> >> > Subject: GHC AST Annotations >> >> > >> >> > Now that the landmines have hopefully been cleared from the AST via >> [1] >> >> > I would like to propose changing the location information in the AST. >> >> > >> >> > Right now the locations of syntactic markers such as >> do/let/where/in/of >> >> > in the source are discarded from the AST, although they are retained >> in the >> >> > rich token stream. >> >> > >> >> > The haskell-src-exts package deals with this by means of using the >> >> > SrcSpanInfo data type [2] which contains the SrcSpan as per the >> current GHC >> >> > Located type but also has a list of SrcSpan s for the syntactic >> markers, >> >> > depending on the particular AST fragment being annotated. >> >> > >> >> > In addition, the annotation type is provided as a parameter to the >> AST, >> >> > so that it can be changed as required, see [3]. >> >> > >> >> > The motivation for this change is then >> >> > >> >> > 1. Simplify the roundtripping and modification of source by >> explicitly >> >> > capturing the missing location information for the syntactic markers. >> >> > >> >> > 2. Allow the annotation to be a parameter so that it can be replaced >> >> > with a different one in tools, for example HaRe would include the >> tokens for >> >> > the AST fragment leaves. >> >> > >> >> > 3. Aim for some level compatibility with haskell-src-exts so that >> tools >> >> > developed for it could be easily ported to GHC, for example >> exactprint [4]. >> >> > >> >> > >> >> > >> >> > I would like feedback as to whether this would be acceptable, or if >> the >> >> > same goals should be achieved a different way. >> >> > >> >> > >> >> > >> >> > Regards >> >> > >> >> > Alan >> >> > >> >> > >> >> > >> >> > >> >> > [1] https://phabricator.haskell.org/D157 >> >> > >> >> > [2] >> >> > >> http://hackage.haskell.org/package/haskell-src-exts-1.15.0.1/docs/Language-… >> >> > >> >> > [3] >> >> > >> http://hackage.haskell.org/package/haskell-src-exts-1.15.0.1/docs/Language-… >> >> > >> >> > [4] >> >> > >> http://hackage.haskell.org/package/haskell-src-exts-1.15.0.1/docs/Language-… >> >> > >> >> >> >> > _______________________________________________ >> >> > ghc-devs mailing list >> >> > ghc-devs(a)haskell.org >> >> > http://www.haskell.org/mailman/listinfo/ghc-devs >> >> >> >> >> > >> > >> > >> > _______________________________________________ >> > ghc-devs mailing list >> > ghc-devs(a)haskell.org >> > http://www.haskell.org/mailman/listinfo/ghc-devs >> > >> > >

1 0

Problems with building GHC 7.8.3 on Windows
by Marek Wawrzos 06 Sep '14

06 Sep '14

Hello, I am trying to compile GHC 7.8.3 on Windows. I was following the instructions from the GHC wiki, but I have encountered errors during the make process. I have filed a bug report describing my issue: https://ghc.haskell.org/trac/ghc/ticket/9513 Does anyone had working setup for building GHC and would be willing to share information on how to achieve it? -- Best regards, Marek Wawrzos

5 6

Trac
by Simon Peyton Jones 06 Sep '14

06 Sep '14

Trac is still very slow, and super-hard to update a wiki page without getting "database locked" and often losing all your eits. It would be great if this could be fixed somehow. Simon

1 0

Status updates
by Austin Seipp 06 Sep '14

06 Sep '14

Hi *, Here are some status updates for the past week, which have been a bit light. - I spent a bunch of time code reviewing things and merging patches this week. There are still things in Phabricator that need some review, so please review them if you get a chance! You will probably learn things and learning things is good. [1] - I spent more time getting a Windows builder working, and talking with upstream about it. I believe it should Basically Work, but unfortunately the changes for this have not gone upstream yet, so it will probably be a week or two before I can officially do that - I have spent some time fixing some bugs, and I'm posting a review for some shortly, notably 7602! Unrelated to what I in particular am doing Right Now: - I would still _really_ like help with the Applicative Monad patch; I haven't touched it much. Please pester me if you have some cycles to spare. Or just helping me brainstorm would be really really useful![2] - After some minor instability in the tree earlier this week (test failures), everything is back to normal (Thanks to Edward & Simon). Please ping here if you're still having trouble on your machine. - I still think we should turn on --slow mode for our buildbots soon, but this will cause noise. I'd really like some inputs on this - maybe someone would like to help clean up the 'slow' vaildate failures? Bonus points for this, since you don't even have to - Gabor Pali & I had a minor discussion this last week about fixing nightly documentation snapshots. We've had complaints about this in the past and the prior system totally disappeared, so it will be really nice to fix this! Binary snapshots should be possible too, but documentation is perhaps the more key thing. A little work is necessary for this though, and my time is limited as always. Please let me know if you'd like to help with this, and I'll pull you into the loop with Gabor so can tackle this. ---------------------------- I've probably forgotten some things other people have done the past week, including myself. If you have any questions, suggestions, or want to pop in on this email and say something, you should. :) [1] https://phabricator.haskell.org/differential/ [2] https://phabricator.haskell.org/D13 -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/

5 5