Re: nofib external dependencies
Hi, Am Montag, den 25.08.2014, 18:35 +0400 schrieb Alexander Pakhomov: > I've noticed nofib depends on external packages, such as vector. > So when vector is updated we have a benchmark result change even without > compiler changes. > I guess we need to use fixed version. When some package has major updates we > do have to pick > we should rename benchmark because it's not the same benchmark. well, the version of vector we use is fixed via git submodules. So in a sense, GHC contains vector, and if someone bumps the vector version via a git commit, this commit has an effect on our benchmarks – not much difference to other commits changing GHC code. Also note that nofib depends on base and the Prelude. Again, not much difference. Greetings, Joachim -- Joachim “nomeata” Breitner m...@joachim-breitner.de • http://www.joachim-breitner.de/ Jabber: nome...@joachim-breitner.de • GPG-Key: 0xF0FBF51F Debian Developer: nome...@debian.org signature.asc Description: This is a digitally signed message part ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Wired-in data-constructors with UNPACKed fields
On Mon, Aug 18, 2014 at 10:01:17PM +, Simon Peyton-Jones wrote: > > My recommendation would be to try (3) first. Ian Lynagh (cc'd) may be able > to comment about why the inconsistency above arose in the first place, and > why we can't simply fix it. I don't know of any reason we can't. I think we didn't before because we didn't need to change S#, and didn't realise that there would be any benefit to doing so. Thanks Ian ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
nofib external dependencies
Hi all! I've noticed nofib depends on external packages, such as vector. So when vector is updated we have a benchmark result change even without compiler changes. I guess we need to use fixed version. When some package has major updates we do have to pick we should rename benchmark because it's not the same benchmark. ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Status updates
Hello *, Here are some notes from what's happened this week: - I've rejiggered some of the wiki pages a bit more, including updating the BugTracker page[1], Phabricator/Harbormaster docs[2], -- The bugtracker page mostly saw some minor updates in relation to the updates from *last* week; notably the new 'upstream' status. -- I split the Phabricator page up a bit to be easier to read, so Harbormaster is its own page now (but see more below). - I spent a day or two working on a Windows buildbot for Phabricator. Good news: I think I have a reliable set of steps to get a windows SSH instance running. However, I have not yet gotten it to build GHC through msys2, so it's not working yet. - I spent time on Friday getting a fix for #7602 ready for real this time. I'll put a review on Phabricator soon (my other machine doesn't have `arc` credentials.) Hopefully OS X users can soon rejoice with a solid performance boost. - I fiddled with Applicative-Monad a tiny bit, but haven't made much progress still. Like last time, it would be really amazing if anyone would like to help me out and try the patch yourself (feel free to email/IRC, or see last weeks' email for more). Other things: - Thomas Miedema helped out Herbert by writing a Trac anti-spam plugin for us - Thank you so much Thomas!! Hopefully the spam will go away soon. I am not yet sure if Thomas's new plugin is installed yet - Herbert? Upcoming: - #7602 will go up for review. - I will land D165 today probably since it's ready and other refactorings can come later. D166 (faster copies) is not yet ready. - I haven't done this yet, but I'm going to try to turn on `--slow` ./validate mode in the next day or two for Phabricator. At first, I'm only going to configure this for *commits* first, and perhaps patches will follow once we have more build machines. That means Phabricator is going to start annoying you with consistent failures (I think `--slow` has a few right now), but putting on pressure is the best way to fix it, I think. I'll send another email about this shortly. - I will probably rejigger the Phabricator page again to be smaller. I've had some complaints it's getting a bit large (due to the images, mostly), so I'll probably move the hierarchy around a bit. - Sit down and do some thorough code review. We have about 3 major features sitting on Phabricator at the moment which are going to need extensive review before landing. I expect this will take a while. See: -- D169, source code notes: https://phabricator.haskell.org/D169 -- D168: Partial type sigs: https://phabricator.haskell.org/D168 -- D119: StaticValues extension: https://phabricator.haskell.org/D119 Please please please - feel free to review these patches! Even if they are not your area of expertise, doing so will A) help you learn more hopefully! and B) you can surely help still (pointing out typos, needed docs, lint violations, suggestions) etc. That would be really useful to help increase the 'shared ownership' we all have, I think. [1] https://ghc.haskell.org/trac/ghc/wiki/WorkingConventions/BugTracker [2] https://ghc.haskell.org/trac/ghc/wiki/Phabricator/Harbormaster -- 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: Moving Haddock *development* out of GHC tree
What happens in the case of a change to the dev branch of ghc that requires a patch to haddock as well, how does that patch get added to phabricator, or is there a separate process? A case in point is https://phabricator.haskell.org/D157 with matching change at https://github.com/alanz/haddock/tree/wip/landmine-param-family Regards Alan On Sat, Aug 16, 2014 at 5:34 PM, Herbert Valerio Riedel wrote: > On 2014-08-16 at 16:59:51 +0200, Mateusz Kowalczyk wrote: > > [...] > > > Herbert kindly updated the sync-all script that > > defaults to the new branch so I think we're covered. > > Minor correction: I did not touch the sync-all script at all. I merely > declared a default branch in the .gitmodules file: > > > http://git.haskell.org/ghc.git/commitdiff/03a8003e5d3aec97b3a14b2d3c774aad43e0456e > > ___ > 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
Re: windows-x86-head (Windows/x86 HEAD (Gabor Pali)), build 2, Success
2014-08-25 10:45 GMT+02:00 Karel Gardas : > thanks a lot for your fantastic job on getting windows builder running. You are most welcome. > It's great to have that in the pool and not need to speculate if the change > breaks windows build or not sometimes in the future when someone attempts > to build that. Now it's one night turn over and this is great. Though, I think it is still a bit bumpy. I will have to fix the build environment to avoid the build failing in odd ways, such as today's problem [1]. By digging into the config.log mentioned in the log, it appears to be some unrelated permission issue. (That I am hoping to fix locally.) On that note, I had a problem with the lndir utility in both MinGW [2]. For some reason, lndir does not like when the path (of the directory hierarchy to be mirrored, its first parameter) starts with "C:/". Instead, it prefers the traditional UNIX-ish pathname. That is, omitting calling ghc-pwd (and replacing for pwd) for setting the TOP make(1) variable in mk/config.mk would make it work fine, I guess. For now, I wrapped lndir to normalize the pathname it gets, but this is a band-aid solution only. I am pondering if anybody else has faced this problem before. All you have to do is to invoke the "sdist" target after the build is done. Otherwise it will not cause any other difficulties. [1] http://haskell.inf.elte.hu/builders/windows-x86-head/4/10.html [2] http://haskell.inf.elte.hu/builders/windows-x86_64-head/2/16.html ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: windows-x86-head (Windows/x86 HEAD (Gabor Pali)), build 2, Success
Gabor, thanks a lot for your fantastic job on getting windows builder running. It's great to have that in the pool and not need to speculate if the change breaks windows build or not sometimes in the future when someone attempts to build that. Now it's one night turn over and this is great. Thanks a lot! Karel On 08/23/14 07:33 AM, Builder wrote: windows-x86-head (Windows/x86 HEAD (Gabor Pali)), build 2 Build succeeded Details: http://haskell.inf.elte.hu/builders/windows-x86-head/2.html git clone | Success create mk/build.mk | Success get subrepos| Success repo versions | Success touching clean-check files | Success setting version date| Success booting | Success configuring | Success creating check-remove-before| Success compiling | Success creating check-remove-after | Success compiling testremove| Success simulating clean| Success checking clean | Success making bindist | Success making srcdist | Success uploading bindist | Success uploading srcdist | Success uploading windows extra src tarball | Success uploading tarball source| Success testing bindist | Success testing | Success testsuite summary | Success Build succeeded Details: http://haskell.inf.elte.hu/builders/windows-x86-head/2.html ___ ghc-builds mailing list ghc-bui...@haskell.org http://www.haskell.org/mailman/listinfo/ghc-builds ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
RE: Suggestion for GHC System User's Guide documentation change
Dear Howard, Yes, emphatically so! Any examples should be copy-paste-runnable if reasonably possible without any further switches, so that means the pragmas *should* be included! Regards, Philip From: Howard B. Golden Sent: 22 August 2014 18:47 To: Holzenspies, P.K.F. (EWI); simo...@microsoft.com; ghc-devs@haskell.org Subject: Re: Suggestion for GHC System User's Guide documentation change p.k.f., I like your less verbose suggestion better than my original. I don't understand your comment about code examples: Are you supporting or opposing the inclusion of the LANGUAGE pragmas in the examples? Howard From: "p.k.f.holzensp...@utwente.nl" To: simo...@microsoft.com; howard_b_gol...@yahoo.com; ghc-devs@haskell.org Sent: Friday, August 22, 2014 5:38 AM Subject: RE: Suggestion for GHC System User's Guide documentation change Marginally less verbose; why not use the language extension *only* in running text? Preferably with a link to the documentation of that language extension. In your example: | The language extension UnicodeSyntax enables Unicode characters to be | used to stand for certain ASCII character sequences. With regards to code examples: Ideally any explicit code example could just be copy-pasted into a .hs-file and loaded into ghci / compiled with ghc without special switches. Just my two cents ;) Ph. ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
