July 2016 - ghc-devs - Haskell.org

atomicModifyMutVar#: cas() is not inlined
by Ömer Sinan Ağacan 27 Jul '16

27 Jul '16

This is from definition of stg_atomicModifyMutVarzh(): (for threaded runtime) retry: x = StgMutVar_var(mv); StgThunk_payload(z,1) = x; (h) = ccall cas(mv + SIZEOF_StgHeader + OFFSET_StgMutVar_var, x, y); if (h != x) { goto retry; } cas() is defined in includes/stg/SMP.h like this: EXTERN_INLINE StgWord cas(StgVolatilePtr p, StgWord o, StgWord n) { return __sync_val_compare_and_swap(p, o, n); } I think this is a function we want to make sure to inline everywhere, right? It's compiled to a single instruction on my x86_64 Linux laptop. >>> disassemble cas Dump of assembler code for function cas: 0x0000000000027240 <+0>: mov %rsi,%rax 0x0000000000027243 <+3>: lock cmpxchg %rdx,(%rdi) 0x0000000000027248 <+8>: retq End of assembler dump. But it seems like it's not really inlined in Cmm functions: >>> disassemble stg_atomicModifyMutVarzh Dump of assembler code for function stg_atomicModifyMutVarzh: ... 0x0000000000046738 <+120>: callq 0x27240 <cas> ... End of assembler dump. I guess the problem is that we can't inline C code in Cmm, but I was wondering if this is important enough to try to fix maybe. Has anyone here looked at some profiling info to see how much time spent on this cas() call when threads are blocked in `atomicModifyIORef` etc?

1 0

Re-exporting traverse_ from Data.Traversable
by Christopher Allen 26 Jul '16

26 Jul '16

Any reason not to do it? I realize it needs Foldable, but even knowing that I still forget it's in Data.Foldable. Seems like a free UX win to me.

2 1

Supporting unboxed tuples in the bytecode compiler
by Ömer Sinan Ağacan 25 Jul '16

25 Jul '16

Simon, I was looking at the bytecode compiler to understand what's needed to support unboxed tuples. It seems like if we generate bytecode after unarise it should be very easy to support unboxed tuples, because after unarise we don't have any unboxed tuple binders (all binders have UnaryType). So only places we see unboxed tuples are: - Return positions. We just push contents of the tuple to the stack. - Case alternatives. The case expression in this case has to have this form: case e1 of (# bndr1, bndr2, ..., bndrN #) -> RHS All binders will have unary types again. We just bind ids in the environment to their stack locations and compile RHS. I think that's it. We also get unboxed sums support for free when we do this after unarise. What do you think about compiling to bytecode from STG? Have you considered that before? Would that be a problem for GHCi's debugger or any other features?

2 1

Proposal process status
by Ben Gamari 22 Jul '16

22 Jul '16

Hello everyone, As you hopefully know, a few weeks ago we proposed a new process [1] for collecting, discussing, and deciding upon changes to GHC and its Haskell superset. While we have been happy to see a small contingent of contributors join the discussion, the number is significantly smaller than the set who took part in the earlier Reddit discussions. In light of this, we are left a bit uncertain of how to proceed. So, we would like to ask you to let us know your feelings regarding the proposed process: * Do you feel the proposed process is an improvement over the status quo? * Why? (this needn't be long, just a sentence hitting the major points) * What would you like to see changed in the proposed process, if anything? That's all. Again, feel free to reply either on the GitHub pull request [1] or this thread if you would prefer. Your response needn't be long; we just want to get a sense of how much of the community feels that 1) this effort is worth undertaking, and 2) that the proposal before us is in fact an improvement over the current state of affairs. Thanks for your help! Cheers, - Ben [1] https://github.com/ghc-proposals/ghc-proposals/pull/1

11 18

GHC build currently broken on OS X and Windows
by Erik de Castro Lopo 22 Jul '16

22 Jul '16

Hi all. The recent Compact Regions commit (cf989ffe490c146be4ed0fd7e0c00d3ff8fe1453) builds fine on Linux but doesn't build on OS X and is at least 99% certain not to build on Windows. I'm in the process of fixing it, but it will be 24-36 hours before I have a patch ready. Erik -- ---------------------------------------------------------------------- Erik de Castro Lopo http://www.mega-nerd.com/

5 4

Should we send Travis messages to ghc-builds?
by Ben Gamari 21 Jul '16

21 Jul '16

Hello everyone, While picking up the pieces from a failed merge today I realized that we currently spend a fair bit of carbon footprint and CPU cycles making Travis test GHC yet the results of these tests aren't pushed anywhere. Would anyone object to having Travis push notifications of changes in red/green state to ghc-builds(a)haskell.org? Perhaps this will allow some of us to react more quickly to regressions. Cheers, - Ben

3 3

Re: Proposal process status
by Niklas Larsson 20 Jul '16

20 Jul '16

> 20 juli 2016 kl. 19:38 skrev amindfv(a)gmail.com: > > > >> El 20 jul 2016, a las 12:45, Ben Gamari <ben(a)well-typed.com> escribió: >> >> Iavor Diatchki <iavor.diatchki(a)gmail.com> writes: >> >>> Hello Ben, >>> >>> I posted this when you originally asked for feed-back, but perhaps it >>> got buried among the rest of the e-mails. >> Indeed it seems that way. Sorry about that! >> >>> I think the proposal sounds fairly reasonable, but it is hard to say how >>> well it will work in practice until we try it, and we should be ready to >>> change it if needs be. >> Right. I fully expect that we will have to iterate on it. >> >>> Some clarifying questions on the intended process: >>> 1. After submitting the initial merge request, is the person making the >>> proposal to wait for any kind of acknowledgment, or just move on to step 2? >> The discussion phase can happen asynchronously from any action by the >> Committee. Of course, the Committee should engauge in discussion early, >> but I don't think any sort of acknowledgement is needed. An open pull >> request should be taken to mean "let's discuss this idea." >> >>> 2. Is the discussion going to happen on one of the mailing lists, if so >>> which? Is it the job of the proposing person to involve/notify the >>> committee about the discussion? If so, how are they to find out who is on >>> the committee? >> >> The proposed process places the discussion in a pull request. The idea >> here is to use well-understood and widely-used code review tools to >> faciliate the conversation. > > This part runs strongly against the grain of what I'd prefer: email is lightweight, decentralized, standard, and has many clients. We can read discussion of Haskell proposals any way we like. Github on the other hand only allows us to read issues by going to Github, and using whatever interface Github has given us (which personally I find very annoying, esp. on mobile). In addition, reading proposals offline becomes very difficult. Many of us read discussion when commuting, where, e.g. in NYC, there isn't cell service. > > For reviewing code that implements a proposal, I'm a lot more flexible (although again I'm not a fan of Github) > > For the people who like having history tracked with git: gitit is a possibility, and is written in Haskell. > > Tom > It's possible both follow and contribute to issues in a github repo via email. I do it all the time for Idris. // Niklas > > >> The Committee members will be notified of the open pull request by the >> usual event notification mechanism (e.g. in GitHub one can subscribe to >> a repository). >> >>> 3. How does one actually perform step 3, another pull request or simply >>> an e-mail to someone? >> The opening of the pull request would mark the beginning of the >> discussion period. When the author feels that the discussion has come to >> something of a conclusion, they will request that the GHC Committee >> consider the proposal for acceptable by leaving a comment on the pull >> request. >> >>> Typo: two separate bullets in the proposal are labelled as 4. >> I believe this should be fixed now. Thanks! >> >> Cheers, >> >> - Ben >> >> _______________________________________________ >> Glasgow-haskell-users mailing list >> Glasgow-haskell-users(a)haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users(a)haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users

1 0

git.haskell.org slow
by Simon Peyton Jones 20 Jul '16

20 Jul '16

Is it my imagination or is git.haskell.org really slow at the moment? SImion

1 0

Note [Api annotations]
by Ömer Sinan Ağacan 20 Jul '16

20 Jul '16

I see some weird comments like -- - 'ApiAnnotation.AnnKeywordId' : 'ApiAnnotation.AnnOpen', -- 'ApiAnnotation.AnnVbar','ApiAnnotation.AnnComma', -- 'ApiAnnotation.AnnClose' -- For details on above see note [Api annotations] in ApiAnnotation in some files, but Note [Api annotations] in compiler/parser/ApiAnnotation.hs doesn't say anything about those comments. Can someone update the note to explain what are those comments for?

4 4

first unboxed sums patch is ready for reviews
by Ömer Sinan Ağacan 19 Jul '16

19 Jul '16

Hi all, I'm almost done with the unboxed sums patch and I'd like to get some reviews at this point. https://phabricator.haskell.org/D2259 Two key files in the patch are UnariseStg.hs and RepType.hs. For the example programs see files in testsuite/tests/unboxedsums/ In addition to any comments about the code and documentation, it'd be appreciated if you tell me about some potential uses of unboxed sums, example programs, edge cases etc. so that I can test it a bit more and make sure the generated code is good. Thanks, Omer

1 1