Re: can't build head: parser file name / module name conflict
On 19/08/13 21:16, Carter Schonwald wrote: hey all, i'm trying to build head to test out some stuff, and i'm hitting the following error message (http://ghc.haskell.org/trac/ghc/ticket/8143 ) compiler/stage1/build/Parser.hs:1:1: File name does not match module name: Saw: `Main' Expected: `Parser' make[1]: *** [compiler/stage1/build/.depend-v.haskell] Error 1 Possibly your Parser.hs is corrupt somehow - take a look. Remove the file and try again? Cheers, Simon ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Disallow pushing of new trailing whitespace
On 20/08/13 12:21, Geoffrey Mainland wrote: Would be nice to have. How about a third hook that disallows commits that include whitespace-only changes unless *all* changes are whitespace-only? ;) The problem with these kind of commit-time checks is that you only find out the problem *after* you've validated your nicely polished commits. If we're going to add more checks on commits they should be done by validate (yes I know that's not at all trivial, but it's not impossible either). Cheers, Simon Geoff On 08/20/2013 10:59 AM, Jan Stolarek wrote: Right now we have a git hook that prevents pushing a file containing tabs, unless that file had them already (in other words: no new files with tabs in our repos). I propose to add similar hook for trailing whitespaces. Herbert says he can implement that. What do others think? Would you find that useful or problematic? Janek ___ 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: Reproducible build recipes for GHC development VMs?
On 21/08/13 15:44, Ryan Newton wrote: Hi all, Returning to the topic discussed by Simon M. and others here: http://projects.haskell.org/pipermail/haskell-platform/2009-July/000572.html This is my attempt at a script for bootstrapping a GHC-validating VM: http://parfunk.blogspot.com/2013/08/zero-to-ghc-development-in-ubuntu-vm-in.html Let me know if there's a better way, or if you'd like to help get this kind of thing into an even more accessible form (Amazon AMI, Chef recipe, etc). I do this occasionally with an Amazon VM. Incidentally, why did you download the GHC 7.6.3 tarball rather than apt-get install ghc? The current GHC on Ubuntu is 7.4 which is enough to bootstrap GHC HEAD. Cheers, Simon ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: 7.8 Feature window
On 21/08/13 16:11, Ryan Newton wrote: Hi all, It is not merged into master presently but I would like to propose the three new primops that are on the atomics branch for inclusion in 7.8. These are pretty much completely apart from everything else and don't break any existing code. For the public library that exposes these things (atomic-primops) it will be a great boon to be able to depend on them in 7.8 and not have to wait yet another release cycle [1]. I skimmed the patches and they look OK to me (modulo the tabs). Of course longer term we should have MachOps for the low-level atomic operations and get rid of the two layers of function call in these primops. Cheers, Simon Best, -Ryan [1] P.S. 7.8 will already be a breaking change to atomic-primops, because of the change in CMM syntax. So if it has to be #ifdef'd anyway, we might as well go straight to the Right Thing rather than having a proliferation of intermediate hacks. On Tue, Aug 20, 2013 at 1:01 PM, Austin Seipp ase...@pobox.com mailto:ase...@pobox.com wrote: All, GHC 7.8's release is drawing near. We would like to make a release candidate sometime around ICFP, which will be in late September. Unfortunately that's just over a month a way, so the clock is ticking! The tree will need a few weeks of stabilization. After that, we will release an RC, and likely branch. Then things will roughly return to normal. The exact date for feature cutoff is not set yet (but I will follow up soon on this.) So, I'd like a show of hands and a quick 'check in' for outstanding work for 7.8. There are a few things we know for sure are - or were - tentatively scheduled for this release: * SIMD improvements * New Template Haskell * Constraint solver for type naturals These are - as far as I'm aware - the largest outstanding features which not quite yet in HEAD. For the release, we would like to minimize 'disruptive' features, because 7.8 already has many large changes. In particular, Dynamic GHCi and dynamic builds will likely prove the biggest challenge 'in the field', so we would like plenty of time to stress this as best we can for the RC, and the release itself. There are some things which we are fairly certain will not make it: * Joachim's new newtype coercion implementation * Adam's new record implementation There are some things I'm not very privvy to perhaps, but could still go in: * Nicolas possibly had some optimisation improvements according to Simon. * Edsko had a small patch for extended plugin functionality in HEAD, but Luite and Thomas also have input here. Status is uncertain. * ERDI was working on pattern synonyms. I believe you were having some trouble with the implementation. Can someone help him if necessary? Finally, there are loose ends to tie off: * I believe Simon and Jose were having discussions about the new Typeable implementation, regarding hand-written instances. This should be fine for 7.8 and is mostly some behavioral tweaking I think. I've undoubtedly missed things here. Please fill me in. :) Note that before the freeze, you should interpret 'disruptive' with your own good judgement. Smaller patches and improvements are certainly welcome as always, and you shouldn't wait on me to push something if you feel good about it. If you're ever unsure, just ask. Worst case is something gets backed out, but it's nothing we cannot come back to. -- Regards, Austin - PGP: 4096R/0x91384671 ___ ghc-devs mailing list ghc-devs@haskell.org mailto: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 ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Disallow pushing of new trailing whitespace
This seems acceptable IMO. The general working conventions already are to separate whitespace and/or tab changes from a commit containing actual content. If you ./validate cleanly, but the server rejects the push for whitespace, adding an extra commit on top to clean up the affected files seems very sensible (it's simple to 'untabify' and eliminate trailing white space in most editors these days, so I imagine this isn't really going to cost you a lot of time.) I also add bonus points for the fact the server will reject it unless you clean up *all* affected files you touched, so things can't slip by. This is how the tab check works now, and it does deal with a 'range' of commits where later commits eliminate tabs introduced in earlier ones. We'd also have to introduce the concept of git into ./validate for this to work (and add the ability to specify a commit range for stuff like this,) but a basic implementation may not be difficult, looking at the pre-receive script. Alternatively, these could be pre-commit hooks in the developer repository, but I believe you have to opt into that. Maybe worth putting on the wiki, though. On Thu, Aug 22, 2013 at 2:33 AM, Simon Marlow marlo...@gmail.com wrote: On 20/08/13 12:21, Geoffrey Mainland wrote: Would be nice to have. How about a third hook that disallows commits that include whitespace-only changes unless *all* changes are whitespace-only? ;) The problem with these kind of commit-time checks is that you only find out the problem *after* you've validated your nicely polished commits. If we're going to add more checks on commits they should be done by validate (yes I know that's not at all trivial, but it's not impossible either). Cheers, Simon Geoff On 08/20/2013 10:59 AM, Jan Stolarek wrote: Right now we have a git hook that prevents pushing a file containing tabs, unless that file had them already (in other words: no new files with tabs in our repos). I propose to add similar hook for trailing whitespaces. Herbert says he can implement that. What do others think? Would you find that useful or problematic? Janek __**_ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/**mailman/listinfo/ghc-devshttp://www.haskell.org/mailman/listinfo/ghc-devs __**_ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/**mailman/listinfo/ghc-devshttp://www.haskell.org/mailman/listinfo/ghc-devs -- Regards, Austin - PGP: 4096R/0x91384671 ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: can't build head: parser file name / module name conflict
Carter is building with the new XCode, which only has Clang on OS X. This error is a result of clang preprocessing Parser.y.pp, since it uses a 'double pass' CPP trick to pass -fcmm-sink to the stage2 compiler. I could never fully come to understand the behavior of why this was an error, and it seemed to be affected by whitespace in the resultant file from Happy. Fiddling with whitespace made it work somehow, but I couldn't find out what behavior (or changes in Clang) allowed this. Looking back on it, the correct fix I think is to only pass -fcmm-sink if Parser.hs is being built with the stage2 compiler, in the build system. This is a lot less fragile, I feel. (Relatedly, we also need to make sure that -fcmm-sink is passed to stage1, if boostrapping ghc = 7.7, so 7.8 can build itself once released.) There's a host of OS X things that need attention at the moment unfortunately, and my personal machine is a bit broken right now. But I have a new 10.7 build machine I can use, so I'll try to get on it ASAP. On Thu, Aug 22, 2013 at 2:28 AM, Simon Marlow marlo...@gmail.com wrote: On 19/08/13 21:16, Carter Schonwald wrote: hey all, i'm trying to build head to test out some stuff, and i'm hitting the following error message (http://ghc.haskell.org/trac/**ghc/ticket/8143http://ghc.haskell.org/trac/ghc/ticket/8143) compiler/stage1/build/Parser.**hs:1:1: File name does not match module name: Saw: `Main' Expected: `Parser' make[1]: *** [compiler/stage1/build/.**depend-v.haskell] Error 1 Possibly your Parser.hs is corrupt somehow - take a look. Remove the file and try again? Cheers, Simon __**_ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/**mailman/listinfo/ghc-devshttp://www.haskell.org/mailman/listinfo/ghc-devs -- Regards, Austin - PGP: 4096R/0x91384671 ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
It's one of those days...
From a fresh ghc-head checkout. On OSX Lion $ ./sync-all get ... == libraries/dph: running git config --local core.ignorecase true == running git config --local core.ignorecase true == running git submodule init == running git submodule update error: Failed connect to git.haskell.org:3128; Operation timed out while accessing http://git.haskell.org/packages/Cabal.git/info/refs?service=git-upload-pack fatal: HTTP request failed Unable to fetch in submodule path 'libraries/Cabal' git failed: 256 at ./sync-all line 119. On OSX Snow Leopard $ make ... ===--- building final phase make -r --no-print-directory -f ghc.mk phase=final all inplace/bin/dll-split compiler/stage2/build/.depend-v-dyn.haskell DynFlags Annotations Avail Bag BasicTypes Binary Bitmap BlockId BreakArray BufWrite ByteCodeAsm ByteCodeInstr ByteCodeItbls ByteCodeLink CLabel Class CmdLineParser Cmm CmmCallConv CmmExpr CmmInfo CmmMachOp CmmNode CmmType CmmUtils CoAxiom CodeGen.Platform CodeGen.Platform.ARM CodeGen.Platform.NoRegs CodeGen.Platform.PPC ... TysWiredIn Unify UniqFM UniqSet UniqSupply Unique Util Var VarEnv VarSet make[1]: *** [compiler/stage2/dll-split.stamp] Segmentation fault make: *** [all] Error 2 On Debian $ inplace/bin/ghc-stage2 --make ~/tmp/Hello.hs -fforce-recomp ... (.data+0x0): undefined reference to `r5Iv_closure' /home/benl/devel/ghc/ghc-head/libraries/base/dist-install/build/libHSbase-4.7.0.0.a(PSQ__40.o):(.text+0x85): undefined reference to `rjV_info' /home/benl/devel/ghc/ghc-head/libraries/base/dist-install/build/libHSbase-4.7.0.0.a(PSQ__40.o): In function `S82I_srt': (.data+0x0): undefined reference to `rjV_closure' /home/benl/devel/ghc/ghc-head/libraries/base/dist-install/build/libHSbase-4.7.0.0.a(PSQ__42.o):(.text+0x85): undefined reference to `rjV_info' /home/benl/devel/ghc/ghc-head/libraries/base/dist-install/build/libHSbase-4.7.0.0.a(PSQ__42.o): In function `S83p_srt': I'm sure it's my fault, but I don't have any more computers... Ben. ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Changes in Hoopl
Me and Simon PJ had some discussion about modifying Hoopl. I summarized that discussion on a wiki page: http://ghc.haskell.org/trac/ghc/wiki/Hoopl/Cleanup I'd like to implement changes once there's a consensus on which changes exactly do we want in Hoopl. Janek ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: It's one of those days...
On 22/08/2013, at 22:48 , Ben Lippmeier b...@ouroborus.net wrote: On OSX Lion $ ./sync-all get ... == libraries/dph: running git config --local core.ignorecase true == running git config --local core.ignorecase true == running git submodule init == running git submodule update error: Failed connect to git.haskell.org:3128; Operation timed out while accessing http://git.haskell.org/packages/Cabal.git/info/refs?service=git-upload-pack fatal: HTTP request failed Unable to fetch in submodule path 'libraries/Cabal' git failed: 256 at ./sync-all line 119. This one was my fault because I had the wrong http_proxy environment variable set. I was confused because the ./sync-all script gets most of the repos with git:// style URLs, but then switches to http:// style URLs for sub modules. not sure about the others yet. Ben. ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Changes in Hoopl
Hey Janek, as a remark, Hoopl is the only library in GHC that defines its own * operation, which will clash with the AMP. Hoopl's * is conceptually just `mappend`, so if you're doing a large-scale refactoring of the module maybe consider adding a suitable Monoid instance to replace * with before it even becomes a problem. David ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Changes to primops break libraries (was Re: 7.8 Feature window)
1. Why do you say this naming feels more consistent? Consistent with what? Convention is that functions ending with # operate on unboxed values and return unboxed values (usually), so to me it seemed consistent that sameTVar# returns an unboxed value, while sameTVar does not. I raised that problem on the Trac (http://ghc.haskell.org/trac/ghc/ticket/6135#comment:72) and the only answer I got was from Ian: Regarding the name of sameMutableArray#, I don't have a strong opinion. I suspect there are few users of the function, so personally I'd be inclined to use the most consistent names. So I assumed that everyone else agrees. But anyway, this can be changed easily. We just need to agree on the names. 2. The module name PrimWrappers is terrible, because it's so close to PrimopWrappers Yes, I also don't like that similarity in names, but I don't think that current name is terrible - if I write sth like this: import GHC.Prim import GHC.PrimWrappers it seems to be clearer whta the second module might contain, than if I write import GHC.Prim import GHC.BoolOpWrappers Again, I can change this, but we have to decide on a name. CmpOpWrappers is not good IMO - not all wrappers are for comparisons! 3. Could you add a section Breaking changes to http://ghc.haskell.org/trac/ghc/wiki/PrimBool to explain what to change. Yes, I was thinking about that yesterday when I realized that second person asks the question which was already answered on the wiki. I wasn't sure where to put information about breaking changes so that it is easy to find for people who need it. I think that I'll make a spearate page on the wiki and link to it from release notes. Janek ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Changes to primops break libraries (was Re: 7.8 Feature window)
Oh, and I think that using sameTVar# for primop and sameTVar for wrapper is a good choice, even if we make transition slightly more difficult. This naming feels better to me and I think there are few libraries that will need to adjust. So I vote to keep these names as they are. Janek - Oryginalna wiadomość - Od: Jan Stolarek jan.stola...@p.lodz.pl Do: Simon Peyton-Jones simo...@microsoft.com DW: ghc-devs@haskell.org, Gabor Greif ggr...@gmail.com Wysłane: czwartek, 22 sierpień 2013 14:43:29 Temat: Re: Changes to primops break libraries (was Re: 7.8 Feature window) 1. Why do you say this naming feels more consistent? Consistent with what? Convention is that functions ending with # operate on unboxed values and return unboxed values (usually), so to me it seemed consistent that sameTVar# returns an unboxed value, while sameTVar does not. I raised that problem on the Trac (http://ghc.haskell.org/trac/ghc/ticket/6135#comment:72) and the only answer I got was from Ian: Regarding the name of sameMutableArray#, I don't have a strong opinion. I suspect there are few users of the function, so personally I'd be inclined to use the most consistent names. So I assumed that everyone else agrees. But anyway, this can be changed easily. We just need to agree on the names. 2. The module name PrimWrappers is terrible, because it's so close to PrimopWrappers Yes, I also don't like that similarity in names, but I don't think that current name is terrible - if I write sth like this: import GHC.Prim import GHC.PrimWrappers it seems to be clearer whta the second module might contain, than if I write import GHC.Prim import GHC.BoolOpWrappers Again, I can change this, but we have to decide on a name. CmpOpWrappers is not good IMO - not all wrappers are for comparisons! 3. Could you add a section Breaking changes to http://ghc.haskell.org/trac/ghc/wiki/PrimBool to explain what to change. Yes, I was thinking about that yesterday when I realized that second person asks the question which was already answered on the wiki. I wasn't sure where to put information about breaking changes so that it is easy to find for people who need it. I think that I'll make a spearate page on the wiki and link to it from release notes. Janek ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Changes in Hoopl
Hi Jan, On 22/08/13 14:01, Jan Stolarek wrote: Me and Simon PJ had some discussion about modifying Hoopl. I summarized that discussion on a wiki page: http://ghc.haskell.org/trac/ghc/wiki/Hoopl/Cleanup I'd like to implement changes once there's a consensus on which changes exactly do we want in Hoopl. I'm all for cleaning up Hoopl. It's definitely a bit of a mess in places. I read through your wiki page and I'm not entirely clear about what changes you're proposing. e.g. it's probably true that in forward analysis if you specify facts for all the input labels then fact_bot is never used (though I'm not 100% sure about that). But you don't say what you want to do with that observation. Could you list the API changes you want to make? Cheers, Simon ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Changes to primops break libraries (was Re: 7.8 Feature window)
I created a wiki page that describes the upgrade process in two easy steps: http://ghc.haskell.org/trac/ghc/wiki/NewPrimopsInGHC7.8 I also added link to this page in the release notes. Simon, does this address points 3 4 of your mail? Of course aside from the fact that if we change name of GHC.PrimWrappers module than these page will need to be updated accordingly. Janek - Oryginalna wiadomość - Od: Simon Peyton-Jones simo...@microsoft.com Do: Jan Stolarek jan.stola...@p.lodz.pl, Gabor Greif ggr...@gmail.com DW: ghc-devs@haskell.org Wysłane: czwartek, 22 sierpień 2013 13:40:09 Temat: RE: Changes to primops break libraries (was Re: 7.8 Feature window) Jan Four things: | •Six primops are an exception to the rules above: sameMutableArray#, | sameMutableByteArray#, sameMutableArrayArray#, sameMutVar#, sameMVar# | and sameTVar#. Their names have remained the same as before and new | wrappers created for them lack # at the end of their name. We made that | decission because this naming feels more consistent and these primops | are rarely used so we expect that they won't break a lot of existing | code. 1. Why do you say this naming feels more consistent? Consistent with what? I'd expect sameTVar# to return a Bool, just like ==#. I'd prefer to say just import PrimWrappers than to say just import PrimWrapper and change the names of these six functions. I don’t really see a clear distinction at all. 2. The module name PrimWrappers is terrible, because it's so close to PrimopWrappers, which is machine generated. Lots of scope for confusion. How about CmpOpWrappers or BoolOpWrappers? Any opinions from other ghc-devs? 3. Could you add a section Breaking changes to http://ghc.haskell.org/trac/ghc/wiki/PrimBool to explain what to change. Currently it's buried (in bold I know) in Implementation details which is not where I'd look as a library author. 4. Can the release notes http://ghc.haskell.org/trac/ghc/browser/docs/users_guide/7.8.1-notes.xml perhaps refer to the wiki page? That gives much more background. Library authors will find that helpful. So long as we get these choices fixed for 7.8 we are fine. Simon ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
./sync-all get git submodule URL dissonance (was: It's one of those days...)
On 2013-08-22 at 15:35:29 +0200, Ben Lippmeier wrote: [...] I was confused because the ./sync-all script gets most of the repos with git:// style URLs, but then switches to http:// style URLs for sub modules. well, that's because the 'sync-all' script is not clever enough to rewrite the urls between the 'git submodule init' and the 'git submodule update' invocations during an initial sync-all get operation. Specifically, the proper way to do this (for an initial 'sync-all get'; it gets more complicated for non-initial 'sync-all get's) is: - before invoking 'git submodule update', iterate over the entries in git config --get-regexp ^submodule and - rewrite the repo URLs (by using 'git config' again), assuming that 'http://git.haskell.org/' is the original repo-base/prefix which is to be replaced by the current $repo_base - proceed with 'git submodule update' Btw, the implementation in sync-all at https://github.com/ghc/ghc/blob/master/sync-all#L897-L912 seems a bit confusing; the submodule init in the if ($command eq get or $command eq pull) branch is probably never invoked. cheers, hvr ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Changes to primops break libraries (was Re: 7.8 Feature window)
You're right Simon - I didn't thought about ltFloat and that my idea of consistency breaks there. Janek - Oryginalna wiadomość - Od: Simon Peyton-Jones simo...@microsoft.com Do: Jan Stolarek jan.stola...@p.lodz.pl DW: ghc-devs@haskell.org, Gabor Greif ggr...@gmail.com Wysłane: czwartek, 22 sierpień 2013 15:31:32 Temat: RE: Changes to primops break libraries (was Re: 7.8 Feature window) | Oh, and I think that using sameTVar# for primop and sameTVar for wrapper | is a good choice, even if we make transition slightly more difficult. | This naming feels better to me You said that before, but *why* does the naming feel better to you? We now have ltFloatI# :: Float# - Float# - Int# (the primop) ltFloat# :: Float# - Float# - Bool (wrapper) ltFloat :: Float - Float - Bool (in GHC.Float) So it makes sense to me to have sameTVarI# :: TVar# s a - TVar# s a - Int# (the primop) sameTVar# :: TVar# s a - TVar# s a - Bool (wrapper) sameTVar :: TVar s a - TVar s a - Bool (in GHC.Conc.Sync) (Actually GHC.Conc.Sync doesn't define sameTVar; it just gives an Eq instance, but you see the idea.) I don’t see why you propose to break the consistency of this naming convention. Simon | | Janek | | - Oryginalna wiadomość - | Od: Jan Stolarek jan.stola...@p.lodz.pl | Do: Simon Peyton-Jones simo...@microsoft.com | DW: ghc-devs@haskell.org, Gabor Greif ggr...@gmail.com | Wysłane: czwartek, 22 sierpień 2013 14:43:29 | Temat: Re: Changes to primops break libraries (was Re: 7.8 Feature | window) | | 1. Why do you say this naming feels more consistent? Consistent | with what? | Convention is that functions ending with # operate on unboxed values and | return unboxed values (usually), so to me it seemed consistent that | sameTVar# returns an unboxed value, while sameTVar does not. I raised | that problem on the Trac | (http://ghc.haskell.org/trac/ghc/ticket/6135#comment:72) and the only | answer I got was from Ian: | | Regarding the name of sameMutableArray#, I don't have a strong opinion. | I suspect there are few users of the function, so personally I'd be | inclined to use the most consistent names. | | So I assumed that everyone else agrees. | | But anyway, this can be changed easily. We just need to agree on the | names. | | 2. The module name PrimWrappers is terrible, because it's so close to | PrimopWrappers | Yes, I also don't like that similarity in names, but I don't think that | current name is terrible - if I write sth like this: | | import GHC.Prim | import GHC.PrimWrappers | | it seems to be clearer whta the second module might contain, than if I | write | | import GHC.Prim | import GHC.BoolOpWrappers | | Again, I can change this, but we have to decide on a name. CmpOpWrappers | is not good IMO - not all wrappers are for comparisons! | | 3. Could you add a section Breaking changes to | http://ghc.haskell.org/trac/ghc/wiki/PrimBool to explain what to change. | Yes, I was thinking about that yesterday when I realized that second | person asks the question which was already answered on the wiki. I | wasn't sure where to put information about breaking changes so that it | is easy to find for people who need it. I think that I'll make a | spearate page on the wiki and link to it from release notes. | | Janek ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Changes to primops break libraries (was Re: 7.8 Feature window)
This is not a completely serious suggestions, but... If we moved the magic GHC.Prim module to GHC.Prim.Base or something, then we could move GHC.PrimWrappers to GHC.Prim, have it import GHC.Prim.Base, and, assuming that we use Simon PJ's naming convention, (I think) no code would have to change. Geoff On 08/22/2013 03:49 PM, Jan Stolarek wrote: I created a wiki page that describes the upgrade process in two easy steps: http://ghc.haskell.org/trac/ghc/wiki/NewPrimopsInGHC7.8 I also added link to this page in the release notes. Simon, does this address points 3 4 of your mail? Of course aside from the fact that if we change name of GHC.PrimWrappers module than these page will need to be updated accordingly. Janek - Oryginalna wiadomość - Od: Simon Peyton-Jones simo...@microsoft.com Do: Jan Stolarek jan.stola...@p.lodz.pl, Gabor Greif ggr...@gmail.com DW: ghc-devs@haskell.org Wysłane: czwartek, 22 sierpień 2013 13:40:09 Temat: RE: Changes to primops break libraries (was Re: 7.8 Feature window) Jan Four things: | •Six primops are an exception to the rules above: sameMutableArray#, | sameMutableByteArray#, sameMutableArrayArray#, sameMutVar#, sameMVar# | and sameTVar#. Their names have remained the same as before and new | wrappers created for them lack # at the end of their name. We made that | decission because this naming feels more consistent and these primops | are rarely used so we expect that they won't break a lot of existing | code. 1. Why do you say this naming feels more consistent? Consistent with what? I'd expect sameTVar# to return a Bool, just like ==#. I'd prefer to say just import PrimWrappers than to say just import PrimWrapper and change the names of these six functions. I don’t really see a clear distinction at all. 2. The module name PrimWrappers is terrible, because it's so close to PrimopWrappers, which is machine generated. Lots of scope for confusion. How about CmpOpWrappers or BoolOpWrappers? Any opinions from other ghc-devs? 3. Could you add a section Breaking changes to http://ghc.haskell.org/trac/ghc/wiki/PrimBool to explain what to change. Currently it's buried (in bold I know) in Implementation details which is not where I'd look as a library author. 4. Can the release notes http://ghc.haskell.org/trac/ghc/browser/docs/users_guide/7.8.1-notes.xml perhaps refer to the wiki page? That gives much more background. Library authors will find that helpful. So long as we get these choices fixed for 7.8 we are fine. Simon ___ 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
Design discussion for atomic primops to land in 7.8
There's a ticket that describes the design here: http://ghc.haskell.org/trac/ghc/ticket/8157#comment:1 It is a fairly simple extension of the casMutVar# that has been in since 7.2. The implementation is on the `atomics` branch currently. Feel free to add your views either here or on that task's comments. One example of an alternative design would be Carter's proposal to expose something closer to the full LLVM concurrency opshttp://llvm.org/docs/Atomics.html : Schonwald carter.schonw...@gmail.com wrote: i'm kinda thinking that we should do the analogue of exposing all the different memory model level choices (because its not that hard to add that), and when the person building it has an old version of GCC, it falls back to the legacy atomic operations? This also gives a nice path to how to upgrade to the inline asm approach. These LLVM ops include many parameterized configurations of loads, stores, cmpxchg, atomicrmw and barriers. In fact, it implements much more than is natively supported in most hardware, but it provides a uniform abstraction. My original thought was that any kind of abstraction like that would be built and maintained as a Haskell library, and only the most rudimentary operations (required to get access to process features) would be exposed as primops. Let's call this the small set of concurrent ops. If we want the big set I think we're doomed to *reproduce* the logic that maps LLVM concurrency abstractions onto machine ops irrespective of whether those abstractions are implemented as Haskell functions or as primops: - If the former, then the Haskell library must map the full set of ops to the reduced small set (just like LLVM does internally) - If we instead have a large set of LLVM-isomorphic primops then to support the same primops *in the native code backend *will, again, require reimplementing all configurations of all operations. Unless... we want to make concurrency ops something that require the LLVM backend? Right now there is not a *performance* disadvantage to supporting a smaller rather than a larger set of concurrency ops (LLVM has to emulate these things anyway, or round up to more expensive ops). The scenario where it would be good to target ALL of LLVMs interface would be if processors and LLVM improved in the future, and we automatically got the benefit of better HW support for some op on on some arch. I'm a bit skeptical of that proposition itself, however. I personally don't really like a world where we program with virtual operations that don't really exist (and thus can't be *tested* against properly). Absent formal verification, it seems hard to get this code right anyway. Errors will be undetectable on existing architectures. -Ryan ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: 7.8 Feature window
In addition to the Hooks patch (see other mail on this post) I have a few minor updates to support GHCJS that I think are pretty uncontroversial: 1. Add a WayCustom to the Ways type in DynFlags to make custom tags. We use this to generate native code (.o, .hi) and JS code (.js_o, .js_hi) in the same dir. This way we have a multitarget compiler that can load the native code for TH. 2. Add foreign import javascript to the FFI grammar and a JavaScriptFFI extension to enable it. 3. Add an ArchJavaScript constructor, unsupported on the built-in NCG Only thing remaining is that the 'safe' and 'unsafe' specs in the javascript imports are actually misnomers, they should be named 'async' and 'sync' respectively, with 'sync' being the default. There used to be more in the GHCJS patch, but the rest has now been superceded with more general Hooks. This means that all GHCJS-specific things have actually been removed from the patch (no more wired-in ghcjs-prim package and JSRef type), so any JS backend could use the exact same things, using Hooks to customize things its own way. luite On Tue, Aug 20, 2013 at 7:01 PM, Austin Seipp ase...@pobox.com wrote: All, GHC 7.8's release is drawing near. We would like to make a release candidate sometime around ICFP, which will be in late September. Unfortunately that's just over a month a way, so the clock is ticking! The tree will need a few weeks of stabilization. After that, we will release an RC, and likely branch. Then things will roughly return to normal. The exact date for feature cutoff is not set yet (but I will follow up soon on this.) So, I'd like a show of hands and a quick 'check in' for outstanding work for 7.8. There are a few things we know for sure are - or were - tentatively scheduled for this release: * SIMD improvements * New Template Haskell * Constraint solver for type naturals These are - as far as I'm aware - the largest outstanding features which not quite yet in HEAD. For the release, we would like to minimize 'disruptive' features, because 7.8 already has many large changes. In particular, Dynamic GHCi and dynamic builds will likely prove the biggest challenge 'in the field', so we would like plenty of time to stress this as best we can for the RC, and the release itself. There are some things which we are fairly certain will not make it: * Joachim's new newtype coercion implementation * Adam's new record implementation There are some things I'm not very privvy to perhaps, but could still go in: * Nicolas possibly had some optimisation improvements according to Simon. * Edsko had a small patch for extended plugin functionality in HEAD, but Luite and Thomas also have input here. Status is uncertain. * ERDI was working on pattern synonyms. I believe you were having some trouble with the implementation. Can someone help him if necessary? Finally, there are loose ends to tie off: * I believe Simon and Jose were having discussions about the new Typeable implementation, regarding hand-written instances. This should be fine for 7.8 and is mostly some behavioral tweaking I think. I've undoubtedly missed things here. Please fill me in. :) Note that before the freeze, you should interpret 'disruptive' with your own good judgement. Smaller patches and improvements are certainly welcome as always, and you shouldn't wait on me to push something if you feel good about it. If you're ever unsure, just ask. Worst case is something gets backed out, but it's nothing we cannot come back to. -- Regards, Austin - PGP: 4096R/0x91384671 ___ 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: extending GHC plugins with Hooks
Luite, Edsko, Thomas, Nicolas You have all variously proposed improvements to the GHC API and/or the plug-in mechanism. I have been so swamped in the last few months that I have not had a chance to look carefully at your proposals, nor how they relate to each other. We are now only three weeks away from wanting to do a feature freeze on GHC 7.8, and there are a lot of other things that we want to complete http://ghc.haskell.org/trac/ghc/wiki/Status/GHC-7.8 (Mostly they have gestating for some time.) So I'm hoping you'll be ok with not putting these plugin-related changes into 7.8. I have the sense that they'd benefit from more discussion among the folk interested in plugins. Perhaps some of the ideas could be combined nicely; I don't know. And the people who are going to write plugins are also probably up for building HEAD anyhow. (Exception: Luite, I think you have some fairly narrow, specific changes that would help GHCJS, and I'm probably fine with those if you care to send patches.) Please say if you think there's a really strong reason for putting stuff in the 7.8. Thanks Simon From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of Luite Stegeman Sent: 21 August 2013 03:51 To: ghc-devs Subject: extending GHC plugins with Hooks hi all, Sorry for taking so long to get back with this. I'm proposing a somewhat general way for adding 'hooks' to the GHC API, where users can override parts of the default compiling pipeline. Hooks are simply functions or actions that replace existing compiler functionality. This means that usually only one application can use a specific hook at a time. The obvious data structure to store the hooks is DynFlags. Unfortunately defining hooks in DynFlags directly would give birth to the mother of all import cycles, and it would also break the split-dll scheme on Windows. So here's the idea: - Define each hook in the module where it's exported - For each hook make a 'phantom' DataType and an instance for the Hook type familiy - Add a TypeRep based map in DynFlags [0] - For each hooked function, check for existence of a hook in DynFlags, otherwise run the default. Example: https://github.com/ghcjs/ghcjs-build/blob/master/refs/patches/ghc-ghcjs.patch#L83 Now this approach does have some disadvantages: - No clear integration with existing plugins (I've tried adding an onLoadPlugin field to Plugin, where the Plugin could update DynFlags when it's loaded, but it was a bit messy, and plugins would not be loaded in time for some hooks, particularly what Edsko needs) - More of GHC depends on type families - Decentralized hooks definitions feel a bit messy So I'm open to suggestions for improvements (or replacements) of this scheme. I have some time the coming weeks to clean up or change the patch. We've been testing some hooks with GHCJS for a while, and so far they seem to provide what we need (but I'm going to doublecheck the coming weeks that we don't have missing functionality): - Customizations for linking JavaScript code with our own library locations [1] - Hooking into the DriverPipeline so we can use the compilation manager [2] - Desugaring customizations to remove some C-isms from the FFI code [3] - Typechecking foreign import javascript imports [4] - Override the built-in GHC.Prim so we can customize primop types [5] I think it's easy to add those for Edsko and Thomas as well. luite [0] https://github.com/ghcjs/ghcjs-build/blob/master/refs/patches/ghc-ghcjs.patch#L239 [1] https://github.com/ghcjs/ghcjs/blob/master/src/Compiler/GhcjsHooks.hs#L44 [2] https://github.com/ghcjs/ghcjs/blob/master/src/Compiler/GhcjsHooks.hs#L192 https://github.com/ghcjs/ghcjs-build/blob/master/refs/patches/ghc-ghcjs.patch#L335 [3] https://github.com/ghcjs/ghcjs/blob/master/src/Gen2/Foreign.hs#L67 https://github.com/ghcjs/ghcjs-build/blob/master/refs/patches/ghc-ghcjs.patch#L83 [4] https://github.com/ghcjs/ghcjs/blob/master/src/Gen2/Foreign.hs#L68 https://github.com/ghcjs/ghcjs-build/blob/master/refs/patches/ghc-ghcjs.patch#L1374 [5] https://github.com/ghcjs/ghcjs/blob/master/src/Compiler/GhcjsHooks.hs#L191 https://github.com/ghcjs/ghcjs-build/blob/master/refs/patches/ghc-ghcjs.patch#L239 (sorry the linked patch also contains other modifications required for GHCJS, that i'm going to submit separately) ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: ./sync-all get git submodule URL dissonance (was: It's one of those days...)
On Thu, Aug 22, 2013 at 05:01:45PM +0200, Herbert Valerio Riedel wrote: Btw, the implementation in sync-all at https://github.com/ghc/ghc/blob/master/sync-all#L897-L912 seems a bit confusing; the submodule init in the if ($command eq get or $command eq pull) branch is probably never invoked. I probably forgot to remove the old block in https://github.com/ghc/ghc/commit/c3db2b2c449e21d0358f1ed4b7a5dd447477ac28 Thanks Ian ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Disallow pushing of new trailing whitespace
GHC already has -fwarn-tabs; we could have -fwarn-trailing-whitespace and turn it on by default, so that validate errors on it but you also notice it when you're doing a build (if you're paying attention to warnings). Edward Excerpts from Simon Marlow's message of Thu Aug 22 05:04:50 -0700 2013: On 22/08/13 12:32, Austin Seipp wrote: This seems acceptable IMO. The general working conventions already are to separate whitespace and/or tab changes from a commit containing actual content. If you ./validate cleanly, but the server rejects the push for whitespace, adding an extra commit on top to clean up the affected files seems very sensible (it's simple to 'untabify' and eliminate trailing white space in most editors these days, so I imagine this isn't really going to cost you a lot of time.) You still have to validate the new commit, so it costs you at least 20 mins, which is a lot. I also add bonus points for the fact the server will reject it unless you clean up *all* affected files you touched, so things can't slip by. This is how the tab check works now, and it does deal with a 'range' of commits where later commits eliminate tabs introduced in earlier ones. We'd also have to introduce the concept of git into ./validate for this to work (and add the ability to specify a commit range for stuff like this,) but a basic implementation may not be difficult, looking at the pre-receive script. Checking everything in 'git rev-list origin..' is probably good enough. Cheers, Simon Alternatively, these could be pre-commit hooks in the developer repository, but I believe you have to opt into that. Maybe worth putting on the wiki, though. On Thu, Aug 22, 2013 at 2:33 AM, Simon Marlow marlo...@gmail.com mailto:marlo...@gmail.com wrote: On 20/08/13 12:21, Geoffrey Mainland wrote: Would be nice to have. How about a third hook that disallows commits that include whitespace-only changes unless *all* changes are whitespace-only? ;) The problem with these kind of commit-time checks is that you only find out the problem *after* you've validated your nicely polished commits. If we're going to add more checks on commits they should be done by validate (yes I know that's not at all trivial, but it's not impossible either). Cheers, Simon Geoff On 08/20/2013 10:59 AM, Jan Stolarek wrote: Right now we have a git hook that prevents pushing a file containing tabs, unless that file had them already (in other words: no new files with tabs in our repos). I propose to add similar hook for trailing whitespaces. Herbert says he can implement that. What do others think? Would you find that useful or problematic? Janek _ ghc-devs mailing list ghc-devs@haskell.org mailto:ghc-devs@haskell.org http://www.haskell.org/__mailman/listinfo/ghc-devs http://www.haskell.org/mailman/listinfo/ghc-devs _ ghc-devs mailing list ghc-devs@haskell.org mailto:ghc-devs@haskell.org http://www.haskell.org/__mailman/listinfo/ghc-devs http://www.haskell.org/mailman/listinfo/ghc-devs -- Regards, Austin - PGP: 4096R/0x91384671 ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
RE: Changes in Hoopl
I have elaborated (more clearly I hope) S | -Original Message- | From: Simon Marlow [mailto:marlo...@gmail.com] | Sent: 22 August 2013 15:14 | To: Jan Stolarek | Cc: ghc-devs; Simon Peyton-Jones; n...@cs.tufts.edu; d...@cs.tufts.edu; | Edward Z. Yang | Subject: Re: Changes in Hoopl | | Hi Jan, | | On 22/08/13 14:01, Jan Stolarek wrote: | Me and Simon PJ had some discussion about modifying Hoopl. I | summarized that discussion on a wiki page: | | http://ghc.haskell.org/trac/ghc/wiki/Hoopl/Cleanup | | I'd like to implement changes once there's a consensus on which | changes exactly do we want in Hoopl. | | I'm all for cleaning up Hoopl. It's definitely a bit of a mess in | places. | | I read through your wiki page and I'm not entirely clear about what | changes you're proposing. e.g. it's probably true that in forward | analysis if you specify facts for all the input labels then fact_bot is | never used (though I'm not 100% sure about that). But you don't say | what you want to do with that observation. Could you list the API | changes you want to make? | | Cheers, | Simon ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
RE: Changes to primops break libraries (was Re: 7.8 Feature window)
I think that's a pretty good idea. It's not just a hack... it makes sense even if you ignore the issues of managing the transition. Maybe GHC.Prim.Builtin for the machine-generated not-written-in-Haskell operations. Jan would you like to try it? Simon | -Original Message- | From: Geoffrey Mainland [mailto:mainl...@apeiron.net] | Sent: 22 August 2013 16:18 | To: Jan Stolarek | Cc: Simon Peyton-Jones; ghc-devs@haskell.org | Subject: Re: Changes to primops break libraries (was Re: 7.8 Feature | window) | | This is not a completely serious suggestions, but... If we moved the | magic GHC.Prim module to GHC.Prim.Base or something, then we could move | GHC.PrimWrappers to GHC.Prim, have it import GHC.Prim.Base, and, | assuming that we use Simon PJ's naming convention, (I think) no code | would have to change. | | Geoff | | On 08/22/2013 03:49 PM, Jan Stolarek wrote: | I created a wiki page that describes the upgrade process in two easy | steps: | | http://ghc.haskell.org/trac/ghc/wiki/NewPrimopsInGHC7.8 | | I also added link to this page in the release notes. Simon, does this | address points 3 4 of your mail? Of course aside from the fact that if | we change name of GHC.PrimWrappers module than these page will need to | be updated accordingly. | | Janek | | - Oryginalna wiadomość - | Od: Simon Peyton-Jones simo...@microsoft.com | Do: Jan Stolarek jan.stola...@p.lodz.pl, Gabor Greif | ggr...@gmail.com | DW: ghc-devs@haskell.org | Wysłane: czwartek, 22 sierpień 2013 13:40:09 | Temat: RE: Changes to primops break libraries (was Re: 7.8 Feature | window) | | Jan | | Four things: | | | •Six primops are an exception to the rules above: sameMutableArray#, | | sameMutableByteArray#, sameMutableArrayArray#, sameMutVar#, | sameMVar# | | and sameTVar#. Their names have remained the same as before and new | | wrappers created for them lack # at the end of their name. We made | that | | decission because this naming feels more consistent and these | primops | | are rarely used so we expect that they won't break a lot of existing | | code. | | 1. Why do you say this naming feels more consistent? Consistent | with what? I'd expect sameTVar# to return a Bool, just like ==#. | | I'd prefer to say just import PrimWrappers than to say just import | PrimWrapper and change the names of these six functions. I don’t | really see a clear distinction at all. | | 2. The module name PrimWrappers is terrible, because it's so close to | PrimopWrappers, which is machine generated. Lots of scope for confusion. | How about CmpOpWrappers or BoolOpWrappers? Any opinions from other ghc- | devs? | | 3. Could you add a section Breaking changes to | http://ghc.haskell.org/trac/ghc/wiki/PrimBool to explain what to change. | Currently it's buried (in bold I know) in Implementation details which | is not where I'd look as a library author. | | 4. Can the release notes | http://ghc.haskell.org/trac/ghc/browser/docs/users_guide/7.8.1-notes.xml | perhaps refer to the wiki page? That gives much more background. | Library authors will find that helpful. | | So long as we get these choices fixed for 7.8 we are fine. | | Simon | | ___ | 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: Changes to primops break libraries (was Re: 7.8 Feature window)
Sure. I considered that idea at some point but it seemed a bit to drastic. Janek - Oryginalna wiadomość - Od: Simon Peyton-Jones simo...@microsoft.com Do: Geoffrey Mainland mainl...@apeiron.net, Jan Stolarek jan.stola...@p.lodz.pl DW: ghc-devs@haskell.org Wysłane: czwartek, 22 sierpień 2013 17:57:48 Temat: RE: Changes to primops break libraries (was Re: 7.8 Feature window) I think that's a pretty good idea. It's not just a hack... it makes sense even if you ignore the issues of managing the transition. Maybe GHC.Prim.Builtin for the machine-generated not-written-in-Haskell operations. Jan would you like to try it? Simon | -Original Message- | From: Geoffrey Mainland [mailto:mainl...@apeiron.net] | Sent: 22 August 2013 16:18 | To: Jan Stolarek | Cc: Simon Peyton-Jones; ghc-devs@haskell.org | Subject: Re: Changes to primops break libraries (was Re: 7.8 Feature | window) | | This is not a completely serious suggestions, but... If we moved the | magic GHC.Prim module to GHC.Prim.Base or something, then we could move | GHC.PrimWrappers to GHC.Prim, have it import GHC.Prim.Base, and, | assuming that we use Simon PJ's naming convention, (I think) no code | would have to change. | | Geoff | | On 08/22/2013 03:49 PM, Jan Stolarek wrote: | I created a wiki page that describes the upgrade process in two easy | steps: | | http://ghc.haskell.org/trac/ghc/wiki/NewPrimopsInGHC7.8 | | I also added link to this page in the release notes. Simon, does this | address points 3 4 of your mail? Of course aside from the fact that if | we change name of GHC.PrimWrappers module than these page will need to | be updated accordingly. | | Janek | | - Oryginalna wiadomość - | Od: Simon Peyton-Jones simo...@microsoft.com | Do: Jan Stolarek jan.stola...@p.lodz.pl, Gabor Greif | ggr...@gmail.com | DW: ghc-devs@haskell.org | Wysłane: czwartek, 22 sierpień 2013 13:40:09 | Temat: RE: Changes to primops break libraries (was Re: 7.8 Feature | window) | | Jan | | Four things: | | | •Six primops are an exception to the rules above: sameMutableArray#, | | sameMutableByteArray#, sameMutableArrayArray#, sameMutVar#, | sameMVar# | | and sameTVar#. Their names have remained the same as before and new | | wrappers created for them lack # at the end of their name. We made | that | | decission because this naming feels more consistent and these | primops | | are rarely used so we expect that they won't break a lot of existing | | code. | | 1. Why do you say this naming feels more consistent? Consistent | with what? I'd expect sameTVar# to return a Bool, just like ==#. | | I'd prefer to say just import PrimWrappers than to say just import | PrimWrapper and change the names of these six functions. I don’t | really see a clear distinction at all. | | 2. The module name PrimWrappers is terrible, because it's so close to | PrimopWrappers, which is machine generated. Lots of scope for confusion. | How about CmpOpWrappers or BoolOpWrappers? Any opinions from other ghc- | devs? | | 3. Could you add a section Breaking changes to | http://ghc.haskell.org/trac/ghc/wiki/PrimBool to explain what to change. | Currently it's buried (in bold I know) in Implementation details which | is not where I'd look as a library author. | | 4. Can the release notes | http://ghc.haskell.org/trac/ghc/browser/docs/users_guide/7.8.1-notes.xml | perhaps refer to the wiki page? That gives much more background. | Library authors will find that helpful. | | So long as we get these choices fixed for 7.8 we are fine. | | Simon | | ___ | 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: Changes in Hoopl
Simon, you give this example: L1: ...blah blah... CondBranch e L1 L2 L2: blah blah and say that (...) on the first iteration, we don't have any fact from L1. So for backwards analysis the client really must give us a bottom element. I think this example does not actually demonstrate that we must have a bottom element, because if we have fact from L2 then we still don't need bottom in the same way we don't need it in forward analysis. We need bottom only when all entry facts are unknown. Janek - Oryginalna wiadomość - Od: Simon Peyton-Jones simo...@microsoft.com Do: Simon Marlow marlo...@gmail.com, Jan Stolarek jan.stola...@p.lodz.pl DW: ghc-devs ghc-devs@haskell.org, n...@cs.tufts.edu, d...@cs.tufts.edu, Edward Z. Yang ezy...@mit.edu Wysłane: czwartek, 22 sierpień 2013 17:44:11 Temat: RE: Changes in Hoopl I have elaborated (more clearly I hope) S | -Original Message- | From: Simon Marlow [mailto:marlo...@gmail.com] | Sent: 22 August 2013 15:14 | To: Jan Stolarek | Cc: ghc-devs; Simon Peyton-Jones; n...@cs.tufts.edu; d...@cs.tufts.edu; | Edward Z. Yang | Subject: Re: Changes in Hoopl | | Hi Jan, | | On 22/08/13 14:01, Jan Stolarek wrote: | Me and Simon PJ had some discussion about modifying Hoopl. I | summarized that discussion on a wiki page: | | http://ghc.haskell.org/trac/ghc/wiki/Hoopl/Cleanup | | I'd like to implement changes once there's a consensus on which | changes exactly do we want in Hoopl. | | I'm all for cleaning up Hoopl. It's definitely a bit of a mess in | places. | | I read through your wiki page and I'm not entirely clear about what | changes you're proposing. e.g. it's probably true that in forward | analysis if you specify facts for all the input labels then fact_bot is | never used (though I'm not 100% sure about that). But you don't say | what you want to do with that observation. Could you list the API | changes you want to make? | | Cheers, | Simon ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Design discussion for atomic primops to land in 7.8
Hey Ryan, you raise some very good points. The most important point you raise (I think) is this: it would be very very nice to (where feasible) to add analogous machinery to the native code gen, so that its not falling behind the llvm one quite as much. at least for these atomic operations (unlike the SIMD ones), it may be worth investigating whats needed to add those to the native code gen as well. (adding simd support on the native codegen would be nice too, but probably *substantially *more work) On Thu, Aug 22, 2013 at 11:40 AM, Ryan Newton rrnew...@gmail.com wrote: There's a ticket that describes the design here: http://ghc.haskell.org/trac/ghc/ticket/8157#comment:1 It is a fairly simple extension of the casMutVar# that has been in since 7.2. The implementation is on the `atomics` branch currently. Feel free to add your views either here or on that task's comments. One example of an alternative design would be Carter's proposal to expose something closer to the full LLVM concurrency opshttp://llvm.org/docs/Atomics.html : Schonwald carter.schonw...@gmail.com wrote: i'm kinda thinking that we should do the analogue of exposing all the different memory model level choices (because its not that hard to add that), and when the person building it has an old version of GCC, it falls back to the legacy atomic operations? This also gives a nice path to how to upgrade to the inline asm approach. These LLVM ops include many parameterized configurations of loads, stores, cmpxchg, atomicrmw and barriers. In fact, it implements much more than is natively supported in most hardware, but it provides a uniform abstraction. My original thought was that any kind of abstraction like that would be built and maintained as a Haskell library, and only the most rudimentary operations (required to get access to process features) would be exposed as primops. Let's call this the small set of concurrent ops. If we want the big set I think we're doomed to *reproduce* the logic that maps LLVM concurrency abstractions onto machine ops irrespective of whether those abstractions are implemented as Haskell functions or as primops: - If the former, then the Haskell library must map the full set of ops to the reduced small set (just like LLVM does internally) - If we instead have a large set of LLVM-isomorphic primops then to support the same primops *in the native code backend *will, again, require reimplementing all configurations of all operations. Unless... we want to make concurrency ops something that require the LLVM backend? Right now there is not a *performance* disadvantage to supporting a smaller rather than a larger set of concurrency ops (LLVM has to emulate these things anyway, or round up to more expensive ops). The scenario where it would be good to target ALL of LLVMs interface would be if processors and LLVM improved in the future, and we automatically got the benefit of better HW support for some op on on some arch. I'm a bit skeptical of that proposition itself, however. I personally don't really like a world where we program with virtual operations that don't really exist (and thus can't be *tested* against properly). Absent formal verification, it seems hard to get this code right anyway. Errors will be undetectable on existing architectures. -Ryan ___ 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: Design discussion for atomic primops to land in 7.8
Well, what's the long term plan? Is the LLVM backend going to become the only backend at some point? On Thu, Aug 22, 2013 at 1:43 PM, Carter Schonwald carter.schonw...@gmail.com wrote: Hey Ryan, you raise some very good points. The most important point you raise (I think) is this: it would be very very nice to (where feasible) to add analogous machinery to the native code gen, so that its not falling behind the llvm one quite as much. at least for these atomic operations (unlike the SIMD ones), it may be worth investigating whats needed to add those to the native code gen as well. (adding simd support on the native codegen would be nice too, but probably *substantially *more work) On Thu, Aug 22, 2013 at 11:40 AM, Ryan Newton rrnew...@gmail.com wrote: There's a ticket that describes the design here: http://ghc.haskell.org/trac/ghc/ticket/8157#comment:1 It is a fairly simple extension of the casMutVar# that has been in since 7.2. The implementation is on the `atomics` branch currently. Feel free to add your views either here or on that task's comments. One example of an alternative design would be Carter's proposal to expose something closer to the full LLVM concurrency opshttp://llvm.org/docs/Atomics.html : Schonwald carter.schonw...@gmail.com wrote: i'm kinda thinking that we should do the analogue of exposing all the different memory model level choices (because its not that hard to add that), and when the person building it has an old version of GCC, it falls back to the legacy atomic operations? This also gives a nice path to how to upgrade to the inline asm approach. These LLVM ops include many parameterized configurations of loads, stores, cmpxchg, atomicrmw and barriers. In fact, it implements much more than is natively supported in most hardware, but it provides a uniform abstraction. My original thought was that any kind of abstraction like that would be built and maintained as a Haskell library, and only the most rudimentary operations (required to get access to process features) would be exposed as primops. Let's call this the small set of concurrent ops. If we want the big set I think we're doomed to *reproduce* the logic that maps LLVM concurrency abstractions onto machine ops irrespective of whether those abstractions are implemented as Haskell functions or as primops: - If the former, then the Haskell library must map the full set of ops to the reduced small set (just like LLVM does internally) - If we instead have a large set of LLVM-isomorphic primops then to support the same primops *in the native code backend *will, again, require reimplementing all configurations of all operations. Unless... we want to make concurrency ops something that require the LLVM backend? Right now there is not a *performance* disadvantage to supporting a smaller rather than a larger set of concurrency ops (LLVM has to emulate these things anyway, or round up to more expensive ops). The scenario where it would be good to target ALL of LLVMs interface would be if processors and LLVM improved in the future, and we automatically got the benefit of better HW support for some op on on some arch. I'm a bit skeptical of that proposition itself, however. I personally don't really like a world where we program with virtual operations that don't really exist (and thus can't be *tested* against properly). Absent formal verification, it seems hard to get this code right anyway. Errors will be undetectable on existing architectures. -Ryan ___ 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
Active Branches
All, A while back, Nicolas Frisby compiled a small list of the currently active branches in the GHC tree. I would like to clean up a lot of the existing branches which are effectively dead (by deleting them.) At the same time, it's nice to take inventory and see what's currently out there, or 'in limbo'. http://ghc.haskell.org/trac/ghc/wiki/ActiveBranches I have kept up with *most* of the branches, and filled out a bunch of details above, greatly expanding the list. However, several are light on details and I'm not sure what's up with all of them, so I'd appreciate your input if you own a branch. I do however, believe all the 'dead' branches are accurate. If you're working on a branch, please note it here. I'd like for people to keep better track of this with a small note on this page; perhaps putting a link on the front of the wiki is a good idea. I'd like to be able to delete a lot of the defunct branches sometime soon, so just let me know in the mean time. -- Regards, Austin - PGP: 4096R/0x91384671 ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Validate failures
Simon, While validating the changes for #8144, I noticed there were several failures that seem like a result of your recent commits (amd64/Linux): Unexpected failures: . T4059 [bad stderr] (normal) . T4850 [bad stderr] (normal) . T5423 [bad stderr] (normal) . T7037 [bad stderr] (normal) . atomicinc [exit code non-0] (normal) . outofmem [bad stderr] (normal) . outofmem2 [bad stderr] (normal) I see several of the these fail, like: = T7037(normal) 1205 of 3760 [0, 6, 0] cd ./rts $MAKE -s --no-print-directory T7037/dev/null T7037.run.stdout 2T7037.run.stderr Actual stderr output differs from expected: --- /dev/null 2013-08-15 19:58:16.771097011 -0500 +++ ./rts/T7037.run.stderr 2013-08-22 13:27:33.531638515 -0500 @@ -0,0 +1 @@ +Makefile:74: xxx/home/a/ghc/ghc-pristine/libraries/base/dist-install/buildxxx *** unexpected failure for T7037(normal) This is because in 269c89062dd5b6d2b8bc4d41e5dca0eca2308d02, you added: +$(warning xxx$(BASE_DIR)xxx) Which I presume is perhaps left-over debugging cruft? I also see this failure: $ make TEST=atomicinc ... = atomicinc(normal) 15 of 41 [0, 0, 0] cd . '/home/a/ghc/ghc-pristine/inplace/bin/ghc-stage2' -fforce-recomp -dcore-lint -dcmm-lint -dno-debug-output -no-user-package-db -rtsopts -fno-ghci-history -o atomicinc atomicinc.c -no-hs-main atomicinc.comp.stderr 21 Compile failed (status 256) errors were: Warning: -rtsopts and -with-rtsopts have no effect with -no-hs-main. Call hs_init_ghc() from your main() function to set these options. atomicinc.o: In function `main': atomicinc.c:(.text+0x20): undefined reference to `atomic_inc' atomicinc.c:(.text+0x60): undefined reference to `atomic_dec' collect2: error: ld returned 1 exit status But I'm not sure what's causing it, since this hasn't been touched in a while. -- Regards, Austin - PGP: 4096R/0x91384671 ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Validate failures
Sorry! Just pushed the fix. atomicinc was also failing for me, I assumed it was nothing to do with me. Perhaps not. I'll look into it. Cheers, Simon On 22/08/13 19:35, Austin Seipp wrote: Simon, While validating the changes for #8144, I noticed there were several failures that seem like a result of your recent commits (amd64/Linux): Unexpected failures: . T4059 [bad stderr] (normal) . T4850 [bad stderr] (normal) . T5423 [bad stderr] (normal) . T7037 [bad stderr] (normal) . atomicinc [exit code non-0] (normal) . outofmem [bad stderr] (normal) . outofmem2 [bad stderr] (normal) I see several of the these fail, like: = T7037(normal) 1205 of 3760 [0, 6, 0] cd ./rts $MAKE -s --no-print-directory T7037/dev/null T7037.run.stdout 2T7037.run.stderr Actual stderr output differs from expected: --- /dev/null2013-08-15 19:58:16.771097011 -0500 +++ ./rts/T7037.run.stderr2013-08-22 13:27:33.531638515 -0500 @@ -0,0 +1 @@ +Makefile:74: xxx/home/a/ghc/ghc-pristine/libraries/base/dist-install/buildxxx *** unexpected failure for T7037(normal) This is because in 269c89062dd5b6d2b8bc4d41e5dca0eca2308d02, you added: +$(warning xxx$(BASE_DIR)xxx) Which I presume is perhaps left-over debugging cruft? I also see this failure: $ make TEST=atomicinc ... = atomicinc(normal) 15 of 41 [0, 0, 0] cd . '/home/a/ghc/ghc-pristine/inplace/bin/ghc-stage2' -fforce-recomp -dcore-lint -dcmm-lint -dno-debug-output -no-user-package-db -rtsopts -fno-ghci-history -o atomicinc atomicinc.c -no-hs-main atomicinc.comp.stderr 21 Compile failed (status 256) errors were: Warning: -rtsopts and -with-rtsopts have no effect with -no-hs-main. Call hs_init_ghc() from your main() function to set these options. atomicinc.o: In function `main': atomicinc.c:(.text+0x20): undefined reference to `atomic_inc' atomicinc.c:(.text+0x60): undefined reference to `atomic_dec' collect2: error: ld returned 1 exit status But I'm not sure what's causing it, since this hasn't been touched in a while. -- Regards, Austin - PGP: 4096R/0x91384671 ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: how to checkout proper submodules
Hi all, I just reread this thread again. Is this one of these situations where *almost everyone agrees, but the fix just didn't happen*? In particular, there is still no formal relationship between versions of the compiler and versions of the testsuite that tests it -- that seems odd! Can we please make *testsuite at least *a sub-module? If we count this long email thread as rough consensus, is it just waiting on someone of sufficient authority typing a git submodule add command (and tweaking sync-all accordingly)? Also, Jan's suggestion sounded good -- that once all child repos are git submodules then sync-all can be replaced with something that helps out with git submodule branching, as it helps out with multi-repo branching now (a little bit). Best, -Ryan On Wed, Jun 5, 2013 at 2:02 PM, Jan Stolarek jan.stola...@p.lodz.pl wrote: I think that testsuite should be included in the main GHC repo. I don't recall any other project that has its tests placed in a separate repository. The nhc argument doesn't convince me - after all, most test that are added nowadays are GHC specific. Janek ___ 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: Can't make libffi
On 20/08/13 11:55, Mateusz Kowalczyk wrote: Trying to build HEAD I get. inplace/bin/ghc-stage1@exeext_host@ -fPIC -dynamic -H32m -O -Werror -Wall -H64m -O0 -Iincludes -Iincludes/dist -Iincludes/dist-derivedconstants/header -Iincludes/dist-ghcconstants/header -Irts -Irts/dist/build -DCOMPILING_RTS -package-name rts -dcmm-lint -i -irts -irts/dist/build -irts/dist/build/autogen -Irts/dist/build -Irts/dist/build/autogen -O2-c rts/PrimOps.cmm -o rts/dist/build/PrimOps.dyn_o inplace/bin/ghc-stage1@exeext_host@ -fPIC -dynamic -H32m -O -Werror -Wall -H64m -O0 -Iincludes -Iincludes/dist -Iincludes/dist-derivedconstants/header -Iincludes/dist-ghcconstants/header -Irts -Irts/dist/build -DCOMPILING_RTS -package-name rts -dcmm-lint -i -irts -irts/dist/build -irts/dist/build/autogen -Irts/dist/build -Irts/dist/build/autogen -O2-c rts/dist/build/AutoApply.cmm -o rts/dist/build/AutoApply.dyn_o inplace/bin/ghc-pkg@exeext_host@ --simple-output field rts extra-libraries \ | sed -e 's/\([^ ][^ ]*\)/-l\1/g' rts/dist/libs.depend inplace/bin/ghc-pkg@exeext_host@ --simple-output field rts library-dirs \ | sed -e 's/\([^ ][^ ]*\)/-L\1/g' rts/dist/libs.depend make[1]: *** No rule to make target `libffi/build/inst/lib/libffi@soext_target@', needed by `rts/dist/build/libffi@soext_target@'. Stop. make: *** [all] Error 2 I know there is some repository moving shenanigans going on at the moment so I am not sure whether that's something to look out for. All I did was ./sync-all get and then ./sync-all pull without changing anything – I have the same setup as I did couple of weeks ago. ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs I started with a fresh tree today and am now getting inplace/bin/ghc-stage1 -optc-Wall -optc-Wextra -optc-Wstrict-prototypes -optc-Wmissing-prototypes -optc-Wmissing-declarations -optc-Winline -optc-Waggregate-return -optc-Wpointer-arith -optc-Wmissing-noreturn -optc-Wnested-externs -optc-Wredundant-decls -optc-Iincludes -optc-Iincludes/dist -optc-Iincludes/dist-derivedconstants/header -optc-Iincludes/dist-ghcconstants/header -optc-Irts -optc-Irts/dist/build -optc-DCOMPILING_RTS -optc-fno-strict-aliasing -optc-fno-common -optc-O2 -optc-fomit-frame-pointer -optc-DRtsWay=\rts_v\ -static -H64m -O0 -fasm -Iincludes -Iincludes/dist -Iincludes/dist-derivedconstants/header -Iincludes/dist-ghcconstants/header -Irts -Irts/dist/build -DCOMPILING_RTS -package-name rts -dcmm-lint -i -irts -irts/dist/build -irts/dist/build/autogen -Irts/dist/build -Irts/dist/build/autogen -O2-c rts/StgPrimFloat.c -o rts/dist/build/StgPrimFloat.o inplace/bin/ghc-stage1 -optc-Wall -optc-Wextra -optc-Wstrict-prototypes -optc-Wmissing-prototypes -optc-Wmissing-declarations -optc-Winline -optc-Waggregate-return -optc-Wpointer-arith -optc-Wmissing-noreturn -optc-Wnested-externs -optc-Wredundant-decls -optc-Iincludes -optc-Iincludes/dist -optc-Iincludes/dist-derivedconstants/header -optc-Iincludes/dist-ghcconstants/header -optc-Irts -optc-Irts/dist/build -optc-DCOMPILING_RTS -optc-fno-strict-aliasing -optc-fno-common -optc-O2 -optc-fomit-frame-pointer -optc-DRtsWay=\rts_v\ -optc-DDYNAMIC_GHC_PROGRAMS -static -H64m -O0 -fasm -Iincludes -Iincludes/dist -Iincludes/dist-derivedconstants/header -Iincludes/dist-ghcconstants/header -Irts -Irts/dist/build -DCOMPILING_RTS -package-name rts -dcmm-lint -i -irts -irts/dist/build -irts/dist/build/autogen -Irts/dist/build -Irts/dist/build/autogen -O2-c rts/Linker.c -o rts/dist/build/Linker.o rts/Linker.c: In function ‘freeObjectCode’: rts/Linker.c:2073:18: error: ‘ObjectCode’ has no member named ‘symbol_extras’ rts/Linker.c:2074:16: error: ‘ObjectCode’ has no member named ‘n_symbol_extras’ make[1]: *** [rts/dist/build/Linker.o] Error 1 make: *** [all] Error 2 Help appreciated. -- Mateusz K. ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Validate failures
Fixed atomicinc too. Cheers, Simon On 22/08/13 19:58, Simon Marlow wrote: Sorry! Just pushed the fix. atomicinc was also failing for me, I assumed it was nothing to do with me. Perhaps not. I'll look into it. Cheers, Simon On 22/08/13 19:35, Austin Seipp wrote: Simon, While validating the changes for #8144, I noticed there were several failures that seem like a result of your recent commits (amd64/Linux): Unexpected failures: . T4059 [bad stderr] (normal) . T4850 [bad stderr] (normal) . T5423 [bad stderr] (normal) . T7037 [bad stderr] (normal) . atomicinc [exit code non-0] (normal) . outofmem [bad stderr] (normal) . outofmem2 [bad stderr] (normal) I see several of the these fail, like: = T7037(normal) 1205 of 3760 [0, 6, 0] cd ./rts $MAKE -s --no-print-directory T7037/dev/null T7037.run.stdout 2T7037.run.stderr Actual stderr output differs from expected: --- /dev/null2013-08-15 19:58:16.771097011 -0500 +++ ./rts/T7037.run.stderr2013-08-22 13:27:33.531638515 -0500 @@ -0,0 +1 @@ +Makefile:74: xxx/home/a/ghc/ghc-pristine/libraries/base/dist-install/buildxxx *** unexpected failure for T7037(normal) This is because in 269c89062dd5b6d2b8bc4d41e5dca0eca2308d02, you added: +$(warning xxx$(BASE_DIR)xxx) Which I presume is perhaps left-over debugging cruft? I also see this failure: $ make TEST=atomicinc ... = atomicinc(normal) 15 of 41 [0, 0, 0] cd . '/home/a/ghc/ghc-pristine/inplace/bin/ghc-stage2' -fforce-recomp -dcore-lint -dcmm-lint -dno-debug-output -no-user-package-db -rtsopts -fno-ghci-history -o atomicinc atomicinc.c -no-hs-main atomicinc.comp.stderr 21 Compile failed (status 256) errors were: Warning: -rtsopts and -with-rtsopts have no effect with -no-hs-main. Call hs_init_ghc() from your main() function to set these options. atomicinc.o: In function `main': atomicinc.c:(.text+0x20): undefined reference to `atomic_inc' atomicinc.c:(.text+0x60): undefined reference to `atomic_dec' collect2: error: ld returned 1 exit status But I'm not sure what's causing it, since this hasn't been touched in a while. -- Regards, Austin - PGP: 4096R/0x91384671 ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: [commit: testsuite] master: linker_unload fails when using dynamic GHCi. (a5875c4)
On 22/08/13 19:24, g...@git.haskell.org wrote: Repository : ssh://g...@git.haskell.org/testsuite On branch : master Link : http://ghc.haskell.org/trac/ghc/changeset/a5875c4e4fb83993142c8e8294b47516adf6a77f/testsuite --- commit a5875c4e4fb83993142c8e8294b47516adf6a77f Author: Austin Seipp ase...@pobox.com Date: Thu Aug 22 13:22:22 2013 -0500 linker_unload fails when using dynamic GHCi. This is because dynamic GHCi can't load archive files, and linker_unload explicitly does this via loadArchive(). Sigh. I've no idea why the linker has an explicit check for this, there's no reason why it can't work. I'll fix it. Cheers, Simon ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: how to checkout proper submodules
Simon and I discussed this a little today. I think there are several legitimate points made throughout the threads here, but the problem is clear: consistent builds are difficult, if not legitimately impossible. That's a very big problem. Right now, it is far too late into release cycle to do anything drastic I'm afraid. Once we branch, we can feasibly start making good changes in this direction. One problem however is that we don't even have a clear writeup over what all the relevant points are (aside from this + all the ranting I did elsewhere, which is loosely in my head still.) Earlier today, I preemptively created this page, but have not jotted down any of my notes: http://ghc.haskell.org/trac/ghc/wiki/GitSubmoduleProblem For a short recap, here is what I think: 1) Several repositories should really just become part of GHC's repository. I'd argue that includes testsuite, nofib, and several others (integer-gmp/integer-simple, hpc, etc.) They don't need to be submodules and making them so is unnecessary complexity, when they can realistically never be used with anything else. This cuts down on something like 10 repositories, IIRC. 2) Several more should become submodules, where 'more' = the libraries under the new Core Libraries Committee. They will be taking over several of the other free floating repositories that are not currently submodules. We no longer will 'own' them, as it is. 3) 'base' and 'ghc-prim' are up for more debate it seems. Roman wants them in particular for haskell-suite, but really he only wants a repository to work with from what I remember. I'm not sure what to do here. Making them a submodule is realistic, but I'm honestly a little afraid of submodules for a package which is so highly traffic'd by developers (another reason I don't want e.g. testsuite as a submodule, either.) The first two points alone should help a lot in making builds more reliable and reproducible, but it will require changes in the development workflow. In particular, it's much easier to lose work with submodules - especially for those among us who are not Git masters. So we should take the time to clearly explain all of this. But 1 2 should cover a large part the current setup, and most repos are very low traffic. Also, I'd like to take the time to have a discussion with Edward Kmett (who I have CC'd) about point 2 to make sure we're on the same page here. But I haven't done this yet. Point 3 seems to really be the most contentious, since a few other things come with it. Should we give up on 'base' being usable by other compilers? Historically that's why it's separate. But really it's easy to write code against 'base' that will never work with another compiler anyway. But maybe that can be fixed. And will the base split - also slated for post 7.8 - also change the ownership of significant parts of the library, based on how it is implemented? There were several things floating around this. Regardless of point 3 and all that, something should and will be done soon. I'll put this up on the wiki later when I have time. We just need a directly spelled out plan of attack. On Thu, Aug 22, 2013 at 2:04 PM, Ryan Newton rrnew...@gmail.com wrote: Hi all, I just reread this thread again. Is this one of these situations where *almost everyone agrees, but the fix just didn't happen*? In particular, there is still no formal relationship between versions of the compiler and versions of the testsuite that tests it -- that seems odd! Can we please make *testsuite at least *a sub-module? If we count this long email thread as rough consensus, is it just waiting on someone of sufficient authority typing a git submodule add command (and tweaking sync-all accordingly)? Also, Jan's suggestion sounded good -- that once all child repos are git submodules then sync-all can be replaced with something that helps out with git submodule branching, as it helps out with multi-repo branching now (a little bit). Best, -Ryan On Wed, Jun 5, 2013 at 2:02 PM, Jan Stolarek jan.stola...@p.lodz.plwrote: I think that testsuite should be included in the main GHC repo. I don't recall any other project that has its tests placed in a separate repository. The nhc argument doesn't convince me - after all, most test that are added nowadays are GHC specific. Janek ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs -- Regards, Austin - PGP: 4096R/0x91384671 ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: [commit: testsuite] master: linker_unload fails when using dynamic GHCi. (a5875c4)
Thanks. When I followed the ticket, it gave me the impression failure for dynamic GHCi seems relatively reasonable, so I assumed this was acceptable. Should've just asked! On Thu, Aug 22, 2013 at 2:16 PM, Simon Marlow marlo...@gmail.com wrote: On 22/08/13 19:24, g...@git.haskell.org wrote: Repository : ssh://g...@git.haskell.org/**testsuitehttp://g...@git.haskell.org/testsuite On branch : master Link : http://ghc.haskell.org/trac/**ghc/changeset/** a5875c4e4fb83993142c8e8294b475**16adf6a77f/testsuitehttp://ghc.haskell.org/trac/ghc/changeset/a5875c4e4fb83993142c8e8294b47516adf6a77f/testsuite --**--**--- commit a5875c4e4fb83993142c8e8294b475**16adf6a77f Author: Austin Seipp ase...@pobox.com Date: Thu Aug 22 13:22:22 2013 -0500 linker_unload fails when using dynamic GHCi. This is because dynamic GHCi can't load archive files, and linker_unload explicitly does this via loadArchive(). Sigh. I've no idea why the linker has an explicit check for this, there's no reason why it can't work. I'll fix it. Cheers, Simon __**_ ghc-commits mailing list ghc-comm...@haskell.org http://www.haskell.org/**mailman/listinfo/ghc-commitshttp://www.haskell.org/mailman/listinfo/ghc-commits -- Regards, Austin - PGP: 4096R/0x91384671 ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
RE: how to checkout proper submodules
There was a long discussion about this a couple of months ago. It did not reach a conclusion, but it is merely parked, not abandoned. I hope that you can all pick it up again after the release. Simon From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of Austin Seipp Sent: 22 August 2013 20:31 To: Ryan Newton Cc: ghc-devs@haskell.org; Edward Kmett Subject: Re: how to checkout proper submodules Simon and I discussed this a little today. I think there are several legitimate points made throughout the threads here, but the problem is clear: consistent builds are difficult, if not legitimately impossible. That's a very big problem. Right now, it is far too late into release cycle to do anything drastic I'm afraid. Once we branch, we can feasibly start making good changes in this direction. One problem however is that we don't even have a clear writeup over what all the relevant points are (aside from this + all the ranting I did elsewhere, which is loosely in my head still.) Earlier today, I preemptively created this page, but have not jotted down any of my notes: http://ghc.haskell.org/trac/ghc/wiki/GitSubmoduleProblem For a short recap, here is what I think: 1) Several repositories should really just become part of GHC's repository. I'd argue that includes testsuite, nofib, and several others (integer-gmp/integer-simple, hpc, etc.) They don't need to be submodules and making them so is unnecessary complexity, when they can realistically never be used with anything else. This cuts down on something like 10 repositories, IIRC. 2) Several more should become submodules, where 'more' = the libraries under the new Core Libraries Committee. They will be taking over several of the other free floating repositories that are not currently submodules. We no longer will 'own' them, as it is. 3) 'base' and 'ghc-prim' are up for more debate it seems. Roman wants them in particular for haskell-suite, but really he only wants a repository to work with from what I remember. I'm not sure what to do here. Making them a submodule is realistic, but I'm honestly a little afraid of submodules for a package which is so highly traffic'd by developers (another reason I don't want e.g. testsuite as a submodule, either.) The first two points alone should help a lot in making builds more reliable and reproducible, but it will require changes in the development workflow. In particular, it's much easier to lose work with submodules - especially for those among us who are not Git masters. So we should take the time to clearly explain all of this. But 1 2 should cover a large part the current setup, and most repos are very low traffic. Also, I'd like to take the time to have a discussion with Edward Kmett (who I have CC'd) about point 2 to make sure we're on the same page here. But I haven't done this yet. Point 3 seems to really be the most contentious, since a few other things come with it. Should we give up on 'base' being usable by other compilers? Historically that's why it's separate. But really it's easy to write code against 'base' that will never work with another compiler anyway. But maybe that can be fixed. And will the base split - also slated for post 7.8 - also change the ownership of significant parts of the library, based on how it is implemented? There were several things floating around this. Regardless of point 3 and all that, something should and will be done soon. I'll put this up on the wiki later when I have time. We just need a directly spelled out plan of attack. On Thu, Aug 22, 2013 at 2:04 PM, Ryan Newton rrnew...@gmail.commailto:rrnew...@gmail.com wrote: Hi all, I just reread this thread again. Is this one of these situations where almost everyone agrees, but the fix just didn't happen? In particular, there is still no formal relationship between versions of the compiler and versions of the testsuite that tests it -- that seems odd! Can we please make testsuite at least a sub-module? If we count this long email thread as rough consensus, is it just waiting on someone of sufficient authority typing a git submodule add command (and tweaking sync-all accordingly)? Also, Jan's suggestion sounded good -- that once all child repos are git submodules then sync-all can be replaced with something that helps out with git submodule branching, as it helps out with multi-repo branching now (a little bit). Best, -Ryan On Wed, Jun 5, 2013 at 2:02 PM, Jan Stolarek jan.stola...@p.lodz.plmailto:jan.stola...@p.lodz.pl wrote: I think that testsuite should be included in the main GHC repo. I don't recall any other project that has its tests placed in a separate repository. The nhc argument doesn't convince me - after all, most test that are added nowadays are GHC specific. Janek ___ ghc-devs mailing list ghc-devs@haskell.orgmailto:ghc-devs@haskell.org
Re: Active Branches
I made the necessary adjustments. Just some more observations... Cardinality: merged, someone should close this: http://ghc.haskell.org/trac/ghc/ticket/7520 but Simon wanted to look at this one: http://ghc.haskell.org/trac/ghc/ticket/8036 Gitolyte, can this be closed? http://ghc.haskell.org/trac/ghc/ticket/8121 Cheers, Gabor On 8/22/13, Austin Seipp ase...@pobox.com wrote: All, A while back, Nicolas Frisby compiled a small list of the currently active branches in the GHC tree. I would like to clean up a lot of the existing branches which are effectively dead (by deleting them.) At the same time, it's nice to take inventory and see what's currently out there, or 'in limbo'. http://ghc.haskell.org/trac/ghc/wiki/ActiveBranches I have kept up with *most* of the branches, and filled out a bunch of details above, greatly expanding the list. However, several are light on details and I'm not sure what's up with all of them, so I'd appreciate your input if you own a branch. I do however, believe all the 'dead' branches are accurate. If you're working on a branch, please note it here. I'd like for people to keep better track of this with a small note on this page; perhaps putting a link on the front of the wiki is a good idea. I'd like to be able to delete a lot of the defunct branches sometime soon, so just let me know in the mean time. -- Regards, Austin - PGP: 4096R/0x91384671 ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: how to checkout proper submodules
Ok, resuming after release makes sense. Regarding whether it reached a conclusion: What struck me about this particular discussion was the *lack* of disagreement (relative to say, the records debate). It seemed like no one was arguing for the status quo and just about everyone agreed that moving to all-submodules is better than the current mix. Still, one could argue that making an improvement is premature if (1) there is significant transition cost to make the change, or (2) it puts you on some kind of local optima that makes it harder to get to a higher peak. Yet in the case of all-submodules vs. ugly-mix, the transition cost is very low, and it doesn't preclude any future improvements. (For example, it is completely reasonable to later decide to copy certain modules into the tree rather than using submodules.) But maybe I'm under-estimating the severity of the anti-submodule grumbling... that is, I may not not be accurately distinguishing the submodules have their annoyances but they are the lesser evil opinion from I will adamantly oppose adding any more submodules. Best, -Ryan On Thu, Aug 22, 2013 at 4:14 PM, Simon Peyton-Jones simo...@microsoft.comwrote: There was a long discussion about this a couple of months ago. It did not reach a conclusion, but it is merely parked, not abandoned. I hope that you can all pick it up again after the release. ** ** Simon ** ** *From:* ghc-devs [mailto:ghc-devs-boun...@haskell.org] *On Behalf Of *Austin Seipp *Sent:* 22 August 2013 20:31 *To:* Ryan Newton *Cc:* ghc-devs@haskell.org; Edward Kmett *Subject:* Re: how to checkout proper submodules ** ** Simon and I discussed this a little today. I think there are several legitimate points made throughout the threads here, but the problem is clear: consistent builds are difficult, if not legitimately impossible. That's a very big problem. ** ** Right now, it is far too late into release cycle to do anything drastic I'm afraid. Once we branch, we can feasibly start making good changes in this direction. One problem however is that we don't even have a clear writeup over what all the relevant points are (aside from this + all the ranting I did elsewhere, which is loosely in my head still.) Earlier today, I preemptively created this page, but have not jotted down any of my notes: http://ghc.haskell.org/trac/ghc/wiki/GitSubmoduleProblem ** ** For a short recap, here is what I think: ** ** 1) Several repositories should really just become part of GHC's repository. I'd argue that includes testsuite, nofib, and several others (integer-gmp/integer-simple, hpc, etc.) They don't need to be submodules and making them so is unnecessary complexity, when they can realistically never be used with anything else. This cuts down on something like 10 repositories, IIRC. ** ** 2) Several more should become submodules, where 'more' = the libraries under the new Core Libraries Committee. They will be taking over several of the other free floating repositories that are not currently submodules. We no longer will 'own' them, as it is. ** ** 3) 'base' and 'ghc-prim' are up for more debate it seems. Roman wants them in particular for haskell-suite, but really he only wants a repository to work with from what I remember. I'm not sure what to do here. Making them a submodule is realistic, but I'm honestly a little afraid of submodules for a package which is so highly traffic'd by developers (another reason I don't want e.g. testsuite as a submodule, either.) ** ** The first two points alone should help a lot in making builds more reliable and reproducible, but it will require changes in the development workflow. In particular, it's much easier to lose work with submodules - especially for those among us who are not Git masters. So we should take the time to clearly explain all of this. But 1 2 should cover a large part the current setup, and most repos are very low traffic. Also, I'd like to take the time to have a discussion with Edward Kmett (who I have CC'd) about point 2 to make sure we're on the same page here. But I haven't done this yet. ** ** Point 3 seems to really be the most contentious, since a few other things come with it. Should we give up on 'base' being usable by other compilers? Historically that's why it's separate. But really it's easy to write code against 'base' that will never work with another compiler anyway. But maybe that can be fixed. And will the base split - also slated for post 7.8 - also change the ownership of significant parts of the library, based on how it is implemented? There were several things floating around this. ** ** Regardless of point 3 and all that, something should and will be done soon. I'll put this up on the wiki later when I have time. We just need a directly spelled out plan of attack. ** ** ** ** On Thu, Aug 22, 2013 at 2:04 PM, Ryan
Re: Reproducible build recipes for GHC development VMs?
Oh, good question. It was Ubuntu 12.04 LTS so I just assumed it would be too old without checking. On Thu, Aug 22, 2013 at 3:38 AM, Simon Marlow marlo...@gmail.com wrote: On 21/08/13 15:44, Ryan Newton wrote: Hi all, Returning to the topic discussed by Simon M. and others here: http://projects.haskell.org/**pipermail/haskell-platform/** 2009-July/000572.htmlhttp://projects.haskell.org/pipermail/haskell-platform/2009-July/000572.html This is my attempt at a script for bootstrapping a GHC-validating VM: http://parfunk.blogspot.com/**2013/08/zero-to-ghc-** development-in-ubuntu-vm-in.**htmlhttp://parfunk.blogspot.com/2013/08/zero-to-ghc-development-in-ubuntu-vm-in.html Let me know if there's a better way, or if you'd like to help get this kind of thing into an even more accessible form (Amazon AMI, Chef recipe, etc). I do this occasionally with an Amazon VM. Incidentally, why did you download the GHC 7.6.3 tarball rather than apt-get install ghc? The current GHC on Ubuntu is 7.4 which is enough to bootstrap GHC HEAD. Cheers, Simon ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
HEADS UP: interface file change
Hi all, I merged patches from #8144 into HEAD to fix nasty recompilation-checking behavior. As a result, the interface format has changed, so you'll need to clean your tree the next time you sync up. -- Regards, Austin - PGP: 4096R/0x91384671 ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Haskell platform
Urk. The Haskell Platform claims to include Happy and Alex. http://www.haskell.org/platform/contents.html But 2013.2.0.0 doesn't. Is that intentional? That's a big problem for people using HP to build GHC. I'm installing 2012.4.0.0 in the hope that it does. No, nor does 2012.2 Am I just being stupid here? Simon ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Building on windows
I've got a new Windows laptop, and have being having a torrid time getting GHC to build on it. 1. Build falls over with checking for gcc... c:/code/HEAD/inplace/mingw/bin/gcc.exe checking whether the C compiler works... no configure: error: in `/c/code/HEAD': configure: error: C compiler cannot create executables Turns out that an earlier error was configure: Making in-tree mingw tree tar (child): ../../ghc-tarballs/mingw/binutils*.tar.lzma: Cannot open: No such file or directory tar (child): Error is not recoverable: exiting now tar: Child returned status 2 tar: Error is not recoverable: exiting now ./configure: line 4050: inplace/mingw/bin/realgcc.exe: No such file or directory configure: In-tree mingw tree created configure: Making in-tree perl tree BUT this error was not fatal, so the build went on (notwithstanding the red message above), leading to a MUCH more obscure error later. 2. Why wasn't ghc-tarballs there? Oh, apparently you have to say sync-all -windows get That's really hard for a naïve user to work out. Can't we either always get it, or work out that we are on windows? 3. I carefully installed mingw/msys as described on http://www.mingw.org/wiki/Getting_Started I used mingw-set-inst, which launches a GUI for a package installer. All seems well. I update my path. But then Can't locate Autom4te/ChannelDefs.pm in @INC (@INC contains: /mingw/share/autoco nf /usr/lib/perl5/5.8/msys /usr/lib/perl5/5.8 /usr/lib/perl5/site_perl/5.8/msys /usr/lib/perl5/site_perl/5.8 /usr/lib/perl5/site_perl/5.8 /usr/lib/perl5/vendor_ perl/5.8/msys /usr/lib/perl5/vendor_perl/5.8 /usr/lib/perl5/vendor_perl/5.8 .) a t /c/Programme/MinGW/bin/autoreconf-2.68 line 40. BEGIN failed--compilation aborted at /c/Programme/MinGW/bin/autoreconf-2.68 line 40. After a long struggle I found that I had missed a crucial thing. With the new autoconf tools, it's essential that c:/mingw be mounted as /mingw, because /mingw is hard-coded into autoconf perl scripts. http://www.mingw.org/wiki/Getting_Started does say (deep in the middle) to edit c:/mingw/msys/1.0/etc/fstab with a text editor, but that appeared to have no effect for me. Saying mount c:/mingw /mingw did work. I have no idea why. What is horrible is how uninformative the error message is. I guess we should update the Windows build instructions. I still don't know if I've bottomed out here because I can't find Happy/Alex in the Haskell platform. Sigh. Simon ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Building on windows
Additionally, if you're using the latest MinGW it ships with GCC 4.7 and fails with an error I reported and thoughtpolice replied here; http://ghc.haskell.org/trac/ghc/ticket/7056#comment:9 There's a patch that (with some hacking, namely, fixing the missing bracket) will bring GHC to build. It later faults again, though. http://lpaste.net/92097 Windows needs some love :( ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Haskell platform
Huh. What OS? Could this be an issue wth your path? Failing that Try cabal update ; cabal install happy ; cabal alex Unless there's some reason you can't use cabal-install? On Thursday, August 22, 2013, Simon Peyton-Jones wrote: Urk. The Haskell Platform claims to include Happy and Alex. http://www.haskell.org/platform/contents.html ** ** But 2013.2.0.0 doesn’t. Is that intentional? ** ** That’s a big problem for people using HP to build GHC. I’m installing 2012.4.0.0 in the hope that it does. No, nor does 2012.2 ** ** Am I just being stupid here? ** ** Simon ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
