(drop)CommonPrefix: ccs call implementation
Dear list, I am reading up on cost centre stacks. Simon Marlow's solving an old problem-slides is the more recent resource I could find. On slide 43 he describes a call function implemented as: call Sapp Slam = foldr push Spre Slam’ where (Spre, Sapp’, Slam’) = commonPrefix Sapp Slam However in rts/profiling.c the following is written: Set CCCS when entering a function. The algorithm is as follows. ccs ++ ccsfn = ccs ++ dropCommonPrefix ccs ccsfn where dropCommonPrefix A B -- returns the suffix of B after removing any prefix common -- to both A and B. e.g. a,b,c ++ = a,b,c a,b,c ++ d = a,b,c,d a,b,c ++ a,b = a,b,c a,b ++ a,b,c = a,b,c a,b,c ++ a,b,d = a,b,c,d For the given examples Simon's proposal would result in different stacks: , d, a,b, a,b,c and a,b,d. Has the implementation changed since Simon Marlow gave his talk? If so, is there something I can read on the motivation behind this change? Or do I maybe misinterpret the slides? Thank you, Maarten Faddegon ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Status updates
Hello all, A cumulative status update will now appear, to summarize a few things that have happened in the past little while since I've been somewhat absent and short on time. - 7.8.3 is looming, because we have a lot of bugfixes as I said last week: https://ghc.haskell.org/trac/ghc/wiki/Status/GHC-7.8.3 That's nearly 30 tickets axed in the past few weeks since 7.8.2, so not bad! As I said before, I'm eager to release sooner rather than later as my time is short. Do keep weighing in if you have anything to say or want something fixed. Now is really the time! - AMP/ORF - these are still on branches, but me and Simon have gotten hung up on a few things delaying it. They'll go in soon, promise! (For certain definitions of 'soon', cooperating with time schedules). AMP in particular can probably land very, very soon. Otherwise we're past a lot of other churn, like removing external core and whatnot. - I merged a bunch of patches this morning to the 7.8 branch, bringing it close to what I expect we will ship 7.8.3 with. Again, pester me soon if you want something! - There's now a proper CI link for GHC on Trac so people don't lose it. The new builders are checking in regularly, so please watch out for them - and subscribe to ghc-bui...@haskell.org if you haven't already. - Some other churn in the tree has not yet passed; I still need to improve and land my performance patches for copies, for example. - XCode 5.1 has introduced some other breaking changes I'll need to fix (things *work*, but the testsuite is useless due to the warning spewage), along with merging the remaining patches. - Also, if you have spare hardware, please email Gabor Pali (or just email the list itself, or reply to this thread) if you're willing to donate, that would be awesome. Another Mac OS X target would be especially welcome, I think (my development machine is on loan right now), and I will have better dedicated Windows targets soon. I'll send another email about 7.8.3 shortly. -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
RE: Status updates
| - 7.8.3 is looming, because we have a lot of bugfixes as I said last | week: https://ghc.haskell.org/trac/ghc/wiki/Status/GHC-7.8.3 Just to be clear, on that page: closed = done in 7.8.3 branch patch = will go in 7.8.3 branch new/infoneeded = will NOT go in 7.8.3 unless you yell loudly and soon and argue for delay to get it in | - There's now a proper CI link for GHC on Trac so people don't lose it. | The new builders are checking in regularly, so please watch out for them | - and subscribe to ghc-bui...@haskell.org if you haven't already. Where exactly is the link? (Ie not what is the link but where on Trac is it posted?) Simon ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Status updates
Drats, I forgot that. Here's where it is: Go to the GHC Trac hompeage: https://ghc.haskell.org/trac/ghc/ and scroll down just a tiny bit. There's a section called 'Nightly builds' with the updated link to the new UI, located on Gabor's server: http://haskell.inf.elte.hu/builders/ Simon, did we talk about adding this to the sidebar? Or maybe we should just highlight it on the front page a little more, and then link to it from somewhere else on the sidebar (like Building Guide links to the builder page). On Thu, Jun 5, 2014 at 8:35 AM, Simon Peyton Jones simo...@microsoft.com wrote: | - 7.8.3 is looming, because we have a lot of bugfixes as I said last | week: https://ghc.haskell.org/trac/ghc/wiki/Status/GHC-7.8.3 Just to be clear, on that page: closed = done in 7.8.3 branch patch = will go in 7.8.3 branch new/infoneeded = will NOT go in 7.8.3 unless you yell loudly and soon and argue for delay to get it in | - There's now a proper CI link for GHC on Trac so people don't lose it. | The new builders are checking in regularly, so please watch out for them | - and subscribe to ghc-bui...@haskell.org if you haven't already. Where exactly is the link? (Ie not what is the link but where on Trac is it posted?) Simon -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: 7.8.3 release - please speak up soon.
On 5 June 2014 23:37, Gergely Risko gerg...@risko.hu wrote: It seems reasonable to just make terminfo, haskeline and xhtml visible to the users from the ghc included packagedb. What can possible go wrong? :) +1 I am planning to do this anyway in the Fedora package [1] and haven't encountered any problems yet (with [2]). But if It is too late, I would suggest doing it for 7.10 anyway Jens. [1] I attached the simple patch to the ticket now. [2] http://copr-be.cloud.fedoraproject.org/results/petersen/ghc-7.8/fedora-20-x86_64/ghc-7.8.2-33.3.fc20/ ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
can a StgRhs have NoCCS when -prof is provided?
Hi all, Can a StgRhs have `NoCCS` as cost-centre stack when -prof is provided while compiling? Or is it always oneOf [CurrentCCS, DontCareCCS, SingletonCCS]? I presume that since we have CCS constructor DontCareCCS and CCS field of StgRhs constructors are not `Maybe CostCentreStack` (so they're not optional), when -prof is provided CCS fields should not be filled with NoCCS(if we still don't care about CCS for some reason, it should be DontCareCCS) but I just wanted to make sure. Thanks. --- Ömer Sinan Ağacan http://osa1.net ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: 7.8.3 release - please speak up soon.
On Thu, 05 Jun 2014 16:37:36 +0200 Gergely Risko gerg...@risko.hu wrote: Probably I'm very late, and the Nix guys can hopefully workaround this on their own side, but can you take a quick look on: https://ghc.haskell.org/trac/ghc/ticket/8919 Hia! Can you write what problems are to ship those libraries in it's current form? Do you have some linking problems or something? Ticket does not describe any actual problems. Thanks! -- Sergei signature.asc Description: PGP signature ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: can a StgRhs have NoCCS when -prof is provided?
Yes, I think all NoCCS are removed in the SCCfinal pass. NoCCS is a convenient thing to fill in when STG is initially created. Edward Excerpts from Ömer Sinan Ağacan's message of 2014-06-05 09:59:36 -0700: Hi all, Can a StgRhs have `NoCCS` as cost-centre stack when -prof is provided while compiling? Or is it always oneOf [CurrentCCS, DontCareCCS, SingletonCCS]? I presume that since we have CCS constructor DontCareCCS and CCS field of StgRhs constructors are not `Maybe CostCentreStack` (so they're not optional), when -prof is provided CCS fields should not be filled with NoCCS(if we still don't care about CCS for some reason, it should be DontCareCCS) but I just wanted to make sure. Thanks. --- Ömer Sinan Ağacan http://osa1.net ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Status updates
Hi, - Also, if you have spare hardware, please email Gabor Pali (or just email the list itself, or reply to this thread) if you're willing to donate, that would be awesome. Another Mac OS X target would be especially welcome, I think (my development machine is on loan right now), and I will have better dedicated Windows targets soon. I have one Mac Pro to build GHC. But it is behind a firewall. Is this useful for this purpose? --Kazu ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Status updates
I can build on my Mac. Happy to do so since I'll be doing anyways :-) On Thursday, June 5, 2014, Kazu Yamamoto k...@iij.ad.jp wrote: Hi, - Also, if you have spare hardware, please email Gabor Pali (or just email the list itself, or reply to this thread) if you're willing to donate, that would be awesome. Another Mac OS X target would be especially welcome, I think (my development machine is on loan right now), and I will have better dedicated Windows targets soon. I have one Mac Pro to build GHC. But it is behind a firewall. Is this useful for this purpose? --Kazu ___ ghc-devs mailing list ghc-devs@haskell.org javascript:; http://www.haskell.org/mailman/listinfo/ghc-devs ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
RFC: Phabricator for patches and code review
Hello all, Recently, while doing server maintenance, several of the administrators for Haskell.org set up an instance of Phabricator[1], located at https://phabricator.haskell.org For those who aren't aware, Phabricator (or Phab) is a suite of tools for software development. Think of it like a polished, semi-private GitHub with a lot of applications and tools for all kinds of needs. We've been using it to do issue tracking for Haskell.org maintenance and like it a lot so far. One very nice aspect of Phabricator though is it has a very nice code review tool, called 'Differential', that is very useful. For people who have used a tool like Review Board, it's similar. Furthermore, it has a very convenient userland tool called 'Arcanist' which makes it easy for newcomers to post a review and get it merged when it's ready all from the command line. I'd like to see if people are interested in using Phab _strictly_ for code review of GHC patches. It is a dedicated tool specifically for this, and I think it works much better than Trac or inline GitHub comments. Also, Phab can also support post-commit reviews. So if I touch something in the runtime system and just push, perhaps Simon or Edward would like to look, and they can be alerted right when I do this, and then yell if I did something stupid. Before I go much further, I'd like to ask: is there *any* interest in this? Or are people satisifed with Trac? The primary motivations are roughly, in no particular order: 1) Code review is good for everyone, a good way for people to learn the code and ask questions, and useful to give feedback to newcomers. And even experienced GHC hackers can learn things from reading code, as we all do regularly, or find things that need cleanup. 2) Phabricator in particular makes it very easy to submit patches for review. To submit a patch, I just run the command 'arc diff' and it Does The Right Thing. It also makes it easy to ensure people are *alerted* when a patch might be relevant to them. 3) They can be uploaded and created from the command line, and merged easily afterwords the same way. This is particularly useful for newcomers, and for me. :) 4) Differential is dedicated to code review, and much better at it than just reading patches on Trac IMO. 5) It supports both post-commit code review, as well as pre-commit review. Post commit would be especially useful for us too, I think. Point #2 and #3 are mostly relevant for me, because I mostly handle incoming patches. But I think in general it would be nice, and make it a lot easier for newcomers to submit patches, and us to look over them. Here's an example of a Differential code review: https://phabricator.haskell.org/D4 This is a demo using my 'wip/ermsb' patch. You'll need to create an account to login, but it shouldn't be much trouble, you can login several ways. I'll fix the login requirement soon. Feel free to read the code, comment on it, and play around. It's more of a demonstration, but real code review would be welcome too. :) If people are interested in doing this, I can add notes to the wiki pages for newcomers, and I'll send another email about Phab so people can understand it a little better. But I want to ask first. There is an argument that our team is so small, code review has unnecessary burdens. But I think Phab could help a lot with tracking outside patches and getting good reviews for incoming patches, and it'll make it easier for newcomers. And experienced pros can probably learn a thing as well. Again, to be clear, I don't propose we migrate anything to Phabricator from, say, Trac. There's no real pressure to do so and it would be tons of work. I only propose we use it for code review, which is perfectly fine, and how other projects like LLVM do code review (they use Bugzilla). I also don't think the usage of Phabricator should be mandatory (unless we decide that later because we like it), but I would like to see people use it if possible. [1] http://phabricator.org -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: RFC: Phabricator for patches and code review
while i'm a novice at using ANY code review tools, having some persistent tooling for patch reviews would be really great! theres a lot of good feedback that otherwise only exists in an email somewhere! On Fri, Jun 6, 2014 at 12:05 AM, Austin Seipp aus...@well-typed.com wrote: Hello all, Recently, while doing server maintenance, several of the administrators for Haskell.org set up an instance of Phabricator[1], located at https://phabricator.haskell.org For those who aren't aware, Phabricator (or Phab) is a suite of tools for software development. Think of it like a polished, semi-private GitHub with a lot of applications and tools for all kinds of needs. We've been using it to do issue tracking for Haskell.org maintenance and like it a lot so far. One very nice aspect of Phabricator though is it has a very nice code review tool, called 'Differential', that is very useful. For people who have used a tool like Review Board, it's similar. Furthermore, it has a very convenient userland tool called 'Arcanist' which makes it easy for newcomers to post a review and get it merged when it's ready all from the command line. I'd like to see if people are interested in using Phab _strictly_ for code review of GHC patches. It is a dedicated tool specifically for this, and I think it works much better than Trac or inline GitHub comments. Also, Phab can also support post-commit reviews. So if I touch something in the runtime system and just push, perhaps Simon or Edward would like to look, and they can be alerted right when I do this, and then yell if I did something stupid. Before I go much further, I'd like to ask: is there *any* interest in this? Or are people satisifed with Trac? The primary motivations are roughly, in no particular order: 1) Code review is good for everyone, a good way for people to learn the code and ask questions, and useful to give feedback to newcomers. And even experienced GHC hackers can learn things from reading code, as we all do regularly, or find things that need cleanup. 2) Phabricator in particular makes it very easy to submit patches for review. To submit a patch, I just run the command 'arc diff' and it Does The Right Thing. It also makes it easy to ensure people are *alerted* when a patch might be relevant to them. 3) They can be uploaded and created from the command line, and merged easily afterwords the same way. This is particularly useful for newcomers, and for me. :) 4) Differential is dedicated to code review, and much better at it than just reading patches on Trac IMO. 5) It supports both post-commit code review, as well as pre-commit review. Post commit would be especially useful for us too, I think. Point #2 and #3 are mostly relevant for me, because I mostly handle incoming patches. But I think in general it would be nice, and make it a lot easier for newcomers to submit patches, and us to look over them. Here's an example of a Differential code review: https://phabricator.haskell.org/D4 This is a demo using my 'wip/ermsb' patch. You'll need to create an account to login, but it shouldn't be much trouble, you can login several ways. I'll fix the login requirement soon. Feel free to read the code, comment on it, and play around. It's more of a demonstration, but real code review would be welcome too. :) If people are interested in doing this, I can add notes to the wiki pages for newcomers, and I'll send another email about Phab so people can understand it a little better. But I want to ask first. There is an argument that our team is so small, code review has unnecessary burdens. But I think Phab could help a lot with tracking outside patches and getting good reviews for incoming patches, and it'll make it easier for newcomers. And experienced pros can probably learn a thing as well. Again, to be clear, I don't propose we migrate anything to Phabricator from, say, Trac. There's no real pressure to do so and it would be tons of work. I only propose we use it for code review, which is perfectly fine, and how other projects like LLVM do code review (they use Bugzilla). I also don't think the usage of Phabricator should be mandatory (unless we decide that later because we like it), but I would like to see people use it if possible. [1] http://phabricator.org -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
