From jan.stolarek at p.lodz.pl Sun Dec 1 08:00:21 2013 From: jan.stolarek at p.lodz.pl (Jan Stolarek) Date: Sun, 1 Dec 2013 09:00:21 +0100 Subject: Getting Involved In-Reply-To: <5299013E.9090501@fuuzetsu.co.uk> References: <201311292129.30805.jan.stolarek@p.lodz.pl> <5299013E.9090501@fuuzetsu.co.uk> Message-ID: <201312010900.21414.jan.stolarek@p.lodz.pl> > perhaps a direct link in the sidebar or maybe even a link on the front > page in Developer Documentation section would be appropriate! I added link to Newcomers page at the main page of Commentary. Don't have the permissions to add it to the sidebar though. Janek From jan.stolarek at p.lodz.pl Sun Dec 1 08:53:18 2013 From: jan.stolarek at p.lodz.pl (Jan Stolarek) Date: Sun, 1 Dec 2013 09:53:18 +0100 Subject: Getting Involved In-Reply-To: <87haat9dia.fsf@gmail.com> References: <201312010900.21414.jan.stolarek@p.lodz.pl> <87haat9dia.fsf@gmail.com> Message-ID: <201312010953.19100.jan.stolarek@p.lodz.pl> Herbert, Austin, right, I didn't notice link to Newcomers is on the "Working on GHC" page. I rearranged it slightly by reversing first three steps. So link to Newcomers is now first on the list and I think it might stay that way. Link to "Working on GHC" is also in the second paragraph of the main wiki page, so I think we're good. As for the sidebar I'm using it on a regular basis although I feel some links could be removed: Documentation -> Repositories; Debugging; View Tickets -> By Milestone; By OS; By Architecture; But that's only my opinion - I'm CCing ghc-devs so others can chime in. If we could somehow track how often each link is used that could be a valuable information. Not sure if it can be done. Janek Dnia niedziela, 1 grudnia 2013, Herbert Valerio Riedel napisa?: > On 2013-12-01 at 09:00:21 +0100, Jan Stolarek wrote: > >> perhaps a direct link in the sidebar or maybe even a link on the front > >> page in Developer Documentation section would be appropriate! > > > > I added link to Newcomers page at the main page of Commentary. > > btw, I'm confused a bit... there's already a rather obvious > > "Joining In"->"Working on GHC" link in the side-bar, which points to > > https://ghc.haskell.org/trac/ghc/wiki/WorkingConventions > > which then points you to the steps that are expected from newcomers, > including the 'Newcomers' page as the 3rd step; once could maybe just > add more emphasis to the 3rd step so that it visually stands out better > (e.g. via [2] or [3]) > > I'm just worried that cluttering the side-bar[1] with a redundant link > may make it less useful. > > > Don't have the permissions to add it to the sidebar though. > > ...the reason is btw, that it's a hacked in HTML fragment that's part of > the custom Trac stylesheet mod for GHC; it can't be edited via the > web-UI. > > > > [1]: which, personally, I find kinda overloaded and redundant which > makes me wonder if it's really that useful in its current form; > > > [2]: https://ghc.haskell.org/trac/ghc/wiki/WikiBoxes > > [3]: https://ghc.haskell.org/trac/ghc/wiki/WikiIcons From simonpj at microsoft.com Mon Dec 2 10:28:29 2013 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Mon, 2 Dec 2013 10:28:29 +0000 Subject: [commit: ghc] master: Respect the ordering of -package directives (574ccfa) In-Reply-To: <20131202023914.B5A612406B@ghc.haskell.org> References: <20131202023914.B5A612406B@ghc.haskell.org> Message-ID: <59543203684B2244980D7E4057D5FBC1486D9865@DB3EX14MBXC308.europe.corp.microsoft.com> Patrick Thanks! When you do something subtle like change 'foldM' to 'foldrM', could you add a comment to point out the subtlety? After all, by definition this was something that someone else missed. Simon | -----Original Message----- | From: ghc-commits [mailto:ghc-commits-bounces at haskell.org] On Behalf Of | git at git.haskell.org | Sent: 02 December 2013 02:39 | To: ghc-commits at haskell.org | Subject: [commit: ghc] master: Respect the ordering of -package | directives (574ccfa) | | Repository : ssh://git at git.haskell.org/ghc | | On branch : master | Link : | http://ghc.haskell.org/trac/ghc/changeset/574ccfa231ca05d03d1da9d31e5bc | 81e74cc5e1e/ghc | | >--------------------------------------------------------------- | | commit 574ccfa231ca05d03d1da9d31e5bc81e74cc5e1e | Author: Patrick Palka | Date: Tue Nov 26 11:46:59 2013 -0500 | | Respect the ordering of -package directives | | | >--------------------------------------------------------------- | | 574ccfa231ca05d03d1da9d31e5bc81e74cc5e1e | compiler/main/Packages.lhs | 15 ++++++++------- | 1 file changed, 8 insertions(+), 7 deletions(-) | | diff --git a/compiler/main/Packages.lhs b/compiler/main/Packages.lhs | index aefb536..df5eddb 100644 | --- a/compiler/main/Packages.lhs | +++ b/compiler/main/Packages.lhs | @@ -59,6 +59,7 @@ import System.FilePath as FilePath | import qualified System.FilePath.Posix as FilePath.Posix | import Control.Monad | import Data.Char (isSpace) | +import Data.Foldable (foldrM) | import Data.List as List | import Data.Map (Map) | import qualified Data.Map as Map | @@ -980,7 +981,7 @@ getPreloadPackagesAnd dflags pkgids = | preload = preloadPackages state | pairs = zip pkgids (repeat Nothing) | in do | - all_pkgs <- throwErr dflags (foldM (add_package pkg_map ipid_map) | preload pairs) | + all_pkgs <- throwErr dflags (foldrM (add_package pkg_map ipid_map) | preload pairs) | return (map (getPackageDetails state) all_pkgs) | | -- Takes a list of packages, and returns the list with dependencies | included, | @@ -1003,15 +1004,15 @@ closeDepsErr :: PackageConfigMap | -> Map InstalledPackageId PackageId | -> [(PackageId,Maybe PackageId)] | -> MaybeErr MsgDoc [PackageId] | -closeDepsErr pkg_map ipid_map ps = foldM (add_package pkg_map | ipid_map) [] ps | +closeDepsErr pkg_map ipid_map ps = foldrM (add_package pkg_map | ipid_map) [] ps | | -- internal helper | add_package :: PackageConfigMap | -> Map InstalledPackageId PackageId | - -> [PackageId] | -> (PackageId,Maybe PackageId) | + -> [PackageId] | -> MaybeErr MsgDoc [PackageId] | -add_package pkg_db ipid_map ps (p, mb_parent) | +add_package pkg_db ipid_map (p, mb_parent) ps | | p `elem` ps = return ps -- Check if we've already added this | package | | otherwise = | case lookupPackage pkg_db p of | @@ -1019,12 +1020,12 @@ add_package pkg_db ipid_map ps (p, mb_parent) | missingDependencyMsg mb_parent) | Just pkg -> do | -- Add the package's dependents also | - ps' <- foldM add_package_ipid ps (depends pkg) | + ps' <- foldrM add_package_ipid ps (depends pkg) | return (p : ps') | where | - add_package_ipid ps ipid@(InstalledPackageId str) | + add_package_ipid ipid@(InstalledPackageId str) ps | | Just pid <- Map.lookup ipid ipid_map | - = add_package pkg_db ipid_map ps (pid, Just p) | + = add_package pkg_db ipid_map (pid, Just p) ps | | otherwise | = Failed (missingPackageMsg str <> missingDependencyMsg | mb_parent) | | | _______________________________________________ | ghc-commits mailing list | ghc-commits at haskell.org | http://www.haskell.org/mailman/listinfo/ghc-commits From marlowsd at gmail.com Mon Dec 2 10:22:58 2013 From: marlowsd at gmail.com (Simon Marlow) Date: Mon, 02 Dec 2013 10:22:58 +0000 Subject: Getting Involved In-Reply-To: <201312010953.19100.jan.stolarek@p.lodz.pl> References: <201312010900.21414.jan.stolarek@p.lodz.pl> <87haat9dia.fsf@gmail.com> <201312010953.19100.jan.stolarek@p.lodz.pl> Message-ID: <529C5F82.8040301@gmail.com> On 01/12/2013 08:53, Jan Stolarek wrote: > Herbert, Austin, > > right, I didn't notice link to Newcomers is on the "Working on GHC" page. I rearranged it slightly > by reversing first three steps. So link to Newcomers is now first on the list and I think it > might stay that way. Link to "Working on GHC" is also in the second paragraph of the main wiki > page, so I think we're good. > > As for the sidebar I'm using it on a regular basis although I feel some links could be removed: > Documentation -> Repositories; Debugging; View Tickets -> By Milestone; By OS; By Architecture; > But that's only my opinion - I'm CCing ghc-devs so others can chime in. If we could somehow track > how often each link is used that could be a valuable information. Not sure if it can be done. The problem with Repositories is that it doesn't live under one of the 4 main hierarchies (Building, Commentary, Debugging, WorkingConventions), so finding it is a bit tricky. I've just added a link to it from the top WorkingConventions page so that should help. I think perhaps it ought to be moved under WorkingConventions/Repositories. I don't know about other people, but the way I most commonly query tickets is from the Roadmap page: pick a milestone and click on "active tickets". Cheers, Simon > > Janek > > Dnia niedziela, 1 grudnia 2013, Herbert Valerio Riedel napisa?: >> On 2013-12-01 at 09:00:21 +0100, Jan Stolarek wrote: >>>> perhaps a direct link in the sidebar or maybe even a link on the front >>>> page in Developer Documentation section would be appropriate! >>> >>> I added link to Newcomers page at the main page of Commentary. >> >> btw, I'm confused a bit... there's already a rather obvious >> >> "Joining In"->"Working on GHC" link in the side-bar, which points to >> >> https://ghc.haskell.org/trac/ghc/wiki/WorkingConventions >> >> which then points you to the steps that are expected from newcomers, >> including the 'Newcomers' page as the 3rd step; once could maybe just >> add more emphasis to the 3rd step so that it visually stands out better >> (e.g. via [2] or [3]) >> >> I'm just worried that cluttering the side-bar[1] with a redundant link >> may make it less useful. >> >>> Don't have the permissions to add it to the sidebar though. >> >> ...the reason is btw, that it's a hacked in HTML fragment that's part of >> the custom Trac stylesheet mod for GHC; it can't be edited via the >> web-UI. >> >> >> >> [1]: which, personally, I find kinda overloaded and redundant which >> makes me wonder if it's really that useful in its current form; >> >> >> [2]: https://ghc.haskell.org/trac/ghc/wiki/WikiBoxes >> >> [3]: https://ghc.haskell.org/trac/ghc/wiki/WikiIcons > > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://www.haskell.org/mailman/listinfo/ghc-devs > From marlowsd at gmail.com Mon Dec 2 09:53:41 2013 From: marlowsd at gmail.com (Simon Marlow) Date: Mon, 02 Dec 2013 09:53:41 +0000 Subject: [commit: testsuite] master: Explain skipping compiler-perf tests when debugging is on (14958ae) In-Reply-To: <1385720922.2431.16.camel@kirk> References: <20131128155552.BD5D42406B@ghc.haskell.org> <529867AB.7030001@gmail.com> <1385720922.2431.16.camel@kirk> Message-ID: <529C58A5.9040508@gmail.com> On 29/11/2013 10:28, Joachim Breitner wrote: > Hi, > > Am Freitag, den 29.11.2013, 10:08 +0000 schrieb Simon Marlow: >> Actually this isn't quite right. compiler_debugged() is true when >> GhcDebugged=YES in the build system, and GhcDebugged controls whether >> GHC is compiled with -debug or not. >> >> That is, compiler_debugged() tells us whether the compiler was compiled >> with -debug, not -DDEBUG. The -debug flag links in the debug RTS and >> doesn't change allocation or heap residency, whereas -DDEBUG enables >> assertions in the compiler and *does* change allocation and heap residency. >> >> It looks like we need another predicate to tell us whether GHC was >> compiled with -DDEBUG or not. >> >> Would you mind backing out these changes in the meantime? > > are you sure? compiler_debugged() is certainly true when I build ghc > with > GhcStage2HcOpts = -O0 -DDEBUG > which yields > ./inplace/bin/ghc-stage2 --info|grep 'Debug on' > ,("Debug on","True") > but > ./inplace/bin/ghc-stage2 +RTS --info|grep -i debug > is empty. > > The test runner sets the value testsuite/mk/ghc-config.hs: > info <- readProcess ghc ["--info"] "" > let fields = read info :: [(String,String)] > getGhcFieldOrFail fields "GhcDebugged" "Debug on" > which writes to testsuite/mk/ghcconfig_* > which is then read by testsuite/mk/boilerplate.mk > which is included everywhere > including mk/test.mk which sets "-e ghc_debugged=$(GhcDebugged)" Oh, we use the same variable name GhcDebugged to mean two different things: in the GHC build system it means that GHC was compiled with -debug, but in the testsuite build system it means that GHC was compiled with -DDEBUG. How confusing! Anyway you're right - there doesn't seem to be a bug, but we should rename things to avoid confusion. I'll do that. > So it seems that it is simply the wiki documentation that is wrong here. I didn't check the wiki, just got confused by the source. Please go ahead and fix the wiki if there's something wrong there. Cheers, Simon From mail at joachim-breitner.de Mon Dec 2 12:13:46 2013 From: mail at joachim-breitner.de (Joachim Breitner) Date: Mon, 02 Dec 2013 12:13:46 +0000 Subject: [commit: testsuite] master: Explain skipping compiler-perf tests when debugging is on (14958ae) In-Reply-To: <529C58A5.9040508@gmail.com> References: <20131128155552.BD5D42406B@ghc.haskell.org> <529867AB.7030001@gmail.com> <1385720922.2431.16.camel@kirk> <529C58A5.9040508@gmail.com> Message-ID: <1385986426.3647.5.camel@kirk> Hi, Am Montag, den 02.12.2013, 09:53 +0000 schrieb Simon Marlow: > Oh, we use the same variable name GhcDebugged to mean two different > things: in the GHC build system it means that GHC was compiled with > -debug, but in the testsuite build system it means that GHC was compiled > with -DDEBUG. How confusing! > > Anyway you're right - there doesn't seem to be a bug, but we should > rename things to avoid confusion. I'll do that. > > > So it seems that it is simply the wiki documentation that is wrong here. > > I didn't check the wiki, just got confused by the source. Please go > ahead and fix the wiki if there's something wrong there. done, in https://ghc.haskell.org/trac/ghc/wiki/Building/RunningTests/Adding If you rename compiler_debuggeed() as well (and not just the test-runner-internal GhcDebugged), make sure to update that page as well. Greetings, Joachim -- Joachim ?nomeata? Breitner mail at joachim-breitner.de ? http://www.joachim-breitner.de/ Jabber: nomeata at joachim-breitner.de ? GPG-Key: 0x4743206C Debian Developer: nomeata at debian.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part URL: From patrick at parcs.ath.cx Mon Dec 2 14:11:54 2013 From: patrick at parcs.ath.cx (Patrick Palka) Date: Mon, 2 Dec 2013 09:11:54 -0500 Subject: [commit: ghc] master: Respect the ordering of -package directives (574ccfa) In-Reply-To: <59543203684B2244980D7E4057D5FBC1486D9865@DB3EX14MBXC308.europe.corp.microsoft.com> References: <20131202023914.B5A612406B@ghc.haskell.org> <59543203684B2244980D7E4057D5FBC1486D9865@DB3EX14MBXC308.europe.corp.microsoft.com> Message-ID: On Mon, Dec 2, 2013 at 5:28 AM, Simon Peyton-Jones wrote: > Patrick > > Thanks! > > When you do something subtle like change 'foldM' to 'foldrM', could you add a comment to point out the subtlety? After all, by definition this was something that someone else missed. > > Simon Yes, will do. This commit was accidentally pushed and reverted shortly afterwards. Sorry about that. From simonpj at microsoft.com Mon Dec 2 15:16:56 2013 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Mon, 2 Dec 2013 15:16:56 +0000 Subject: Getting Involved In-Reply-To: References: Message-ID: <59543203684B2244980D7E4057D5FBC1486DA2F0@DB3EX14MBXC308.europe.corp.microsoft.com> Blair Great. We always need more people to help. Do get stuck in, and yell if you need help. Thanks! Simon From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of Blair Archibald Sent: 29 November 2013 12:40 To: ghc-devs at haskell.org Subject: Getting Involved Hi, I'm looking to get involved working on GHC - I've been using Haskell for quite a while now and thought I'd give back to the community. Bit about me: I'm Blair an (4th year) Undergraduate at the University of Glasgow and my main interests at the moment are Functional Programming, Runtime systems (mainly memory management/GC work) and Transactional Memory (making GHC a great place to be!) I've noticed that there is talk of adding a better flags parser to the RTS and this seems like a good place to start (less likely to break things!). Ticket: #4243 Is anyone currently working in this area or have plans to start work in this area? Many thanks, Blair -------------- next part -------------- An HTML attachment was scrubbed... URL: From mail at joachim-breitner.de Mon Dec 2 15:36:51 2013 From: mail at joachim-breitner.de (Joachim Breitner) Date: Mon, 02 Dec 2013 15:36:51 +0000 Subject: Can cardinality analysis subsume strictness analysis In-Reply-To: <1385726045.2431.21.camel@kirk> References: <1385726045.2431.21.camel@kirk> Message-ID: <1385998611.3647.86.camel@kirk> Hi, Am Freitag, den 29.11.2013, 11:54 +0000 schrieb Joachim Breitner: > after playing a bit with the Demand analyser and trying debug tricky > bugs (#8569), I begin to wonder: Can cardinality analysis subsume > strictness analysis? this is a more structured attempt to answer that question. The motivation for this proposal is that I find it easier to think about what the lubDemand, bothDemand etc. should be if I mostly have to think about how often something is called (type Count below), instead of thinking about Demand&Cardinality and Strictness (which feel very similar to me) separately. Currently we have these data structures (Demand.lhs, slightly simplified by removing field names and type aliases): data DmdType = DmdType (VarEnv JointDmd) [Demand] DmdResult data CPRResult = NoCPR | RetProd | RetSum ConTag | BotCPR data Demand = JD MaybeStr MaybeUsed data MaybeStr = Lazy | Str StrDmd data StrDmd = HyperStr | SCall | SProd [MaybeStr] | HeadStr data MaybeUsed = Abs | Use Count UseDmd data UseDmd = UCall Count UseDmd | UProd [MaybeUsed] | UHead | Used data Count = One | Many I suggest the following date type to replace the latter six above: data CDemand = BotDemand | Use Count Demand -- C for cardinality data Demand = Call Count Demand | Prod [CDemand] | PolyUse | TopDemand data Count = NoIdea | Zero | AtMostOne | AtLeastOne | ExactlyOne -- interesting intervals of {0, 1, ?}, corresponding to {0,1,?} {0} {0,1} {1,?} {1} Invariants and equations: * "Use Zero x" implies x = TopDemand. Therefore in the following: useZero = useZero TopDemand * TopDemand = Prod [Use NoIdea TopDemand,...] and TopDemand = Call (Use NoIdea TopDemand), but as ever we can use the latter form for piggy-backed boxity analysis. * BotDemand is the demand put on something that diverges for sure. So it is not only the ?bottom of the demand lattice? but also ?the demand of something bottoming? ? either way of thinking works. And here is a transformation from old to new: combine1 :: MaybeStr -> MaybeUsed -> CDemand Lazy Abs -> useZero Lazy (Use c d) -> Use c' (convertLazy d) where c' = case c of One -> AtMostOne Many -> NoIdea (Str HyperStr) Abs -> BotDemand (Str HyperStr) _ -> ? not representable ? (Note 1) (Str _) Abs -> ? not representable ? (Note 2) (Str s) (Use c d) -> Use c' (combine2 s d) where c' = case c of One -> ExactlyOne Many -> AtLeastOne convertLazy :: UseDMD -> Demand UCall c d -> Call c' (convertLazy d) where c' = case c of One -> AtMostOne -- see Note 4 Many -> NoIdea UProd ds -> UProd (map convertLazy ds) UHead -> PolyUse useZero Used -> TopDemand combine2 :: StrDmd -> UseDMD -> Demand SCall (UCall Many d) -> Call NoIdea (convertLazy d) SCall (UCall One d) -> Call (AtMostOne (convertLazy d)) SCall (UProd _) -> ? not representable ? (Note 3) SCall (UHead _) -> PolyUse SCall Used -> Call TopDemand (SProd ss) (UCall _ _) -> ? not representable ? (Note 3) (SProd ss) (UProd ds) -> Prod (zipwith combine1 ss ds) (SProd ss) (UHead _) -> Prod (zipwith combine1 ss (repeat Abs)) (SProd ss) Used -> Prod (zipwith combine1 ss (repeat Used)) HeadStr (UCall Many d) -> Call NoIdea (convertLazy d) HeadStr (UCall One d) -> Call (AtMostOne (convertLazy d) HeadStr (UProd ds) -> Prod (zipwith combine1 (repeat Lazy) ds) HeadStr (UHead _) -> PolyUse HeadStr Used -> PolyUse HyperStr _ -> ? dead code ? (handled by combine1) Note 1: About HyperStr As far as I can see, this strictness demand is the one caused by diverging calls (error or non-termination), and is only relevant when it comes with a Use demand of Abs Note 2: Strict but absent Besides diverging things (who currently put a hyper-strict & absent demand on free variables), nothing can be strict and absent, right? Note 3: Disagreeing signatures When the strictness side sees a Call, the the demand side better not see a Product, and vica versa Note 4: The Count in Call is currently either AtMostOne or NoIdea, i.e. there is notion of ?function is not called at all?. Does that correctly reflect what we have right now? And here is the lattice. The nice thing is that there is a lattice for Counts that is mostly independent from the other lattice, at least in terms of thinking about it. NoIdea / \ / \ AtMostOnce AtLeastOnce / \ / Zero ExactlyOne TopDemand / \ Use c Call Use c Prod \ / Use c PolyUse | BotDemand Some thoughts: The lattices (both existing and proposed) are mostly complicated by two special cases: * bottoming stuff with hyperstrict demand and * polymorphic seq. As mentioned above, (HyperStr, Abs), i.e. the demand of error, becomes BotDemand. We have no way of representing (HyperStr, Used), for example. Would that occur? For seq, I propose to use PolyUse (for ?unknown polymorphic use?). This goes well the current use of (HeadStr, UHead) for seq. The strange is, though, that HeadStr lives _above_ SCall und SProd, while UHead lives _below_ UCall and UProd. This means that currently, case b of True -> x `seq` () False -> case x of (a,b) -> () has a joint demand of d=(HeadStrict, UProd [Abs, Abs]) on x ? why not d'=(SProd [Lazy, Lazy], UProd [Abs, Abs])? Anyways, in my lattice both of these demands correspond to (Prod [absZero, absZero]), i.e. my proposal hides the current differences. Are these wanted differences or unwanted ones? Some advantages of the code are: * Less duplication between StrDemand and UseDemand. * Non-redundant information about what is a function and what is a product. * Functions like cleanDemand simply take out Demand from CDemand, and the Count is the information that one needs to pass to deferAndUse, so less logic and less cases there. So my proposal is not an isomorphism of the existing lattice (as expected), and can neither express all existing combinations, nor differentiate between all of them. Which is a good thing, iff those values and differences are not desired. Surely more interesting corner cases will turn up when and if one tries to employ this scheme. Also, of course, there is still improvement for further polishing. The question is: Is this worth pursuing, or is there a reason why this cannot work, or maybe it would but it would not be an improvement? Thanks, Joachim -- Joachim ?nomeata? Breitner mail at joachim-breitner.de ? http://www.joachim-breitner.de/ Jabber: nomeata at joachim-breitner.de ? GPG-Key: 0x4743206C Debian Developer: nomeata at debian.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part URL: From marlowsd at gmail.com Mon Dec 2 20:31:08 2013 From: marlowsd at gmail.com (Simon Marlow) Date: Mon, 02 Dec 2013 20:31:08 +0000 Subject: Getting Involved In-Reply-To: References: Message-ID: <529CEE0C.9040009@gmail.com> On 29/11/13 12:39, Blair Archibald wrote: > Hi, > > I'm looking to get involved working on GHC - I've been using Haskell for > quite a while now and thought I'd give back to the community. > > Bit about me: I'm Blair an (4th year) Undergraduate at the University of > Glasgow and my main interests at the moment are Functional Programming, > Runtime systems (mainly memory management/GC work) and Transactional > Memory (making GHC a great place to be!) As I mentioned on the Haskell Cast, there is plenty of scope for speeding up STM in particular. One problem with getting started though is that we don't have a good benchmark suite, and any well-tuned programs that use STM will already be avoiding the known issues (like sensitivity to the size of transactions). The C/C++ STM community has some good benchmarks, e.g. http://stamp.stanford.edu/, I think it would be great to translate some of these to Haskell, and then use them as a starting point to look for ways to optimise the implementation. There's also a rather large literature on optimising STM for C/C++, some of which is probably useful. > I've noticed that there is talk of adding a better flags parser to the > RTS and this seems like a good place to start (less likely to break > things!). Ticket: #4243 > > Is anyone currently working in this area or have plans to start work in > this area? There was someone else looking at it... I forget who. Try searching the archives. Cheers, Simon From jan.stolarek at p.lodz.pl Tue Dec 3 07:24:48 2013 From: jan.stolarek at p.lodz.pl (Jan Stolarek) Date: Tue, 3 Dec 2013 08:24:48 +0100 Subject: Getting Involved In-Reply-To: <529CEE0C.9040009@gmail.com> References: <529CEE0C.9040009@gmail.com> Message-ID: <201312030824.48523.jan.stolarek@p.lodz.pl> > > I've noticed that there is talk of adding a better flags parser to the > > RTS and this seems like a good place to start (less likely to break > > things!). Ticket: #4243 > > > > Is anyone currently working in this area or have plans to start work in > > this area? > > There was someone else looking at it... I forget who. Try searching the > archives. I recall that when I was starting with GHC I considered working on this. Improving flag parser sounds like a good first step for a beginner because: a) it is precisly localized in one place (more or less); b) it doesn't require deep theoretical knowledge. Janek From mail at joachim-breitner.de Tue Dec 3 12:09:47 2013 From: mail at joachim-breitner.de (Joachim Breitner) Date: Tue, 03 Dec 2013 12:09:47 +0000 Subject: arising from the dependency ... in the instance declaration Message-ID: <1386072587.3239.8.camel@kirk> Hi, I have an error message, and I?m looking for code that produces it (how is that for a change...) While fixing https://ghc.haskell.org/trac/ghc/ticket/8576 I?d like to clean up some error reporting in FunDeps.lhs, in particular code that is involved in producing errors like Couldn't match type 'False with 'True When using functional dependencies to combine And 'False 'False 'False, arising from the dependency `a b -> c' in the instance declaration in `UnitTyped.Units' And 'False 'False 'True, arising from a use of `+' at :14:7 In the expression: meter + second In an equation for `it': it = meter + second but unfortunately, the test suite does _not_ contain any code that creates this error message. Also, the results obtained from googling for that error message yield either no code, or only unhelpful code fragments, or code that produces a different error message with current HEAD. Unfortunately, I cannot produce code that triggers it. Does anyone have code lying around that triggers that error message? Also: I found code that had this kind of error message in 7.6, e.g. the attached code?s error changed from FunDepError.hs:86:27: Couldn't match type `F a1' with `U' When using functional dependencies to combine UpdateR (xs :> s) (S n) t (xs' :> s), arising from the dependency xs n t -> xs' in the instance declaration at FunDepError.hs:54:10 UpdateR ((xs' :> F a0) :> F a1) (S O) U ((jj0 :> U) :> U), arising from a use of `var' at FunDepError.hs:86:27-29 In the expression: var a In the first argument of `lam', namely `(\ b -> var a)' (sorry for not finding something simpler) to FunDepError.hs:86:5: No instance for (Consume xs' jj) arising from a use of ?lam? Possible fix: add (Consume xs' jj) to the context of the inferred type of x :: LLC t xs' jj (a :-> (a1 :-> a)) In the expression: lam (\ a -> lam (\ b -> var a)) In an equation for ?x?: x = lam (\ a -> lam (\ b -> var a)) FunDepError.hs:86:27: No instance for (UpdateR ((xs' :> F a) :> F a1) (S O) U ((jj :> U) :> U)) arising from a use of ?var? In the expression: var a In the first argument of ?lam?, namely ?(\ b -> var a)? In the expression: lam (\ b -> var a) Is that desired or a regression? Greetings, Joachim -- Joachim ?nomeata? Breitner mail at joachim-breitner.de ? http://www.joachim-breitner.de/ Jabber: nomeata at joachim-breitner.de ? GPG-Key: 0x4743206C Debian Developer: nomeata at debian.org -------------- next part -------------- A non-text attachment was scrubbed... Name: FunDepError.hs Type: text/x-haskell Size: 2811 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part URL: From iavor.diatchki at gmail.com Tue Dec 3 19:08:01 2013 From: iavor.diatchki at gmail.com (Iavor Diatchki) Date: Tue, 3 Dec 2013 11:08:01 -0800 Subject: arising from the dependency ... in the instance declaration In-Reply-To: <1386072587.3239.8.camel@kirk> References: <1386072587.3239.8.camel@kirk> Message-ID: Hi Joachim, Here is a piece of code that produces the desired error: {-# LANGUAGE MultiParamTypeClasses, FunctionalDependencies #-} {-# LANGUAGE DataKinds, KindSignatures #-} data P (x :: Bool) = P class And a b c | a b -> c where op :: P a -> P b -> P c instance And False False False where op _ _ = P test = op (P :: P False) (P :: P False) :: P True The `DataKinds` and `KindSigantures` are only used to match your example closely. Here is a simpler version that causes essentially the same error: {-# LANGUAGE MultiParamTypeClasses, FunctionalDependencies #-} class C a b | a -> b where op :: a -> b instance C Bool Char where op _ = 'a' test = op True :: Float -Iavor On Tue, Dec 3, 2013 at 4:09 AM, Joachim Breitner wrote: > Hi, > > I have an error message, and I?m looking for code that produces it (how > is that for a change...) > > While fixing https://ghc.haskell.org/trac/ghc/ticket/8576 I?d like to > clean up some error reporting in FunDeps.lhs, in particular code that is > involved in producing errors like > > Couldn't match type 'False with 'True > When using functional dependencies to combine > And 'False 'False 'False, > arising from the dependency `a b -> c' > in the instance declaration in `UnitTyped.Units' > And 'False 'False 'True, > arising from a use of `+' at :14:7 > In the expression: meter + second > In an equation for `it': it = meter + second > > but unfortunately, the test suite does _not_ contain any code that > creates this error message. Also, the results obtained from googling for > that error message yield either no code, or only unhelpful code > fragments, or code that produces a different error message with current > HEAD. > > Unfortunately, I cannot produce code that triggers it. Does anyone have > code lying around that triggers that error message? > > Also: I found code that had this kind of error message in 7.6, e.g. the > attached code?s error changed from > > FunDepError.hs:86:27: > Couldn't match type `F a1' with `U' > When using functional dependencies to combine > UpdateR (xs :> s) (S n) t (xs' :> s), > arising from the dependency xs n t -> xs' > in the instance declaration at FunDepError.hs:54:10 > UpdateR ((xs' :> F a0) :> F a1) (S O) U ((jj0 :> U) :> U), > arising from a use of `var' at FunDepError.hs:86:27-29 > In the expression: var a > In the first argument of `lam', namely `(\ b -> var a)' > > (sorry for not finding something simpler) to > > FunDepError.hs:86:5: > No instance for (Consume xs' jj) arising from a use of ?lam? > Possible fix: > add (Consume xs' jj) to the context of > the inferred type of x :: LLC t xs' jj (a :-> (a1 :-> a)) > In the expression: lam (\ a -> lam (\ b -> var a)) > In an equation for ?x?: x = lam (\ a -> lam (\ b -> var a)) > > FunDepError.hs:86:27: > No instance for (UpdateR > ((xs' :> F a) :> F a1) (S O) U ((jj :> U) > :> U)) > arising from a use of ?var? > In the expression: var a > In the first argument of ?lam?, namely ?(\ b -> var a)? > In the expression: lam (\ b -> var a) > > Is that desired or a regression? > > Greetings, > Joachim > > > -- > Joachim ?nomeata? Breitner > mail at joachim-breitner.de ? http://www.joachim-breitner.de/ > Jabber: nomeata at joachim-breitner.de ? GPG-Key: 0x4743206C > Debian Developer: nomeata at debian.org > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://www.haskell.org/mailman/listinfo/ghc-devs > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mail at joachim-breitner.de Tue Dec 3 21:40:10 2013 From: mail at joachim-breitner.de (Joachim Breitner) Date: Tue, 03 Dec 2013 21:40:10 +0000 Subject: arising from the dependency ... in the instance declaration In-Reply-To: References: <1386072587.3239.8.camel@kirk> Message-ID: <1386106810.2397.3.camel@kirk> Hi, Am Dienstag, den 03.12.2013, 11:08 -0800 schrieb Iavor Diatchki: > Here is a piece of code that produces the desired error: > > [..] > > The `DataKinds` and `KindSigantures` are only used to match your > example closely. > Here is a simpler version that causes essentially the same error: > > [..] > thanks for these examples. Both, though, give different error messages in GHC HEAD. I?m more and more confident that this is an inadvertent error message, see https://ghc.haskell.org/trac/ghc/ticket/8592 Once that is sorted out, I?ll make sure these examples (or at least a representative one) makes it into the testsuite. Greetings, Joachim -- Joachim ?nomeata? Breitner mail at joachim-breitner.de ? http://www.joachim-breitner.de/ Jabber: nomeata at joachim-breitner.de ? GPG-Key: 0x4743206C Debian Developer: nomeata at debian.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part URL: From iavor.diatchki at gmail.com Tue Dec 3 22:12:36 2013 From: iavor.diatchki at gmail.com (Iavor Diatchki) Date: Tue, 3 Dec 2013 14:12:36 -0800 Subject: arising from the dependency ... in the instance declaration In-Reply-To: <1386106810.2397.3.camel@kirk> References: <1386072587.3239.8.camel@kirk> <1386106810.2397.3.camel@kirk> Message-ID: Hi, oh, I didn't realize that you meant using HEAD. I'd guess that the new behavior is a result of the changes Simon made to the constraint solver a little while ago (maybe about a month ago?). I haven't had a chance to look at the code yet, but I believe he eliminated some constraint interactions, which did not contribute towards type-checking more programs, but lead to more confusing error messages. By the way, I am not sure that this is a regression---I kind of like new the new behavior. For my second example we get: test.hs:9:8: No instance for (C Bool Float) arising from a use of ?op? In the expression: op True :: Float In an equation for ?test?: test = op True :: Float This tells us exactly what the problem is, namely the missing instance, without going into stuff about functional dependencies. I guess we _could_ also say that such an instance can't exist because of the other instance and the functional dependency, but I am not sure how relevant that is... -Iavor On Tue, Dec 3, 2013 at 1:40 PM, Joachim Breitner wrote: > Hi, > > Am Dienstag, den 03.12.2013, 11:08 -0800 schrieb Iavor Diatchki: > > > Here is a piece of code that produces the desired error: > > > > [..] > > > > The `DataKinds` and `KindSigantures` are only used to match your > > example closely. > > Here is a simpler version that causes essentially the same error: > > > > [..] > > > > thanks for these examples. Both, though, give different error messages > in GHC HEAD. I?m more and more confident that this is an inadvertent > error message, see > https://ghc.haskell.org/trac/ghc/ticket/8592 > > Once that is sorted out, I?ll make sure these examples (or at least a > representative one) makes it into the testsuite. > > Greetings, > Joachim > > > -- > Joachim ?nomeata? Breitner > mail at joachim-breitner.de ? http://www.joachim-breitner.de/ > Jabber: nomeata at joachim-breitner.de ? GPG-Key: 0x4743206C > Debian Developer: nomeata at debian.org > -------------- next part -------------- An HTML attachment was scrubbed... URL: From johan.tibell at gmail.com Wed Dec 4 09:33:47 2013 From: johan.tibell at gmail.com (Johan Tibell) Date: Wed, 4 Dec 2013 10:33:47 +0100 Subject: [commit: ghc] wip/nested-cpr: Add a flag -fnested-cpr-off to conveniently test the effect of nested CPR (90529b1) In-Reply-To: <20131204091939.3136F2406B@ghc.haskell.org> References: <20131204091939.3136F2406B@ghc.haskell.org> Message-ID: Nitpick: don't we usually name these flags -fno-nested-cpr? On Wed, Dec 4, 2013 at 10:19 AM, wrote: > Repository : ssh://git at git.haskell.org/ghc > > On branch : wip/nested-cpr > Link : > http://ghc.haskell.org/trac/ghc/changeset/90529b15c02ef03dcece13c267b76d470941b808/ghc > > >--------------------------------------------------------------- > > commit 90529b15c02ef03dcece13c267b76d470941b808 > Author: Joachim Breitner > Date: Wed Dec 4 09:14:26 2013 +0000 > > Add a flag -fnested-cpr-off to conveniently test the effect of nested > CPR > > > >--------------------------------------------------------------- > > 90529b15c02ef03dcece13c267b76d470941b808 > compiler/basicTypes/Demand.lhs | 28 +++++++++++++++++++--------- > compiler/main/StaticFlags.hs | 9 +++++++-- > 2 files changed, 26 insertions(+), 11 deletions(-) > > diff --git a/compiler/basicTypes/Demand.lhs > b/compiler/basicTypes/Demand.lhs > index 557a9bd..e955195 100644 > --- a/compiler/basicTypes/Demand.lhs > +++ b/compiler/basicTypes/Demand.lhs > @@ -791,20 +791,29 @@ botRes = Diverges > maxCPRDepth :: Int > maxCPRDepth = 3 > > +-- This is the depth we use with -fnested-cpr-off, in order > +-- to get precisely the same behaviour as before introduction of nested > cpr > +-- -fnested-cpr-off can eventually be removed if nested cpr is deemd to be > +-- a good thing always. > +flatCPRDepth :: Int > +flatCPRDepth = 1 > + > -- With nested CPR, DmdResult can be arbitrarily deep; consider e.g. the > -- DmdResult of repeat > -- > -- So we need to forget information at a certain depth. We do that at all > points > -- where we are building RetCon constructors. > -cutDmdResult :: Int -> DmdResult -> DmdResult > -cutDmdResult 0 _ = topRes > -cutDmdResult _ Diverges = Diverges > -cutDmdResult n (Converges c) = Converges (cutCPRResult n c) > -cutDmdResult n (Dunno c) = Dunno (cutCPRResult n c) > - > cutCPRResult :: Int -> CPRResult -> CPRResult > -cutCPRResult _ NoCPR = NoCPR > +cutCPRResult 0 _ = NoCPR > +cutCPRResult _ NoCPR = NoCPR > cutCPRResult n (RetCon tag rs) = RetCon tag (map (cutDmdResult (n-1)) rs) > + where > + cutDmdResult :: Int -> DmdResult -> DmdResult > + cutDmdResult 0 _ = topRes > + cutDmdResult _ Diverges = Diverges > + cutDmdResult n (Converges c) = Converges (cutCPRResult n c) > + cutDmdResult n (Dunno c) = Dunno (cutCPRResult n c) > + > > -- Forget that something might converge for sure > divergeDmdResult :: DmdResult -> DmdResult > @@ -819,8 +828,9 @@ forgetCPR (Dunno _) = Dunno NoCPR > > cprConRes :: ConTag -> [DmdType] -> CPRResult > cprConRes tag arg_tys > - | opt_CprOff = NoCPR > - | otherwise = cutCPRResult maxCPRDepth $ RetCon tag (map get_res > arg_tys) > + | opt_CprOff = NoCPR > + | opt_NestedCprOff = cutCPRResult flatCPRDepth $ RetCon tag (map > get_res arg_tys) > + | otherwise = cutCPRResult maxCPRDepth $ RetCon tag (map > get_res arg_tys) > where > get_res :: DmdType -> DmdResult > get_res (DmdType _ [] r) = r -- Only for data-typed arguments! > diff --git a/compiler/main/StaticFlags.hs b/compiler/main/StaticFlags.hs > index 01dc3b7..feb7235 100644 > --- a/compiler/main/StaticFlags.hs > +++ b/compiler/main/StaticFlags.hs > @@ -27,6 +27,7 @@ module StaticFlags ( > -- optimisation opts > opt_NoStateHack, > opt_CprOff, > + opt_NestedCprOff, > opt_NoOptCoercion, > > -- For the parser > @@ -140,7 +141,8 @@ flagsStaticNames :: [String] > flagsStaticNames = [ > "fno-state-hack", > "fno-opt-coercion", > - "fcpr-off" > + "fcpr-off", > + "fnested-cpr-off" > ] > > -- We specifically need to discard static flags for clients of the > @@ -195,10 +197,13 @@ opt_NoDebugOutput = lookUp (fsLit > "-dno-debug-output") > opt_NoStateHack :: Bool > opt_NoStateHack = lookUp (fsLit "-fno-state-hack") > > --- Switch off CPR analysis in the new demand analyser > +-- Switch off CPR analysis in the demand analyser > opt_CprOff :: Bool > opt_CprOff = lookUp (fsLit "-fcpr-off") > > +opt_NestedCprOff :: Bool > +opt_NestedCprOff = lookUp (fsLit "-fnested-cpr-off") > + > opt_NoOptCoercion :: Bool > opt_NoOptCoercion = lookUp (fsLit "-fno-opt-coercion") > > > _______________________________________________ > ghc-commits mailing list > ghc-commits at haskell.org > http://www.haskell.org/mailman/listinfo/ghc-commits > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mail at joachim-breitner.de Wed Dec 4 10:13:30 2013 From: mail at joachim-breitner.de (Joachim Breitner) Date: Wed, 04 Dec 2013 10:13:30 +0000 Subject: [commit: ghc] wip/nested-cpr: Add a flag -fnested-cpr-off to conveniently test the effect of nested CPR (90529b1) In-Reply-To: References: <20131204091939.3136F2406B@ghc.haskell.org> Message-ID: <1386152010.2514.6.camel@kirk> Hi, Am Mittwoch, den 04.12.2013, 10:33 +0100 schrieb Johan Tibell: > Nitpick: don't we usually name these flags -fno-nested-cpr? I thought so as well, but I?m just following what?s there: > --- Switch off CPR analysis in the new demand analyser > +-- Switch off CPR analysis in the demand analyser > opt_CprOff :: Bool > opt_CprOff = lookUp (fsLit "-fcpr-off") > > +opt_NestedCprOff :: Bool > +opt_NestedCprOff = lookUp (fsLit "-fnested-cpr-off") > + > opt_NoOptCoercion :: Bool > opt_NoOptCoercion = lookUp (fsLit "-fno-opt-coercion") > anyways, ideally that flag stays branch-local and will be removed before merging into master. But thx for watching these commits; I hope they don?t cause too much noise on ghc-commits. Greetings, Joachim -- Joachim ?nomeata? Breitner mail at joachim-breitner.de ? http://www.joachim-breitner.de/ Jabber: nomeata at joachim-breitner.de ? GPG-Key: 0x4743206C Debian Developer: nomeata at debian.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part URL: From austin at well-typed.com Wed Dec 4 21:24:40 2013 From: austin at well-typed.com (Austin Seipp) Date: Wed, 4 Dec 2013 15:24:40 -0600 Subject: Repository Reorganization Question Message-ID: Hi all, While discussing something with Herbert this week in preparation of making a new stable branch, he brought a good point to my attention, which is that if we go ahead and reorganize the repository situation post 7.8, merging things to the stable branch from HEAD will become a bit harder. Notably, we had planned to fold testsuite (and perhaps some other repositories) into the GHC tree. Once we do this, the two branches will have diverged quite a bit, so merging from HEAD to STABLE will become harder* (because HEAD would have rolled in testsuite changes for example, but the STABLE branch would not have this history.) Thinking about it, the best time to do such a move is, basically, when there is no active stable branch. Unfortunately this time is right now, but I'm not sure how everyone feels about this. So, the question is: should we go ahead and pull the trigger on some of these perhaps? Herbert collected some numbers on the git repositories and outlined all the basic details here: https://ghc.haskell.org/trac/ghc/wiki/GitRepoReorganization The only thing I'd honestly propose right now is folding 'testsuite' into the main repository, but of course we should see what people think - perhaps we should keep base/etc off the table for now, since they seem more controversial. * I'll point out they will only become *slightly* harder in most cases, because I can always instead apply unified diffs, rather than cherry pick or something. But it does lose the original metadata from commits too. But I won't cry if people vote against this. -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ From simonpj at microsoft.com Wed Dec 4 22:13:52 2013 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Wed, 4 Dec 2013 22:13:52 +0000 Subject: Repository Reorganization Question In-Reply-To: References: Message-ID: <59543203684B2244980D7E4057D5FBC1486DF8E3@DB3EX14MBXC308.europe.corp.microsoft.com> I have no objection to doing it now, though my opinion should count for little, since I know so little. The main person who is affected is Austin, since he has to do the merging. And I'm not sure that even 'base' is really controversial, is it? Simon | -----Original Message----- | From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of | Austin Seipp | Sent: 04 December 2013 21:25 | To: ghc-devs at haskell.org | Subject: Repository Reorganization Question | | Hi all, | | While discussing something with Herbert this week in preparation of | making a new stable branch, he brought a good point to my attention, | which is that if we go ahead and reorganize the repository situation | post 7.8, merging things to the stable branch from HEAD will become a | bit harder. | | Notably, we had planned to fold testsuite (and perhaps some other | repositories) into the GHC tree. Once we do this, the two branches | will have diverged quite a bit, so merging from HEAD to STABLE will | become harder* (because HEAD would have rolled in testsuite changes | for example, but the STABLE branch would not have this history.) | | Thinking about it, the best time to do such a move is, basically, when | there is no active stable branch. Unfortunately this time is right | now, but I'm not sure how everyone feels about this. | | So, the question is: should we go ahead and pull the trigger on some | of these perhaps? Herbert collected some numbers on the git | repositories and outlined all the basic details here: | | https://ghc.haskell.org/trac/ghc/wiki/GitRepoReorganization | | The only thing I'd honestly propose right now is folding 'testsuite' | into the main repository, but of course we should see what people | think - perhaps we should keep base/etc off the table for now, since | they seem more controversial. | | * I'll point out they will only become *slightly* harder in most | cases, because I can always instead apply unified diffs, rather than | cherry pick or something. But it does lose the original metadata from | commits too. But I won't cry if people vote against this. | | -- | Regards, | | Austin Seipp, Haskell Consultant | Well-Typed LLP, http://www.well-typed.com/ | _______________________________________________ | ghc-devs mailing list | ghc-devs at haskell.org | http://www.haskell.org/mailman/listinfo/ghc-devs From carter.schonwald at gmail.com Wed Dec 4 22:36:39 2013 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Wed, 4 Dec 2013 17:36:39 -0500 Subject: Repository Reorganization Question In-Reply-To: <59543203684B2244980D7E4057D5FBC1486DF8E3@DB3EX14MBXC308.europe.corp.microsoft.com> References: <59543203684B2244980D7E4057D5FBC1486DF8E3@DB3EX14MBXC308.europe.corp.microsoft.com> Message-ID: i'm fine with them being merged, otoh I don't have any large in progress patches afoot, and having testsuite and ghc repos merged will make it much easier for some of the patches i have planned for end of december. -Carter On Wed, Dec 4, 2013 at 5:13 PM, Simon Peyton-Jones wrote: > I have no objection to doing it now, though my opinion should count for > little, since I know so little. The main person who is affected is Austin, > since he has to do the merging. And I'm not sure that even 'base' is really > controversial, is it? > > Simon > > | -----Original Message----- > | From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of > | Austin Seipp > | Sent: 04 December 2013 21:25 > | To: ghc-devs at haskell.org > | Subject: Repository Reorganization Question > | > | Hi all, > | > | While discussing something with Herbert this week in preparation of > | making a new stable branch, he brought a good point to my attention, > | which is that if we go ahead and reorganize the repository situation > | post 7.8, merging things to the stable branch from HEAD will become a > | bit harder. > | > | Notably, we had planned to fold testsuite (and perhaps some other > | repositories) into the GHC tree. Once we do this, the two branches > | will have diverged quite a bit, so merging from HEAD to STABLE will > | become harder* (because HEAD would have rolled in testsuite changes > | for example, but the STABLE branch would not have this history.) > | > | Thinking about it, the best time to do such a move is, basically, when > | there is no active stable branch. Unfortunately this time is right > | now, but I'm not sure how everyone feels about this. > | > | So, the question is: should we go ahead and pull the trigger on some > | of these perhaps? Herbert collected some numbers on the git > | repositories and outlined all the basic details here: > | > | https://ghc.haskell.org/trac/ghc/wiki/GitRepoReorganization > | > | The only thing I'd honestly propose right now is folding 'testsuite' > | into the main repository, but of course we should see what people > | think - perhaps we should keep base/etc off the table for now, since > | they seem more controversial. > | > | * I'll point out they will only become *slightly* harder in most > | cases, because I can always instead apply unified diffs, rather than > | cherry pick or something. But it does lose the original metadata from > | commits too. But I won't cry if people vote against this. > | > | -- > | Regards, > | > | Austin Seipp, Haskell Consultant > | Well-Typed LLP, http://www.well-typed.com/ > | _______________________________________________ > | ghc-devs mailing list > | ghc-devs at haskell.org > | http://www.haskell.org/mailman/listinfo/ghc-devs > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://www.haskell.org/mailman/listinfo/ghc-devs > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mail at joachim-breitner.de Wed Dec 4 23:28:43 2013 From: mail at joachim-breitner.de (Joachim Breitner) Date: Wed, 04 Dec 2013 23:28:43 +0000 Subject: Repository Reorganization Question In-Reply-To: References: Message-ID: <1386199723.32541.0.camel@kirk> Hi, Am Mittwoch, den 04.12.2013, 15:24 -0600 schrieb Austin Seipp: > The only thing I'd honestly propose right now is folding 'testsuite' > into the main repository, but of course we should see what people > think - perhaps we should keep base/etc off the table for now, since > they seem more controversial. yes please! It will make live much easier for me. And it would allow to remove "expect_broken" flags with the same commit that unbreaks them. Greetings, Joachim -- Joachim ?nomeata? Breitner mail at joachim-breitner.de ? http://www.joachim-breitner.de/ Jabber: nomeata at joachim-breitner.de ? GPG-Key: 0x4743206C Debian Developer: nomeata at debian.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part URL: From kwangyul.seo at gmail.com Thu Dec 5 06:00:51 2013 From: kwangyul.seo at gmail.com (KwangYul Seo) Date: Thu, 5 Dec 2013 15:00:51 +0900 Subject: [Haskell-cafe] Simple script to make existing GHC or HP installation work with Xcode 5 In-Reply-To: References: Message-ID: Hi, Your script works well on my machine (OS X 10.9 and Xcode 5) though it emits the following warning while running configure: configure: WARNING: unrecognized options: --with-compiler, --with-gcc BTW, the script does not locate where my settings is. I installed Haskell Platform using Homebrew and the settings file is under /usr/local/Cellar/ghc/7.6.3/lib/ghc-7.6.3/settings. It would be good if your script checks this directory too for Homebrew users. Thanks, Kwang Yul Seo On Thu, Oct 31, 2013 at 4:04 PM, Mark Lentczner wrote: > Friends - > > I've developed a simple shell script that should enable your existing GHC > 7. or HP installation work with Xcode 5. > > https://gist.github.com/mzero/7245290 > > > Place that script somewhere, make it executable, and run it. > *Then follow the instructions it tells you!* > You will end up having to run it more than once: > > First time it will tell you where to install a copy of the script > > Second time it will patch your GHC settings file(s) > > > The script is safe to install and setup before you upgrade to Xcode 5, as > it reverts to "getting out of the way" if it detects Xcode 4 based > installation. > > It has been tested on two machines: > > - OS X 10.8 and Xcode 4 > - OS X 10.9 and Xcode 5 > > If a few more intrepid souls test it and it works, I'll post instructions > in more prominent places! > I'll be testing OS X 10.9 and Xcode 4, tomorrow, and expect it should work > fine on OS X10.8 with Xcode 5. But looking for reports that it all works. > > - Mark "Mac Packager" Lentczner > > > > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kwangyul.seo at gmail.com Thu Dec 5 07:58:50 2013 From: kwangyul.seo at gmail.com (KwangYul Seo) Date: Thu, 5 Dec 2013 16:58:50 +0900 Subject: Compare-and-swap semantics in GHC Message-ID: Hi, java.util.concurrent.atomic package provides two flavors of compare and set operations: compareAndSet and weakCompareAndSet. The latter does not create any happens-before orderings, so we can use it where no guarantees with respect to previous or subsequent reads and writes of any variables other than the target of the weakCompareAndSet are required. I'd like to ask if the compare-and-swap function provided by GHC runtime (cas() in includes/stg/SMP.h) is strong or weak. If it is strong, do all use cases of cas() require this semantics? Regards, Kwang Yul Seo -------------- next part -------------- An HTML attachment was scrubbed... URL: From carter.schonwald at gmail.com Thu Dec 5 08:48:44 2013 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Thu, 5 Dec 2013 03:48:44 -0500 Subject: Compare-and-swap semantics in GHC In-Reply-To: References: Message-ID: cas in ghc has sequential semantics. i'm not sure if every use of it needs that semantics, if you identify examples where weaker operations may suffice, please share! On Thu, Dec 5, 2013 at 2:58 AM, KwangYul Seo wrote: > Hi, > > java.util.concurrent.atomic package provides two flavors of compare and > set operations: compareAndSet and weakCompareAndSet. The latter does not > create any happens-before orderings, so we can use it where no guarantees > with respect to previous or subsequent reads and writes of any variables > other than the target of the weakCompareAndSet are required. > > I'd like to ask if the compare-and-swap function provided by GHC runtime > (cas() in includes/stg/SMP.h) is strong or weak. If it is strong, do all > use cases of cas() require this semantics? > > Regards, > Kwang Yul Seo > > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://www.haskell.org/mailman/listinfo/ghc-devs > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From carter.schonwald at gmail.com Thu Dec 5 08:52:10 2013 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Thu, 5 Dec 2013 03:52:10 -0500 Subject: Compare-and-swap semantics in GHC In-Reply-To: References: Message-ID: hrm, i'm reading your mesage a bit more closely, and i'm not sure i understand the distinction you mean by strong vs weak. Do you mean "strong" as in STM style semantics for reads and writes? (ie if i'm doing a CAS on memory location x, it totally orders all reads and writes to ANY location y!=x too?). if you mean something like that, I think CAS isn't strong, though perhaps the best way to answer you question is to read the source for CAS and look up the semantics of the assembly instructions on various architectures! cheers (and apologies for the confusion on my part) -Carter On Thu, Dec 5, 2013 at 3:48 AM, Carter Schonwald wrote: > cas in ghc has sequential semantics. > > i'm not sure if every use of it needs that semantics, if you identify > examples where weaker operations may suffice, please share! > > > On Thu, Dec 5, 2013 at 2:58 AM, KwangYul Seo wrote: > >> Hi, >> >> java.util.concurrent.atomic package provides two flavors of compare and >> set operations: compareAndSet and weakCompareAndSet. The latter does not >> create any happens-before orderings, so we can use it where no guarantees >> with respect to previous or subsequent reads and writes of any variables >> other than the target of the weakCompareAndSet are required. >> >> I'd like to ask if the compare-and-swap function provided by GHC runtime >> (cas() in includes/stg/SMP.h) is strong or weak. If it is strong, do all >> use cases of cas() require this semantics? >> >> Regards, >> Kwang Yul Seo >> >> >> _______________________________________________ >> ghc-devs mailing list >> ghc-devs at haskell.org >> http://www.haskell.org/mailman/listinfo/ghc-devs >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hvr at gnu.org Thu Dec 5 10:17:01 2013 From: hvr at gnu.org (Herbert Valerio Riedel) Date: Thu, 05 Dec 2013 11:17:01 +0100 Subject: Repository Reorganization Question In-Reply-To: (Austin Seipp's message of "Wed, 4 Dec 2013 15:24:40 -0600") References: Message-ID: <87d2lb4n6q.fsf@gmail.com> On 2013-12-04 at 22:24:40 +0100, Austin Seipp wrote: > So, the question is: should we go ahead and pull the trigger on some > of these perhaps? Herbert collected some numbers on the git > repositories and outlined all the basic details here: > > https://ghc.haskell.org/trac/ghc/wiki/GitRepoReorganization > > The only thing I'd honestly propose right now is folding 'testsuite' > into the main repository, but of course we should see what people > think Fyi, I've drafted how the change would look like in the new ghc.git branch 'wip/T8545' so we can test/evaluate the effects/fallout before peforming this operation on 'master'. So running git clone -b wip/T8545 git://git.haskell.org/ghc.git cd ghc/ ./sync-all get should result in a new checkout including the folded-in testsuite/ folder. PS: If we decide to fold in `base` too (which imho would make life easier for GHC devs as it reduces exposure to confusing git-submodule effects) I think we should also fold in ghc-prim/integer-{gmp,simple} in, as `base` depends on those and they're even more tightly coupled to GHC than `base` is and so imho don't benefit much from being kept in a separate Git repo. Cheers, hvr From hvriedel at gmail.com Thu Dec 5 11:15:24 2013 From: hvriedel at gmail.com (Herbert Valerio Riedel) Date: Thu, 05 Dec 2013 12:15:24 +0100 Subject: Repository Reorganization Question In-Reply-To: <87d2lb4n6q.fsf@gmail.com> (Herbert Valerio Riedel's message of "Thu, 05 Dec 2013 11:17:01 +0100") References: <87d2lb4n6q.fsf@gmail.com> Message-ID: <878uvz4khf.fsf@gmail.com> On 2013-12-05 at 11:17:01 +0100, Herbert Valerio Riedel wrote: [...] > Fyi, I've drafted how the change would look like in the new ghc.git > branch 'wip/T8545' so we can test/evaluate the effects/fallout before > peforming this operation on 'master'. > > So running > > git clone -b wip/T8545 git://git.haskell.org/ghc.git > cd ghc/ > ./sync-all get > > should result in a new checkout including the folded-in testsuite/ > folder. PS: I didn't merge in testsuite's Git history as that would bloat ghc.git quite a bit; however, 'git blame' functionality can be recovered in a local checkout by using something like Git's grafting feature: # make available old testsuite Git objects in local ghc.git git remote add -f old-testsuite git://git.haskell.org/testsuite.git # add 2nd parent commit to e45b9f57a90 pointing to testsuite.git echo e45b9f57a9044e8a20e3cc13bcff86b12b3da405 \ 1860dae3a7e377f085f3a4134f532a7f577fccbe \ 3e66489ebcef0f4cd86968c6781a1d4ad1981f94 > .git/info/grafts This way when peforming 'git blame' on files in the the testsuite/ folder results in sensible information dating back before the history-cut-off point. From simonpj at microsoft.com Thu Dec 5 11:31:40 2013 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Thu, 5 Dec 2013 11:31:40 +0000 Subject: Repository Reorganization Question In-Reply-To: <878uvz4khf.fsf@gmail.com> References: <87d2lb4n6q.fsf@gmail.com> <878uvz4khf.fsf@gmail.com> Message-ID: <59543203684B2244980D7E4057D5FBC1486E07C1@DB3EX14MBXC308.europe.corp.microsoft.com> What (if anything) do we need to do when updating existing local repos. Will everything be ok if I just do sync-all pull Simon | -----Original Message----- | From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of | Herbert Valerio Riedel | Sent: 05 December 2013 11:15 | To: ghc-devs at haskell.org | Subject: Re: Repository Reorganization Question | | On 2013-12-05 at 11:17:01 +0100, Herbert Valerio Riedel wrote: | | [...] | | > Fyi, I've drafted how the change would look like in the new ghc.git | > branch 'wip/T8545' so we can test/evaluate the effects/fallout before | > peforming this operation on 'master'. | > | > So running | > | > git clone -b wip/T8545 git://git.haskell.org/ghc.git | > cd ghc/ | > ./sync-all get | > | > should result in a new checkout including the folded-in testsuite/ | > folder. | | PS: I didn't merge in testsuite's Git history as that would bloat | ghc.git quite a bit; however, 'git blame' functionality can be | recovered in a local checkout by using something like Git's | grafting | feature: | | # make available old testsuite Git objects in local ghc.git | git remote add -f old-testsuite git://git.haskell.org/testsuite.git | | # add 2nd parent commit to e45b9f57a90 pointing to testsuite.git | echo e45b9f57a9044e8a20e3cc13bcff86b12b3da405 \ | 1860dae3a7e377f085f3a4134f532a7f577fccbe \ | 3e66489ebcef0f4cd86968c6781a1d4ad1981f94 > .git/info/grafts | | This way when peforming 'git blame' on files in the the testsuite/ | folder results in sensible information dating back before the | history-cut-off point. | | _______________________________________________ | ghc-devs mailing list | ghc-devs at haskell.org | http://www.haskell.org/mailman/listinfo/ghc-devs From mail at joachim-breitner.de Thu Dec 5 11:56:55 2013 From: mail at joachim-breitner.de (Joachim Breitner) Date: Thu, 05 Dec 2013 11:56:55 +0000 Subject: Repository Reorganization Question In-Reply-To: <878uvz4khf.fsf@gmail.com> References: <87d2lb4n6q.fsf@gmail.com> <878uvz4khf.fsf@gmail.com> Message-ID: <1386244615.2760.3.camel@kirk> Hi, Am Donnerstag, den 05.12.2013, 12:15 +0100 schrieb Herbert Valerio Riedel: > PS: I didn't merge in testsuite's Git history as that would bloat > ghc.git quite a bit; would that really be a problem? How different are the numbers? I?m a fan of keeping history readily available, so unless it really hurts I suggest to do a proper merge. Greetings, Joachim -- Joachim ?nomeata? Breitner mail at joachim-breitner.de ? http://www.joachim-breitner.de/ Jabber: nomeata at joachim-breitner.de ? GPG-Key: 0x4743206C Debian Developer: nomeata at debian.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part URL: From hvr at gnu.org Thu Dec 5 13:32:10 2013 From: hvr at gnu.org (Herbert Valerio Riedel) Date: Thu, 05 Dec 2013 14:32:10 +0100 Subject: Repository Reorganization Question In-Reply-To: <1386244615.2760.3.camel@kirk> (Joachim Breitner's message of "Thu, 05 Dec 2013 11:56:55 +0000") References: <87d2lb4n6q.fsf@gmail.com> <878uvz4khf.fsf@gmail.com> <1386244615.2760.3.camel@kirk> Message-ID: <8738m74e5h.fsf@gnu.org> Hello Joachim, On 2013-12-05 at 12:56:55 +0100, Joachim Breitner wrote: > Am Donnerstag, den 05.12.2013, 12:15 +0100 schrieb Herbert Valerio > Riedel: >> PS: I didn't merge in testsuite's Git history as that would bloat >> ghc.git quite a bit; > > would that really be a problem? How different are the numbers? Here's a rough estimate: testsuite.git current single packfile: 1.8M Dec 5 14:18 .git/objects/pack/pack-5d85ce17a3003e44e0e36d757564ce7df09275d4.idx 27M Dec 5 14:18 .git/objects/pack/pack-5d85ce17a3003e44e0e36d757564ce7df09275d4.pack whereas, when I create a new git repo containing only the HEAD commit from testsuite.git, the resulting single packfile: 204K Dec 5 14:19 .git/objects/pack/pack-27355d714321978fd34c21ce341a7b55f416719a.idx 2.5M Dec 5 14:19 .git/objects/pack/pack-27355d714321978fd34c21ce341a7b55f416719a.pack this seemed to be a significant increase to me; > I?m a fan of keeping history readily available, so unless it really > hurts I suggest to do a proper merge. btw, it'd be easy to provide a simple script which would re-attach the testsuite history (and any other repositories with truncated history) but there's another subtle issue; there's multiple ways to merge in the old testsuite repo, one is without any path-translation, as accomplished by the grafting example I gave; the other is to first rewrite the 'testsuite.git' to have its root-folder being located in a 'testsuite/' folder, so that Git doesn't have to follow renames and thus maybe also simplify navigating/querying the Git history. Cheers, hvr From johan.tibell at gmail.com Thu Dec 5 14:01:29 2013 From: johan.tibell at gmail.com (Johan Tibell) Date: Thu, 5 Dec 2013 15:01:29 +0100 Subject: Repository Reorganization Question In-Reply-To: <8738m74e5h.fsf@gnu.org> References: <87d2lb4n6q.fsf@gmail.com> <878uvz4khf.fsf@gmail.com> <1386244615.2760.3.camel@kirk> <8738m74e5h.fsf@gnu.org> Message-ID: Lets not lose our history or make it annoying to access. Disk is cheap. On Thu, Dec 5, 2013 at 2:32 PM, Herbert Valerio Riedel wrote: > Hello Joachim, > > On 2013-12-05 at 12:56:55 +0100, Joachim Breitner wrote: > > Am Donnerstag, den 05.12.2013, 12:15 +0100 schrieb Herbert Valerio > > Riedel: > >> PS: I didn't merge in testsuite's Git history as that would bloat > >> ghc.git quite a bit; > > > > would that really be a problem? How different are the numbers? > > Here's a rough estimate: > > testsuite.git current single packfile: > > 1.8M Dec 5 14:18 > .git/objects/pack/pack-5d85ce17a3003e44e0e36d757564ce7df09275d4.idx > 27M Dec 5 14:18 > .git/objects/pack/pack-5d85ce17a3003e44e0e36d757564ce7df09275d4.pack > > whereas, when I create a new git repo containing only the HEAD commit > from testsuite.git, the resulting single packfile: > > 204K Dec 5 14:19 > .git/objects/pack/pack-27355d714321978fd34c21ce341a7b55f416719a.idx > 2.5M Dec 5 14:19 > .git/objects/pack/pack-27355d714321978fd34c21ce341a7b55f416719a.pack > > this seemed to be a significant increase to me; > > > I?m a fan of keeping history readily available, so unless it really > > hurts I suggest to do a proper merge. > > btw, it'd be easy to provide a simple script which would re-attach the > testsuite history (and any other repositories with truncated history) > > but there's another subtle issue; there's multiple ways to merge in the > old testsuite repo, one is without any path-translation, as accomplished > by the grafting example I gave; the other is to first rewrite the > 'testsuite.git' to have its root-folder being located in a 'testsuite/' > folder, so that Git doesn't have to follow renames and thus maybe also > simplify navigating/querying the Git history. > > Cheers, > hvr > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://www.haskell.org/mailman/listinfo/ghc-devs > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hvr at gnu.org Thu Dec 5 14:03:42 2013 From: hvr at gnu.org (Herbert Valerio Riedel) Date: Thu, 05 Dec 2013 15:03:42 +0100 Subject: Repository Reorganization Question In-Reply-To: <59543203684B2244980D7E4057D5FBC1486E07C1@DB3EX14MBXC308.europe.corp.microsoft.com> (Simon Peyton-Jones's message of "Thu, 5 Dec 2013 11:31:40 +0000") References: <87d2lb4n6q.fsf@gmail.com> <878uvz4khf.fsf@gmail.com> <59543203684B2244980D7E4057D5FBC1486E07C1@DB3EX14MBXC308.europe.corp.microsoft.com> Message-ID: <87y53z2y4h.fsf@gnu.org> On 2013-12-05 at 12:31:40 +0100, Simon Peyton-Jones wrote: > What (if anything) do we need to do when updating existing local repos. Will everything be ok if I just do > sync-all pull ...assuming there's no important uncommitted data left in testsuite/ (and ideally nowhere else in the source-tree), it *should* suffice to just './sync-all pull' as this operation *should* overwrite any testsuite/* files laying around (at least that's what I've observed so far in my tests) However, if the testsuite/ was already checked out before the 'sync-all pull', the 'testsuite/.git' folder won't be removed automatically (and it shouldn't hurt either, as 'sync-all' won't traverse it anymore after ghc.git was updated) Cheers, hvr From igloo at earth.li Thu Dec 5 14:17:53 2013 From: igloo at earth.li (Ian Lynagh) Date: Thu, 5 Dec 2013 14:17:53 +0000 Subject: Repository Reorganization Question In-Reply-To: <87y53z2y4h.fsf@gnu.org> References: <87d2lb4n6q.fsf@gmail.com> <878uvz4khf.fsf@gmail.com> <59543203684B2244980D7E4057D5FBC1486E07C1@DB3EX14MBXC308.europe.corp.microsoft.com> <87y53z2y4h.fsf@gnu.org> Message-ID: <20131205141753.GA12830@matrix.chaos.earth.li> On Thu, Dec 05, 2013 at 03:03:42PM +0100, Herbert Valerio Riedel wrote: > > However, if the testsuite/ was already checked out before the 'sync-all > pull', the 'testsuite/.git' folder won't be removed automatically (and > it shouldn't hurt either, as 'sync-all' won't traverse it anymore after > ghc.git was updated) But git commands under testsuite/ will use the wrong .git, won't they? Thanks Ian From hvr at gnu.org Thu Dec 5 14:22:20 2013 From: hvr at gnu.org (Herbert Valerio Riedel) Date: Thu, 05 Dec 2013 15:22:20 +0100 Subject: Repository Reorganization Question In-Reply-To: <20131205141753.GA12830@matrix.chaos.earth.li> (Ian Lynagh's message of "Thu, 5 Dec 2013 14:17:53 +0000") References: <87d2lb4n6q.fsf@gmail.com> <878uvz4khf.fsf@gmail.com> <59543203684B2244980D7E4057D5FBC1486E07C1@DB3EX14MBXC308.europe.corp.microsoft.com> <87y53z2y4h.fsf@gnu.org> <20131205141753.GA12830@matrix.chaos.earth.li> Message-ID: <87txen2x9f.fsf@gmail.com> On 2013-12-05 at 15:17:53 +0100, Ian Lynagh wrote: > On Thu, Dec 05, 2013 at 03:03:42PM +0100, Herbert Valerio Riedel wrote: >> >> However, if the testsuite/ was already checked out before the 'sync-all >> pull', the 'testsuite/.git' folder won't be removed automatically (and >> it shouldn't hurt either, as 'sync-all' won't traverse it anymore after >> ghc.git was updated) > > But git commands under testsuite/ will use the wrong .git, won't they? good point, didn't think of that :-/ So I guess 'sync-all' should be tweaked to either delete the .git/ folder or warn the user to remove it; From mainland at apeiron.net Thu Dec 5 18:19:33 2013 From: mainland at apeiron.net (Geoffrey Mainland) Date: Thu, 05 Dec 2013 13:19:33 -0500 Subject: Repository Reorganization Question In-Reply-To: References: Message-ID: <52A0C3B5.7050406@apeiron.net> I'm all for converting to submodules. Since we will have submodules anyway, we could also convert testsuite et al to submodules and see how painful that is before deciding to fold them in to the main repo. I'm not clear on the pros/cons of having, e.g., testsuite, as a submodule vs folded in. The submodule approach will certainly maintain history! Geoff On 12/04/2013 04:24 PM, Austin Seipp wrote: > Hi all, > > While discussing something with Herbert this week in preparation of > making a new stable branch, he brought a good point to my attention, > which is that if we go ahead and reorganize the repository situation > post 7.8, merging things to the stable branch from HEAD will become a > bit harder. > > Notably, we had planned to fold testsuite (and perhaps some other > repositories) into the GHC tree. Once we do this, the two branches > will have diverged quite a bit, so merging from HEAD to STABLE will > become harder* (because HEAD would have rolled in testsuite changes > for example, but the STABLE branch would not have this history.) > > Thinking about it, the best time to do such a move is, basically, when > there is no active stable branch. Unfortunately this time is right > now, but I'm not sure how everyone feels about this. > > So, the question is: should we go ahead and pull the trigger on some > of these perhaps? Herbert collected some numbers on the git > repositories and outlined all the basic details here: > > https://ghc.haskell.org/trac/ghc/wiki/GitRepoReorganization > > The only thing I'd honestly propose right now is folding 'testsuite' > into the main repository, but of course we should see what people > think - perhaps we should keep base/etc off the table for now, since > they seem more controversial. > > * I'll point out they will only become *slightly* harder in most > cases, because I can always instead apply unified diffs, rather than > cherry pick or something. But it does lose the original metadata from > commits too. But I won't cry if people vote against this. > From kazu at iij.ad.jp Thu Dec 5 21:32:10 2013 From: kazu at iij.ad.jp (Kazu Yamamoto (=?iso-2022-jp?B?GyRCOzNLXE9CSScbKEI=?=)) Date: Fri, 06 Dec 2013 06:32:10 +0900 (JST) Subject: __builtin___clear_cache In-Reply-To: <20131129.174412.1952476927693992470.kazu@iij.ad.jp> References: <20131129.113743.2086479021786836429.kazu@iij.ad.jp> <87r49zaa62.fsf@gmail.com> <20131129.174412.1952476927693992470.kazu@iij.ad.jp> Message-ID: <20131206.063210.1947612207244915964.kazu@iij.ad.jp> Hi, I verified that the recent change solves this problem on Mac. Thank you, Austin. --Kazu > I was discussed this with Austin in private messages. He understand > what's the source of this problem and will fix it. > > --Kazu > >> On 2013-11-29 at 03:37:43 +0100, Kazu Yamamoto (????) wrote: >>> 5bab1a57f572e29dfdffd6d1ce8e53a2772b18fd introduced >>> __builtin___clear_cache. I think this is GCC specific. >>> So, Storage.c cannot be compiled with clang: >>> >>> ---- >>> rts/sm/Storage.c:1294:3: >>> error: use of unknown builtin '__builtin___clear_cache' [-Wimplicit-function-declaration] >>> __builtin___clear_cache(begin, end); >>> ^ >>> 1 error generated. >>> ---- >> >> Fyi, the following posting seems related: >> >> http://lists.nongnu.org/archive/html/libunwind-devel/2012-08/msg00057.html >> > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://www.haskell.org/mailman/listinfo/ghc-devs From ezyang at mit.edu Thu Dec 5 11:43:35 2013 From: ezyang at mit.edu (Edward Z. Yang) Date: Thu, 05 Dec 2013 03:43:35 -0800 Subject: Compare-and-swap semantics in GHC In-Reply-To: References: Message-ID: <1386241559-sup-1935@sabre> It's strong. How to tell: x86 doesn't support really have any kind of weak CAS implementation; and our PowerPC implementation loops over LL/SC. (oh, and our asm is marked volatile) As for whether or not there are any uses of CAS that don't need these guarantees, probably the best way to figure this out is to look for any uses of CAS, for which better algorithms using LL/SC are known (since that's really the only well known implementation of this "weak" compare and swap). Of course, it's worth noting that any of these improvements would not apply to today's x86, so they'd be of somewhat limited applicability. Cheers, Edward Excerpts from KwangYul Seo's message of 2013-12-04 23:58:50 -0800: > Hi, > > java.util.concurrent.atomic package provides two flavors of compare and set > operations: compareAndSet and weakCompareAndSet. The latter does not create > any happens-before orderings, so we can use it where no guarantees with > respect to previous or subsequent reads and writes of any variables other > than the target of the weakCompareAndSet are required. > > I'd like to ask if the compare-and-swap function provided by GHC runtime > (cas() in includes/stg/SMP.h) is strong or weak. If it is strong, do all > use cases of cas() require this semantics? > > Regards, > Kwang Yul Seo From hvr at gnu.org Fri Dec 6 10:05:05 2013 From: hvr at gnu.org (Herbert Valerio Riedel) Date: Fri, 06 Dec 2013 11:05:05 +0100 Subject: Repository Reorganization Question In-Reply-To: <8738m74e5h.fsf@gnu.org> (Herbert Valerio Riedel's message of "Thu, 05 Dec 2013 14:32:10 +0100") References: <87d2lb4n6q.fsf@gmail.com> <878uvz4khf.fsf@gmail.com> <1386244615.2760.3.camel@kirk> <8738m74e5h.fsf@gnu.org> Message-ID: <87mwke9twu.fsf@gmail.com> On 2013-12-05 at 14:32:10 +0100, Herbert Valerio Riedel wrote: [...] > whereas, when I create a new git repo containing only the HEAD commit > from testsuite.git, the resulting single packfile: > > 204K Dec 5 14:19 .git/objects/pack/pack-27355d714321978fd34c21ce341a7b55f416719a.idx > 2.5M Dec 5 14:19 .git/objects/pack/pack-27355d714321978fd34c21ce341a7b55f416719a.pack > > this seemed to be a significant increase to me; PS: if anyone wonders why the testsuite.git history is so large: there were a few *huge* binary files with bad compressibility checked in by accident, such as the one removed via http://git.haskell.org/testsuite.git/commitdiff/68acef7dd144452db12689db3299ae7106d87f16 tests/haddock/should_compile_flag_nohaddock/a.out | Bin 2745963 -> 0 bytes tests/haddock/should_compile_noflag_nohaddock/a.out | Bin 2745963 -> 0 bytes or http://git.haskell.org/testsuite.git/commitdiff/cb540135b26504cffe557fd57fa3bb936e413769 tests/ghc-regress/dph/diophantine/dph-diophantine-fast | Bin 16854700 -> 0 bytes tests/ghc-regress/dph/diophantine/dph-diophantine-opt | Bin 17017376 -> 0 bytes tests/ghc-regress/dph/primespj/dph-primespj-fast | Bin 16783780 -> 0 bytes tests/ghc-regress/dph/quickhull/dph-quickhull-fast | Bin 17092732 -> 0 bytes tests/ghc-regress/dph/smvm/dph-smvm | Bin 16581028 -> 0 bytes tests/ghc-regress/dph/sumnats/dph-sumnats | Bin 16101268 -> 0 bytes tests/ghc-regress/dph/words/dph-words-fast | Bin 17580076 -> 0 bytes which account for most of the ~20MiB history.... From mail at joachim-breitner.de Fri Dec 6 11:07:09 2013 From: mail at joachim-breitner.de (Joachim Breitner) Date: Fri, 06 Dec 2013 11:07:09 +0000 Subject: Repository Reorganization Question In-Reply-To: <87mwke9twu.fsf@gmail.com> References: <87d2lb4n6q.fsf@gmail.com> <878uvz4khf.fsf@gmail.com> <1386244615.2760.3.camel@kirk> <8738m74e5h.fsf@gnu.org> <87mwke9twu.fsf@gmail.com> Message-ID: <1386328029.2621.1.camel@kirk> Hi, Am Freitag, den 06.12.2013, 11:05 +0100 schrieb Herbert Valerio Riedel: > PS: if anyone wonders why the testsuite.git history is so large: there > were a few *huge* binary files with bad compressibility checked in by > accident, such as the one removed via > >[..] > > s/dph/words/dph-words-fast | Bin 17580076 -> 0 bytes > > which account for most of the ~20MiB history.... so if we were to do the marge including a pathname rewrite (which I tend to think of as fine), we could remove these files from the history as well, and get a reasonably sized repository? Greetings, Joachim -- Joachim ?nomeata? Breitner mail at joachim-breitner.de ? http://www.joachim-breitner.de/ Jabber: nomeata at joachim-breitner.de ? GPG-Key: 0x4743206C Debian Developer: nomeata at debian.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part URL: From johan.tibell at gmail.com Fri Dec 6 12:01:41 2013 From: johan.tibell at gmail.com (Johan Tibell) Date: Fri, 6 Dec 2013 13:01:41 +0100 Subject: Repository Reorganization Question In-Reply-To: <1386328029.2621.1.camel@kirk> References: <87d2lb4n6q.fsf@gmail.com> <878uvz4khf.fsf@gmail.com> <1386244615.2760.3.camel@kirk> <8738m74e5h.fsf@gnu.org> <87mwke9twu.fsf@gmail.com> <1386328029.2621.1.camel@kirk> Message-ID: Hi, When we merge in the testsuite repo, can we still keep the old commit IDs? They're referenced from all over the place. On Fri, Dec 6, 2013 at 12:07 PM, Joachim Breitner wrote: > Hi, > > Am Freitag, den 06.12.2013, 11:05 +0100 schrieb Herbert Valerio Riedel: > > PS: if anyone wonders why the testsuite.git history is so large: there > > were a few *huge* binary files with bad compressibility checked in by > > accident, such as the one removed via > > > >[..] > > > > s/dph/words/dph-words-fast | Bin 17580076 -> 0 bytes > > > > which account for most of the ~20MiB history.... > > so if we were to do the marge including a pathname rewrite (which I tend > to think of as fine), we could remove these files from the history as > well, and get a reasonably sized repository? > > Greetings, > Joachim > > -- > Joachim ?nomeata? Breitner > mail at joachim-breitner.de ? http://www.joachim-breitner.de/ > Jabber: nomeata at joachim-breitner.de ? GPG-Key: 0x4743206C > Debian Developer: nomeata at debian.org > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://www.haskell.org/mailman/listinfo/ghc-devs > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mail at joachim-breitner.de Fri Dec 6 12:06:21 2013 From: mail at joachim-breitner.de (Joachim Breitner) Date: Fri, 06 Dec 2013 12:06:21 +0000 Subject: Repository Reorganization Question In-Reply-To: References: <87d2lb4n6q.fsf@gmail.com> <878uvz4khf.fsf@gmail.com> <1386244615.2760.3.camel@kirk> <8738m74e5h.fsf@gnu.org> <87mwke9twu.fsf@gmail.com> <1386328029.2621.1.camel@kirk> Message-ID: <1386331581.2621.3.camel@kirk> Hi, Am Freitag, den 06.12.2013, 13:01 +0100 schrieb Johan Tibell: > When we merge in the testsuite repo, can we still keep the old commit > IDs? They're referenced from all over the place. that depends on the style of merge: * With pathname rewriting: + git can easily trace the history of a file + we can remove the large binary blobs while we are at it * Without pathname rewriting: + commit IDs stay the same Greetings, Joachim -- Joachim ?nomeata? Breitner mail at joachim-breitner.de ? http://www.joachim-breitner.de/ Jabber: nomeata at joachim-breitner.de ? GPG-Key: 0x4743206C Debian Developer: nomeata at debian.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part URL: From hvr at gnu.org Fri Dec 6 12:15:34 2013 From: hvr at gnu.org (Herbert Valerio Riedel) Date: Fri, 06 Dec 2013 13:15:34 +0100 Subject: Repository Reorganization Question In-Reply-To: (Johan Tibell's message of "Fri, 6 Dec 2013 13:01:41 +0100") References: <87d2lb4n6q.fsf@gmail.com> <878uvz4khf.fsf@gmail.com> <1386244615.2760.3.camel@kirk> <8738m74e5h.fsf@gnu.org> <87mwke9twu.fsf@gmail.com> <1386328029.2621.1.camel@kirk> Message-ID: <87fvq69nvd.fsf@gmail.com> On 2013-12-06 at 13:01:41 +0100, Johan Tibell wrote: > When we merge in the testsuite repo, can we still keep the old commit IDs? > They're referenced from all over the place. ...if we want to preserve the old testsuite's commit-ids, then we'll have to live with carrying around those superflous large blobs in testsuite's history nobody really needs, as afaik[1] we can't remove the blobs w/o causing the commit-ids to change. I'm not so much concerned about disk-space, but rather the wasted network bandwidth involved (and yes, we're already suffering from that now with the current testsuite.git). But I don't feel very strongly on this one, if there's agreement that we want to keep around those dead weights in the Git history in order to retain testsuite.git's original commit ids *inside* ghc.git (nb: the old testsuite.git repo won't be deleted and thus remain available, it just won't be pushed into anymore). Otoh, which use-cases exactly do you have in mind wrt the testsuite.git commit-ids? [1]: maybe someone with more Git-foo knows a trick here? From johan.tibell at gmail.com Fri Dec 6 12:50:55 2013 From: johan.tibell at gmail.com (Johan Tibell) Date: Fri, 6 Dec 2013 13:50:55 +0100 Subject: Repository Reorganization Question In-Reply-To: <87fvq69nvd.fsf@gmail.com> References: <87d2lb4n6q.fsf@gmail.com> <878uvz4khf.fsf@gmail.com> <1386244615.2760.3.camel@kirk> <8738m74e5h.fsf@gnu.org> <87mwke9twu.fsf@gmail.com> <1386328029.2621.1.camel@kirk> <87fvq69nvd.fsf@gmail.com> Message-ID: Whichever way to go, we should write down the options and consequences and communicating them widely enough so no core devs get surprised. Commit IDs for the test suite are referenced in e.g. various Trac issues, on mailing lists (although rarely), and perhaps even in code. On Fri, Dec 6, 2013 at 1:15 PM, Herbert Valerio Riedel wrote: > On 2013-12-06 at 13:01:41 +0100, Johan Tibell wrote: > > When we merge in the testsuite repo, can we still keep the old commit > IDs? > > They're referenced from all over the place. > > ...if we want to preserve the old testsuite's commit-ids, then we'll > have to live with carrying around those superflous large blobs in > testsuite's history nobody really needs, as afaik[1] we can't remove the > blobs w/o causing the commit-ids to change. > > I'm not so much concerned about disk-space, but rather the wasted > network bandwidth involved (and yes, we're already suffering from that > now with the current testsuite.git). But I don't feel very strongly on > this one, if there's agreement that we want to keep around those dead > weights in the Git history in order to retain testsuite.git's original > commit ids *inside* ghc.git (nb: the old testsuite.git repo won't be > deleted and thus remain available, it just won't be pushed into > anymore). > > Otoh, which use-cases exactly do you have in mind wrt the testsuite.git > commit-ids? > > > [1]: maybe someone with more Git-foo knows a trick here? > -------------- next part -------------- An HTML attachment was scrubbed... URL: From marlowsd at gmail.com Fri Dec 6 14:12:09 2013 From: marlowsd at gmail.com (Simon Marlow) Date: Fri, 06 Dec 2013 14:12:09 +0000 Subject: Repository Reorganization Question In-Reply-To: References: <87d2lb4n6q.fsf@gmail.com> <878uvz4khf.fsf@gmail.com> <1386244615.2760.3.camel@kirk> <8738m74e5h.fsf@gnu.org> <87mwke9twu.fsf@gmail.com> <1386328029.2621.1.camel@kirk> <87fvq69nvd.fsf@gmail.com> Message-ID: <52A1DB39.3040909@gmail.com> Trac tickets with links to commits are the important case. If the commit IDs change, someone will have to run a script over the Trac database and rewrite all those links to testsuite commits to the new ones. Sounds possible, but it'll be at least a few hours work I'd guess. I'm in favour of removing the unnecessary binary blobs from the history so long as we can do it without any serious disruption. Cheers, Simon On 06/12/2013 12:50, Johan Tibell wrote: > Whichever way to go, we should write down the options and consequences > and communicating them widely enough so no core devs get surprised. > > Commit IDs for the test suite are referenced in e.g. various Trac > issues, on mailing lists (although rarely), and perhaps even in code. > > > On Fri, Dec 6, 2013 at 1:15 PM, Herbert Valerio Riedel > wrote: > > On 2013-12-06 at 13:01:41 +0100, Johan Tibell wrote: > > When we merge in the testsuite repo, can we still keep the old > commit IDs? > > They're referenced from all over the place. > > ...if we want to preserve the old testsuite's commit-ids, then we'll > have to live with carrying around those superflous large blobs in > testsuite's history nobody really needs, as afaik[1] we can't remove the > blobs w/o causing the commit-ids to change. > > I'm not so much concerned about disk-space, but rather the wasted > network bandwidth involved (and yes, we're already suffering from that > now with the current testsuite.git). But I don't feel very strongly on > this one, if there's agreement that we want to keep around those dead > weights in the Git history in order to retain testsuite.git's original > commit ids *inside* ghc.git (nb: the old testsuite.git repo won't be > deleted and thus remain available, it just won't be pushed into > anymore). > > Otoh, which use-cases exactly do you have in mind wrt the testsuite.git > commit-ids? > > > [1]: maybe someone with more Git-foo knows a trick here? > > > > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://www.haskell.org/mailman/listinfo/ghc-devs > From marlowsd at gmail.com Fri Dec 6 14:21:39 2013 From: marlowsd at gmail.com (Simon Marlow) Date: Fri, 06 Dec 2013 14:21:39 +0000 Subject: Repository Reorganization Question In-Reply-To: References: Message-ID: <52A1DD73.60306@gmail.com> My only concern with this is that we consider the workflow and tooling issues that I outlined in http://permalink.gmane.org/gmane.comp.lang.haskell.ghc.devel/2718 The main points are making sure the workflow for submodules doesn't have too much friction, that it's integrated nicely into sync-all, and that we avoid the worst pitfall of submodules: losing local changes to a submodule on a git submodule update. I think this means that sync-all pull should do either 'git submodule update --merge' or 'git submodule update --rebase' depending on whether you used sync-all pull --rebase or not. But caveats apply, I've only skimmed the docs and not tried this out for real :-) OTOH, it's not hard to do manual cherry-picks with git. 'git show | patch -p1' is something I often do, and 'git commit -C ' reuses the metadata from another commit. So it's probably not essential that we do this now. Cheers, Simon On 04/12/2013 21:24, Austin Seipp wrote: > Hi all, > > While discussing something with Herbert this week in preparation of > making a new stable branch, he brought a good point to my attention, > which is that if we go ahead and reorganize the repository situation > post 7.8, merging things to the stable branch from HEAD will become a > bit harder. > > Notably, we had planned to fold testsuite (and perhaps some other > repositories) into the GHC tree. Once we do this, the two branches > will have diverged quite a bit, so merging from HEAD to STABLE will > become harder* (because HEAD would have rolled in testsuite changes > for example, but the STABLE branch would not have this history.) > > Thinking about it, the best time to do such a move is, basically, when > there is no active stable branch. Unfortunately this time is right > now, but I'm not sure how everyone feels about this. > > So, the question is: should we go ahead and pull the trigger on some > of these perhaps? Herbert collected some numbers on the git > repositories and outlined all the basic details here: > > https://ghc.haskell.org/trac/ghc/wiki/GitRepoReorganization > > The only thing I'd honestly propose right now is folding 'testsuite' > into the main repository, but of course we should see what people > think - perhaps we should keep base/etc off the table for now, since > they seem more controversial. > > * I'll point out they will only become *slightly* harder in most > cases, because I can always instead apply unified diffs, rather than > cherry pick or something. But it does lose the original metadata from > commits too. But I won't cry if people vote against this. > From simonpj at microsoft.com Fri Dec 6 14:27:16 2013 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Fri, 6 Dec 2013 14:27:16 +0000 Subject: [GHC] #8598: IO hack in demand analyzer gets in the way of CPR In-Reply-To: <046.257cc2180dce5fcae9e4dfcb90ad22aa@haskell.org> References: <046.257cc2180dce5fcae9e4dfcb90ad22aa@haskell.org> Message-ID: <59543203684B2244980D7E4057D5FBC1486E296A@DB3EX14MBXC308.europe.corp.microsoft.com> Well spotted. I'm on a train, hence email response. Maybe you can paste this into the ticket? There are two different issues here. '''First''', `isDoubleFinite` is declared as non-side-effecting: {{{ foreign import ccall unsafe "isDoubleFinite" isDoubleFinite :: Double -> Int }}} But (as you can see from the code you give) we currently desugar it into something that looks (to Core) as though it might have a side effect, or raise a (synchronous) exception. That is stupid. How might we fix that? I can think of two ways. * Generate a `FCallId` whose type is `Double -> Int` rather than (as now) `Double -> IO Int`. There would be a few knock-on consequences to make sure they were correctly code-generated. I like this path best, because it reflects the truth. * Currently {{{ IO a = State# RealWorld# -> (# State# RealWorld#, a #) }}} For these non-side-effecting things we could instead generate a `FCallId` with a type involving `SafeIO` instead of `IO`: {{{ SafeIO a = State# SafeWorld# -> (# State# SafeWorld#, a #) }}} The different "world token" would express the idea that the function can't throw an exception. I don't like this as much, but it might in any case be useful for things that ''do'' have side effects but ''don't'' throw exceptions. My preference is for the first. '''Second''', as you point out, consider {{{ f x = do { when (x>3) exit ; return (True, False) } }}} Function `f` might throw an exception or exit rather than returning, but ''if it does return'' it will certainly have the CPR property. So yes, CPR-ness is quite safe. It's not quite so obvious for divergence: {{{ g x = do { when (x>3) exit ; g x } h 0 y = y h x y = g x }}} Is `h` strict in `y`? You might say (reasonably) that we can ignore the possible IO exception/exit in `g` when figuring out that `g` is sure to diverge. If so, we'd say that `h` is strict in `y`. But if `(x>3)` then really `y` is not evaluated... and spotting that is exactly what the IO hack in the demand analyser is spotting. So I think it is ''not'' safe to propagate divergence information. In short, CPR info yes, guaranteed-divergence no. Simon | -----Original Message----- | From: ghc-tickets [mailto:ghc-tickets-bounces at haskell.org] On Behalf Of | GHC | Sent: 06 December 2013 10:54 | Cc: ghc-tickets at haskell.org | Subject: [GHC] #8598: IO hack in demand analyzer gets in the way of CPR | | #8598: IO hack in demand analyzer gets in the way of CPR | ------------------------------------+---------------------------------- | --- | Reporter: nomeata | Owner: | Type: task | Status: new | Priority: normal | Milestone: | Component: Compiler | Version: 7.6.3 | Keywords: | Operating System: | Unknown/Multiple | Architecture: Unknown/Multiple | Type of failure: None/Unknown | Difficulty: Unknown | Test Case: | Blocked By: | Blocking: | Related Tickets: | | ------------------------------------+---------------------------------- | --- | After a lot of staring at code and comparing unexpected nofib results | I | found the following: | | The IO hack in the demand analyzer (see `dmdAnalAlt` in `StrAnal.lhs` | and | #1592 for a good discussion) prevents CPR in any function that uses a | C | call. This is a small example, reduced from the `scaleFloat` method | for | doubles: | | {{{ | module Float(fun) where | | import GHC.Float (Double(..)) | import GHC.Integer (decodeDoubleInteger, encodeDoubleInteger) | | fun :: Double -> Double | fun x | isFix = x | | otherwise = case x of | (D# x#) -> case decodeDoubleInteger x# of | (# i, j #) -> D# (encodeDoubleInteger i j) | where | isFix = isDoubleFinite x == 0 | | foreign import ccall unsafe "isDoubleFinite" isDoubleFinite :: Double | -> | Int | }}} | | Here, `fun` does current not get the CPR property, and the work gets | type | `GHC.Prim.Double# -> GHC.Types.Double`. Why? Because in core, there | will | be a | {{{ | case {__pkg_ccall main isDoubleFinite GHC.Prim.Double# | -> GHC.Prim.State# GHC.Prim.RealWorld | -> (# GHC.Prim.State# | GHC.Prim.RealWorld, | GHC.Prim.Int# #)}_dQD | ds_dQA GHC.Prim.realWorld# | of _ [Occ=Dead, Dmd=] | { (# ds_dQC [Dmd=, OS=OneShot], ds_dQB [Dmd=] #) -> | ... | }}} | where the case body has `DmdType m {dQz-> dQA->}`, but | `dmdAnalAlt` detects that this is evaluating a possibly exiting | function | and throws aways the information using `alt_ty `lubDmdType` | topDmdType`. | | Would it be ok to `lub` only the demand on the free variables, but | keep | the CPR information? | | In nofib (if I managed to compare the right results) this does nothing | for | almost all benchmarks, `-9.2%` of allocations for `mandel` and `+4.9%` | for | reverse-complement (but these numbers are not obtained very cleanly, | and | all is happening on top of the better-ho-cardinality branch. | | -- | Ticket URL: | GHC | The Glasgow Haskell Compiler | _______________________________________________ | ghc-tickets mailing list | ghc-tickets at haskell.org | http://www.haskell.org/mailman/listinfo/ghc-tickets From hvr at gnu.org Fri Dec 6 15:43:46 2013 From: hvr at gnu.org (Herbert Valerio Riedel) Date: Fri, 06 Dec 2013 16:43:46 +0100 Subject: Repository Reorganization Question In-Reply-To: (Johan Tibell's message of "Fri, 6 Dec 2013 13:50:55 +0100") References: <87d2lb4n6q.fsf@gmail.com> <878uvz4khf.fsf@gmail.com> <1386244615.2760.3.camel@kirk> <8738m74e5h.fsf@gnu.org> <87mwke9twu.fsf@gmail.com> <1386328029.2621.1.camel@kirk> <87fvq69nvd.fsf@gmail.com> Message-ID: <87bo0u9e8d.fsf@gmail.com> On 2013-12-06 at 13:50:55 +0100, Johan Tibell wrote: > Whichever way to go, we should write down the options and consequences and > communicating them widely enough so no core devs get surprised. > > Commit IDs for the test suite are referenced in e.g. various Trac issues, > on mailing lists (although rarely), and perhaps even in code. ...as I hinted at in an earlier post, the old commit-ids will still allow to find the original commit; for isntance, there's already the find-commit-by-sha1 service at http://git.haskell.org/.findhash/ which searches all repos hosted at git.haskell.org for the given sha1 prefix; there's also a convenient text-entry field at http://git.haskell.org/ which allows you to copy'n'paste any commit-ids you might come across in emails, irc logs, trac comments or even commit messages... ...does this lookup-service alleviate your concerns? Cheers, hvr From johan.tibell at gmail.com Fri Dec 6 16:26:34 2013 From: johan.tibell at gmail.com (Johan Tibell) Date: Fri, 6 Dec 2013 17:26:34 +0100 Subject: Repository Reorganization Question In-Reply-To: <87bo0u9e8d.fsf@gmail.com> References: <87d2lb4n6q.fsf@gmail.com> <878uvz4khf.fsf@gmail.com> <1386244615.2760.3.camel@kirk> <8738m74e5h.fsf@gnu.org> <87mwke9twu.fsf@gmail.com> <1386328029.2621.1.camel@kirk> <87fvq69nvd.fsf@gmail.com> <87bo0u9e8d.fsf@gmail.com> Message-ID: On Fri, Dec 6, 2013 at 4:43 PM, Herbert Valerio Riedel wrote: > On 2013-12-06 at 13:50:55 +0100, Johan Tibell wrote: > > Whichever way to go, we should write down the options and consequences > and > > communicating them widely enough so no core devs get surprised. > > > > Commit IDs for the test suite are referenced in e.g. various Trac issues, > > on mailing lists (although rarely), and perhaps even in code. > > ...as I hinted at in an earlier post, the old commit-ids will still > allow to find the original commit; for isntance, there's already the > find-commit-by-sha1 service at > > http://git.haskell.org/.findhash/ > > which searches all repos hosted at git.haskell.org for the given sha1 > prefix; there's also a convenient text-entry field at > http://git.haskell.org/ which allows you to copy'n'paste any commit-ids > you might come across in emails, irc logs, trac comments or even commit > messages... > > ...does this lookup-service alleviate your concerns? > Personally I think it's still much friction; another thing to remember. Is it really worth it for a couple of megs of bandwidth* and some disk space? If it really is I believe git has some facility for nuking the data of old commits. That facility exists for the case when someone committed something sensitive to the code base that should never have been there. * GitHub's bandwidth if you use that mirror. -- Johan -------------- next part -------------- An HTML attachment was scrubbed... URL: From mail at joachim-breitner.de Fri Dec 6 16:53:08 2013 From: mail at joachim-breitner.de (Joachim Breitner) Date: Fri, 06 Dec 2013 16:53:08 +0000 Subject: Moving travis CI repo to git.haskell.org? In-Reply-To: <1385162624.10037.22.camel@kirk> References: <1385158086.10037.7.camel@kirk> <1385162624.10037.22.camel@kirk> Message-ID: <1386348788.7910.2.camel@kirk> Hi, Am Freitag, den 22.11.2013, 23:23 +0000 schrieb Joachim Breitner: > It is updated regularly (currently a cronjob every 15 minutes, ideally > by push hooks), and each push triggers a build of exactly these recorded > versions of all components via travis: > https://travis-ci.org/nomeata/ghc-complete/builds I just found this alternative front-end to travis: https://travis-lite.com/nomeata/ghc-complete It does not use fancy Javascript to show the logs, so you can actually watch our (quite large) logs conveniently there. Greetings, Joachim -- Joachim ?nomeata? Breitner mail at joachim-breitner.de ? http://www.joachim-breitner.de/ Jabber: nomeata at joachim-breitner.de ? GPG-Key: 0x4743206C Debian Developer: nomeata at debian.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part URL: From carter.schonwald at gmail.com Fri Dec 6 17:47:47 2013 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Fri, 6 Dec 2013 12:47:47 -0500 Subject: Repository Reorganization Question In-Reply-To: References: <87d2lb4n6q.fsf@gmail.com> <878uvz4khf.fsf@gmail.com> <1386244615.2760.3.camel@kirk> <8738m74e5h.fsf@gnu.org> <87mwke9twu.fsf@gmail.com> <1386328029.2621.1.camel@kirk> <87fvq69nvd.fsf@gmail.com> <87bo0u9e8d.fsf@gmail.com> Message-ID: personally i don't care about the bandwidth, and others are correct about the value of logs. If theres a way to get both, awesome! If not, 20mb here and there i don't care. On Fri, Dec 6, 2013 at 11:26 AM, Johan Tibell wrote: > On Fri, Dec 6, 2013 at 4:43 PM, Herbert Valerio Riedel wrote: > >> On 2013-12-06 at 13:50:55 +0100, Johan Tibell wrote: >> > Whichever way to go, we should write down the options and consequences >> and >> > communicating them widely enough so no core devs get surprised. >> > >> > Commit IDs for the test suite are referenced in e.g. various Trac >> issues, >> > on mailing lists (although rarely), and perhaps even in code. >> >> ...as I hinted at in an earlier post, the old commit-ids will still >> allow to find the original commit; for isntance, there's already the >> find-commit-by-sha1 service at >> >> http://git.haskell.org/.findhash/ >> >> which searches all repos hosted at git.haskell.org for the given sha1 >> prefix; there's also a convenient text-entry field at >> http://git.haskell.org/ which allows you to copy'n'paste any commit-ids >> you might come across in emails, irc logs, trac comments or even commit >> messages... >> >> ...does this lookup-service alleviate your concerns? >> > > Personally I think it's still much friction; another thing to remember. Is > it really worth it for a couple of megs of bandwidth* and some disk space? > > If it really is I believe git has some facility for nuking the data of old > commits. That facility exists for the case when someone committed something > sensitive to the code base that should never have been there. > > * GitHub's bandwidth if you use that mirror. > > -- Johan > > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://www.haskell.org/mailman/listinfo/ghc-devs > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ml at isaac.cedarswampstudios.org Fri Dec 6 19:01:29 2013 From: ml at isaac.cedarswampstudios.org (Isaac Dupree) Date: Fri, 06 Dec 2013 14:01:29 -0500 Subject: Repository Reorganization Question In-Reply-To: References: <87d2lb4n6q.fsf@gmail.com> <878uvz4khf.fsf@gmail.com> <1386244615.2760.3.camel@kirk> <8738m74e5h.fsf@gnu.org> <87mwke9twu.fsf@gmail.com> <1386328029.2621.1.camel@kirk> <87fvq69nvd.fsf@gmail.com> <87bo0u9e8d.fsf@gmail.com> Message-ID: <52A21F09.7040904@isaac.cedarswampstudios.org> 20MB of bandwidth represents 20 additional seconds to do an initial clone on my 1 megabyte/second connection. ghc.git is already about 75MB, so it wouldn't dramatically change the experience either way. Just a data point. On 12/06/2013 12:47 PM, Carter Schonwald wrote: > personally i don't care about the bandwidth, and others are correct > about the value of logs. If theres a way to get both, awesome! If not, > 20mb here and there i don't care. > > > On Fri, Dec 6, 2013 at 11:26 AM, Johan Tibell > wrote: > > On Fri, Dec 6, 2013 at 4:43 PM, Herbert Valerio Riedel > wrote: > > On 2013-12-06 at 13:50:55 +0100, Johan Tibell wrote: > > Whichever way to go, we should write down the options and > consequences and > > communicating them widely enough so no core devs get surprised. > > > > Commit IDs for the test suite are referenced in e.g. various > Trac issues, > > on mailing lists (although rarely), and perhaps even in code. > > ...as I hinted at in an earlier post, the old commit-ids will still > allow to find the original commit; for isntance, there's already the > find-commit-by-sha1 service at > > http://git.haskell.org/.findhash/ > > which searches all repos hosted at git.haskell.org > for the given sha1 > prefix; there's also a convenient text-entry field at > http://git.haskell.org/ which allows you to copy'n'paste any > commit-ids > you might come across in emails, irc logs, trac comments or even > commit > messages... > > ...does this lookup-service alleviate your concerns? > > > Personally I think it's still much friction; another thing to > remember. Is it really worth it for a couple of megs of bandwidth* > and some disk space? > > If it really is I believe git has some facility for nuking the data > of old commits. That facility exists for the case when someone > committed something sensitive to the code base that should never > have been there. > > * GitHub's bandwidth if you use that mirror. > > -- Johan > > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://www.haskell.org/mailman/listinfo/ghc-devs > > > > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://www.haskell.org/mailman/listinfo/ghc-devs > From gergo at erdi.hu Mon Dec 9 06:05:30 2013 From: gergo at erdi.hu (Dr. ERDI Gergo) Date: Mon, 9 Dec 2013 14:05:30 +0800 (SGT) Subject: Preparing for a review of pattern synonyms Message-ID: Hi, I believe I've finished implementing version 1 of pattern synonyms (i.e. everything described in #5144, minus the things in #8581, #8582, #8583 and #8584). I've discussed the way forward with SPJ and he suggested because of the cross-cutting nature of the patch, I should wait a reasonably long time (~1 month) after 7.8 is branched off for things to settle, and then formally submit it for review. So my question is, is there anything I can do in the meantime, in preparation for the review? The code is available at https://github.com/gergoerdi/ghc. I've also added some tests to the testsuite (https://github.com/gergoerdi/ghc-testsuite), and updated the wiki pages at https://ghc.haskell.org/trac/ghc/wiki/PatternSynonyms and https://ghc.haskell.org/trac/ghc/wiki/PatternSynonyms/Implementation. Thanks, Gergo From marlowsd at gmail.com Mon Dec 9 08:18:09 2013 From: marlowsd at gmail.com (Simon Marlow) Date: Mon, 09 Dec 2013 08:18:09 +0000 Subject: Repository Reorganization Question In-Reply-To: <87bo0u9e8d.fsf@gmail.com> References: <87d2lb4n6q.fsf@gmail.com> <878uvz4khf.fsf@gmail.com> <1386244615.2760.3.camel@kirk> <8738m74e5h.fsf@gnu.org> <87mwke9twu.fsf@gmail.com> <1386328029.2621.1.camel@kirk> <87fvq69nvd.fsf@gmail.com> <87bo0u9e8d.fsf@gmail.com> Message-ID: <52A57CC1.7080105@gmail.com> On 06/12/2013 15:43, Herbert Valerio Riedel wrote: > On 2013-12-06 at 13:50:55 +0100, Johan Tibell wrote: >> Whichever way to go, we should write down the options and consequences and >> communicating them widely enough so no core devs get surprised. >> >> Commit IDs for the test suite are referenced in e.g. various Trac issues, >> on mailing lists (although rarely), and perhaps even in code. > > ...as I hinted at in an earlier post, the old commit-ids will still > allow to find the original commit; for isntance, there's already the > find-commit-by-sha1 service at > > http://git.haskell.org/.findhash/ > > which searches all repos hosted at git.haskell.org for the given sha1 > prefix; there's also a convenient text-entry field at > http://git.haskell.org/ which allows you to copy'n'paste any commit-ids > you might come across in emails, irc logs, trac comments or even commit > messages... > > ...does this lookup-service alleviate your concerns? No :-) To be honest I would probably just paste the SHA1 into Google and find it that way, which would probably work. But it's *far* better if the links just work. While I'm here can I just point out that old links into the mailing list archives are still broken, AFAIK. I run into this quite often, and it's a total pain, because you have no idea how to find the message that the link was originally pointing at. Cheers, Simon From hvriedel at gmail.com Mon Dec 9 08:24:20 2013 From: hvriedel at gmail.com (Herbert Valerio Riedel) Date: Mon, 09 Dec 2013 09:24:20 +0100 Subject: Repository Reorganization Question In-Reply-To: <52A57CC1.7080105@gmail.com> (Simon Marlow's message of "Mon, 09 Dec 2013 08:18:09 +0000") References: <87d2lb4n6q.fsf@gmail.com> <878uvz4khf.fsf@gmail.com> <1386244615.2760.3.camel@kirk> <8738m74e5h.fsf@gnu.org> <87mwke9twu.fsf@gmail.com> <1386328029.2621.1.camel@kirk> <87fvq69nvd.fsf@gmail.com> <87bo0u9e8d.fsf@gmail.com> <52A57CC1.7080105@gmail.com> Message-ID: <87ppp6fn4b.fsf@gmail.com> On 2013-12-09 at 09:18:09 +0100, Simon Marlow wrote: [...] >> ...as I hinted at in an earlier post, the old commit-ids will still >> allow to find the original commit; for isntance, there's already the >> find-commit-by-sha1 service at >> >> http://git.haskell.org/.findhash/ >> >> which searches all repos hosted at git.haskell.org for the given sha1 >> prefix; there's also a convenient text-entry field at >> http://git.haskell.org/ which allows you to copy'n'paste any commit-ids >> you might come across in emails, irc logs, trac comments or even commit >> messages... >> >> ...does this lookup-service alleviate your concerns? > > No :-) To be honest I would probably just paste the SHA1 into Google > and find it that way, which would probably work. But it's *far* > better if the links just work. What kind of links are you referring to btw? I don't see any clickable GHC SHA1 ids these days anymore... :-) ...any SHA1 links into the testsuite never had any chance of working in the first place out-of-the-box, unless they used Trac syntax to specify they referred to the testsuite repository. And now that we've disabled wiki-format rendering of commit messages again, we have lost that again as well. What I'm trying to say is, that I don't see any regression at all here. I.e. we wouldn't break any facility that didn't work before anyway. Cheers, hvr From mail at joachim-breitner.de Mon Dec 9 08:34:23 2013 From: mail at joachim-breitner.de (Joachim Breitner) Date: Mon, 09 Dec 2013 08:34:23 +0000 Subject: Repository Reorganization Question In-Reply-To: <87ppp6fn4b.fsf@gmail.com> References: <87d2lb4n6q.fsf@gmail.com> <878uvz4khf.fsf@gmail.com> <1386244615.2760.3.camel@kirk> <8738m74e5h.fsf@gnu.org> <87mwke9twu.fsf@gmail.com> <1386328029.2621.1.camel@kirk> <87fvq69nvd.fsf@gmail.com> <87bo0u9e8d.fsf@gmail.com> <52A57CC1.7080105@gmail.com> <87ppp6fn4b.fsf@gmail.com> Message-ID: <1386578063.2480.8.camel@kirk> Hi, Am Montag, den 09.12.2013, 09:24 +0100 schrieb Herbert Valerio Riedel: > What kind of links are you referring to btw? I don't see any clickable > GHC SHA1 ids these days anymore... :-) well, people do write SHA1 ids in tickets comments directly. (At least I do. And then I rebase my branch. And then the link is dead ;-)) But in contrast to the mailing list link issue, even if we rewrite the testsuite before merging, it will be possible, although a bit more tedious, to look up the corresponding new hash. It is hard to predict what is more common: Following SHA1-links from old (and in the future even older) tickets, or doing git archeology inside the repo. I guess both are relatively rare that we are risking to spend more time discussing it than we?d save otherwise... The only thing that will permanently hurt if we do not fix it now are the binary blobs. I do often make new checkouts (I still do separate feature branches in separate checkouts, plus validate trees, plus baseline trees to compare the effect of my changes). So I?m still in favor of rewriting the branch. We could even check in the ID?ID mapping in the repo and have a easy to discover ./testsuite/lookup-old-id script so that this is even less an annoyance. Greetings, Joachim PS: What happens if we set up replace objects in the git repo that cgit and trac are using: https://www.kernel.org/pub/software/scm/git/docs/git-replace.html Would that make the old links still work? -- Joachim ?nomeata? Breitner mail at joachim-breitner.de ? http://www.joachim-breitner.de/ Jabber: nomeata at joachim-breitner.de ? GPG-Key: 0x4743206C Debian Developer: nomeata at debian.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part URL: From ggreif at gmail.com Mon Dec 9 08:54:02 2013 From: ggreif at gmail.com (Gabor Greif) Date: Mon, 9 Dec 2013 09:54:02 +0100 Subject: Preparing for a review of pattern synonyms In-Reply-To: References: Message-ID: On 12/9/13, Dr. ERDI Gergo wrote: > Hi, Hi Gerg?, > > I believe I've finished implementing version 1 of pattern synonyms (i.e. > everything described in #5144, minus the things in #8581, #8582, #8583 and > #8584). I've discussed the way forward with SPJ and he suggested because > of the cross-cutting nature of the patch, I should wait a reasonably long > time (~1 month) after 7.8 is branched off for things to settle, and > then formally submit it for review. Geat to hear this. > > So my question is, is there anything I can do in the meantime, in > preparation for the review? The code is available at Does your implementation cover only H98 ADTs or do you support existentials/GADTs too? Cheers, Gabor > https://github.com/gergoerdi/ghc. I've also added some tests > to the testsuite (https://github.com/gergoerdi/ghc-testsuite), and > updated the wiki pages at > https://ghc.haskell.org/trac/ghc/wiki/PatternSynonyms and > https://ghc.haskell.org/trac/ghc/wiki/PatternSynonyms/Implementation. > > Thanks, > Gergo > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://www.haskell.org/mailman/listinfo/ghc-devs > From simonpj at microsoft.com Mon Dec 9 08:57:43 2013 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Mon, 9 Dec 2013 08:57:43 +0000 Subject: Preparing for a review of pattern synonyms In-Reply-To: References: Message-ID: <59543203684B2244980D7E4057D5FBC1486E6194@DB3EX14MBXC308.europe.corp.microsoft.com> Just to say that I'm very pleased by this work. Haskell can abstract over just about everything except patterns, and this feature fixes that embarrassing lack. I've discussed the implementation extensively with Gergo, and he's more-or-less rewritten it several times. It's quite pretty I think. Thanks too to Lennart for pressing for it. I believe the first impetus came at the Cambridge Haskell Hackathon. Simon | -----Original Message----- | From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of Dr. | ERDI Gergo | Sent: 09 December 2013 06:06 | To: GHC Devs | Subject: Preparing for a review of pattern synonyms | | Hi, | | I believe I've finished implementing version 1 of pattern synonyms (i.e. | everything described in #5144, minus the things in #8581, #8582, #8583 | and | #8584). I've discussed the way forward with SPJ and he suggested because | of the cross-cutting nature of the patch, I should wait a reasonably | long | time (~1 month) after 7.8 is branched off for things to settle, and | then formally submit it for review. | | So my question is, is there anything I can do in the meantime, in | preparation for the review? The code is available at | https://github.com/gergoerdi/ghc. I've also added some tests | to the testsuite (https://github.com/gergoerdi/ghc-testsuite), and | updated the wiki pages at | https://ghc.haskell.org/trac/ghc/wiki/PatternSynonyms and | https://ghc.haskell.org/trac/ghc/wiki/PatternSynonyms/Implementation. | | Thanks, | Gergo | | _______________________________________________ | ghc-devs mailing list | ghc-devs at haskell.org | http://www.haskell.org/mailman/listinfo/ghc-devs From simonpj at microsoft.com Mon Dec 9 08:58:35 2013 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Mon, 9 Dec 2013 08:58:35 +0000 Subject: Preparing for a review of pattern synonyms References: Message-ID: <59543203684B2244980D7E4057D5FBC1486E61B5@DB3EX14MBXC308.europe.corp.microsoft.com> PS: it was so obvious that I forgot to add: a major thank-you to Gergo, who did ALL the work. Simon | -----Original Message----- | From: Simon Peyton-Jones | Sent: 09 December 2013 08:58 | To: 'Dr. ERDI Gergo'; GHC Devs | Cc: Augustsson, Lennart | Subject: RE: Preparing for a review of pattern synonyms | | Just to say that I'm very pleased by this work. Haskell can abstract | over just about everything except patterns, and this feature fixes that | embarrassing lack. I've discussed the implementation extensively with | Gergo, and he's more-or-less rewritten it several times. It's quite | pretty I think. | | Thanks too to Lennart for pressing for it. I believe the first impetus | came at the Cambridge Haskell Hackathon. | | Simon | | | -----Original Message----- | | From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of Dr. | | ERDI Gergo | | Sent: 09 December 2013 06:06 | | To: GHC Devs | | Subject: Preparing for a review of pattern synonyms | | | | Hi, | | | | I believe I've finished implementing version 1 of pattern synonyms | (i.e. | | everything described in #5144, minus the things in #8581, #8582, #8583 | | and | | #8584). I've discussed the way forward with SPJ and he suggested | because | | of the cross-cutting nature of the patch, I should wait a reasonably | | long | | time (~1 month) after 7.8 is branched off for things to settle, and | | then formally submit it for review. | | | | So my question is, is there anything I can do in the meantime, in | | preparation for the review? The code is available at | | https://github.com/gergoerdi/ghc. I've also added some tests | | to the testsuite (https://github.com/gergoerdi/ghc-testsuite), and | | updated the wiki pages at | | https://ghc.haskell.org/trac/ghc/wiki/PatternSynonyms and | | https://ghc.haskell.org/trac/ghc/wiki/PatternSynonyms/Implementation. | | | | Thanks, | | Gergo | | | | _______________________________________________ | | ghc-devs mailing list | | ghc-devs at haskell.org | | http://www.haskell.org/mailman/listinfo/ghc-devs From hvriedel at gmail.com Mon Dec 9 09:04:38 2013 From: hvriedel at gmail.com (Herbert Valerio Riedel) Date: Mon, 09 Dec 2013 10:04:38 +0100 Subject: Repository Reorganization Question In-Reply-To: <1386578063.2480.8.camel@kirk> (Joachim Breitner's message of "Mon, 09 Dec 2013 08:34:23 +0000") References: <87d2lb4n6q.fsf@gmail.com> <878uvz4khf.fsf@gmail.com> <1386244615.2760.3.camel@kirk> <8738m74e5h.fsf@gnu.org> <87mwke9twu.fsf@gmail.com> <1386328029.2621.1.camel@kirk> <87fvq69nvd.fsf@gmail.com> <87bo0u9e8d.fsf@gmail.com> <52A57CC1.7080105@gmail.com> <87ppp6fn4b.fsf@gmail.com> <1386578063.2480.8.camel@kirk> Message-ID: <87haaifl95.fsf@gmail.com> On 2013-12-09 at 09:34:23 +0100, Joachim Breitner wrote: > Am Montag, den 09.12.2013, 09:24 +0100 schrieb Herbert Valerio Riedel: >> What kind of links are you referring to btw? I don't see any clickable >> GHC SHA1 ids these days anymore... :-) > > well, people do write SHA1 ids in tickets comments directly. (At least I > do. And then I rebase my branch. And then the link is dead ;-)) ...those links manually written into ticket comments will continue to work since they had to explicitly refer to the testsuite repo anyway (e.g. `[27c42f4022/testsuite]`) if they had any chance of working before, and even if we retain the old commit ids in ghc.git, those links would still point to the testsuite.git repo and not to ghc.git > But in contrast to the mailing list link issue, even if we rewrite the > testsuite before merging, it will be possible, although a bit more > tedious, to look up the corresponding new hash. What I don't understand yet is, why do we need to know the new hash ids at all? If we come across an old hash-id, aren't we just interested in finding the commitdiff (and possibly neighbor commits) it refers to? [...] > We could even check in the ID?ID mapping in the repo and have a easy to > discover ./testsuite/lookup-old-id script so that this is even less an > annoyance. > PS: What happens if we set up replace objects in the git repo that > cgit and trac are using: > https://www.kernel.org/pub/software/scm/git/docs/git-replace.html > Would that make the old links still work? That feature sounds *very* interesting to our problem at hand as it effectively allows to hide the real new SHA1 ids for the over 6000 "historic" testsuite commits (or put differently, it allows use to embed the oldid-newid mapping at the Git meta-data level); I'll experiment with 'git replace' to see if it could really work in our use-case. Cheers, hvr From mail at joachim-breitner.de Mon Dec 9 09:15:25 2013 From: mail at joachim-breitner.de (Joachim Breitner) Date: Mon, 09 Dec 2013 09:15:25 +0000 Subject: Repository Reorganization Question In-Reply-To: <87haaifl95.fsf@gmail.com> References: <87d2lb4n6q.fsf@gmail.com> <878uvz4khf.fsf@gmail.com> <1386244615.2760.3.camel@kirk> <8738m74e5h.fsf@gnu.org> <87mwke9twu.fsf@gmail.com> <1386328029.2621.1.camel@kirk> <87fvq69nvd.fsf@gmail.com> <87bo0u9e8d.fsf@gmail.com> <52A57CC1.7080105@gmail.com> <87ppp6fn4b.fsf@gmail.com> <1386578063.2480.8.camel@kirk> <87haaifl95.fsf@gmail.com> Message-ID: <1386580525.2480.10.camel@kirk> Hi, Am Montag, den 09.12.2013, 10:04 +0100 schrieb Herbert Valerio Riedel: > > But in contrast to the mailing list link issue, even if we rewrite the > > testsuite before merging, it will be possible, although a bit more > > tedious, to look up the corresponding new hash. > > What I don't understand yet is, why do we need to know the new hash ids > at all? If we come across an old hash-id, aren't we just interested in > finding the commitdiff (and possibly neighbor commits) it refers to? good point, I did not think of that. So if trac links are preserved anyways, doesn?t that then solve the problem? Greetings, Joachim -- Joachim ?nomeata? Breitner mail at joachim-breitner.de ? http://www.joachim-breitner.de/ Jabber: nomeata at joachim-breitner.de ? GPG-Key: 0x4743206C Debian Developer: nomeata at debian.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part URL: From marlowsd at gmail.com Mon Dec 9 09:23:10 2013 From: marlowsd at gmail.com (Simon Marlow) Date: Mon, 09 Dec 2013 09:23:10 +0000 Subject: Repository Reorganization Question In-Reply-To: <87ppp6fn4b.fsf@gmail.com> References: <87d2lb4n6q.fsf@gmail.com> <878uvz4khf.fsf@gmail.com> <1386244615.2760.3.camel@kirk> <8738m74e5h.fsf@gnu.org> <87mwke9twu.fsf@gmail.com> <1386328029.2621.1.camel@kirk> <87fvq69nvd.fsf@gmail.com> <87bo0u9e8d.fsf@gmail.com> <52A57CC1.7080105@gmail.com> <87ppp6fn4b.fsf@gmail.com> Message-ID: <52A58BFE.809@gmail.com> On 09/12/2013 08:24, Herbert Valerio Riedel wrote: > On 2013-12-09 at 09:18:09 +0100, Simon Marlow wrote: > > [...] > >>> ...as I hinted at in an earlier post, the old commit-ids will still >>> allow to find the original commit; for isntance, there's already the >>> find-commit-by-sha1 service at >>> >>> http://git.haskell.org/.findhash/ >>> >>> which searches all repos hosted at git.haskell.org for the given sha1 >>> prefix; there's also a convenient text-entry field at >>> http://git.haskell.org/ which allows you to copy'n'paste any commit-ids >>> you might come across in emails, irc logs, trac comments or even commit >>> messages... >>> >>> ...does this lookup-service alleviate your concerns? >> >> No :-) To be honest I would probably just paste the SHA1 into Google >> and find it that way, which would probably work. But it's *far* >> better if the links just work. > > What kind of links are you referring to btw? I don't see any clickable > GHC SHA1 ids these days anymore... :-) I'm confused. We definitely do have clickable commit links, inserted automatically by the post-commit hook, e.g.: https://ghc.haskell.org/trac/ghc/ticket/8577#comment:21 Those links would break if the hashes change, right? Cheers, Simon From mail at joachim-breitner.de Mon Dec 9 09:28:00 2013 From: mail at joachim-breitner.de (Joachim Breitner) Date: Mon, 09 Dec 2013 09:28:00 +0000 Subject: Repository Reorganization Question In-Reply-To: <52A58BFE.809@gmail.com> References: <87d2lb4n6q.fsf@gmail.com> <878uvz4khf.fsf@gmail.com> <1386244615.2760.3.camel@kirk> <8738m74e5h.fsf@gnu.org> <87mwke9twu.fsf@gmail.com> <1386328029.2621.1.camel@kirk> <87fvq69nvd.fsf@gmail.com> <87bo0u9e8d.fsf@gmail.com> <52A57CC1.7080105@gmail.com> <87ppp6fn4b.fsf@gmail.com> <52A58BFE.809@gmail.com> Message-ID: <1386581280.2480.13.camel@kirk> Hi, Am Montag, den 09.12.2013, 09:23 +0000 schrieb Simon Marlow: > I'm confused. We definitely do have clickable commit links, inserted > automatically by the post-commit hook, e.g.: > > https://ghc.haskell.org/trac/ghc/ticket/8577#comment:21 > > Those links would break if the hashes change, right? but, as Herbert pointed out, these links point to the testsuite repository explicitly (deadbeef/testsuite). If there did not do that, they would be dead already (e.g. if someone would write them manually and not paying attention to that). And since they are qualified by the repository they point to, they will continue to point to the (then uncontinued, but unmodified) testsuite repository. Which is ? I believe ? sufficient to make sense out of old tickets. The links to the ghc repository are of course unchanged, there is no plan to rewrite history here. Greetings, Joachim -- Joachim ?nomeata? Breitner mail at joachim-breitner.de ? http://www.joachim-breitner.de/ Jabber: nomeata at joachim-breitner.de ? GPG-Key: 0x4743206C Debian Developer: nomeata at debian.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part URL: From marlowsd at gmail.com Mon Dec 9 10:28:58 2013 From: marlowsd at gmail.com (Simon Marlow) Date: Mon, 09 Dec 2013 10:28:58 +0000 Subject: Repository Reorganization Question In-Reply-To: <1386581280.2480.13.camel@kirk> References: <87d2lb4n6q.fsf@gmail.com> <878uvz4khf.fsf@gmail.com> <1386244615.2760.3.camel@kirk> <8738m74e5h.fsf@gnu.org> <87mwke9twu.fsf@gmail.com> <1386328029.2621.1.camel@kirk> <87fvq69nvd.fsf@gmail.com> <87bo0u9e8d.fsf@gmail.com> <52A57CC1.7080105@gmail.com> <87ppp6fn4b.fsf@gmail.com> <52A58BFE.809@gmail.com> <1386581280.2480.13.camel@kirk> Message-ID: <52A59B6A.1020401@gmail.com> On 09/12/2013 09:28, Joachim Breitner wrote: > Hi, > > Am Montag, den 09.12.2013, 09:23 +0000 schrieb Simon Marlow: >> I'm confused. We definitely do have clickable commit links, inserted >> automatically by the post-commit hook, e.g.: >> >> https://ghc.haskell.org/trac/ghc/ticket/8577#comment:21 >> >> Those links would break if the hashes change, right? > > but, as Herbert pointed out, these links point to the testsuite > repository explicitly (deadbeef/testsuite). If there did not do that, > they would be dead already (e.g. if someone would write them manually > and not paying attention to that). > > And since they are qualified by the repository they point to, they will > continue to point to the (then uncontinued, but unmodified) testsuite > repository. Which is ? I believe ? sufficient to make sense out of old > tickets. > > The links to the ghc repository are of course unchanged, there is no > plan to rewrite history here. Ah yes, I see. That's fine then. Cheers, Simon From marlowsd at gmail.com Mon Dec 9 11:34:43 2013 From: marlowsd at gmail.com (Simon Marlow) Date: Mon, 09 Dec 2013 11:34:43 +0000 Subject: Preparing for a review of pattern synonyms In-Reply-To: <59543203684B2244980D7E4057D5FBC1486E61B5@DB3EX14MBXC308.europe.corp.microsoft.com> References: <59543203684B2244980D7E4057D5FBC1486E61B5@DB3EX14MBXC308.europe.corp.microsoft.com> Message-ID: <52A5AAD3.1020200@gmail.com> I think pattern synonyms are great! A couple of questions: * what will Haddock show for a pattern export? * can we still write pattern matches that GHC can infer to be exhaustive when using pattern synonyms? Are we not doing ViewPatternsAlternative any more? https://ghc.haskell.org/trac/ghc/wiki/ViewPatternsAlternative Or is that just being treated as an orthogonal issue? I rather like that proposal, and we originally discussed it in conjunction with pattern synonyms. Cheers, Simon On 09/12/2013 08:58, Simon Peyton-Jones wrote: > PS: it was so obvious that I forgot to add: a major thank-you to Gergo, who did ALL the work. > > Simon > > | -----Original Message----- > | From: Simon Peyton-Jones > | Sent: 09 December 2013 08:58 > | To: 'Dr. ERDI Gergo'; GHC Devs > | Cc: Augustsson, Lennart > | Subject: RE: Preparing for a review of pattern synonyms > | > | Just to say that I'm very pleased by this work. Haskell can abstract > | over just about everything except patterns, and this feature fixes that > | embarrassing lack. I've discussed the implementation extensively with > | Gergo, and he's more-or-less rewritten it several times. It's quite > | pretty I think. > | > | Thanks too to Lennart for pressing for it. I believe the first impetus > | came at the Cambridge Haskell Hackathon. > | > | Simon > | > | | -----Original Message----- > | | From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of Dr. > | | ERDI Gergo > | | Sent: 09 December 2013 06:06 > | | To: GHC Devs > | | Subject: Preparing for a review of pattern synonyms > | | > | | Hi, > | | > | | I believe I've finished implementing version 1 of pattern synonyms > | (i.e. > | | everything described in #5144, minus the things in #8581, #8582, #8583 > | | and > | | #8584). I've discussed the way forward with SPJ and he suggested > | because > | | of the cross-cutting nature of the patch, I should wait a reasonably > | | long > | | time (~1 month) after 7.8 is branched off for things to settle, and > | | then formally submit it for review. > | | > | | So my question is, is there anything I can do in the meantime, in > | | preparation for the review? The code is available at > | | https://github.com/gergoerdi/ghc. I've also added some tests > | | to the testsuite (https://github.com/gergoerdi/ghc-testsuite), and > | | updated the wiki pages at > | | https://ghc.haskell.org/trac/ghc/wiki/PatternSynonyms and > | | https://ghc.haskell.org/trac/ghc/wiki/PatternSynonyms/Implementation. > | | > | | Thanks, > | | Gergo > | | > | | _______________________________________________ > | | ghc-devs mailing list > | | ghc-devs at haskell.org > | | http://www.haskell.org/mailman/listinfo/ghc-devs > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://www.haskell.org/mailman/listinfo/ghc-devs > From austin at well-typed.com Mon Dec 9 12:31:15 2013 From: austin at well-typed.com (Austin Seipp) Date: Mon, 9 Dec 2013 06:31:15 -0600 Subject: Repository Reorganization Question In-Reply-To: <52A59B6A.1020401@gmail.com> References: <87d2lb4n6q.fsf@gmail.com> <878uvz4khf.fsf@gmail.com> <1386244615.2760.3.camel@kirk> <8738m74e5h.fsf@gnu.org> <87mwke9twu.fsf@gmail.com> <1386328029.2621.1.camel@kirk> <87fvq69nvd.fsf@gmail.com> <87bo0u9e8d.fsf@gmail.com> <52A57CC1.7080105@gmail.com> <87ppp6fn4b.fsf@gmail.com> <52A58BFE.809@gmail.com> <1386581280.2480.13.camel@kirk> <52A59B6A.1020401@gmail.com> Message-ID: Hi all, It seems that while most people are in favor of migrating and preserving the history there are a few sticky bits concerning some of the minor details. So I think the discussion should continue, but we clearly shouldn't pull the trigger quite yet. testsuite etc will live on for a while longer. In the mean time, maintaining a branch is relatively minimal cost, so whatever solution we come up with won't hurt too badly in the mean time. On Mon, Dec 9, 2013 at 4:28 AM, Simon Marlow wrote: > On 09/12/2013 09:28, Joachim Breitner wrote: >> >> Hi, >> >> Am Montag, den 09.12.2013, 09:23 +0000 schrieb Simon Marlow: >>> >>> I'm confused. We definitely do have clickable commit links, inserted >>> automatically by the post-commit hook, e.g.: >>> >>> https://ghc.haskell.org/trac/ghc/ticket/8577#comment:21 >>> >>> Those links would break if the hashes change, right? >> >> >> but, as Herbert pointed out, these links point to the testsuite >> repository explicitly (deadbeef/testsuite). If there did not do that, >> they would be dead already (e.g. if someone would write them manually >> and not paying attention to that). >> >> And since they are qualified by the repository they point to, they will >> continue to point to the (then uncontinued, but unmodified) testsuite >> repository. Which is ? I believe ? sufficient to make sense out of old >> tickets. >> >> The links to the ghc repository are of course unchanged, there is no >> plan to rewrite history here. > > > Ah yes, I see. That's fine then. > > > Cheers, > Simon > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://www.haskell.org/mailman/listinfo/ghc-devs > -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ From austin at well-typed.com Mon Dec 9 13:13:54 2013 From: austin at well-typed.com (Austin Seipp) Date: Mon, 9 Dec 2013 07:13:54 -0600 Subject: Better GHC builds for Windows users Message-ID: Hello all, After fiddling around this weekend I've written a quick, comprehensive guide to a Better Build Environment for windows users. It pretty much "Just works" and I think should make it easy to get started with new machines: https://ghc.haskell.org/trac/ghc/wiki/Building/Preparation/Windows/MSYS2 Many thanks to Kyra for pointing this out to us on the GHC developer list. It is a much nicer to use mingw/msys environment with a lot of bugs fixed, and it's easy to install. Following the instructions should mostly be copy-paste. In particular, this resolves some weird issues with `validate` and traditional `make`, including a horrible deadlocking bug with make (and also 'tee', it seems.) So windows users can build in parallel again and everything works as expected. It also gives a simple and complete guide to build for x86_64 users (we didn't really mention it previously.) Please shout if you have problems. I've tested this with both an x86 and x86_64 build. -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ From gergo at erdi.hu Mon Dec 9 13:26:00 2013 From: gergo at erdi.hu (Dr. ERDI Gergo) Date: Mon, 9 Dec 2013 21:26:00 +0800 (SGT) Subject: Preparing for a review of pattern synonyms In-Reply-To: References: Message-ID: On Mon, 9 Dec 2013, Gabor Greif wrote: >> So my question is, is there anything I can do in the meantime, in >> preparation for the review? The code is available at > > Does your implementation cover only H98 ADTs or do you support > existentials/GADTs too? Yes, it has full support for GHC's type system extensions. -- .--= ULLA! =-----------------. \ http://gergo.erdi.hu \ `---= gergo at erdi.hu =-------' If I drive fast enough at the red light, it'll appear green. From gergo at erdi.hu Mon Dec 9 13:31:35 2013 From: gergo at erdi.hu (Dr. ERDI Gergo) Date: Mon, 9 Dec 2013 21:31:35 +0800 (SGT) Subject: Preparing for a review of pattern synonyms In-Reply-To: <52A5AAD3.1020200@gmail.com> References: <59543203684B2244980D7E4057D5FBC1486E61B5@DB3EX14MBXC308.europe.corp.microsoft.com> <52A5AAD3.1020200@gmail.com> Message-ID: Hi Simon, On Mon, 9 Dec 2013, Simon Marlow wrote: > I think pattern synonyms are great! A couple of questions: > > * what will Haddock show for a pattern export? Is Haddock a part of GHC? I don't know. If it's not, then whatever parser it's using will have to be extended to support pattern synonyms. > * can we still write pattern matches that GHC can infer > to be exhaustive when using pattern synonyms? No. I don't see how that would be possible without having access to the pattern synonym definition when typechecking/compiling a use site. One deliberate design decision was to make pattern synonyms proper abstractions, in the sense that compiling use sites shouldn't require access to its definition details. > Are we not doing ViewPatternsAlternative any more? > https://ghc.haskell.org/trac/ghc/wiki/ViewPatternsAlternative > Or is that just being treated as an orthogonal issue? I rather like that > proposal, and we originally discussed it in conjunction with pattern > synonyms. It should be treated as orthogonal -- if and when GHC gets support for it, they will be available in PatternSynonyms as well. If there's no separate Trac ticket for ViewPatternsAlternative yet, I'm happy to open one. Bye, Gergo -- .--= ULLA! =-----------------. \ http://gergo.erdi.hu \ `---= gergo at erdi.hu =-------' I'm sure the pension plan includes all the starvation I can eat. From marlowsd at gmail.com Mon Dec 9 14:29:59 2013 From: marlowsd at gmail.com (Simon Marlow) Date: Mon, 09 Dec 2013 14:29:59 +0000 Subject: Preparing for a review of pattern synonyms In-Reply-To: References: <59543203684B2244980D7E4057D5FBC1486E61B5@DB3EX14MBXC308.europe.corp.microsoft.com> <52A5AAD3.1020200@gmail.com> Message-ID: <52A5D3E7.4030802@gmail.com> On 09/12/2013 13:31, Dr. ERDI Gergo wrote: > Hi Simon, > > On Mon, 9 Dec 2013, Simon Marlow wrote: > >> I think pattern synonyms are great! A couple of questions: >> >> * what will Haddock show for a pattern export? > > Is Haddock a part of GHC? I don't know. If it's not, then whatever > parser it's using will have to be extended to support pattern synonyms. Haddock uses GHC's parser, but it will need to be taught about pattern synonyms and how to render them in documentation. >> * can we still write pattern matches that GHC can infer >> to be exhaustive when using pattern synonyms? > > No. I don't see how that would be possible without having access to the > pattern synonym definition when typechecking/compiling a use site. One > deliberate design decision was to make pattern synonyms proper > abstractions, in the sense that compiling use sites shouldn't require > access to its definition details. Right, I'm not suggesting that we should break the abstraction, but I think it would be really nice if there was a way to say "the following 3 patterns are exhaustive", perhaps in a pragma. One of the things that we ought to be able to do with this extension is to provide abstract datatypes with pattern matching support. The only thing missing is support for exhaustive pattern matches. F# active patterns has it! >> Are we not doing ViewPatternsAlternative any more? >> https://ghc.haskell.org/trac/ghc/wiki/ViewPatternsAlternative >> Or is that just being treated as an orthogonal issue? I rather like >> that proposal, and we originally discussed it in conjunction with >> pattern synonyms. > > It should be treated as orthogonal -- if and when GHC gets support for > it, they will be available in PatternSynonyms as well. > > If there's no separate Trac ticket for ViewPatternsAlternative yet, I'm > happy to open one. That would be great! Cheers, Simon From simonpj at microsoft.com Mon Dec 9 14:35:41 2013 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Mon, 9 Dec 2013 14:35:41 +0000 Subject: Preparing for a review of pattern synonyms In-Reply-To: <52A5D3E7.4030802@gmail.com> References: <59543203684B2244980D7E4057D5FBC1486E61B5@DB3EX14MBXC308.europe.corp.microsoft.com> <52A5AAD3.1020200@gmail.com> <52A5D3E7.4030802@gmail.com> Message-ID: <59543203684B2244980D7E4057D5FBC1486E697F@DB3EX14MBXC308.europe.corp.microsoft.com> | > Is Haddock a part of GHC? I don't know. If it's not, then whatever | > parser it's using will have to be extended to support pattern | synonyms. | | Haddock uses GHC's parser, but it will need to be taught about pattern | synonyms and how to render them in documentation. Yes, it's in utils/haddock in the main tree, and that really does need to be done before release. | One of the things that we ought to be able to do with this extension is | to provide abstract datatypes with pattern matching support. The only | thing missing is support for exhaustive pattern matches. F# active | patterns has it! We already lack exhaustiveness support as soon as we have guards or view patterns. But it seems a bit more feasible with pattern synonyms. Something to add to the "missing features" list! Simon From ker0sin at yandex.ru Mon Dec 9 22:21:48 2013 From: ker0sin at yandex.ru (Alexander Pakhomov) Date: Tue, 10 Dec 2013 02:21:48 +0400 Subject: benchmarks Message-ID: <286541386627708@web16j.yandex.ru> Hi. Do you do performance testing? I would be interested in statistics by release. I worked at optimizing compiler at my previous job and we had quite huge amount of performance tests for each commit. When something slowed down we fixed it. It is strange but most of times we found and fixed slowdown. From mail at joachim-breitner.de Mon Dec 9 22:54:12 2013 From: mail at joachim-breitner.de (Joachim Breitner) Date: Mon, 09 Dec 2013 22:54:12 +0000 Subject: benchmarks In-Reply-To: <286541386627708@web16j.yandex.ru> References: <286541386627708@web16j.yandex.ru> Message-ID: <1386629652.31873.6.camel@kirk> Hi, Am Dienstag, den 10.12.2013, 02:21 +0400 schrieb Alexander Pakhomov: > Hi. > Do you do performance testing? > I would be interested in statistics by release. > I worked at optimizing compiler at my previous job and we had quite huge amount of performance tests for each commit. When something slowed down we fixed it. It is strange but most of times we found and fixed slowdown. we have a benchmark suite called nofib, see https://ghc.haskell.org/trac/ghc/wiki/Building/RunningNoFib and http://git.haskell.org/?p=nofib.git Unfortunately, we do not run it automatically for each commit, and this is unfortunate. In fact, I do spend a relevant fraction of my GHC hacking time starting nofib runs, manually comparing the results etc. But of course only when I expect a change (or expect that made a change that I did not want to do) and more automation would help here. But automatically running the test suite is more urgent, I?d say :-) Greetings, Joachim -- Joachim ?nomeata? Breitner mail at joachim-breitner.de ? http://www.joachim-breitner.de/ Jabber: nomeata at joachim-breitner.de ? GPG-Key: 0x4743206C Debian Developer: nomeata at debian.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part URL: From ker0sin at yandex.ru Tue Dec 10 00:35:03 2013 From: ker0sin at yandex.ru (Alexander Pakhomov) Date: Tue, 10 Dec 2013 04:35:03 +0400 Subject: HeapStackCheck.cmm Message-ID: <182701386635703@web5j.yandex.ru> Hi. Trying to compile ghc HEAD on OpenBSD I got an error: rts/HeapStackCheck.cmm:97:18: parse error on input `[' The code is following: 96 if (HpAlloc <= BLOCK_SIZE 97 && bdescr_link(CurrentNursery) != NULL) { which preprocesses to: if (HpAlloc <= (1<<12) && b0[CurrentNursery+15] != (0::bits64)) { This is the first occurrence of b0 in preprocessed file. I believe that it is due to undefined b0. Command that fails is: "inplace/bin/ghc-stage1" -static -H32m -O -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/HeapStackCheck.cmm -o rts/dist/build/HeapStackCheck.o To preprocess do the following: cpp -O -Iincludes -Iincludes/dist -Iincludes/dist-derivedconstants/header -Iincludes/dist-ghcconstants/header -Irts -Irts/dist/build -DCOMPILING_RTS -Irts/dist/build -Irts/dist/build/autogen rts/HeapStackCheck.cmm | less Can you please find source of b0 in preprocessed file? From simonpj at microsoft.com Tue Dec 10 08:46:20 2013 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Tue, 10 Dec 2013 08:46:20 +0000 Subject: benchmarks In-Reply-To: <286541386627708@web16j.yandex.ru> References: <286541386627708@web16j.yandex.ru> Message-ID: <59543203684B2244980D7E4057D5FBC1486E8129@DB3EX14MBXC308.europe.corp.microsoft.com> Alexander: we have two Performance Tsars, namely Johan Tibell and Bryan O'Sullivan. Their mission is to watch GHC's performance (both as a compiler and the code it produces) like a hawk, encourage it to get better, and yell if it gets worse. But they are busy men. I'm sure they would welcome help from you. Right Bryan, Johan? Simon | -----Original Message----- | From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of | Alexander Pakhomov | Sent: 09 December 2013 22:22 | To: ghc-devs at haskell.org | Subject: benchmarks | | Hi. | Do you do performance testing? | I would be interested in statistics by release. | I worked at optimizing compiler at my previous job and we had quite huge | amount of performance tests for each commit. When something slowed down | we fixed it. It is strange but most of times we found and fixed | slowdown. | _______________________________________________ | ghc-devs mailing list | ghc-devs at haskell.org | http://www.haskell.org/mailman/listinfo/ghc-devs From hvr at gnu.org Tue Dec 10 09:34:16 2013 From: hvr at gnu.org (Herbert Valerio Riedel) Date: Tue, 10 Dec 2013 10:34:16 +0100 Subject: Please help complete `.mailmap` Message-ID: <87vbyx59t3.fsf@gnu.org> Hello *, I've been trying to (re)construct a .mailmap file[1] in ghc.git which allows `git shortlog` and `git log --use-mailmap` (and possibly other tools/commands) to fixup bogus author-ids when displaying the Git history, in the hopes to provide a more complete history of GHC and all contributors involved. I've been able to infer mappings for most users, but I'm stuck on a couple of older account usernames dating back a decade ago for which I have no idea what real names to associate with. These are specifically: $ git shortlog -es | grep unknown 16 apt 1 cryder 13 desrt 8 dnt 1 geoffw 12 gla 3 josefs 5 krc 1 kw 5 kw217 1 mbs 1 moran 3 njn 8 ralf 11 rje 1 sseefried 1 tgedell 1 uid245 1 umuta 1 y.zhuang5 at lse.ac.uk If you happen to know who these past contributors are, please either tell me or update [1] accordingly. Moreover, if you stumble over any wrong entry in [1], feel free to correct it. Thanks, hvr [1] http://git.haskell.org/ghc.git/blob/HEAD:/.mailmap PS: If anyone's curious, the top-5 committers in ghc.git are currently: $ git shortlog -sn | head -n5 8513 Simon Marlow 5368 Simon Peyton Jones 4629 Ian Lynagh 2633 Sigbjorn Finne 941 Julian Seward From simonpj at microsoft.com Tue Dec 10 09:46:57 2013 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Tue, 10 Dec 2013 09:46:57 +0000 Subject: Please help complete `.mailmap` In-Reply-To: <87vbyx59t3.fsf@gnu.org> References: <87vbyx59t3.fsf@gnu.org> Message-ID: <59543203684B2244980D7E4057D5FBC1486E82F1@DB3EX14MBXC308.europe.corp.microsoft.com> apt: Andrew Tolmach josefs: Josef Svenningsson kw, kw217: Keith Wansbrough Simon | -----Original Message----- | From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of | Herbert Valerio Riedel | Sent: 10 December 2013 09:34 | To: ghc-devs | Subject: Please help complete `.mailmap` | | Hello *, | | I've been trying to (re)construct a .mailmap file[1] in ghc.git which | allows `git shortlog` and `git log --use-mailmap` (and possibly other | tools/commands) to fixup bogus author-ids when displaying the Git | history, in the hopes to provide a more complete history of GHC and all | contributors involved. | | I've been able to infer mappings for most users, but I'm stuck on a | couple of older account usernames dating back a decade ago for which I | have no idea what real names to associate with. These are specifically: | | $ git shortlog -es | grep unknown | 16 apt | 1 cryder | 13 desrt | 8 dnt | 1 geoffw | 12 gla | 3 josefs | 5 krc | 1 kw | 5 kw217 | 1 mbs | 1 moran | 3 njn | 8 ralf | 11 rje | 1 sseefried | 1 tgedell | 1 uid245 | 1 umuta | 1 y.zhuang5 at lse.ac.uk | | If you happen to know who these past contributors are, please either | tell me or update [1] accordingly. Moreover, if you stumble over any | wrong entry in [1], feel free to correct it. | | | Thanks, | hvr | | [1] http://git.haskell.org/ghc.git/blob/HEAD:/.mailmap | | | PS: If anyone's curious, the top-5 committers in ghc.git are currently: | | $ git shortlog -sn | head -n5 | 8513 Simon Marlow | 5368 Simon Peyton Jones | 4629 Ian Lynagh | 2633 Sigbjorn Finne | 941 Julian Seward | _______________________________________________ | ghc-devs mailing list | ghc-devs at haskell.org | http://www.haskell.org/mailman/listinfo/ghc-devs From hvr at gnu.org Tue Dec 10 10:33:29 2013 From: hvr at gnu.org (Herbert Valerio Riedel) Date: Tue, 10 Dec 2013 11:33:29 +0100 Subject: Repository Reorganization Question In-Reply-To: (Austin Seipp's message of "Mon, 9 Dec 2013 06:31:15 -0600") References: <87d2lb4n6q.fsf@gmail.com> <878uvz4khf.fsf@gmail.com> <1386244615.2760.3.camel@kirk> <8738m74e5h.fsf@gnu.org> <87mwke9twu.fsf@gmail.com> <1386328029.2621.1.camel@kirk> <87fvq69nvd.fsf@gmail.com> <87bo0u9e8d.fsf@gmail.com> <52A57CC1.7080105@gmail.com> <87ppp6fn4b.fsf@gmail.com> <52A58BFE.809@gmail.com> <1386581280.2480.13.camel@kirk> <52A59B6A.1020401@gmail.com> Message-ID: <87ppp5572e.fsf@gmail.com> On 2013-12-09 at 13:31:15 +0100, Austin Seipp wrote: > It seems that while most people are in favor of migrating and > preserving the history there are a few sticky bits concerning some of > the minor details. So I think the discussion should continue, but we > clearly shouldn't pull the trigger quite yet. testsuite etc will live > on for a while longer. In the mean time I've updated the branch http://git.haskell.org/ghc.git/log/refs/heads/wip/T8545 to include the full testsuite.git history, with the history rewritten as if the files have been always in the 'testsuite/' folder, and with the blobs removed; moreover I've tweaked the sync-all script to check for a left-over testsuite/.git folder, to remind users to move it out of the way. Thus, with the current state of the T8545 branch, - `git blame testsuite/tests/typecheck/should_compile/all.T` works as expected - `git log testsuite/` as well as `cd testsuite/ && git log .` works as expected - The cleaned-from-large-blob testsuite.git history adds only about 10MiB packed transfer size (as opposed to the full ~30MiB it would require if the blobs weren't removed) - The historic/original testsuite.git commit hash ids are not retained in ghc.git, as they continue to exist in the "legacy" testsuite.git (where all current Trac hyperlinks will continue to refer to anyway)[1]; - When peferming a `sync-all pull` (with the old `sync-all` script) developers will get the new ghc.git-tracked `testsuite/` folder and on the next `sync-all` invocation (which will use the updated sync-all script for the first time) they'll be reminded/forced to move away a possibly left-over `testsuite/.git` folder. - At some point after the switch, `testsuite.git` should be set read-only (for the `master` branch at least). So, what are the current sticky bits left over given the proof-of-concept in wip/T8545 that still need to be addressed? [1] If we really need this for our development workflows, we could still attempt to make use of the `git replace` facility in the future to overlay the old commit ids. But if we don't need it (and from the discussion so far I don't see a requirement for that), it's better to keep it simple. From gergo at erdi.hu Tue Dec 10 12:11:14 2013 From: gergo at erdi.hu (Dr. ERDI Gergo) Date: Tue, 10 Dec 2013 20:11:14 +0800 (SGT) Subject: Preparing for a review of pattern synonyms In-Reply-To: <52A5D3E7.4030802@gmail.com> References: <59543203684B2244980D7E4057D5FBC1486E61B5@DB3EX14MBXC308.europe.corp.microsoft.com> <52A5AAD3.1020200@gmail.com> <52A5D3E7.4030802@gmail.com> Message-ID: On Mon, 9 Dec 2013, Simon Marlow wrote: >> Is Haddock a part of GHC? I don't know. If it's not, then whatever >> parser it's using will have to be extended to support pattern synonyms. > > Haddock uses GHC's parser, but it will need to be taught about pattern > synonyms and how to render them in documentation. OK, I'll add pattern synonym support for Haddock. We don't really have a surface syntax for pattern types (yet?), so for now I'll just use this format: pattern P :: b -> a -> T a; requires (Num a); provides (Eq b) > Right, I'm not suggesting that we should break the abstraction, but I think > it would be really nice if there was a way to say "the following 3 patterns > are exhaustive", perhaps in a pragma. > > One of the things that we ought to be able to do with this extension is to > provide abstract datatypes with pattern matching support. The only thing > missing is support for exhaustive pattern matches. F# active patterns has > it! This should be something orthogonal to pattern synonyms that supports regular view patterns as well. >> If there's no separate Trac ticket for ViewPatternsAlternative yet, I'm >> happy to open one. > > That would be great! I've added it as #8605. Bye, Gergo -- .--= ULLA! =-----------------. \ http://gergo.erdi.hu \ `---= gergo at erdi.hu =-------' ?lni tudn?k egy Nobel-b?ked?j?rt. From gergo at erdi.hu Tue Dec 10 14:24:33 2013 From: gergo at erdi.hu (Dr. ERDI Gergo) Date: Tue, 10 Dec 2013 22:24:33 +0800 (SGT) Subject: Building Haddock in GHC source tree (Re: Preparing for a review of pattern synonyms) In-Reply-To: References: <59543203684B2244980D7E4057D5FBC1486E61B5@DB3EX14MBXC308.europe.corp.microsoft.com> <52A5AAD3.1020200@gmail.com> <52A5D3E7.4030802@gmail.com> Message-ID: On Tue, 10 Dec 2013, Dr. ERDI Gergo wrote: > OK, I'll add pattern synonym support for Haddock. Ummm..., so how do I build the version of Haddock included in the GHC source tree under utils? I tried just $ cd utils/haddock $ make but that fails with ===--- building final phase make -r --no-print-directory -f ghc.mk phase=final all_utils/haddock make[2]: *** No rule to make target `all_utils/haddock'. Stop. make[1]: *** [all_utils/haddock] Error 2 make[1]: Leaving directory `/home/cactus/prog/haskell/ghc/ghc' From marlowsd at gmail.com Tue Dec 10 14:46:38 2013 From: marlowsd at gmail.com (Simon Marlow) Date: Tue, 10 Dec 2013 14:46:38 +0000 Subject: Preparing for a review of pattern synonyms In-Reply-To: References: <59543203684B2244980D7E4057D5FBC1486E61B5@DB3EX14MBXC308.europe.corp.microsoft.com> <52A5AAD3.1020200@gmail.com> <52A5D3E7.4030802@gmail.com> Message-ID: <52A7294E.9080803@gmail.com> On 10/12/2013 12:11, Dr. ERDI Gergo wrote: > On Mon, 9 Dec 2013, Simon Marlow wrote: > >>> Is Haddock a part of GHC? I don't know. If it's not, then whatever >>> parser it's using will have to be extended to support pattern synonyms. >> >> Haddock uses GHC's parser, but it will need to be taught about pattern >> synonyms and how to render them in documentation. > > OK, I'll add pattern synonym support for Haddock. We don't really have a > surface syntax for pattern types (yet?), so for now I'll just use this > format: > > pattern P :: b -> a -> T a; requires (Num a); provides (Eq b) > >> Right, I'm not suggesting that we should break the abstraction, but I >> think it would be really nice if there was a way to say "the following >> 3 patterns are exhaustive", perhaps in a pragma. >> >> One of the things that we ought to be able to do with this extension >> is to provide abstract datatypes with pattern matching support. The >> only thing missing is support for exhaustive pattern matches. F# >> active patterns has it! > > This should be something orthogonal to pattern synonyms that supports > regular view patterns as well. I disagree - dealing with this in the context of pattern synonyms is much easier. You just need some way to declare a set of pattern synonym constructors that together constitute an exhaustive set. There's no good way to "name" a view pattern for this purpose. Besides, I think that once pattern synonyms are in, the main use case for view patterns will be in defining interesting pattern synonyms. And I'd rather use ViewPatternsAlternative for that purpose, because it's a more natural generalisation of pattern guards. Cheers, Simon From marlowsd at gmail.com Tue Dec 10 14:47:27 2013 From: marlowsd at gmail.com (Simon Marlow) Date: Tue, 10 Dec 2013 14:47:27 +0000 Subject: Building Haddock in GHC source tree (Re: Preparing for a review of pattern synonyms) In-Reply-To: References: <59543203684B2244980D7E4057D5FBC1486E61B5@DB3EX14MBXC308.europe.corp.microsoft.com> <52A5AAD3.1020200@gmail.com> <52A5D3E7.4030802@gmail.com> Message-ID: <52A7297F.6040900@gmail.com> Do you have HADDOCK_DOCS = NO in your mk/build.mk? On 10/12/2013 14:24, Dr. ERDI Gergo wrote: > On Tue, 10 Dec 2013, Dr. ERDI Gergo wrote: > >> OK, I'll add pattern synonym support for Haddock. > > Ummm..., so how do I build the version of Haddock included in the GHC > source tree under utils? I tried just > > $ cd utils/haddock > $ make > > but that fails with > > ===--- building final phase > make -r --no-print-directory -f ghc.mk phase=final all_utils/haddock > make[2]: *** No rule to make target `all_utils/haddock'. Stop. > make[1]: *** [all_utils/haddock] Error 2 > make[1]: Leaving directory `/home/cactus/prog/haskell/ghc/ghc' > From hvriedel at gmail.com Tue Dec 10 14:48:12 2013 From: hvriedel at gmail.com (Herbert Valerio Riedel) Date: Tue, 10 Dec 2013 15:48:12 +0100 Subject: Building Haddock in GHC source tree (Re: Preparing for a review of pattern synonyms) In-Reply-To: (ERDI Gergo's message of "Tue, 10 Dec 2013 22:24:33 +0800 (SGT)") References: <59543203684B2244980D7E4057D5FBC1486E61B5@DB3EX14MBXC308.europe.corp.microsoft.com> <52A5AAD3.1020200@gmail.com> <52A5D3E7.4030802@gmail.com> Message-ID: <87d2l469ub.fsf@gmail.com> On 2013-12-10 at 15:24:33 +0100, Dr. ERDI Gergo wrote: > On Tue, 10 Dec 2013, Dr. ERDI Gergo wrote: > >> OK, I'll add pattern synonym support for Haddock. > > Ummm..., so how do I build the version of Haddock included in the GHC > source tree under utils? I tried just > $ cd utils/haddock > $ make > > but that fails with ...do you have "HADDOCK_DOCS=YES" active in your mk/build.mk ? From bgamari.foss at gmail.com Tue Dec 10 16:53:23 2013 From: bgamari.foss at gmail.com (Ben Gamari) Date: Tue, 10 Dec 2013 11:53:23 -0500 Subject: Repository Reorganization Question In-Reply-To: <87ppp5572e.fsf@gmail.com> References: <87d2lb4n6q.fsf@gmail.com> <878uvz4khf.fsf@gmail.com> <1386244615.2760.3.camel@kirk> <8738m74e5h.fsf@gnu.org> <87mwke9twu.fsf@gmail.com> <1386328029.2621.1.camel@kirk> <87fvq69nvd.fsf@gmail.com> <87bo0u9e8d.fsf@gmail.com> <52A57CC1.7080105@gmail.com> <87ppp6fn4b.fsf@gmail.com> <52A58BFE.809@gmail.com> <1386581280.2480.13.camel@kirk> <52A59B6A.1020401@gmail.com> <87ppp5572e.fsf@gmail.com> Message-ID: <87eh5kzlz0.fsf@gmail.com> Herbert Valerio Riedel writes: > On 2013-12-09 at 13:31:15 +0100, Austin Seipp wrote: >> It seems that while most people are in favor of migrating and >> preserving the history there are a few sticky bits concerning some of >> the minor details. So I think the discussion should continue, but we >> clearly shouldn't pull the trigger quite yet. testsuite etc will live >> on for a while longer. > > In the mean time I've updated the branch > > http://git.haskell.org/ghc.git/log/refs/heads/wip/T8545 > > to include the full testsuite.git history, with the history rewritten as > if the files have been always in the 'testsuite/' folder, and with the > blobs removed; moreover I've tweaked the sync-all script to check for a > left-over testsuite/.git folder, to remind users to move it out of the > way. > If the old commit IDs are really needed, one would think it wouldn't be too hard to write them into the commit message while rewriting history. That way you could at least `git log --grep` IIRC. Cheers, - Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 489 bytes Desc: not available URL: From mail at joachim-breitner.de Tue Dec 10 18:30:04 2013 From: mail at joachim-breitner.de (Joachim Breitner) Date: Tue, 10 Dec 2013 18:30:04 +0000 Subject: =?UTF-8?Q?nofib=E2=80=99s?= =?UTF-8?Q?_cacheprof=E2=80=99s?= Allocations not deterministic Message-ID: <1386700204.2464.13.camel@kirk> Hi, with most of nofib, one expects at least the Allocation numbers to be reliably and deterministic. This is not the case with cacheprof, they seem to wibble around by ~0.2%, which is strange. Has anyone else noticed this yes, and if so, tried to find out the cause? Is it expected and desired, or a bug somewhere? Greetings, Joachim -- Joachim ?nomeata? Breitner mail at joachim-breitner.de ? http://www.joachim-breitner.de/ Jabber: nomeata at joachim-breitner.de ? GPG-Key: 0x4743206C Debian Developer: nomeata at debian.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part URL: From mle+hs at mega-nerd.com Tue Dec 10 20:52:47 2013 From: mle+hs at mega-nerd.com (Erik de Castro Lopo) Date: Wed, 11 Dec 2013 07:52:47 +1100 Subject: Please help complete `.mailmap` In-Reply-To: <87vbyx59t3.fsf@gnu.org> References: <87vbyx59t3.fsf@gnu.org> Message-ID: <20131211075247.d88ffa1a05eb14b3a050d517@mega-nerd.com> Herbert Valerio Riedel wrote: > Hello *, > > I've been trying to (re)construct a .mailmap file[1] in ghc.git which > allows `git shortlog` and `git log --use-mailmap` (and possibly other > tools/commands) to fixup bogus author-ids when displaying the Git > history, in the hopes to provide a more complete history of GHC and all > contributors involved. > > I've been able to infer mappings for most users, but I'm stuck on a > couple of older account usernames dating back a decade ago for which I > have no idea what real names to associate with. These are specifically: > 1 sseefried Sean Seefried, CC-ed. Cheers, Erik -- ---------------------------------------------------------------------- Erik de Castro Lopo http://www.mega-nerd.com/ From marlowsd at gmail.com Tue Dec 10 21:06:00 2013 From: marlowsd at gmail.com (Simon Marlow) Date: Tue, 10 Dec 2013 21:06:00 +0000 Subject: HeapStackCheck.cmm In-Reply-To: <182701386635703@web5j.yandex.ru> References: <182701386635703@web5j.yandex.ru> Message-ID: <52A78238.7080205@gmail.com> On 10/12/13 00:35, Alexander Pakhomov wrote: > Hi. Trying to compile ghc HEAD on OpenBSD I got an error: > rts/HeapStackCheck.cmm:97:18: parse error on input `[' > The code is following: > 96 if (HpAlloc <= BLOCK_SIZE > 97 && bdescr_link(CurrentNursery) != NULL) { > which preprocesses to: > if (HpAlloc <= (1<<12) > && b0[CurrentNursery+15] != (0::bits64)) { > This is the first occurrence of b0 in preprocessed file. I believe that it is due to undefined b0. > Command that fails is: > "inplace/bin/ghc-stage1" -static -H32m -O -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/HeapStackCheck.cmm -o rts/dist/build/HeapStackCheck.o > To preprocess do the following: > cpp -O -Iincludes -Iincludes/dist -Iincludes/dist-derivedconstants/header -Iincludes/dist-ghcconstants/header -Irts -Irts/dist/build -DCOMPILING_RTS -Irts/dist/build -Irts/dist/build/autogen rts/HeapStackCheck.cmm | less > > Can you please find source of b0 in preprocessed file? I think this means that something went wrong when generating DerivedConstants.h, which is where the definition of bdescr_link() comes from. In my build, I have the following, in the file includes/dist-derivedconstants/header/: #define OFFSET_bdescr_link 16 #define REP_bdescr_link b64 #define bdescr_link(__ptr__) REP_bdescr_link[__ptr__+OFFSET_bdescr_link] This is auto-generated by the program in utils/deriveConstants. This used to be a C program, but nowadays it's a Haskell program that generates a C program for reasons that I forget. Anyway, your problem is somewhere in there... see if you can find out where by dumping out intermediate files and so forth. If you get stuck, tell us where you get to and we'll try to help some more. Cheers, Simon From marlowsd at gmail.com Tue Dec 10 21:09:50 2013 From: marlowsd at gmail.com (Simon Marlow) Date: Tue, 10 Dec 2013 21:09:50 +0000 Subject: =?windows-1252?Q?nofib=92s_cacheprof=92s_Allocations_n?= =?windows-1252?Q?ot_deterministic?= In-Reply-To: <1386700204.2464.13.camel@kirk> References: <1386700204.2464.13.camel@kirk> Message-ID: <52A7831E.1010801@gmail.com> On 10/12/13 18:30, Joachim Breitner wrote: > Hi, > > with most of nofib, one expects at least the Allocation numbers to be > reliably and deterministic. This is not the case with cacheprof, they > seem to wibble around by ~0.2%, which is strange. > > Has anyone else noticed this yes, and if so, tried to find out the > cause? Is it expected and desired, or a bug somewhere? It is neither expected nor desired, and if you could do anything to diagnose it further that would be great. Sometimes programs do things like generate a random temporary filename, and that can lead to non-deterministic allocation. If this program is doing something like that, we should fix it so it doesn't. Cheers, Simon From nicolas.frisby at gmail.com Tue Dec 10 21:20:22 2013 From: nicolas.frisby at gmail.com (Nicolas Frisby) Date: Tue, 10 Dec 2013 15:20:22 -0600 Subject: =?windows-1252?Q?Re=3A_nofib=92s_cacheprof=92s_Allocations_not_determin?= =?windows-1252?Q?istic?= In-Reply-To: <1386700204.2464.13.camel@kirk> References: <1386700204.2464.13.camel@kirk> Message-ID: Just chiming in to say that I have also noticed that cacheprof's allocation wiggles. I've seen it on linux and on mac On Tue, Dec 10, 2013 at 12:30 PM, Joachim Breitner wrote: > Hi, > > with most of nofib, one expects at least the Allocation numbers to be > reliably and deterministic. This is not the case with cacheprof, they > seem to wibble around by ~0.2%, which is strange. > > Has anyone else noticed this yes, and if so, tried to find out the > cause? Is it expected and desired, or a bug somewhere? > > Greetings, > Joachim > > -- > Joachim ?nomeata? Breitner > mail at joachim-breitner.de ? http://www.joachim-breitner.de/ > Jabber: nomeata at joachim-breitner.de ? GPG-Key: 0x4743206C > Debian Developer: nomeata at debian.org > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://www.haskell.org/mailman/listinfo/ghc-devs > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hvr at gnu.org Tue Dec 10 21:42:16 2013 From: hvr at gnu.org (Herbert Valerio Riedel) Date: Tue, 10 Dec 2013 22:42:16 +0100 Subject: Repository Reorganization Question In-Reply-To: <87eh5kzlz0.fsf@gmail.com> (Ben Gamari's message of "Tue, 10 Dec 2013 11:53:23 -0500") References: <87d2lb4n6q.fsf@gmail.com> <878uvz4khf.fsf@gmail.com> <1386244615.2760.3.camel@kirk> <8738m74e5h.fsf@gnu.org> <87mwke9twu.fsf@gmail.com> <1386328029.2621.1.camel@kirk> <87fvq69nvd.fsf@gmail.com> <87bo0u9e8d.fsf@gmail.com> <52A57CC1.7080105@gmail.com> <87ppp6fn4b.fsf@gmail.com> <52A58BFE.809@gmail.com> <1386581280.2480.13.camel@kirk> <52A59B6A.1020401@gmail.com> <87ppp5572e.fsf@gmail.com> <87eh5kzlz0.fsf@gmail.com> Message-ID: <874n6g5qo7.fsf@gmail.com> Hi Ben, On 2013-12-10 at 17:53:23 +0100, Ben Gamari wrote: > If the old commit IDs are really needed, one would think it wouldn't be > too hard to write them into the commit message while rewriting > history. That way you could at least `git log --grep` IIRC. Good idea, that's quite easy actually, I just need to perform git filter-branch \ --msg-filter 'cat - && echo && echo "(original commit: [$GIT_COMMIT/testsuite])"' as the first rewrite step (so that the $GIT_COMMIT variable still points to the original commit hash ids), and then the imported commits will look like e.g. ,---- | commit afe483f9b9e0eadda178f9f6786d835ea7b8395c | Author: Joachim Breitner | Date: Mon Dec 9 15:40:20 2013 +0000 | | Use -ddump-strsigs in tests/stranal/sigs | | because it is more reliable than the previous GHC plugin (no need to | support annotations etc.), plus it works nicely with "make accept". | | (original commit: [323cab22d65ea88410a607ef22db23198c03e305/testsuite]) `---- So if we want it that way, it's easily accomplished... Cheers, hvr From ker0sin at yandex.ru Tue Dec 10 21:43:42 2013 From: ker0sin at yandex.ru (Alexander Pakhomov) Date: Wed, 11 Dec 2013 01:43:42 +0400 Subject: HeapStackCheck.cmm In-Reply-To: <52A78238.7080205@gmail.com> References: <182701386635703@web5j.yandex.ru> <52A78238.7080205@gmail.com> Message-ID: <239301386711822@web2h.yandex.ru> Thanks. I think preprocessor dump could help me: cpp -Iincludes -Iincludes/dist -Iincludes/dist-derivedconstants/header -Iincludes/dist-ghcconstants/header -Irts -Irts/dist/build -DCOMPILING_RTS -Irts/dist/build -Irts/dist/build/autogen rts/HeapStackCheck.cmm > cpp_dump That is ghc-stage1 -> cpp and all options that cpp doesn't accept removed. I hope ghc preprocessor is compatible with system C preprocessor. 11.12.2013, 01:06, "Simon Marlow" : > On 10/12/13 00:35, Alexander Pakhomov wrote: > >> ?Hi. Trying to compile ghc HEAD on OpenBSD I got an error: >> ?rts/HeapStackCheck.cmm:97:18: parse error on input `[' >> ?The code is following: >> ???96 ????????if (HpAlloc <= BLOCK_SIZE >> ???97 ????????????&& bdescr_link(CurrentNursery) != NULL) { >> ?which preprocesses to: >> ??????????if (HpAlloc <= (1<<12) >> ??????????????&& b0[CurrentNursery+15] != (0::bits64)) { >> ?This is the first occurrence of b0 in preprocessed file. I believe that it is due to undefined b0. >> ?Command that fails is: >> ?"inplace/bin/ghc-stage1" -static ?-H32m -O -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/HeapStackCheck.cmm -o rts/dist/build/HeapStackCheck.o >> ?To preprocess do the following: >> ?cpp -O -Iincludes -Iincludes/dist -Iincludes/dist-derivedconstants/header -Iincludes/dist-ghcconstants/header -Irts -Irts/dist/build -DCOMPILING_RTS -Irts/dist/build -Irts/dist/build/autogen ????????rts/HeapStackCheck.cmm | less >> >> ?Can you please find source of b0 in preprocessed file? > > I think this means that something went wrong when generating > DerivedConstants.h, which is where the definition of bdescr_link() comes > from. ?In my build, I have the following, in the file > includes/dist-derivedconstants/header/: > > #define OFFSET_bdescr_link 16 > #define REP_bdescr_link b64 > #define bdescr_link(__ptr__) REP_bdescr_link[__ptr__+OFFSET_bdescr_link] > > This is auto-generated by the program in utils/deriveConstants. ?This > used to be a C program, but nowadays it's a Haskell program that > generates a C program for reasons that I forget. ?Anyway, your problem > is somewhere in there... see if you can find out where by dumping out > intermediate files and so forth. ?If you get stuck, tell us where you > get to and we'll try to help some more. > > Cheers, > Simon From carter.schonwald at gmail.com Tue Dec 10 21:46:48 2013 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Tue, 10 Dec 2013 16:46:48 -0500 Subject: HeapStackCheck.cmm In-Reply-To: <239301386711822@web2h.yandex.ru> References: <182701386635703@web5j.yandex.ru> <52A78238.7080205@gmail.com> <239301386711822@web2h.yandex.ru> Message-ID: are you using GCC or Clang, what versions are they? On Tue, Dec 10, 2013 at 4:43 PM, Alexander Pakhomov wrote: > Thanks. I think preprocessor dump could help me: > cpp -Iincludes -Iincludes/dist -Iincludes/dist-derivedconstants/header > -Iincludes/dist-ghcconstants/header -Irts -Irts/dist/build -DCOMPILING_RTS > -Irts/dist/build -Irts/dist/build/autogen rts/HeapStackCheck.cmm > > cpp_dump > That is ghc-stage1 -> cpp and all options that cpp doesn't accept removed. > I hope ghc preprocessor is compatible with system C preprocessor. > > 11.12.2013, 01:06, "Simon Marlow" : > > On 10/12/13 00:35, Alexander Pakhomov wrote: > > > >> Hi. Trying to compile ghc HEAD on OpenBSD I got an error: > >> rts/HeapStackCheck.cmm:97:18: parse error on input `[' > >> The code is following: > >> 96 if (HpAlloc <= BLOCK_SIZE > >> 97 && bdescr_link(CurrentNursery) != NULL) { > >> which preprocesses to: > >> if (HpAlloc <= (1<<12) > >> && b0[CurrentNursery+15] != (0::bits64)) { > >> This is the first occurrence of b0 in preprocessed file. I believe > that it is due to undefined b0. > >> Command that fails is: > >> "inplace/bin/ghc-stage1" -static -H32m -O -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/HeapStackCheck.cmm -o > rts/dist/build/HeapStackCheck.o > >> To preprocess do the following: > >> cpp -O -Iincludes -Iincludes/dist > -Iincludes/dist-derivedconstants/header -Iincludes/dist-ghcconstants/header > -Irts -Irts/dist/build -DCOMPILING_RTS -Irts/dist/build > -Irts/dist/build/autogen rts/HeapStackCheck.cmm | less > >> > >> Can you please find source of b0 in preprocessed file? > > > > I think this means that something went wrong when generating > > DerivedConstants.h, which is where the definition of bdescr_link() comes > > from. In my build, I have the following, in the file > > includes/dist-derivedconstants/header/: > > > > #define OFFSET_bdescr_link 16 > > #define REP_bdescr_link b64 > > #define bdescr_link(__ptr__) REP_bdescr_link[__ptr__+OFFSET_bdescr_link] > > > > This is auto-generated by the program in utils/deriveConstants. This > > used to be a C program, but nowadays it's a Haskell program that > > generates a C program for reasons that I forget. Anyway, your problem > > is somewhere in there... see if you can find out where by dumping out > > intermediate files and so forth. If you get stuck, tell us where you > > get to and we'll try to help some more. > > > > Cheers, > > Simon > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://www.haskell.org/mailman/listinfo/ghc-devs > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mail at joachim-breitner.de Tue Dec 10 21:47:20 2013 From: mail at joachim-breitner.de (Joachim Breitner) Date: Tue, 10 Dec 2013 21:47:20 +0000 Subject: Repository Reorganization Question In-Reply-To: <874n6g5qo7.fsf@gmail.com> References: <87d2lb4n6q.fsf@gmail.com> <878uvz4khf.fsf@gmail.com> <1386244615.2760.3.camel@kirk> <8738m74e5h.fsf@gnu.org> <87mwke9twu.fsf@gmail.com> <1386328029.2621.1.camel@kirk> <87fvq69nvd.fsf@gmail.com> <87bo0u9e8d.fsf@gmail.com> <52A57CC1.7080105@gmail.com> <87ppp6fn4b.fsf@gmail.com> <52A58BFE.809@gmail.com> <1386581280.2480.13.camel@kirk> <52A59B6A.1020401@gmail.com> <87ppp5572e.fsf@gmail.com> <87eh5kzlz0.fsf@gmail.com> <874n6g5qo7.fsf@gmail.com> Message-ID: <1386712040.22876.1.camel@kirk> Hi, Am Dienstag, den 10.12.2013, 22:42 +0100 schrieb Herbert Valerio Riedel: > So if we want it that way, it's easily accomplished... yes, looks good. Make sure that when you merge master, you are not adding new comments to all the tickets references from commit messages... Greetings, Joachim -- Joachim Breitner e-Mail: mail at joachim-breitner.de Homepage: http://www.joachim-breitner.de Jabber-ID: nomeata at joachim-breitner.de -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part URL: From gergo at erdi.hu Tue Dec 10 23:10:33 2013 From: gergo at erdi.hu (Dr. ERDI Gergo) Date: Wed, 11 Dec 2013 07:10:33 +0800 (SGT) Subject: Building Haddock in GHC source tree (Re: Preparing for a review of pattern synonyms) In-Reply-To: <52A7297F.6040900@gmail.com> References: <59543203684B2244980D7E4057D5FBC1486E61B5@DB3EX14MBXC308.europe.corp.microsoft.com> <52A5AAD3.1020200@gmail.com> <52A5D3E7.4030802@gmail.com> <52A7297F.6040900@gmail.com> Message-ID: On Tue, 10 Dec 2013, Simon Marlow wrote: > Do you have HADDOCK_DOCS = NO in your mk/build.mk? yes; I thought that only controls whether documentation gets generated or not. I've now changed it to YES and Haddock is building. Thanks, Gergo From ker0sin at yandex.ru Wed Dec 11 00:42:55 2013 From: ker0sin at yandex.ru (Alexander Pakhomov) Date: Wed, 11 Dec 2013 04:42:55 +0400 Subject: HeapStackCheck.cmm In-Reply-To: References: <182701386635703@web5j.yandex.ru> <52A78238.7080205@gmail.com> <239301386711822@web2h.yandex.ru> Message-ID: <290201386722575@web3m.yandex.ru> An HTML attachment was scrubbed... URL: From benl at ouroborus.net Wed Dec 11 02:24:49 2013 From: benl at ouroborus.net (Ben Lippmeier) Date: Wed, 11 Dec 2013 13:24:49 +1100 Subject: Please help complete `.mailmap` In-Reply-To: <87vbyx59t3.fsf@gnu.org> References: <87vbyx59t3.fsf@gnu.org> Message-ID: On 10/12/2013, at 20:34 , Herbert Valerio Riedel wrote: > Hello *, > > I've been trying to (re)construct a .mailmap file[1] > 1 moran This is probably Andy Adams-Moran, from Galois. Ben. From marlowsd at gmail.com Wed Dec 11 08:12:21 2013 From: marlowsd at gmail.com (Simon Marlow) Date: Wed, 11 Dec 2013 08:12:21 +0000 Subject: HeapStackCheck.cmm In-Reply-To: <239301386711822@web2h.yandex.ru> References: <182701386635703@web5j.yandex.ru> <52A78238.7080205@gmail.com> <239301386711822@web2h.yandex.ru> Message-ID: <52A81E65.90209@gmail.com> I think you should look at includes/dist-derivedconstants/header/DerivedConstants.h first, look for the lines that I pasted in my email below. The problem is likely in there, but the file is automatically generated so you'll need to look at how it is generated. The program is in utils/deriveConstants. Cheers, Simon On 10/12/2013 21:43, Alexander Pakhomov wrote: > Thanks. I think preprocessor dump could help me: > cpp -Iincludes -Iincludes/dist -Iincludes/dist-derivedconstants/header -Iincludes/dist-ghcconstants/header -Irts -Irts/dist/build -DCOMPILING_RTS -Irts/dist/build -Irts/dist/build/autogen rts/HeapStackCheck.cmm > cpp_dump > That is ghc-stage1 -> cpp and all options that cpp doesn't accept removed. > I hope ghc preprocessor is compatible with system C preprocessor. > > 11.12.2013, 01:06, "Simon Marlow" : >> On 10/12/13 00:35, Alexander Pakhomov wrote: >> >>> Hi. Trying to compile ghc HEAD on OpenBSD I got an error: >>> rts/HeapStackCheck.cmm:97:18: parse error on input `[' >>> The code is following: >>> 96 if (HpAlloc <= BLOCK_SIZE >>> 97 && bdescr_link(CurrentNursery) != NULL) { >>> which preprocesses to: >>> if (HpAlloc <= (1<<12) >>> && b0[CurrentNursery+15] != (0::bits64)) { >>> This is the first occurrence of b0 in preprocessed file. I believe that it is due to undefined b0. >>> Command that fails is: >>> "inplace/bin/ghc-stage1" -static -H32m -O -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/HeapStackCheck.cmm -o rts/dist/build/HeapStackCheck.o >>> To preprocess do the following: >>> cpp -O -Iincludes -Iincludes/dist -Iincludes/dist-derivedconstants/header -Iincludes/dist-ghcconstants/header -Irts -Irts/dist/build -DCOMPILING_RTS -Irts/dist/build -Irts/dist/build/autogen rts/HeapStackCheck.cmm | less >>> >>> Can you please find source of b0 in preprocessed file? >> >> I think this means that something went wrong when generating >> DerivedConstants.h, which is where the definition of bdescr_link() comes >> from. In my build, I have the following, in the file >> includes/dist-derivedconstants/header/: >> >> #define OFFSET_bdescr_link 16 >> #define REP_bdescr_link b64 >> #define bdescr_link(__ptr__) REP_bdescr_link[__ptr__+OFFSET_bdescr_link] >> >> This is auto-generated by the program in utils/deriveConstants. This >> used to be a C program, but nowadays it's a Haskell program that >> generates a C program for reasons that I forget. Anyway, your problem >> is somewhere in there... see if you can find out where by dumping out >> intermediate files and so forth. If you get stuck, tell us where you >> get to and we'll try to help some more. >> >> Cheers, >> Simon From marlowsd at gmail.com Wed Dec 11 09:34:43 2013 From: marlowsd at gmail.com (Simon Marlow) Date: Wed, 11 Dec 2013 09:34:43 +0000 Subject: Repository Reorganization Question In-Reply-To: <874n6g5qo7.fsf@gmail.com> References: <87d2lb4n6q.fsf@gmail.com> <878uvz4khf.fsf@gmail.com> <1386244615.2760.3.camel@kirk> <8738m74e5h.fsf@gnu.org> <87mwke9twu.fsf@gmail.com> <1386328029.2621.1.camel@kirk> <87fvq69nvd.fsf@gmail.com> <87bo0u9e8d.fsf@gmail.com> <52A57CC1.7080105@gmail.com> <87ppp6fn4b.fsf@gmail.com> <52A58BFE.809@gmail.com> <1386581280.2480.13.camel@kirk> <52A59B6A.1020401@gmail.com> <87ppp5572e.fsf@gmail.com> <87eh5kzlz0.fsf@gmail.com> <874n6g5qo7.fsf@gmail.com> Message-ID: <52A831B3.5070303@gmail.com> I don't feel terribly strongly about this, but I'd rather not clutter up the commit messages. As long as we keep the old testsuite.git repository attached to Trac, we can always find the old commits, and Google is a good hash table for SHA-1 keys. Cheers, Simon On 10/12/2013 21:42, Herbert Valerio Riedel wrote: > Hi Ben, > > On 2013-12-10 at 17:53:23 +0100, Ben Gamari wrote: >> If the old commit IDs are really needed, one would think it wouldn't be >> too hard to write them into the commit message while rewriting >> history. That way you could at least `git log --grep` IIRC. > > Good idea, that's quite easy actually, I just need to perform > > git filter-branch \ > --msg-filter 'cat - && echo && echo "(original commit: [$GIT_COMMIT/testsuite])"' > > as the first rewrite step (so that the $GIT_COMMIT variable still points > to the original commit hash ids), and then the imported commits will > look like e.g. > > ,---- > | commit afe483f9b9e0eadda178f9f6786d835ea7b8395c > | Author: Joachim Breitner > | Date: Mon Dec 9 15:40:20 2013 +0000 > | > | Use -ddump-strsigs in tests/stranal/sigs > | > | because it is more reliable than the previous GHC plugin (no need to > | support annotations etc.), plus it works nicely with "make accept". > | > | (original commit: [323cab22d65ea88410a607ef22db23198c03e305/testsuite]) > `---- > > So if we want it that way, it's easily accomplished... > > Cheers, > hvr > From mail at joachim-breitner.de Thu Dec 12 01:28:46 2013 From: mail at joachim-breitner.de (Joachim Breitner) Date: Thu, 12 Dec 2013 01:28:46 +0000 Subject: Common Context transformation for join points Message-ID: <1386811726.2470.33.camel@kirk> Hi all, I just came up with this, and unless I write it down I doubt I?ll be able to fall asleep. The problem I?m trying to solve is the bad interaction of the CPR worker wrapper transformation and join points. Consider, as a running example: f x = let $j n = Just (Int# (n +# 1)) in case x of A -> $j 1 B -> $j 2 C -> Just undefined The join point $j has the important property that in the final code, it can be jumped to, because its result is also the result of f, so no function closure has to be allocated for it. It seems that this is crucial for performance. But now lets do CPR, and just for demonstration, do nested CPR (the effect can also occur with non-nested CPR). Doing w/w we get $wf x = case ( let $w$j n = n +# 1 $j n = Just (Int# ($w$j n)) in case x of A -> $j 1 B -> $j 2 C -> Just undefined ) of Just n -> n f x = Just ($wf x) now we simplify, i.e. move the worker transformation inside, and inline $j?s wrapper. (I hope I am doing this right; but this is what I expect to happen): $wf x = let $w$j n = n+1 in case x of A -> Int# ($w$j 1) B -> Int# ($w$j 2) C -> undefined f x = Just ($wf x) So f?s worker transformation has nicely canceled with the invocations of Just, but it still leaves a "Int#" invocation around $w$j, so we lose the no-let-escape property of it and get worse code in the backend. This will always happen if the join point function gets a richer CPR property than the function that it belongs to, and is the reason for some hacks in the CPR code (i.e. no CPR for locally stuff that returns a sum type... not nice.) I think I have a solution for this. One observation is that these $j-functions are not really functions of their own. For this transformation (and possibly for others), one should try to treat them so that they behave as if they were inlined. So here is the idea: We do not do any w/w for $j at first, on the premise that it is not a proper function of its own. We do w/w for f as before, and simplify as before, ending up with $wf x = let $j n = Just (Int# (n +# 1)) in case x of A -> case $j 1 of Just n -> n B -> case $j 2 of Just n -> n C -> undefined f x = Just ($wf x) so we temporarily broke the property. Now a new simplifier step kicks in: For a let that looks like it was or should be a join point (hand waving here ? one could possibly do it for all non-recursive lets, maybe there is even more to gain), we find out for all uses of $j applied to its arity number of arguments, what is the largest common context? where a context is * ?, the trivial context, * case c of ..., where c is a context, and ... does not contain a call to $j, * f c, where c is a context and f does not contain a call to $j, or * c x, where c is a context and f does not contain a call to $j. In particular we do not include code here where $j is part of an alternative of a case. (Casts should ok fine as well, ignoring them for now.) In our example, the context would be "case ? of Just n -> n". Once we have found that, I believe it will be always safe and beneficial to replace the body e of $j by c[e], and in the body of the let replace every c[$j args..] by $j args. In our example, we would obtain $wf x = let ?j n = case Just (Int# (n +# 1)) of Just n -> n in case x of A -> $j 1 B -> $j 2 C -> undefined f x = Just ($wf x) which then in further steps simplifies to the in all respects ideal code $wf x = let ?j n = Int# (n +# 1)) in case x of A -> $j 1 B -> $j 2 C -> undefined f x = Just ($wf x) Implementationwise I figured that this will need two traversals (down and up each) of the let body: Starting from a let binding that looks promising (e.g. one-shot non-recursive lambda), walk down the body until invocations of the right arity are found. Then walk back returning a growing contest, and at case-expressions lub these contexts by taking their common prefix (or suffix, depends on how they are represented :-)). Then decide whether the transformation is useful (i.e. the context is non-trivial), and if so, walk back down to find the $j invocations again, and then walk back, removing the final context while doing so. I believe this would make some let-no-escape-related reluctanceness in the CPR-analysis obsolete, which would be great. And it might be a worthwhile transformation on its own (if it actually does occur), as it reduces code size without any downside (as far as I can see). Now it is likely that I thought of something existing here, or of something that has been tried and found not useful or feasible. If so, please let me know. Good night, Joachim -- Joachim ?nomeata? Breitner mail at joachim-breitner.de ? http://www.joachim-breitner.de/ Jabber: nomeata at joachim-breitner.de ? GPG-Key: 0x4743206C Debian Developer: nomeata at debian.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part URL: From alrunner4 at gmail.com Fri Dec 13 01:50:16 2013 From: alrunner4 at gmail.com (Alex Carter) Date: Thu, 12 Dec 2013 17:50:16 -0800 Subject: Cross-Compiler: Windows-to-iOS Message-ID: Hello, ghc-devs! This is continuation of a conversation from the iphone list, but since it seems to be more of a general cross-compilation issue, I'll toss it up for you guys. (See the conversation history below if you're curious.) The gist is that I'm trying to build a Windows-to-iOS cross-compiler, and since I imagine this isn't something done very often, I've hit a few bumps along the way. First up, gcc (4.5.2, inplace/mingw/bin) really doesn't seem to like rts/Task.h:283, complaining "error: aggregate value used where an integer was expected." For this configuration, presumably OSThreadId is pthread_t and TaskId is uint64, so I'm not sure why it doesn't like the casts. I worked around with return *( (TaskId*) ( (size_t*) &taskID ) ); Last night I was stuck on compiling some automatically generated headers that come out of the deriveConstants utility, and as best I can gather, it generates a header that is (marginally) dependent upon the platform on which it's currently running by using System.Info.os, but the compilation that uses the header seems to be expecting it to work for the target (runtime, maybe?). I added an "os" switch to deriveConstants rather than using System.Info.os and passed the target OS through in includes/ghc.mk where it's invoked. So that seems to fix my issues with StgAsyncIOResults (Windows-only, right?) but I have no idea if these hacks make any sense in the big picture, or if the compiler will even work once I finish the build... Presently I'm stuck on something I expected to be rather straightforward: "Warning: Couldn't figure out LLVM version! Make sure you have installed LLVM." The iOS toolchain I'm using is in my PATH, and both "llc -version" and "opt -version" work as expected in my shell. I'm curious if it's because of the odd version number: $ llc -version LLVM (http://llvm.org/): LLVM version 3.3svn ... Is ./configure perhaps getting caught up on the "svn" and treating this as a failure of version detection? I haven't been able to find a way to manually override the configuration and specify the LLVM paths. Any help is appreciated so I can get back to writing Haskell instead of build debugging. ;) Thanks, Alex On Wed, Dec 11, 2013 at 12:27 AM, Simon Marlow wrote: > Yes, this is correct. ghc_boot_platform describes the platforms for the > stage 1 compiler (assuming you're looking at the one in compiler/stage1). > ghcplatform.h describes the platforms in use for compiled code, so the host > in that case is ios. In fact ghcplatform.h shouldn't have a target platform > at all - the only reason it does is for "backwards compatibility", though I > don't remember exactly what goes wrong if we remove these. > > Cheers, > Simon > > > On 11/12/2013 00:08, Alex Carter wrote: >> >> I'm on an interesting journey building a GHC cross-compiler on Windows >> to target iOS, using a third-party iOS toolchain for Windows >> (http://www.pmbaty.com/iosbuildenv/ for the curious), and I'm running >> into an unusual issue. Since this is a cross-compiler, this should be >> all stage 1, so in ghc_boot_platform.h I see what I expect: >> >> ... >> #define BUILD_OS "mingw32" >> #define HOST_OS "mingw32" >> #define TARGET_OS "ios" >> ... >> >> but ghcplatform.h shows: >> >> ... >> #define BUILD_OS "mingw32" >> #define HOST_OS "ios" >> ... >> #define TARGET_OS "ios" >> ... >> >> which I understand to mean that whatever's happening there is set up >> for the stage 2 compiler (unless there's some good magic happening >> here with the deriveConstants utility?). I discovered this through a >> pragma added at the error site: >> >> ... >> rts/Task.h:280:9: note: #pragma message: HOST_OS=ios >> rts/Task.h:287:5: error: aggregate value used where an integer was >> expected >> ... >> >> Anybody know what's going on here? Is it right (for some reason beyond >> my current comprehension) for ghcplatform.h to have the #defines it >> does? Is HOST_OS=ios correct, but rts/Task.h:280 should also check >> defined(ios_HOST_OS)? >> >> Thanks for the help, >> Alex >> >> >> >> _______________________________________________ >> iPhone mailing list >> iPhone at haskell.org >> http://www.haskell.org/mailman/listinfo/iphone >> > From bgamari.foss at gmail.com Sat Dec 14 21:52:34 2013 From: bgamari.foss at gmail.com (Ben Gamari) Date: Sat, 14 Dec 2013 16:52:34 -0500 Subject: More GND + role inference woes In-Reply-To: References: <59543203684B2244980D7E4057D5FBC14864A4A7@DB3EX14MBXC308.europe.corp.microsoft.com> Message-ID: <878uvnuml9.fsf@gmail.com> Edward Kmett writes: > If this forced me to write those instances by hand, I could accept > that as a tax for correctness. It means you can't GND any of the > HasFoo dictionaries that lens builds, but meh. > Am I correct in assuming that Bind, R1, R2, R3, and R4 are the problematic instances in linear? With recent GHC I get the errors below. Cheers, - Ben src/Linear/Affine.hs:112:34: Could not coerce from ?f (f a)? to ?f (Point f a)? because ?f (f a)? and ?f (Point f a)? are different types. arising from the coercion of the method ?join? from type ?forall a. f (f a) -> f a? to type ?forall a. Point f (Point f a) -> Point f a? Possible fix: use a standalone 'deriving instance' declaration, so you can specify the instance context yourself When deriving the instance for (Bind (Point f)) src/Linear/Affine.hs:112:58: Could not coerce from ?g (f x)? to ?g (Point f x)? because ?g (f x)? and ?g (Point f x)? are different types. arising from the coercion of the method ?core? from type ?forall a. ((forall (g :: * -> *) x. Functor g => (x -> g x) -> f x -> g (f x)) -> a) -> f a? to type ?forall a. ((forall (g :: * -> *) x. Functor g => (x -> g x) -> Point f x -> g (Point f x)) -> a) -> Point f a? Possible fix: use a standalone 'deriving instance' declaration, so you can specify the instance context yourself When deriving the instance for (Core (Point f)) src/Linear/Affine.hs:112:64: Could not coerce from ?f1 (f a)? to ?f1 (Point f a)? because ?f1 (f a)? and ?f1 (Point f a)? are different types. arising from the coercion of the method ?_x? from type ?forall a (f :: * -> *). Functor f => (a -> f a) -> f a -> f (f a)? to type ?forall a (f :: * -> *). Functor f => (a -> f a) -> Point f a -> f (Point f a)? Possible fix: use a standalone 'deriving instance' declaration, so you can specify the instance context yourself When deriving the instance for (R1 (Point f)) src/Linear/Affine.hs:112:68: Could not coerce from ?f1 (f a)? to ?f1 (Point f a)? because ?f1 (f a)? and ?f1 (Point f a)? are different types. arising from the coercion of the method ?_xy? from type ?forall a (f :: * -> *). Functor f => (V2 a -> f (V2 a)) -> f a -> f (f a)? to type ?forall a (f :: * -> *). Functor f => (V2 a -> f (V2 a)) -> Point f a -> f (Point f a)? Possible fix: use a standalone 'deriving instance' declaration, so you can specify the instance context yourself When deriving the instance for (R2 (Point f)) src/Linear/Affine.hs:112:68: Could not coerce from ?f1 (f a)? to ?f1 (Point f a)? because ?f1 (f a)? and ?f1 (Point f a)? are different types. arising from the coercion of the method ?_y? from type ?forall a (f :: * -> *). Functor f => (a -> f a) -> f a -> f (f a)? to type ?forall a (f :: * -> *). Functor f => (a -> f a) -> Point f a -> f (Point f a)? Possible fix: use a standalone 'deriving instance' declaration, so you can specify the instance context yourself When deriving the instance for (R2 (Point f)) src/Linear/Affine.hs:112:72: Could not coerce from ?f1 (f a)? to ?f1 (Point f a)? because ?f1 (f a)? and ?f1 (Point f a)? are different types. arising from the coercion of the method ?_xyz? from type ?forall a (f :: * -> *). Functor f => (V3 a -> f (V3 a)) -> f a -> f (f a)? to type ?forall a (f :: * -> *). Functor f => (V3 a -> f (V3 a)) -> Point f a -> f (Point f a)? Possible fix: use a standalone 'deriving instance' declaration, so you can specify the instance context yourself When deriving the instance for (R3 (Point f)) src/Linear/Affine.hs:112:72: Could not coerce from ?f1 (f a)? to ?f1 (Point f a)? because ?f1 (f a)? and ?f1 (Point f a)? are different types. arising from the coercion of the method ?_z? from type ?forall a (f :: * -> *). Functor f => (a -> f a) -> f a -> f (f a)? to type ?forall a (f :: * -> *). Functor f => (a -> f a) -> Point f a -> f (Point f a)? Possible fix: use a standalone 'deriving instance' declaration, so you can specify the instance context yourself When deriving the instance for (R3 (Point f)) src/Linear/Affine.hs:112:76: Could not coerce from ?f1 (f a)? to ?f1 (Point f a)? because ?f1 (f a)? and ?f1 (Point f a)? are different types. arising from the coercion of the method ?_xyzw? from type ?forall a (f :: * -> *). Functor f => (V4 a -> f (V4 a)) -> f a -> f (f a)? to type ?forall a (f :: * -> *). Functor f => (V4 a -> f (V4 a)) -> Point f a -> f (Point f a)? Possible fix: use a standalone 'deriving instance' declaration, so you can specify the instance context yourself When deriving the instance for (R4 (Point f)) src/Linear/Affine.hs:112:76: Could not coerce from ?f1 (f a)? to ?f1 (Point f a)? because ?f1 (f a)? and ?f1 (Point f a)? are different types. arising from the coercion of the method ?_w? from type ?forall a (f :: * -> *). Functor f => (a -> f a) -> f a -> f (f a)? to type ?forall a (f :: * -> *). Functor f => (a -> f a) -> Point f a -> f (Point f a)? Possible fix: use a standalone 'deriving instance' declaration, so you can specify the instance context yourself When deriving the instance for (R4 (Point f)) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 489 bytes Desc: not available URL: From bgamari.foss at gmail.com Sat Dec 14 22:13:25 2013 From: bgamari.foss at gmail.com (Ben Gamari) Date: Sat, 14 Dec 2013 17:13:25 -0500 Subject: LLVM and dynamic linking Message-ID: <877gb7ulmi.fsf@gmail.com> # The Problem Dynamic linking is currently broken with the LLVM code generator. This can be easily seen by attempting to compile GHC with, GhcDynamic = YES DYNAMIC_BY_DEFAULT = YES DYNAMIC_GHC_PROGRAMS = YES BuildFlavour = quick-llvm This build will fail with a error along the lines of, dll-split: internal error: invalid closure, info=0x402ec0 (GHC version 7.7.20131212 for x86_64_unknown_linux) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug After some poking around with the help of Peter Wortmann, it seems clear that this is due to a subtle difference in how LLVM emits function symbols. While the NCG emits these symbols with `.type @object`, LLVM emits `.type @function`. It appears that the `.type` annotation guides the linker in choosing the relocation mechanism to use for the symbol. While `@object` symbols use the Global Offset Table, `@function` symbols are relocated through the Procedure Linking Table, a table of trampoline calls which are fixed up at runtime. This means that static references to functions end up pointing not to the object itself (and its info table) but instead to some linker-generated assembly. When the garbage collector attempts to examine the info table of one of these references, it finds nonsense and fails. # A solution Peter demonstrated that manually modifying the assembler produced by llc, passing this through GHC's mangler, and assembling the result yields a functional binary. As far as I can tell, LLVM's intermediate language doesn't expose any way to force a function to `.type @object`. Unfortunately this means that, at least for now, the only fix is to augment the mangler with logic to perform this transform. I've done this in my `llvm-dynamic` branch[1] (in addition to finding a bug in the `rewriteInstructions` function used by AVX rewriting). This branch compiles on my x86_64 machine to produce what appears to be a functional compiler. Unfortunately installation issues (which I'll describe shortly in a new thread) prevent me from verifying this. I'm currently waiting for a build on my ARM box but assuming this fix works this means that GHC could (finally) have first-class, stable ARM support. Comments? Cheers, - Ben [1] https://github.com/bgamari/ghc/tree/llvm-dynamic -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 489 bytes Desc: not available URL: From eir at cis.upenn.edu Sun Dec 15 00:53:23 2013 From: eir at cis.upenn.edu (Richard Eisenberg) Date: Sat, 14 Dec 2013 19:53:23 -0500 Subject: More GND + role inference woes In-Reply-To: <878uvnuml9.fsf@gmail.com> References: <59543203684B2244980D7E4057D5FBC14864A4A7@DB3EX14MBXC308.europe.corp.microsoft.com> <878uvnuml9.fsf@gmail.com> Message-ID: Yes, I believe that's right. As far as I can figure out, these classes really *are* problematic, in that if we allowed GeneralizedNewtypeDeriving for them, there would be a way to subvert the type system. To make these derivable, we would need to be able to restrict various type parameters from taking on values that take a nominal argument. Without the ability to restrict the values in this way, there could be trouble. Richard On Dec 14, 2013, at 4:52 PM, Ben Gamari wrote: > Edward Kmett writes: > >> If this forced me to write those instances by hand, I could accept >> that as a tax for correctness. It means you can't GND any of the >> HasFoo dictionaries that lens builds, but meh. >> > Am I correct in assuming that Bind, R1, R2, R3, and R4 are the > problematic instances in linear? With recent GHC I get the errors below. > > Cheers, > > - Ben > > > src/Linear/Affine.hs:112:34: > Could not coerce from ?f (f a)? to ?f (Point f a)? > because ?f (f a)? and ?f (Point f a)? are different types. > arising from the coercion of the method ?join? from type > ?forall a. f (f a) -> f a? to type > ?forall a. Point f (Point f a) -> Point f a? > Possible fix: > use a standalone 'deriving instance' declaration, > so you can specify the instance context yourself > When deriving the instance for (Bind (Point f)) > > src/Linear/Affine.hs:112:58: > Could not coerce from ?g (f x)? to ?g (Point f x)? > because ?g (f x)? and ?g (Point f x)? are different types. > arising from the coercion of the method ?core? from type > ?forall a. > ((forall (g :: * -> *) x. > Functor g => > (x -> g x) -> f x -> g (f x)) > -> a) > -> f a? > to type > ?forall a. > ((forall (g :: * -> *) x. > Functor g => > (x -> g x) -> Point f x -> g (Point f x)) > -> a) > -> Point f a? > Possible fix: > use a standalone 'deriving instance' declaration, > so you can specify the instance context yourself > When deriving the instance for (Core (Point f)) > > src/Linear/Affine.hs:112:64: > Could not coerce from ?f1 (f a)? to ?f1 (Point f a)? > because ?f1 (f a)? and ?f1 (Point f a)? are different types. > arising from the coercion of the method ?_x? from type > ?forall a (f :: * -> *). Functor f => (a -> f a) -> f a -> f (f a)? > to type > ?forall a (f :: * -> *). > Functor f => > (a -> f a) -> Point f a -> f (Point f a)? > Possible fix: > use a standalone 'deriving instance' declaration, > so you can specify the instance context yourself > When deriving the instance for (R1 (Point f)) > > src/Linear/Affine.hs:112:68: > Could not coerce from ?f1 (f a)? to ?f1 (Point f a)? > because ?f1 (f a)? and ?f1 (Point f a)? are different types. > arising from the coercion of the method ?_xy? from type > ?forall a (f :: * -> *). > Functor f => > (V2 a -> f (V2 a)) -> f a -> f (f a)? > to type > ?forall a (f :: * -> *). > Functor f => > (V2 a -> f (V2 a)) -> Point f a -> f (Point f a)? > Possible fix: > use a standalone 'deriving instance' declaration, > so you can specify the instance context yourself > When deriving the instance for (R2 (Point f)) > > src/Linear/Affine.hs:112:68: > Could not coerce from ?f1 (f a)? to ?f1 (Point f a)? > because ?f1 (f a)? and ?f1 (Point f a)? are different types. > arising from the coercion of the method ?_y? from type > ?forall a (f :: * -> *). Functor f => (a -> f a) -> f a -> f (f a)? > to type > ?forall a (f :: * -> *). > Functor f => > (a -> f a) -> Point f a -> f (Point f a)? > Possible fix: > use a standalone 'deriving instance' declaration, > so you can specify the instance context yourself > When deriving the instance for (R2 (Point f)) > > src/Linear/Affine.hs:112:72: > Could not coerce from ?f1 (f a)? to ?f1 (Point f a)? > because ?f1 (f a)? and ?f1 (Point f a)? are different types. > arising from the coercion of the method ?_xyz? from type > ?forall a (f :: * -> *). > Functor f => > (V3 a -> f (V3 a)) -> f a -> f (f a)? > to type > ?forall a (f :: * -> *). > Functor f => > (V3 a -> f (V3 a)) -> Point f a -> f (Point f a)? > Possible fix: > use a standalone 'deriving instance' declaration, > so you can specify the instance context yourself > When deriving the instance for (R3 (Point f)) > > src/Linear/Affine.hs:112:72: > Could not coerce from ?f1 (f a)? to ?f1 (Point f a)? > because ?f1 (f a)? and ?f1 (Point f a)? are different types. > arising from the coercion of the method ?_z? from type > ?forall a (f :: * -> *). Functor f => (a -> f a) -> f a -> f (f a)? > to type > ?forall a (f :: * -> *). > Functor f => > (a -> f a) -> Point f a -> f (Point f a)? > Possible fix: > use a standalone 'deriving instance' declaration, > so you can specify the instance context yourself > When deriving the instance for (R3 (Point f)) > > src/Linear/Affine.hs:112:76: > Could not coerce from ?f1 (f a)? to ?f1 (Point f a)? > because ?f1 (f a)? and ?f1 (Point f a)? are different types. > arising from the coercion of the method ?_xyzw? from type > ?forall a (f :: * -> *). > Functor f => > (V4 a -> f (V4 a)) -> f a -> f (f a)? > to type > ?forall a (f :: * -> *). > Functor f => > (V4 a -> f (V4 a)) -> Point f a -> f (Point f a)? > Possible fix: > use a standalone 'deriving instance' declaration, > so you can specify the instance context yourself > When deriving the instance for (R4 (Point f)) > > src/Linear/Affine.hs:112:76: > Could not coerce from ?f1 (f a)? to ?f1 (Point f a)? > because ?f1 (f a)? and ?f1 (Point f a)? are different types. > arising from the coercion of the method ?_w? from type > ?forall a (f :: * -> *). Functor f => (a -> f a) -> f a -> f (f a)? > to type > ?forall a (f :: * -> *). > Functor f => > (a -> f a) -> Point f a -> f (Point f a)? > Possible fix: > use a standalone 'deriving instance' declaration, > so you can specify the instance context yourself > When deriving the instance for (R4 (Point f)) From bgamari.foss at gmail.com Sun Dec 15 00:59:03 2013 From: bgamari.foss at gmail.com (Ben Gamari) Date: Sat, 14 Dec 2013 19:59:03 -0500 Subject: More GND + role inference woes In-Reply-To: References: <59543203684B2244980D7E4057D5FBC14864A4A7@DB3EX14MBXC308.europe.corp.microsoft.com> <878uvnuml9.fsf@gmail.com> Message-ID: <8738lvudyg.fsf@gmail.com> Richard Eisenberg writes: > Yes, I believe that's right. As far as I can figure out, these classes > really *are* problematic, in that if we allowed > GeneralizedNewtypeDeriving for them, there would be a way to subvert > the type system. To make these derivable, we would need to be able to > restrict various type parameters from taking on values that take a > nominal argument. Without the ability to restrict the values in this > way, there could be trouble. > I suppose it's unlikely that the roles mechanism will be extended to allow for such restriction? Cheers, - Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 489 bytes Desc: not available URL: From eir at cis.upenn.edu Sun Dec 15 01:06:08 2013 From: eir at cis.upenn.edu (Richard Eisenberg) Date: Sat, 14 Dec 2013 20:06:08 -0500 Subject: More GND + role inference woes In-Reply-To: <8738lvudyg.fsf@gmail.com> References: <59543203684B2244980D7E4057D5FBC14864A4A7@DB3EX14MBXC308.europe.corp.microsoft.com> <878uvnuml9.fsf@gmail.com> <8738lvudyg.fsf@gmail.com> Message-ID: On Dec 14, 2013, at 7:59 PM, Ben Gamari wrote: > > I suppose it's unlikely that the roles mechanism will be extended to > allow for such restriction? Very unlikely in the short term. As more use cases for such a feature filter in and the community demands the feature, there's no strong technical reason it can't be done. We believe that doing this would add quite a bit more complexity within GHC and doesn't have the right payoff-to-complexity ratio, for now. Richard From bgamari.foss at gmail.com Sun Dec 15 01:29:16 2013 From: bgamari.foss at gmail.com (Ben Gamari) Date: Sat, 14 Dec 2013 20:29:16 -0500 Subject: Ways issues with GhcDynamic=YES Message-ID: <871u1evr4j.fsf@gmail.com> I've spent much of the day trying to determine the root cause of, ... "inplace/bin/ghc-cabal" register libraries/ghc-prim dist-install "/opt/exp/ghc/root-ghc-llvm-dyn-7.8/lib/ghc-7.7.20131214/bin/ghc" "/opt/exp/ghc/root-ghc-llvm-dyn-7.8/lib/ghc-7.7.20131214/bin/ghc-pkg" "/opt/exp/ghc/root-ghc-llvm-dyn-7.8/lib/ghc-7.7.20131214" '' '/opt/exp/ghc/root-ghc-llvm-dyn-7.8' '/opt/exp/ghc/root-ghc-llvm-dyn-7.8/lib/ghc-7.7.20131214' '/opt/exp/ghc/root-ghc-llvm-dyn-7.8/share/doc/ghc/html/libraries' NO ghc-cabal: Bad interface file: dist-install/build/GHC/CString.hi mismatched interface file ways (wanted "dyn", got "") I'm attempting to produce a build to validate dynamic linking with LLVM so build.mk looks something like, DYNAMIC_BY_DEFAULT = YES BuildFlavour = quick-llvm Looking at the interface files produced for ghc-prim, it seems that ghc-cabal is looking for the wrong extension, $ inplace/bin/ghc-stage2 --show-iface libraries/ghc-prim/dist-install/build/GHC/CString.hi | grep --after-context=1 Way Way: Wanted [d, y, n], got [] $ inplace/bin/ghc-stage2 --show-iface libraries/ghc-prim/dist-install/build/GHC/CString.dyn_hi | grep --after-context=1 Way Way: Wanted [d, y, n], got [d, y, n] Any ideas what might be going on here? How is `ghc-cabal` supposed to know which interface file to use? Cheers, - Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 489 bytes Desc: not available URL: From ekmett at gmail.com Sun Dec 15 09:27:59 2013 From: ekmett at gmail.com (Edward Kmett) Date: Sun, 15 Dec 2013 04:27:59 -0500 Subject: More GND + role inference woes In-Reply-To: <8738lvudyg.fsf@gmail.com> References: <59543203684B2244980D7E4057D5FBC14864A4A7@DB3EX14MBXC308.europe.corp.microsoft.com> <878uvnuml9.fsf@gmail.com> <8738lvudyg.fsf@gmail.com> Message-ID: Correct. With 7.8 we'll need to hand-implement those instances rather than derive them. On Sat, Dec 14, 2013 at 7:59 PM, Ben Gamari wrote: > Richard Eisenberg writes: > > > Yes, I believe that's right. As far as I can figure out, these classes > > really *are* problematic, in that if we allowed > > GeneralizedNewtypeDeriving for them, there would be a way to subvert > > the type system. To make these derivable, we would need to be able to > > restrict various type parameters from taking on values that take a > > nominal argument. Without the ability to restrict the values in this > > way, there could be trouble. > > > I suppose it's unlikely that the roles mechanism will be extended to > allow for such restriction? > > Cheers, > > - Ben > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mail at joachim-breitner.de Sun Dec 15 16:35:45 2013 From: mail at joachim-breitner.de (Joachim Breitner) Date: Sun, 15 Dec 2013 17:35:45 +0100 Subject: Using features from containers-0.5 Message-ID: <1387125345.2563.11.camel@kirk> Hi, especially to Austin with his Release Manager hat on, in my nested-cpr branch I have a few nice patches that clean up, refactor and especially Note?ify the demand analyzer. I?d like to see both my branch to be shorter, and to see those improvements in the mainline independent of whether nested-cpr will turn out to be useful, so I invested some time to rebase my branch and move all these patches below those that actually change the code. The result is the contents of the wip/nested-cpr branch up to and including the patch ?Make types of bothDmdType more precise?, which I find especially useful (currently c26d31, but I tend to rebase while I add more polish or remove typos). I am confident that this is a pure refactoring (validate passes without changes to the testsuite, nofib shows identical Allocation numbers), and I?d like to push this to master. But one of the patches, ?Clarify the default demand on demand environments? (currently 2b6a6a), uses a function from containers (IntMap.mergeWithKey) which was only added in containers-0.5, which ships with GHC 7.6, but not with 7.4. But especially that change is nice, as removes the confusing modifyEnv function and makes the code (IMHO) easier to understand. What is the policy here? Is it ok to expect the user to upgrade the containers package of the bootstrap compiler? Or can we start building containers before stage-1, so that we can expect the new code (but when I tried it seems that this needs some adjustments to the build system)? Or should I add an alternative definition via CPP in compiler/utils/UniqFM.lhs? Or is it not worth it and I should wait until 7.9 (which would then drop the requirement to be bootstrappable with 7.4, right?) Thanks, Joachim -- Joachim ?nomeata? Breitner mail at joachim-breitner.de ? http://www.joachim-breitner.de/ Jabber: nomeata at joachim-breitner.de ? GPG-Key: 0x4743206C Debian Developer: nomeata at debian.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part URL: From carter.schonwald at gmail.com Sun Dec 15 23:52:28 2013 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Sun, 15 Dec 2013 18:52:28 -0500 Subject: whats our timeline for 7.8 release? Message-ID: hey all, many many folks are wondering about when 7.8 is going to hit RC officially. What are the bugs / blockers / etc that are left to deal with? We should at least aim to communicate whats going on instead of leaving folks wondering. -Carter -------------- next part -------------- An HTML attachment was scrubbed... URL: From marlowsd at gmail.com Mon Dec 16 10:21:40 2013 From: marlowsd at gmail.com (Simon Marlow) Date: Mon, 16 Dec 2013 10:21:40 +0000 Subject: Using features from containers-0.5 In-Reply-To: <1387125345.2563.11.camel@kirk> References: <1387125345.2563.11.camel@kirk> Message-ID: <52AED434.2000104@gmail.com> GHC's policy is: - we do not require that the user installs any libraries or upgrades any libraries in order to build GHC. - we support bootstrapping with the two previous major releases of GHC. So that means, after the 7.8 release, the HEAD will support only 7.6 and 7.8. So that means you'll be able to use containers-0.5 after the 7.8 branch split (but not merge any patches that require it onto the branch). The other way around this is to make containers into a zero-boot package, but we typically wouldn't do this for just one function. The main use case for this is Cabal, which in the past has changed quickly and in tandem with changes in GHC, so we want stage 1 to see the same Cabal as stage 2. Cheers, Simon On 15/12/2013 16:35, Joachim Breitner wrote: > Hi, especially to Austin with his Release Manager hat on, > > in my nested-cpr branch I have a few nice patches that clean up, > refactor and especially Note?ify the demand analyzer. I?d like to see > both my branch to be shorter, and to see those improvements in the > mainline independent of whether nested-cpr will turn out to be useful, > so I invested some time to rebase my branch and move all these patches > below those that actually change the code. > > The result is the contents of the wip/nested-cpr branch up to and > including the patch ?Make types of bothDmdType more precise?, which I > find especially useful (currently c26d31, but I tend to rebase while I > add more polish or remove typos). I am confident that this is a pure > refactoring (validate passes without changes to the testsuite, nofib > shows identical Allocation numbers), and I?d like to push this to > master. > > But one of the patches, ?Clarify the default demand on demand > environments? (currently 2b6a6a), uses a function from containers > (IntMap.mergeWithKey) which was only added in containers-0.5, which > ships with GHC 7.6, but not with 7.4. But especially that change is > nice, as removes the confusing modifyEnv function and makes the code > (IMHO) easier to understand. > > What is the policy here? Is it ok to expect the user to upgrade the > containers package of the bootstrap compiler? Or can we start building > containers before stage-1, so that we can expect the new code (but when > I tried it seems that this needs some adjustments to the build system)? > Or should I add an alternative definition via CPP in > compiler/utils/UniqFM.lhs? Or is it not worth it and I should wait until > 7.9 (which would then drop the requirement to be bootstrappable with > 7.4, right?) > > > Thanks, > Joachim > > > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://www.haskell.org/mailman/listinfo/ghc-devs > From mail at joachim-breitner.de Mon Dec 16 21:10:34 2013 From: mail at joachim-breitner.de (Joachim Breitner) Date: Mon, 16 Dec 2013 22:10:34 +0100 Subject: Using features from containers-0.5 In-Reply-To: <52AED434.2000104@gmail.com> References: <1387125345.2563.11.camel@kirk> <52AED434.2000104@gmail.com> Message-ID: <1387228234.10096.7.camel@kirk> Hi, Am Montag, den 16.12.2013, 10:21 +0000 schrieb Simon Marlow: > So that means, after the 7.8 release, the HEAD will support only 7.6 and > 7.8. So that means you'll be able to use containers-0.5 after the 7.8 > branch split (but not merge any patches that require it onto the branch). > > The other way around this is to make containers into a zero-boot > package, but we typically wouldn't do this for just one function. ok; I changed the code to use the older containers functions, with the new implementation in a comment, to be used later. Greetings, Joachim -- Joachim ?nomeata? Breitner mail at joachim-breitner.de ? http://www.joachim-breitner.de/ Jabber: nomeata at joachim-breitner.de ? GPG-Key: 0x4743206C Debian Developer: nomeata at debian.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part URL: From efsubenovex at gmail.com Mon Dec 16 23:18:20 2013 From: efsubenovex at gmail.com (Schell Scivally) Date: Mon, 16 Dec 2013 15:18:20 -0800 Subject: arm-apple-darwin10-cabal install woes Message-ID: Hi all, I posted this earlier to the haskell-iphone list and heard it may be better off here. I'm having trouble installing primitive from hackage with arm-apple-darwin10-cabal. It seems a funky error is happening that is not getting written out or logged. Here is the output from my attempted install from hackage after a `rm -rf ~/.cabal` and `arm-apple-darwin10-cabal update`: http://lpaste.net/97092. Nothiing is listed in the log mentioned. So I tried installing from the git repo and got the same error. Then I tried to configure build and then install and the build phase spat out: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ranlib: archive library: dist-arm/build/libHSprimitive-0.5.2.0.a will be fat and ar(1) will not be able to operate on it In-place registering primitive-0.5.2.0... So it seems it's building but not linking? Maybe I shouldn't be developing with cabal? What's the normal procedure here? -- Schell Scivally http://blog.efnx.com http://github.com/schell http://twitter.com/schellsan -------------- next part -------------- An HTML attachment was scrubbed... URL: From mail at joachim-breitner.de Tue Dec 17 15:39:04 2013 From: mail at joachim-breitner.de (Joachim Breitner) Date: Tue, 17 Dec 2013 16:39:04 +0100 Subject: eqExprX - dead code? Message-ID: <1387294744.2450.11.camel@kirk> Hi, I came across some seemingly dead code, but I?d like to ask here before I clean it up. (Generally, cleaning up dead code is desirable, right?) The function eqExprX takes a parameter id_unfolding_fun which allows it to look through variable unfoldings. But the only use of this fuction is in eqExpr, which passes "const noUnfolding". Therefore, the two fancy cases in lines 1351-1362 never apply: http://git.haskell.org/ghc.git/blob/HEAD:/compiler/coreSyn/CoreUtils.lhs#l1329 Some archeology: In Dec 2010, SPJ removed a use of eqExprX from the CSE module, which made use of that parameter (aae915d6). Thinking about it, it is probably safe to clean up the code. And if not, I?m not going to be offended by a "git revert", but just doing the change instead of waiting for permission seems to be more efficient to me. Greetings, Joachim -- Joachim ?nomeata? Breitner mail at joachim-breitner.de ? http://www.joachim-breitner.de/ Jabber: nomeata at joachim-breitner.de ? GPG-Key: 0x4743206C Debian Developer: nomeata at debian.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part URL: From krz.gogolewski at gmail.com Tue Dec 17 18:28:14 2013 From: krz.gogolewski at gmail.com (Krzysztof Gogolewski) Date: Tue, 17 Dec 2013 19:28:14 +0100 Subject: Renaming Void# Message-ID: Hello, Small bikeshedding: I propose to rename recently added Void# (in GHC.Prim) to Unit#, and void# to unit#. As far as I understand, this type is the unboxed equivalent of () (i.e. single-element type) rather than Void (i.e. empty type). The name Void# might be reserved for a type which has completely no inhabitants. Any comments? KG -------------- next part -------------- An HTML attachment was scrubbed... URL: From ekmett at gmail.com Tue Dec 17 18:33:05 2013 From: ekmett at gmail.com (Edward Kmett) Date: Tue, 17 Dec 2013 13:33:05 -0500 Subject: Renaming Void# In-Reply-To: References: Message-ID: The change makes sense to me. Others? On Tue, Dec 17, 2013 at 1:28 PM, Krzysztof Gogolewski < krz.gogolewski at gmail.com> wrote: > Hello, > > Small bikeshedding: I propose to rename recently added Void# (in GHC.Prim) > to Unit#, and void# to unit#. As far as I understand, this type is the > unboxed equivalent of () (i.e. single-element type) rather than Void (i.e. > empty type). The name Void# might be reserved for a type which has > completely no inhabitants. Any comments? > > KG > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://www.haskell.org/mailman/listinfo/ghc-devs > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From roma at ro-che.info Tue Dec 17 19:45:34 2013 From: roma at ro-che.info (Roman Cheplyaka) Date: Tue, 17 Dec 2013 21:45:34 +0200 Subject: Renaming Void# In-Reply-To: References: Message-ID: <20131217194534.GA16740@sniper> Have you read the Note [Nullary unboxed tuple] in compiler/types/Type.lhs? I think it addresses this, although I'm not going to pretend I understand what's going on there. Roman * Krzysztof Gogolewski [2013-12-17 19:28:14+0100] > Hello, > > Small bikeshedding: I propose to rename recently added Void# (in GHC.Prim) > to Unit#, and void# to unit#. As far as I understand, this type is the > unboxed equivalent of () (i.e. single-element type) rather than Void (i.e. > empty type). The name Void# might be reserved for a type which has > completely no inhabitants. Any comments? > > KG > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://www.haskell.org/mailman/listinfo/ghc-devs -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: Digital signature URL: From ekmett at gmail.com Tue Dec 17 20:04:28 2013 From: ekmett at gmail.com (Edward Kmett) Date: Tue, 17 Dec 2013 15:04:28 -0500 Subject: Renaming Void# In-Reply-To: <20131217194534.GA16740@sniper> References: <20131217194534.GA16740@sniper> Message-ID: That doesn't seem to be saying anything motivating the choice of name, just motivates the existence of some nullary unboxed type. -Edward On Tue, Dec 17, 2013 at 2:45 PM, Roman Cheplyaka wrote: > Have you read the Note [Nullary unboxed tuple] in compiler/types/Type.lhs? > I think it addresses this, although I'm not going to pretend I > understand what's going on there. > > Roman > > * Krzysztof Gogolewski [2013-12-17 > 19:28:14+0100] > > Hello, > > > > Small bikeshedding: I propose to rename recently added Void# (in > GHC.Prim) > > to Unit#, and void# to unit#. As far as I understand, this type is the > > unboxed equivalent of () (i.e. single-element type) rather than Void > (i.e. > > empty type). The name Void# might be reserved for a type which has > > completely no inhabitants. Any comments? > > > > KG > > > _______________________________________________ > > ghc-devs mailing list > > ghc-devs at haskell.org > > http://www.haskell.org/mailman/listinfo/ghc-devs > > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://www.haskell.org/mailman/listinfo/ghc-devs > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mail at joachim-breitner.de Tue Dec 17 23:50:45 2013 From: mail at joachim-breitner.de (Joachim Breitner) Date: Wed, 18 Dec 2013 00:50:45 +0100 Subject: Common Context transformation for join points In-Reply-To: <1386811726.2470.33.camel@kirk> References: <1386811726.2470.33.camel@kirk> Message-ID: <1387324245.29442.12.camel@kirk> Hi, I created a first prototype of this optimization (branch wip/common-context), and the results are a clear, although very small win in some benchmarks, and no regression (ignoring the flaky cacheprof): -------------------------------------------------------------------------------- Program Size Allocs Runtime Elapsed TotalMem -------------------------------------------------------------------------------- cacheprof -0.0% +0.1% +2.4% +2.4% +0.0% fibheaps -0.0% -0.3% 0.02 0.02 +0.0% fluid -0.1% -0.0% 0.01 0.01 +0.0% gamteb -0.0% -0.3% 0.04 0.04 +0.0% ida -0.0% -1.4% 0.06 0.06 +0.0% scs -0.0% -0.2% -0.5% -0.5% +0.0% simple -0.0% -0.8% 0.15 0.15 +0.0% -------------------------------------------------------------------------------- Min -0.1% -1.4% -4.5% -4.5% +0.0% Max -0.0% +0.1% +3.3% +3.3% +6.7% Geometric Mean -0.0% -0.0% +0.2% +0.2% +0.1% I don?t have much experience with performance numbers in GHC yet, but I guess a geometric mean of -0.0% is not something to get excited about. Maybe in conjunction with CPR and nested CPR, there will be a combined benefit. Not sure why size does not go down generally, as I expected the optimization to take code that is generated more than once, and move it to where it is generated only once. Greetings, Joachim -- Joachim ?nomeata? Breitner mail at joachim-breitner.de ? http://www.joachim-breitner.de/ Jabber: nomeata at joachim-breitner.de ? GPG-Key: 0x4743206C Debian Developer: nomeata at debian.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part URL: From jpm at cs.uu.nl Wed Dec 18 13:07:09 2013 From: jpm at cs.uu.nl (=?ISO-8859-1?Q?Jos=E9_Pedro_Magalh=E3es?=) Date: Wed, 18 Dec 2013 14:07:09 +0100 Subject: Renaming Void# In-Reply-To: References: Message-ID: +1 On Tue, Dec 17, 2013 at 7:33 PM, Edward Kmett wrote: > The change makes sense to me. Others? > > > On Tue, Dec 17, 2013 at 1:28 PM, Krzysztof Gogolewski < > krz.gogolewski at gmail.com> wrote: > >> Hello, >> >> Small bikeshedding: I propose to rename recently added Void# (in >> GHC.Prim) to Unit#, and void# to unit#. As far as I understand, this type >> is the unboxed equivalent of () (i.e. single-element type) rather than Void >> (i.e. empty type). The name Void# might be reserved for a type which has >> completely no inhabitants. Any comments? >> >> KG >> >> _______________________________________________ >> ghc-devs mailing list >> ghc-devs at haskell.org >> http://www.haskell.org/mailman/listinfo/ghc-devs >> >> > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://www.haskell.org/mailman/listinfo/ghc-devs > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From aaron at frieltek.com Thu Dec 19 15:47:46 2013 From: aaron at frieltek.com (Aaron Friel) Date: Thu, 19 Dec 2013 15:47:46 +0000 Subject: Building GHC in a small amount of memory, in parts. In-Reply-To: References: Message-ID: <43bc172d76324a26aa893727bf8efb9c@BN1PR05MB171.namprd05.prod.outlook.com> I am trying to build GHC-HEAD and produce a reliable Dockerfile (see: docker.io) to allow others to use GHC-HEAD and also to make my own build process more reliable. I would like advice/assistance on two things to help this. For reference, I am using the stackbrew/ubuntu:13.10 image as my starting point, and bootstrapping GHC to HEAD using the current GHC (7.6.x) in Ubuntu's repositories. First issue: I am having issues with constraining the resource consumption during the build and have resorted to a few hacks such as replacing ld with gold (or rather, a script that filters out --hash-size arguments) and a custom build.mk file that uses -fasm for stage1. I would also like the final (stage 2?) result to be compiled with llvm, perhaps even without requiring gcc installed at all. How can I continue to push down the resource requirements of a build, and end up with a GHC that represents the bleeding edge? (That is what I want to be testing against, finding bugs for, etc.) Here is my build.mk: ################## BUILD.MK # Default to a very fast build for compilation and stage1: SRC_HC_OPTS = -H64m -O0 GhcStage1HcOpts = -O -fasm # But then use perf-llvm settings for remaining settings: GhcStage2HcOpts = -O2 -fllvm GhcHcOpts = -Rghc-timing GhcLibHcOpts = -O2 -fllvm -XGenerics GhcLibWays += p DYNAMIC_BY_DEFAULT = NO DYNAMIC_GHC_PROGRAMS = NO # Disable building all docs HADDOCK_DOCS = NO BUILD_DOCBOOK_HTML = NO BUILD_DOCBOOK_PS = NO BUILD_DOCBOOK_PDF = NO ################## BUILD.MK Second issue: These seem to bring memory usage down, but the monolithic ".\make" command is difficult to debug and very time consuming. When building a container image from a Dockerfile, the commands used are cached so that subsequent attempted builds use the intermediate results. So, even though my Dockerfile starts out with "apt-get update; apt-get upgrade -y", I don't have to do that every time I retry my build. Currently my Dockerfile pulls all the requisite packages from Ubuntu's repos, downloads and builds the latest cabal-install and builds alex, happy, hscolour and haddock, gets the ghc repo from GitHub, does "perl boot" ".\configure" and then I hit a wall with the monstrous amount of work that ".\make" does. I have tried splitting it up by doing ".\make stage=1", ".\make 1", and various combinations, but I hit dependency issues. Is there a way to break up the build into multiple commands? -------------- next part -------------- An HTML attachment was scrubbed... URL: From marlowsd at gmail.com Fri Dec 20 10:16:12 2013 From: marlowsd at gmail.com (Simon Marlow) Date: Fri, 20 Dec 2013 10:16:12 +0000 Subject: LLVM and dynamic linking In-Reply-To: <877gb7ulmi.fsf@gmail.com> References: <877gb7ulmi.fsf@gmail.com> Message-ID: <52B418EC.8090308@gmail.com> This sounds right to me. Did you submit a patch? Note that dynamic linking with LLVM is likely to produce significantly worse code that with the NCG right now, because the LLVM back end uses dynamic references even for symbols in the same package, whereas the NCG back-end uses direct static references for these. Cheers, Simon On 14/12/2013 22:13, Ben Gamari wrote: > > # The Problem > > Dynamic linking is currently broken with the LLVM code generator. This > can be easily seen by attempting to compile GHC with, > > GhcDynamic = YES > DYNAMIC_BY_DEFAULT = YES > DYNAMIC_GHC_PROGRAMS = YES > BuildFlavour = quick-llvm > > This build will fail with a error along the lines of, > > dll-split: internal error: invalid closure, info=0x402ec0 > (GHC version 7.7.20131212 for x86_64_unknown_linux) > Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug > > After some poking around with the help of Peter Wortmann, it seems clear > that this is due to a subtle difference in how LLVM emits function > symbols. While the NCG emits these symbols with `.type @object`, LLVM > emits `.type @function`. > > It appears that the `.type` annotation guides the linker in choosing the > relocation mechanism to use for the symbol. While `@object` symbols use > the Global Offset Table, `@function` symbols are relocated through the > Procedure Linking Table, a table of trampoline calls which are fixed up > at runtime. This means that static references to functions end up > pointing not to the object itself (and its info table) but instead to > some linker-generated assembly. When the garbage collector attempts to > examine the info table of one of these references, it finds nonsense and > fails. > > # A solution > > Peter demonstrated that manually modifying the assembler produced by > llc, passing this through GHC's mangler, and assembling the result > yields a functional binary. > > As far as I can tell, LLVM's intermediate language doesn't expose any > way to force a function to `.type @object`. Unfortunately this means > that, at least for now, the only fix is to augment the mangler with > logic to perform this transform. I've done this in my `llvm-dynamic` > branch[1] (in addition to finding a bug in the `rewriteInstructions` > function used by AVX rewriting). > > This branch compiles on my x86_64 machine to produce what appears to be > a functional compiler. Unfortunately installation issues (which I'll > describe shortly in a new thread) prevent me from verifying this. I'm > currently waiting for a build on my ARM box but assuming this fix works > this means that GHC could (finally) have first-class, stable ARM support. > > Comments? > > Cheers, > > - Ben > > > [1] https://github.com/bgamari/ghc/tree/llvm-dynamic > > > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://www.haskell.org/mailman/listinfo/ghc-devs > From gergo at erdi.hu Fri Dec 20 12:45:28 2013 From: gergo at erdi.hu (Dr. ERDI Gergo) Date: Fri, 20 Dec 2013 20:45:28 +0800 (SGT) Subject: Help needed: adding pattern synonym support to Haddock Message-ID: Hi, I've started looking at adding pattern synonym support to Haddock (as part of #5144), but I've realized that pattern synonyms are different enough from other, existing declarations that are processed by Haddock that I'd like to discuss it first. Who would be 'the Haddock guy' to talk to? Thanks, Gergo -- .--= ULLA! =-----------------. \ http://gergo.erdi.hu \ `---= gergo at erdi.hu =-------' Duct tape is like the force; it has a light side and a dark side, and it holds the universe together. From fuuzetsu at fuuzetsu.co.uk Fri Dec 20 12:49:19 2013 From: fuuzetsu at fuuzetsu.co.uk (Mateusz Kowalczyk) Date: Fri, 20 Dec 2013 12:49:19 +0000 Subject: Help needed: adding pattern synonym support to Haddock In-Reply-To: References: Message-ID: <52B43CCF.5070900@fuuzetsu.co.uk> On 20/12/13 12:45, Dr. ERDI Gergo wrote: > Hi, > > I've started looking at adding pattern synonym support to Haddock (as part > of #5144), but I've realized that pattern synonyms are different enough > from other, existing declarations that are processed by Haddock that I'd > like to discuss it first. Who would be 'the Haddock guy' to talk to? > > Thanks, > Gergo > Simon Marlow probably has a lot of the information you need, especially considering that he's usually current with what's going on in GHC. The current Haddock maintainers are Simon Hengel and David Waern. -- Mateusz K. From bgamari.foss at gmail.com Fri Dec 20 13:45:50 2013 From: bgamari.foss at gmail.com (Ben Gamari) Date: Fri, 20 Dec 2013 08:45:50 -0500 Subject: LLVM and dynamic linking In-Reply-To: <52B418EC.8090308@gmail.com> References: <877gb7ulmi.fsf@gmail.com> <52B418EC.8090308@gmail.com> Message-ID: <87r4974ovl.fsf@gmail.com> Simon Marlow writes: > This sounds right to me. Did you submit a patch? > Not yet, I'm currently fighting through some build system issues which are preventing me from actually installing and testing the compiler on my ARM box. > Note that dynamic linking with LLVM is likely to produce significantly > worse code that with the NCG right now, because the LLVM back end uses > dynamic references even for symbols in the same package, whereas the NCG > back-end uses direct static references for these. > Right. However it (hopefully) works on ARM which is more than I can say about the NCG. Moreover, I'm hopeful that it will be possible to fix LLVM's output. Would this not simply be a matter of flagging package-local symbols with LLVM's `private` linkage type[1]? In the case where you have references both internal and external to the package could you not define two overlapping symbols, one flagged with `private` and the other `external`? Perhaps I'm missing a subtlety? Cheers, - Ben [1] http://llvm.org/docs/LangRef.html#linkage-types -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 489 bytes Desc: not available URL: From bgamari.foss at gmail.com Sun Dec 22 17:34:25 2013 From: bgamari.foss at gmail.com (Ben Gamari) Date: Sun, 22 Dec 2013 12:34:25 -0500 Subject: Interface loading and dynamic linking Message-ID: <87wqiwpz6m.fsf@gmail.com> In trying to test my LLVM-dynamic linking changes, I've encountered some builds which fail with, Bad interface file: dist-install/build/GHC/CString.hi mismatched interface file ways (wanted "dyn", got "") during `make install`. The failing command is `ghc-stage2`, invoked by `ghc-cabal`, ../../inplace/bin/ghc-stage2 '-B/opt/exp/ghc/root-ghc-7.8-dyn/lib/ghc-7.7.20131221' '--abi-hash' '-fbuilding-cabal-package' '-O' '-outputdir' 'dist-install/build' '-odir' 'dist-install/build' '-hidir' 'dist-install/build' '-stubdir' 'dist-install/build' '-i' '-idist-install/build' '-i.' '-idist-install/build/autogen' '-Idist-install/build/autogen' '-Idist-install/build' '-optP-include' '-optPdist-install/build/autogen/cabal_macros.h' '-package-name' 'ghc-prim-0.3.1.0' '-hide-all-packages' '-no-user-package-db' '-package-id' 'builtin_rts' '-XHaskell2010' 'GHC.CString' 'GHC.Classes' 'GHC.Debug' 'GHC.IntWord64' 'GHC.Magic' 'GHC.PrimopWrappers' 'GHC.Tuple' 'GHC.Types' 'GHC.Prim' '-package-name' 'ghc-prim' The build is on an x86_64 box with `build.mk` containing, GhcDebugged = YES DYNAMIC_BY_DEFAULT = YES # Roughly BuildFlavour=quick-llvm without disabling dynamic linking SRC_HC_OPTS = -H64m -O0 -fllvm # -keep-llvm-files GhcStage1HcOpts = -O -fllvm GhcStage2HcOpts = -O0 -fllvm GhcLibHcOpts = -O -fllvm SplitObjs = NO HADDOCK_DOCS = NO BUILD_DOCBOOK_HTML = NO BUILD_DOCBOOK_PS = NO BUILD_DOCBOOK_PDF = NO I've spent the morning tracing through the interface loading code and have finally met an impasse. As far as I can tell, the relevant subset of the call graph is, LoadIface.lhs: loadInterface LoadIface.lhs : findAndReadIface Finder.hs: findExactModule Finder.hs: findHomeModule Finder.hs: homeSearchCache Finder.hs: findHomeModule findAndReadIface(read_file) findAndReadIface(checkBuildDynamicToo) whenGeneratingDynamicToo TcRnMonad.hs: withDoDynamicToo DynFlags.hs: dynamicTooMkDynamicDynFlags findAndReadIface(read_file) where findAndReadIFace(read_file) LoadIface.lhs : readIface BinIface.hs : readBinIface Up until `checkBuildDynamicToo` the dynflags have, ways dflags == [WayDyn] buildTag dflags == "dyn" hiSuf dflags == "hi" dynHiSuf dflags == "dyn_hi" Given this, it's perhaps unsurprising that `readBinIface` gets quite confused when it attempts to read `dist-install/build/GHC/CString.hi` to find that it was compiled with a null tag, not `dyn` as expected. If I add `-static` to the command line the build succeeds. However, adding `-dynamic` or `-dynamic-too` or omitting all of the above (due to `DYNAMIC_BY_DEFAULT`) all fail. It seems that `findAndReadIface` attempts to account for `-dynamic-too` but I don't see how the approach should work: it tries to first load the static interface file (but with `ways==[WayDyn]`) then tries again to load the interface using `DynFlags` and .hi file name constructed for the dynamic case. I can't see how this would ever work as `readBinIface` will expect to see a dynamic interface file due to the DynFlags' ways. It's also unclear how the `-dynamic` case (not `-dynamic-too`) is handled under this scheme. I would have thought that running with `-dynamic` would cause `hiSuf == dynHiSuf` but I can't find any code to suggest this is the case. Could someone offer some insight into how interface loading, `-dynamic`, and `-dynamic-too` are supposed to interact? Thanks, - Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 489 bytes Desc: not available URL: From coreyoconnor at gmail.com Sun Dec 22 19:17:39 2013 From: coreyoconnor at gmail.com (Corey O'Connor) Date: Sun, 22 Dec 2013 11:17:39 -0800 Subject: ticket for adding ARM backend to NCG? Message-ID: Is there an existing ticket or wiki page describing the work required for adding an ARM backend to the NCG? I tried the following search with no luck: https://ghc.haskell.org/trac/ghc/query?status=infoneeded&status=merge&status=new&status=patch&component=Compiler+(NCG)&col=id&col=summary&col=status&col=type&col=priority&col=milestone&col=component&order=priority -Corey O'Connor coreyoconnor at gmail.com http://corebotllc.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From igloo at earth.li Sun Dec 22 19:58:52 2013 From: igloo at earth.li (Ian Lynagh) Date: Sun, 22 Dec 2013 19:58:52 +0000 Subject: Interface loading and dynamic linking In-Reply-To: <87wqiwpz6m.fsf@gmail.com> References: <87wqiwpz6m.fsf@gmail.com> Message-ID: <20131222195852.GA28658@matrix.chaos.earth.li> On Sun, Dec 22, 2013 at 12:34:25PM -0500, Ben Gamari wrote: > > DYNAMIC_BY_DEFAULT = YES Dynamic-by-default was a previous experiment to get GHCi to use the system linker. We now use dynamic-too instead. I'm not sure whether dynamic-by-default works, and in any case it's probably not something we want to keep supporting. I'd recommend removing it. Thanks Ian From carter.schonwald at gmail.com Sun Dec 22 22:14:11 2013 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Sun, 22 Dec 2013 17:14:11 -0500 Subject: ticket for adding ARM backend to NCG? In-Reply-To: References: Message-ID: I believe there are no current plans to add arm to the ncg. However, I'm hoping to spend a wee bit of time later this year cleaning up the ncg, and one consequence of that that simon marlow remarked upon at icfp is that would perhaps make it easier to add new targets to ncg. Which arm variant are you thinking of? There's quite a few arm isa variants. Also once Ben gamari's current debugging is sorted, we'll have stage 2 support for arm with ghci tooo. What's your interest and or use case? Cheers Carter On Sunday, December 22, 2013, Corey O'Connor wrote: > Is there an existing ticket or wiki page describing the work required for > adding an ARM backend to the NCG? > > I tried the following search with no luck: > > > https://ghc.haskell.org/trac/ghc/query?status=infoneeded&status=merge&status=new&status=patch&component=Compiler+(NCG)&col=id&col=summary&col=status&col=type&col=priority&col=milestone&col=component&order=priority > > -Corey O'Connor > coreyoconnor at gmail.com 'coreyoconnor at gmail.com');> > http://corebotllc.com/ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bgamari.foss at gmail.com Sun Dec 22 23:56:11 2013 From: bgamari.foss at gmail.com (Ben Gamari) Date: Sun, 22 Dec 2013 18:56:11 -0500 Subject: Interface loading and dynamic linking In-Reply-To: <20131222195852.GA28658@matrix.chaos.earth.li> References: <87wqiwpz6m.fsf@gmail.com> <20131222195852.GA28658@matrix.chaos.earth.li> Message-ID: <87bo084ezo.fsf@gmail.com> Ian Lynagh writes: > On Sun, Dec 22, 2013 at 12:34:25PM -0500, Ben Gamari wrote: >> >> DYNAMIC_BY_DEFAULT = YES > > Dynamic-by-default was a previous experiment to get GHCi to use the > system linker. We now use dynamic-too instead. > Causing GHCi to use the system linker is indeed my intent. Given the currently rather broken state of the ARM runtime linker it seems like the easiest way to get ARM supported as somewhat-first-class citizen is to use the system linker. `DYNAMIC_BY_DEFAULT` provides an easy way to accomplish this. I've now reproduced the error on both my x86_64 laptop and my ARM box. It seems that the only effect of `DYNAMIC_BY_DEFAULT` is to set the default ways. Even with `-dynamic` or `-dynamic-too` set explicitly the error persists so I don't believe that the option itself is the issue. Cheers, - Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 489 bytes Desc: not available URL: From mle+hs at mega-nerd.com Mon Dec 23 02:07:59 2013 From: mle+hs at mega-nerd.com (Erik de Castro Lopo) Date: Mon, 23 Dec 2013 13:07:59 +1100 Subject: ticket for adding ARM backend to NCG? In-Reply-To: References: Message-ID: <20131223130759.463580657bd05f4bca3a725c@mega-nerd.com> Carter Schonwald wrote: > I believe there are no current plans to add arm to the ncg. > > However, I'm hoping to spend a wee bit of time later this year cleaning up Dude, you have 7 days! Or did you mean next year :-). > the ncg, and one consequence of that that simon marlow remarked upon at > icfp is that would perhaps make it easier to add new targets to ncg. As soon as that NCG cleanup is ready for public consumption, please let me know so I can validate the PowerPC NCG. I think I am one of the few people who regularly builds GHC on PowerPC and even I haven't done it for two weeks because I just moved house. Cheers, Erik -- ---------------------------------------------------------------------- Erik de Castro Lopo http://www.mega-nerd.com/ From carter.schonwald at gmail.com Mon Dec 23 03:54:11 2013 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Sun, 22 Dec 2013 22:54:11 -0500 Subject: ticket for adding ARM backend to NCG? In-Reply-To: <20131223130759.463580657bd05f4bca3a725c@mega-nerd.com> References: <20131223130759.463580657bd05f4bca3a725c@mega-nerd.com> Message-ID: I mean next year. I'm hoping to start hacking on it and a few other ncg related tasks early January with about 1-2 evenings of regularly scheduled work on it. So feel welcome to do a Ppc validate anyways in the mean time :-) On Sunday, December 22, 2013, Erik de Castro Lopo wrote: > Carter Schonwald wrote: > > > I believe there are no current plans to add arm to the ncg. > > > > However, I'm hoping to spend a wee bit of time later this year cleaning > up > > Dude, you have 7 days! Or did you mean next year :-). > > > the ncg, and one consequence of that that simon marlow remarked upon at > > icfp is that would perhaps make it easier to add new targets to ncg. > > As soon as that NCG cleanup is ready for public consumption, please > let me know so I can validate the PowerPC NCG. I think I am one of > the few people who regularly builds GHC on PowerPC and even I haven't > done it for two weeks because I just moved house. > > Cheers, > Erik > -- > ---------------------------------------------------------------------- > Erik de Castro Lopo > http://www.mega-nerd.com/ > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://www.haskell.org/mailman/listinfo/ghc-devs > -------------- next part -------------- An HTML attachment was scrubbed... URL: From igloo at earth.li Mon Dec 23 12:04:44 2013 From: igloo at earth.li (Ian Lynagh) Date: Mon, 23 Dec 2013 12:04:44 +0000 Subject: Interface loading and dynamic linking In-Reply-To: <87bo084ezo.fsf@gmail.com> References: <87wqiwpz6m.fsf@gmail.com> <20131222195852.GA28658@matrix.chaos.earth.li> <87bo084ezo.fsf@gmail.com> Message-ID: <20131223120444.GA6405@matrix.chaos.earth.li> On Sun, Dec 22, 2013 at 06:56:11PM -0500, Ben Gamari wrote: > Ian Lynagh writes: > > > On Sun, Dec 22, 2013 at 12:34:25PM -0500, Ben Gamari wrote: > >> > >> DYNAMIC_BY_DEFAULT = YES > > > > Dynamic-by-default was a previous experiment to get GHCi to use the > > system linker. We now use dynamic-too instead. > > > Causing GHCi to use the system linker is indeed my intent. Given the > currently rather broken state of the ARM runtime linker it seems like > the easiest way to get ARM supported as somewhat-first-class citizen is > to use the system linker. `DYNAMIC_BY_DEFAULT` provides an easy way to > accomplish this. You shouldn't need dynamic-by-default. It should Just Work in HEAD, both unregisterised and registerised. Thanks Ian From bgamari.foss at gmail.com Mon Dec 23 17:59:06 2013 From: bgamari.foss at gmail.com (Ben Gamari) Date: Mon, 23 Dec 2013 12:59:06 -0500 Subject: Interface loading and dynamic linking In-Reply-To: <20131223120444.GA6405@matrix.chaos.earth.li> References: <87wqiwpz6m.fsf@gmail.com> <20131222195852.GA28658@matrix.chaos.earth.li> <87bo084ezo.fsf@gmail.com> <20131223120444.GA6405@matrix.chaos.earth.li> Message-ID: <8738lj4ff9.fsf@gmail.com> Ian Lynagh writes: > You shouldn't need dynamic-by-default. It should Just Work in HEAD, both > unregisterised and registerised. > Just to clarify, how does one configure GHCi to use dynamic linking now? Should I interpret your message to mean that it is already configured this way? Where in the tree is this configured? To be perfectly clear, I want to ensure that dynamic linking is always preferred over linking static objects with the RTS linker. Will this happen as things stand? How does GHCi decide how to load a library? Is this the role of GhcDynamic? I'm still not really sure why `DYNAMIC_BY_DEFAULT` should be causing the problems I'm observing. It seems to me that it is functionally equivalent to passing the `-dynamic` flag as they both simply add `WayDyn` to DynFlag's `ways` list. Do you have any idea where they might differ? Cheers, - Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 489 bytes Desc: not available URL: From carter.schonwald at gmail.com Mon Dec 23 18:02:37 2013 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Mon, 23 Dec 2013 13:02:37 -0500 Subject: Interface loading and dynamic linking In-Reply-To: <8738lj4ff9.fsf@gmail.com> References: <87wqiwpz6m.fsf@gmail.com> <20131222195852.GA28658@matrix.chaos.earth.li> <87bo084ezo.fsf@gmail.com> <20131223120444.GA6405@matrix.chaos.earth.li> <8738lj4ff9.fsf@gmail.com> Message-ID: I think part of what Ian is saying is that the default config for a Perf build for HEAD will build the dylib versions of all the libraries. Or am I not understanding the question? eg: see the default make file https://github.com/ghc/ghc/blob/master/mk/build.mk.sample#L55-L75 On Mon, Dec 23, 2013 at 12:59 PM, Ben Gamari wrote: > Ian Lynagh writes: > > > You shouldn't need dynamic-by-default. It should Just Work in HEAD, both > > unregisterised and registerised. > > > Just to clarify, how does one configure GHCi to use dynamic linking now? > Should I interpret your message to mean that it is already configured > this way? Where in the tree is this configured? > > To be perfectly clear, I want to ensure that dynamic linking is always > preferred over linking static objects with the RTS linker. Will this > happen as things stand? How does GHCi decide how to load a library? Is > this the role of GhcDynamic? > > I'm still not really sure why `DYNAMIC_BY_DEFAULT` should be causing the > problems I'm observing. It seems to me that it is functionally equivalent > to passing the `-dynamic` flag as they both simply add `WayDyn` to > DynFlag's > `ways` list. Do you have any idea where they might differ? > > Cheers, > > - Ben > > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://www.haskell.org/mailman/listinfo/ghc-devs > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bgamari.foss at gmail.com Mon Dec 23 18:08:39 2013 From: bgamari.foss at gmail.com (Ben Gamari) Date: Mon, 23 Dec 2013 13:08:39 -0500 Subject: Interface loading and dynamic linking In-Reply-To: References: <87wqiwpz6m.fsf@gmail.com> <20131222195852.GA28658@matrix.chaos.earth.li> <87bo084ezo.fsf@gmail.com> <20131223120444.GA6405@matrix.chaos.earth.li> <8738lj4ff9.fsf@gmail.com> Message-ID: <87zjnr30ew.fsf@gmail.com> Carter Schonwald writes: > I think part of what Ian is saying is that the default config for a Perf > build for HEAD will build the dylib versions of all the libraries. Or am I > not understanding the question? > > eg: see the default make file > https://github.com/ghc/ghc/blob/master/mk/build.mk.sample#L55-L75 > Yes, I understand this. That being said, it will also build static versions. On ARM these static libraries should be avoided as the RTS's linker is still quite broken. Therefore I'd like to ensure that dynamic linking is used whenever possible. Cheers, - Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 489 bytes Desc: not available URL: From carter.schonwald at gmail.com Mon Dec 23 18:43:57 2013 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Mon, 23 Dec 2013 13:43:57 -0500 Subject: Interface loading and dynamic linking In-Reply-To: <87zjnr30ew.fsf@gmail.com> References: <87wqiwpz6m.fsf@gmail.com> <20131222195852.GA28658@matrix.chaos.earth.li> <87bo084ezo.fsf@gmail.com> <20131223120444.GA6405@matrix.chaos.earth.li> <8738lj4ff9.fsf@gmail.com> <87zjnr30ew.fsf@gmail.com> Message-ID: why would the RTS linker be used? I'm not understanding that piece. I thought static linking and dynamic linking both use the system linkers now. Are you meaning the rts linker use for ghci in <= 7.6? On Mon, Dec 23, 2013 at 1:08 PM, Ben Gamari wrote: > Carter Schonwald writes: > > > I think part of what Ian is saying is that the default config for a Perf > > build for HEAD will build the dylib versions of all the libraries. Or am > I > > not understanding the question? > > > > eg: see the default make file > > https://github.com/ghc/ghc/blob/master/mk/build.mk.sample#L55-L75 > > > Yes, I understand this. That being said, it will also build static > versions. On ARM these static libraries should be avoided as the RTS's > linker is still quite broken. Therefore I'd like to ensure that dynamic > linking is used whenever possible. > > Cheers, > > - Ben > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bgamari.foss at gmail.com Mon Dec 23 19:07:30 2013 From: bgamari.foss at gmail.com (Ben Gamari) Date: Mon, 23 Dec 2013 14:07:30 -0500 Subject: Interface loading and dynamic linking In-Reply-To: References: <87wqiwpz6m.fsf@gmail.com> <20131222195852.GA28658@matrix.chaos.earth.li> <87bo084ezo.fsf@gmail.com> <20131223120444.GA6405@matrix.chaos.earth.li> <8738lj4ff9.fsf@gmail.com> <87zjnr30ew.fsf@gmail.com> Message-ID: <87txdz2xot.fsf@gmail.com> Carter Schonwald writes: > why would the RTS linker be used? I'm not understanding that piece. I > thought static linking and dynamic linking both use the system linkers now. > Are you meaning the rts linker use for ghci in <= 7.6? > As far as I know, the RTS linker is always used in the static case. The system dynamic linker is just that, a dynamic linker for linking dynamic objects. This could just be a misconception I somehow formed, but that is my understanding. Cheers, - Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 489 bytes Desc: not available URL: From kazu at iij.ad.jp Tue Dec 24 06:11:22 2013 From: kazu at iij.ad.jp (Kazu Yamamoto (=?iso-2022-jp?B?GyRCOzNLXE9CSScbKEI=?=)) Date: Tue, 24 Dec 2013 15:11:22 +0900 (JST) Subject: whats our timeline for 7.8 release? In-Reply-To: References: Message-ID: <20131224.151122.806529637268798149.kazu@iij.ad.jp> Hi, > many many folks are wondering about when 7.8 is going to hit RC officially. > What are the bugs / blockers / etc that are left to deal with? > We should at least aim to communicate whats going on instead of leaving > folks wondering. Would somebody answer this question? I'm also wondering. --Kazu From carter.schonwald at gmail.com Tue Dec 24 06:34:26 2013 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Tue, 24 Dec 2013 01:34:26 -0500 Subject: whats our timeline for 7.8 release? In-Reply-To: <20131224.151122.806529637268798149.kazu@iij.ad.jp> References: <20131224.151122.806529637268798149.kazu@iij.ad.jp> Message-ID: indeed! At this point, I think wee all agree theres a few known bugs that are being tracked down, so maybe its time to do an RC to start shaking out any thing thats not been caught yet? @Austin / @Simon / @HVR, are there any current blockers for saying "we have an RC" sometime in the next week? On Tue, Dec 24, 2013 at 1:11 AM, Kazu Yamamoto wrote: > Hi, > > > many many folks are wondering about when 7.8 is going to hit RC > officially. > > What are the bugs / blockers / etc that are left to deal with? > > We should at least aim to communicate whats going on instead of leaving > > folks wondering. > > Would somebody answer this question? > I'm also wondering. > > --Kazu > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://www.haskell.org/mailman/listinfo/ghc-devs > -------------- next part -------------- An HTML attachment was scrubbed... URL: From aaron at frieltek.com Tue Dec 24 22:13:40 2013 From: aaron at frieltek.com (Aaron Friel) Date: Tue, 24 Dec 2013 22:13:40 +0000 Subject: Normal for make install to (re?)build libraries with stage1 compiler? Message-ID: <1fafffe71b9a4adb91a449e8c503bb46@BN1PR05MB171.namprd05.prod.outlook.com> Still working on getting my own development environment configured, I am seeing make install perform a lot of rebuilds of libraries: > "inplace/bin/ghc-stage1" -hisuf hi -osuf o -hcsuf hc -static -H64m -O0 -fasm -package-name base-4.7.0.0 -hide-all-packages -i -ilibraries/base/. -ilibraries/base/dist-install/build -ilibraries/base/dist-install/build/autogen -Ilibraries/base/dist-install/build -Ilibraries/base/dist-install/build/autogen -Ilibraries/base/include -optP-DOPTIMISE_INTEGER_GCD_LCM -optP-include -optPlibraries/base/dist-install/build/autogen/cabal_macros.h -package ghc-prim-0.3.1.0 -package integer-gmp-0.5.1.0 -package rts-1.0 -package-name base -XHaskell2010 -O2 -fllvm -no-user-package-db -rtsopts -odir libraries/base/dist-install/build -hidir libraries/base/dist-install/build -stubdir libraries/base/dist-install/build -split-objs -c libraries/base/./GHC/IO/Encoding/Types.hs -o libraries/base/dist-install/build/GHC/IO/Encoding/Types.o However, GHC has already been built to stage 2. Why is GHC inplace/bin/stage1 being invoked here - and hasn?t this library already been built by make? -------------- next part -------------- An HTML attachment was scrubbed... URL: From klangner at gmail.com Wed Dec 25 10:43:57 2013 From: klangner at gmail.com (Krzysztof Langner) Date: Wed, 25 Dec 2013 11:43:57 +0100 Subject: My first patch Message-ID: Hello, Since I'm new here I will first introduce myself. My name is Krzysztof and I have more then 20 years experience with object oriented languages. Recently I learned about functional programming. And I really like it. Because my current project uses OO languages (no FP) I decided to try to engage with GHC development to learn Haskell. So here is my first patch. It is related to the ticket: https://ghc.haskell.org/trac/ghc/ticket/5412 I just changed error message so it should be easier (I hope) to understand what has happened. No functionality was changed. The patch is attached to the ticket. Should I submit it to someone to review? -- Thanks Krzysztof Langner -------------- next part -------------- An HTML attachment was scrubbed... URL: From mail at joachim-breitner.de Wed Dec 25 10:52:15 2013 From: mail at joachim-breitner.de (Joachim Breitner) Date: Wed, 25 Dec 2013 11:52:15 +0100 Subject: My first patch In-Reply-To: References: Message-ID: <1387968735.5664.1.camel@kirk> Hi, Am Mittwoch, den 25.12.2013, 11:43 +0100 schrieb Krzysztof Langner: > So here is my first patch. It is related to the ticket: > https://ghc.haskell.org/trac/ghc/ticket/5412 > > > I just changed error message so it should be easier (I hope) to > understand what has happened. No functionality was changed. The patch > is attached to the ticket. > > > Should I submit it to someone to review? attaching the patch to the ticket, and setting its status to ?please review? is the right thing to do. Note that you should attach a ".diff", not a ".diff.gz", so that we can review it directly in trac. Greetings, Joachim -- Joachim ?nomeata? Breitner mail at joachim-breitner.de ? http://www.joachim-breitner.de/ Jabber: nomeata at joachim-breitner.de ? GPG-Key: 0x4743206C Debian Developer: nomeata at debian.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part URL: From klangner at gmail.com Wed Dec 25 11:07:23 2013 From: klangner at gmail.com (Krzysztof Langner) Date: Wed, 25 Dec 2013 12:07:23 +0100 Subject: My first patch In-Reply-To: <1387968735.5664.1.camel@kirk> References: <1387968735.5664.1.camel@kirk> Message-ID: 2013/12/25 Joachim Breitner > Hi, > > Am Mittwoch, den 25.12.2013, 11:43 +0100 schrieb Krzysztof Langner: > > > So here is my first patch. It is related to the ticket: > > https://ghc.haskell.org/trac/ghc/ticket/5412 > > > > > > I just changed error message so it should be easier (I hope) to > > understand what has happened. No functionality was changed. The patch > > is attached to the ticket. > > > > > > Should I submit it to someone to review? > > attaching the patch to the ticket, and setting its status to ?please > review? is the right thing to do. Note that you should attach a ".diff", > not a ".diff.gz", so that we can review it directly in trac. > > Done. Thank you for the information. -- Thanks Krzysztof -------------- next part -------------- An HTML attachment was scrubbed... URL: From kazu at iij.ad.jp Fri Dec 27 01:07:16 2013 From: kazu at iij.ad.jp (Kazu Yamamoto (=?iso-2022-jp?B?GyRCOzNLXE9CSScbKEI=?=)) Date: Fri, 27 Dec 2013 10:07:16 +0900 (JST) Subject: panic when compiling SHA Message-ID: <20131227.100716.1812997308262292710.kazu@iij.ad.jp> Hi, When I tried to build the SHA library with GHC head on on 32bit Linux, GHC head got panic. GHC 7.4.2 can build SHA on the same machine. Configuring SHA-1.6.1... Building SHA-1.6.1... Failed to install SHA-1.6.1 Last 10 lines of the build log ( /home/kazu/work/rpf/.cabal-sandbox/logs/SHA-1.6.1.log ): Preprocessing library SHA-1.6.1... [1 of 1] Compiling Data.Digest.Pure.SHA ( Data/Digest/Pure/SHA.hs, dist/dist-sandbox-ef3aaa11/build/Data/Digest/Pure/SHA.o ) ghc: panic! (the 'impossible' happened) (GHC version 7.7.20131202 for i386-unknown-linux): regSpill: out of spill slots! regs to spill = 1129 slots left = 677 Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug --Kazu From targen at gmail.com Fri Dec 27 01:47:33 2013 From: targen at gmail.com (=?UTF-8?Q?Manuel_G=C3=B3mez?=) Date: Thu, 26 Dec 2013 21:17:33 -0430 Subject: panic when compiling SHA In-Reply-To: <20131227.100716.1812997308262292710.kazu@iij.ad.jp> References: <20131227.100716.1812997308262292710.kazu@iij.ad.jp> Message-ID: On Thu, Dec 26, 2013 at 8:37 PM, Kazu Yamamoto wrote: > When I tried to build the SHA library with GHC head on on 32bit Linux, > GHC head got panic. GHC 7.4.2 can build SHA on the same machine. > > [1 of 1] Compiling Data.Digest.Pure.SHA ( Data/Digest/Pure/SHA.hs, dist/dist-sandbox-ef3aaa11/build/Data/Digest/Pure/SHA.o ) > ghc: panic! (the 'impossible' happened) > (GHC version 7.7.20131202 for i386-unknown-linux): > regSpill: out of spill slots! > regs to spill = 1129 > slots left = 677 I ran into this a while ago. Turns out it?s a known bug[0], but it seems like it?s been hard to reproduce. FWIW, I also hit it on 32bit Linux. You can probably work around it with `-fno-regs-graph`. [0]: From nathan.d.howell at gmail.com Fri Dec 27 03:30:24 2013 From: nathan.d.howell at gmail.com (Nathan Howell) Date: Thu, 26 Dec 2013 19:30:24 -0800 Subject: GeneralizedNewtypeDeriving regression in HEAD? Message-ID: I can't file a trac ticket at the meny but wanted to see if this is a bug... This is an excerpt from llvm-general that compiles on 7.6.3 but doesn't without ImpredicativeTypes enabled on HEAD: https://gist.github.com/NathanHowell/8138977 thanks, -n -------------- next part -------------- An HTML attachment was scrubbed... URL: From eir at cis.upenn.edu Fri Dec 27 03:51:33 2013 From: eir at cis.upenn.edu (Richard Eisenberg) Date: Thu, 26 Dec 2013 22:51:33 -0500 Subject: GeneralizedNewtypeDeriving regression in HEAD? In-Reply-To: References: Message-ID: I would say you do indeed need impredicative types to compile the instance you request -- you need to instantiate a type variable with a forall-type. But, whether or not we should require users to actually specify ImpredicativeTypes to compile code that we're generating is another question. And, the error message is terrible, regardless. I'll post. Thanks for bringing this up! Richard On Dec 26, 2013, at 10:30 PM, Nathan Howell wrote: > I can't file a trac ticket at the meny but wanted to see if this is a bug... This is an excerpt from llvm-general that compiles on 7.6.3 but doesn't without ImpredicativeTypes enabled on HEAD: https://gist.github.com/NathanHowell/8138977 > > thanks, > -n > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://www.haskell.org/mailman/listinfo/ghc-devs -------------- next part -------------- An HTML attachment was scrubbed... URL: From carter.schonwald at gmail.com Fri Dec 27 18:33:58 2013 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Fri, 27 Dec 2013 13:33:58 -0500 Subject: RC timeline for 7.8 REDUX Message-ID: Hey Everyone, what is the set of tasks left before we can do a 7.8 RC? Is it there are some serious bugs that have been left unaddressed? Is there anything preventing us from doing an RC sometime in the next two weeks? I understand certain type system related problems have been getting a bit of polish over the past month or so, but if thats the blocker I'd like to know so that when people ask I can point to a concrete reason. I can only speak for myself, but theres been a pretty painful communication gap about whats left before we hit RC, and whenever someone asks me "when is 7.8 coming out, and how can i help make it happen on time?", I can only reply with "no one knows" and "do stuff". that said, happy holidays and preemptive happy new years to everyone! -Carter -------------- next part -------------- An HTML attachment was scrubbed... URL: From bgamari.foss at gmail.com Fri Dec 27 20:21:28 2013 From: bgamari.foss at gmail.com (Ben Gamari) Date: Fri, 27 Dec 2013 15:21:28 -0500 Subject: LLVM and dynamic linking In-Reply-To: <52B418EC.8090308@gmail.com> References: <877gb7ulmi.fsf@gmail.com> <52B418EC.8090308@gmail.com> Message-ID: <87a9fm2gfr.fsf@gmail.com> Simon Marlow writes: > This sounds right to me. Did you submit a patch? > > Note that dynamic linking with LLVM is likely to produce significantly > worse code that with the NCG right now, because the LLVM back end uses > dynamic references even for symbols in the same package, whereas the NCG > back-end uses direct static references for these. > Today with the help of Edward Yang I examined the code produced by the LLVM backend in light of this statement. I was surprised to find that LLVM's code appears to be no worse than the NCG with respect to intra-package references. My test case can be found here[2] and can be built with the included `build.sh` script. The test consists of two modules build into a shared library. One module, `LibTest`, exports a few simple members while the other module (`LibTest2`) defines members that consume them. Care is taken to ensure the members are not inlined. The tests were done on x86_64 running LLVM 3.4 and GHC HEAD with the patches[1] I referred to in my last message. Please let me know if I've missed something. # Evaluation ## First example ## The first member is a simple `String` (defined in `LibTest`), helloWorld :: String helloWorld = "Hello World!" The use-site is quite straightforward, testHelloWorld :: IO String testHelloWorld = return helloWorld With `-O1` the code looks reasonable in both cases. Most importantly, both backends use IP relative addressing to find the symbol. ### LLVM ### 0000000000000ef8 : ef8: 48 8b 45 00 mov 0x0(%rbp),%rax efc: 48 8d 1d cd 11 20 00 lea 0x2011cd(%rip),%rbx # 2020d0 f03: ff e0 jmpq *%rax 0000000000000f28 : f28: eb ce jmp ef8 f2a: 66 0f 1f 44 00 00 nopw 0x0(%rax,%rax,1) ### NCG ### 0000000000000d58 : d58: 48 8d 1d 71 13 20 00 lea 0x201371(%rip),%rbx # 2020d0 d5f: ff 65 00 jmpq *0x0(%rbp) 0000000000000d88 : d88: eb ce jmp d58 With `-O0` the code is substantially longer but the relocation behavior is still correct, as one would expect. Looking at the definition of `helloWorld`[3] itself it becomes clear that the LLVM backend is more likely to use PLT relocations over GOT. In general, `stg_*` primitives are called through the PLT. As far as I can tell, both of these call mechanisms will incur two memory accesses. However, in the case of the PLT the call will consist of two JMPs whereas the GOT will consist of only one. Is this a cause for concern? Could these two jumps interfere with prediction? In general the LLVM backend produces a few more instructions than the NCG although this doesn't appear to be related to handling of relocations. For instance, the inexplicable (to me) `mov` at the beginning of LLVM's `rKw_info`. ## Second example ## The second example demonstrates an actual call, -- Definition (in LibTest) infoRef :: Int -> Int infoRef n = n + 1 -- Call site testInfoRef :: IO Int testInfoRef = return (infoRef 2) With `-O1` this produces the following code, ### LLVM ### 0000000000000fb0 : fb0: 48 8b 45 00 mov 0x0(%rbp),%rax fb4: 48 8d 1d a5 10 20 00 lea 0x2010a5(%rip),%rbx # 202060 fbb: ff e0 jmpq *%rax 0000000000000fe0 : fe0: eb ce jmp fb0 ### NCG ### 0000000000000e10 : e10: 48 8d 1d 51 12 20 00 lea 0x201251(%rip),%rbx # 202068 e17: ff 65 00 jmpq *0x0(%rbp) 0000000000000e40 : e40: eb ce jmp e10 Again, it seems that LLVM is a bit more verbose but seems to handle intra-package calls efficiently. [1] https://github.com/bgamari/ghc/commits/llvm-dynamic [2] https://github.com/bgamari/ghc-linking-tests/tree/master/ghc-test [3] `helloWorld` definitions: LLVM: 00000000000010a8 : 10a8: 50 push %rax 10a9: 4c 8d 75 f0 lea -0x10(%rbp),%r14 10ad: 4d 39 fe cmp %r15,%r14 10b0: 73 07 jae 10b9 10b2: 49 8b 45 f0 mov -0x10(%r13),%rax 10b6: 5a pop %rdx 10b7: ff e0 jmpq *%rax 10b9: 4c 89 ef mov %r13,%rdi 10bc: 48 89 de mov %rbx,%rsi 10bf: e8 0c fd ff ff callq dd0 10c4: 48 85 c0 test %rax,%rax 10c7: 74 22 je 10eb 10c9: 48 8b 0d 18 0f 20 00 mov 0x200f18(%rip),%rcx # 201fe8 <_DYNAMIC+0x228> 10d0: 48 89 4d f0 mov %rcx,-0x10(%rbp) 10d4: 48 89 45 f8 mov %rax,-0x8(%rbp) 10d8: 48 8d 05 21 00 00 00 lea 0x21(%rip),%rax # 1100 10df: 4c 89 f5 mov %r14,%rbp 10e2: 49 89 c6 mov %rax,%r14 10e5: 58 pop %rax 10e6: e9 b5 fc ff ff jmpq da0 10eb: 48 8b 03 mov (%rbx),%rax 10ee: 5a pop %rdx 10ef: ff e0 jmpq *%rax NCG: 0000000000000ef8 : ef8: 48 8d 45 f0 lea -0x10(%rbp),%rax efc: 4c 39 f8 cmp %r15,%rax eff: 72 3f jb f40 f01: 4c 89 ef mov %r13,%rdi f04: 48 89 de mov %rbx,%rsi f07: 48 83 ec 08 sub $0x8,%rsp f0b: b8 00 00 00 00 mov $0x0,%eax f10: e8 1b fd ff ff callq c30 f15: 48 83 c4 08 add $0x8,%rsp f19: 48 85 c0 test %rax,%rax f1c: 74 20 je f3e f1e: 48 8b 1d cb 10 20 00 mov 0x2010cb(%rip),%rbx # 201ff0 <_DYNAMIC+0x238> f25: 48 89 5d f0 mov %rbx,-0x10(%rbp) f29: 48 89 45 f8 mov %rax,-0x8(%rbp) f2d: 4c 8d 35 1c 00 00 00 lea 0x1c(%rip),%r14 # f50 f34: 48 83 c5 f0 add $0xfffffffffffffff0,%rbp f38: ff 25 7a 10 20 00 jmpq *0x20107a(%rip) # 201fb8 <_DYNAMIC+0x200> f3e: ff 23 jmpq *(%rbx) f40: 41 ff 65 f0 jmpq *-0x10(%r13) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 489 bytes Desc: not available URL: From carter.schonwald at gmail.com Fri Dec 27 20:41:10 2013 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Fri, 27 Dec 2013 15:41:10 -0500 Subject: LLVM and dynamic linking In-Reply-To: <87a9fm2gfr.fsf@gmail.com> References: <877gb7ulmi.fsf@gmail.com> <52B418EC.8090308@gmail.com> <87a9fm2gfr.fsf@gmail.com> Message-ID: great work! :) On Fri, Dec 27, 2013 at 3:21 PM, Ben Gamari wrote: > Simon Marlow writes: > > > This sounds right to me. Did you submit a patch? > > > > Note that dynamic linking with LLVM is likely to produce significantly > > worse code that with the NCG right now, because the LLVM back end uses > > dynamic references even for symbols in the same package, whereas the NCG > > back-end uses direct static references for these. > > > Today with the help of Edward Yang I examined the code produced by the > LLVM backend in light of this statement. I was surprised to find that > LLVM's code appears to be no worse than the NCG with respect to > intra-package references. > > My test case can be found here[2] and can be built with the included > `build.sh` script. The test consists of two modules build into a shared > library. One module, `LibTest`, exports a few simple members while the > other module (`LibTest2`) defines members that consume them. Care is > taken to ensure the members are not inlined. > > The tests were done on x86_64 running LLVM 3.4 and GHC HEAD with the > patches[1] I referred to in my last message. Please let me know if I've > missed something. > > > > # Evaluation > > ## First example ## > > The first member is a simple `String` (defined in `LibTest`), > > helloWorld :: String > helloWorld = "Hello World!" > > The use-site is quite straightforward, > > testHelloWorld :: IO String > testHelloWorld = return helloWorld > > With `-O1` the code looks reasonable in both cases. Most importantly, > both backends use IP relative addressing to find the symbol. > > ### LLVM ### > > 0000000000000ef8 : > ef8: 48 8b 45 00 mov 0x0(%rbp),%rax > efc: 48 8d 1d cd 11 20 00 lea 0x2011cd(%rip),%rbx > # 2020d0 > f03: ff e0 jmpq *%rax > > 0000000000000f28 : > f28: eb ce jmp ef8 > f2a: 66 0f 1f 44 00 00 nopw 0x0(%rax,%rax,1) > > ### NCG ### > > 0000000000000d58 : > d58: 48 8d 1d 71 13 20 00 lea 0x201371(%rip),%rbx > # 2020d0 > d5f: ff 65 00 jmpq *0x0(%rbp) > > 0000000000000d88 : > d88: eb ce jmp d58 > > > With `-O0` the code is substantially longer but the relocation behavior > is still correct, as one would expect. > > Looking at the definition of `helloWorld`[3] itself it becomes clear that > the LLVM backend is more likely to use PLT relocations over GOT. In > general, `stg_*` primitives are called through the PLT. As far as I can > tell, both of these call mechanisms will incur two memory > accesses. However, in the case of the PLT the call will consist of two > JMPs whereas the GOT will consist of only one. Is this a cause for > concern? Could these two jumps interfere with prediction? > > In general the LLVM backend produces a few more instructions than the > NCG although this doesn't appear to be related to handling of > relocations. For instance, the inexplicable (to me) `mov` at the > beginning of LLVM's `rKw_info`. > > > ## Second example ## > > The second example demonstrates an actual call, > > -- Definition (in LibTest) > infoRef :: Int -> Int > infoRef n = n + 1 > > -- Call site > testInfoRef :: IO Int > testInfoRef = return (infoRef 2) > > With `-O1` this produces the following code, > > ### LLVM ### > > 0000000000000fb0 : > fb0: 48 8b 45 00 mov 0x0(%rbp),%rax > fb4: 48 8d 1d a5 10 20 00 lea 0x2010a5(%rip),%rbx > # 202060 > fbb: ff e0 jmpq *%rax > > 0000000000000fe0 : > fe0: eb ce jmp fb0 > > ### NCG ### > > 0000000000000e10 : > e10: 48 8d 1d 51 12 20 00 lea 0x201251(%rip),%rbx > # 202068 > e17: ff 65 00 jmpq *0x0(%rbp) > > 0000000000000e40 : > e40: eb ce jmp e10 > > Again, it seems that LLVM is a bit more verbose but seems to handle > intra-package calls efficiently. > > > > [1] https://github.com/bgamari/ghc/commits/llvm-dynamic > [2] https://github.com/bgamari/ghc-linking-tests/tree/master/ghc-test > [3] `helloWorld` definitions: > > LLVM: > 00000000000010a8 : > 10a8: 50 push %rax > 10a9: 4c 8d 75 f0 lea -0x10(%rbp),%r14 > 10ad: 4d 39 fe cmp %r15,%r14 > 10b0: 73 07 jae 10b9 > > 10b2: 49 8b 45 f0 mov -0x10(%r13),%rax > 10b6: 5a pop %rdx > 10b7: ff e0 jmpq *%rax > 10b9: 4c 89 ef mov %r13,%rdi > 10bc: 48 89 de mov %rbx,%rsi > 10bf: e8 0c fd ff ff callq dd0 > 10c4: 48 85 c0 test %rax,%rax > 10c7: 74 22 je 10eb > > 10c9: 48 8b 0d 18 0f 20 00 mov 0x200f18(%rip),%rcx > # 201fe8 <_DYNAMIC+0x228> > 10d0: 48 89 4d f0 mov %rcx,-0x10(%rbp) > 10d4: 48 89 45 f8 mov %rax,-0x8(%rbp) > 10d8: 48 8d 05 21 00 00 00 lea 0x21(%rip),%rax # > 1100 > 10df: 4c 89 f5 mov %r14,%rbp > 10e2: 49 89 c6 mov %rax,%r14 > 10e5: 58 pop %rax > 10e6: e9 b5 fc ff ff jmpq da0 > > 10eb: 48 8b 03 mov (%rbx),%rax > 10ee: 5a pop %rdx > 10ef: ff e0 jmpq *%rax > > > NCG: > > 0000000000000ef8 : > ef8: 48 8d 45 f0 lea -0x10(%rbp),%rax > efc: 4c 39 f8 cmp %r15,%rax > eff: 72 3f jb f40 > > f01: 4c 89 ef mov %r13,%rdi > f04: 48 89 de mov %rbx,%rsi > f07: 48 83 ec 08 sub $0x8,%rsp > f0b: b8 00 00 00 00 mov $0x0,%eax > f10: e8 1b fd ff ff callq c30 > f15: 48 83 c4 08 add $0x8,%rsp > f19: 48 85 c0 test %rax,%rax > f1c: 74 20 je f3e > > f1e: 48 8b 1d cb 10 20 00 mov 0x2010cb(%rip),%rbx > # 201ff0 <_DYNAMIC+0x238> > f25: 48 89 5d f0 mov %rbx,-0x10(%rbp) > f29: 48 89 45 f8 mov %rax,-0x8(%rbp) > f2d: 4c 8d 35 1c 00 00 00 lea 0x1c(%rip),%r14 # > f50 > f34: 48 83 c5 f0 add $0xfffffffffffffff0,%rbp > f38: ff 25 7a 10 20 00 jmpq *0x20107a(%rip) # > 201fb8 <_DYNAMIC+0x200> > f3e: ff 23 jmpq *(%rbx) > f40: 41 ff 65 f0 jmpq *-0x10(%r13) > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://www.haskell.org/mailman/listinfo/ghc-devs > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From eir at cis.upenn.edu Fri Dec 27 21:37:42 2013 From: eir at cis.upenn.edu (Richard Eisenberg) Date: Fri, 27 Dec 2013 16:37:42 -0500 Subject: RC timeline for 7.8 REDUX In-Reply-To: References: Message-ID: <0F4E9FB1-0B4E-4CD4-BE29-9A88FDE9BEC8@cis.upenn.edu> As someone CC'd on this email directly, I'll answer for myself: While I've benefited from the delay to fine-tune the behavior of certain bits & bobs, I didn't request the delay nor do I believe myself responsible for generating or needing to fix any "blocking" feature. Please correct me if I'm wrong here. From my vantage point, I'm ready to move to RC, and have been for some time. Richard On Dec 27, 2013, at 1:33 PM, Carter Schonwald wrote: > Hey Everyone, > what is the set of tasks left before we can do a 7.8 RC? Is it there are some serious bugs that have been left unaddressed? Is there anything preventing us from doing an RC sometime in the next two weeks? > > I understand certain type system related problems have been getting a bit of polish over the past month or so, but if thats the blocker I'd like to know so that when people ask I can point to a concrete reason. > > I can only speak for myself, but theres been a pretty painful communication gap about whats left before we hit RC, and whenever someone asks me "when is 7.8 coming out, and how can i help make it happen on time?", I can only reply with "no one knows" and "do stuff". > > that said, happy holidays and preemptive happy new years to everyone! > -Carter From carter.schonwald at gmail.com Fri Dec 27 22:14:27 2013 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Fri, 27 Dec 2013 17:14:27 -0500 Subject: RC timeline for 7.8 REDUX In-Reply-To: <0F4E9FB1-0B4E-4CD4-BE29-9A88FDE9BEC8@cis.upenn.edu> References: <0F4E9FB1-0B4E-4CD4-BE29-9A88FDE9BEC8@cis.upenn.edu> Message-ID: gotcha. I didn't mean to imply any such responsibility, i merely cc'd the folks who i know have been actively hacking on stuff thats landing in 7.8 in the past monthish because they are more apt to be informed (one hopes :) ) thanks! -Carter On Fri, Dec 27, 2013 at 4:37 PM, Richard Eisenberg wrote: > As someone CC'd on this email directly, I'll answer for myself: While I've > benefited from the delay to fine-tune the behavior of certain bits & bobs, > I didn't request the delay nor do I believe myself responsible for > generating or needing to fix any "blocking" feature. Please correct me if > I'm wrong here. From my vantage point, I'm ready to move to RC, and have > been for some time. > > Richard > > On Dec 27, 2013, at 1:33 PM, Carter Schonwald > wrote: > > > Hey Everyone, > > what is the set of tasks left before we can do a 7.8 RC? Is it there are > some serious bugs that have been left unaddressed? Is there anything > preventing us from doing an RC sometime in the next two weeks? > > > > I understand certain type system related problems have been getting a > bit of polish over the past month or so, but if thats the blocker I'd like > to know so that when people ask I can point to a concrete reason. > > > > I can only speak for myself, but theres been a pretty painful > communication gap about whats left before we hit RC, and whenever someone > asks me "when is 7.8 coming out, and how can i help make it happen on > time?", I can only reply with "no one knows" and "do stuff". > > > > that said, happy holidays and preemptive happy new years to everyone! > > -Carter > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From benl at ouroborus.net Sat Dec 28 03:58:30 2013 From: benl at ouroborus.net (Ben Lippmeier) Date: Sat, 28 Dec 2013 14:58:30 +1100 Subject: panic when compiling SHA In-Reply-To: <20131227.100716.1812997308262292710.kazu@iij.ad.jp> References: <20131227.100716.1812997308262292710.kazu@iij.ad.jp> Message-ID: <501EC3C7-E7EF-4485-879A-404FFFF22F55@ouroborus.net> On 27/12/2013, at 12:07 PM, Kazu Yamamoto (????) wrote: > Hi, > > When I tried to build the SHA library with GHC head on on 32bit Linux, > GHC head got panic. GHC 7.4.2 can build SHA on the same machine. > > Configuring SHA-1.6.1... > Building SHA-1.6.1... > Failed to install SHA-1.6.1 > Last 10 lines of the build log ( /home/kazu/work/rpf/.cabal-sandbox/logs/SHA-1.6.1.log ): > Preprocessing library SHA-1.6.1... > [1 of 1] Compiling Data.Digest.Pure.SHA ( Data/Digest/Pure/SHA.hs, dist/dist-sandbox-ef3aaa11/build/Data/Digest/Pure/SHA.o ) > ghc: panic! (the 'impossible' happened) > (GHC version 7.7.20131202 for i386-unknown-linux): > regSpill: out of spill slots! > regs to spill = 1129 > slots left = 677 There are only a fixed number of register spill slots, and when they're all used the compiler can't dynamically allocate more of them. This SHA benchmark is pathological in that the intermediate code expands to have many variables with long, overlapping live ranges. The underlying problem is really that the inliner and/or other optimisations have gone crazy and made a huge intermediate program. We *could* give it more spill slots, to make it compile, but the generated code would be horrible. Try turning down the optimisation level, reduce inliner keenness, or reduce SpecConstr flags. Ben. From fuuzetsu at fuuzetsu.co.uk Sat Dec 28 16:53:29 2013 From: fuuzetsu at fuuzetsu.co.uk (Mateusz Kowalczyk) Date: Sat, 28 Dec 2013 16:53:29 +0000 Subject: Validating with Haddock Message-ID: <52BF0209.6020000@fuuzetsu.co.uk> Greetings, I'm trying to validate HEAD and I care that Haddock is built alongside it (so --no-haddock is not an option). I get the following errors listed at the bottom of this e-mail. How can I validate so that it all builds? >From what I understand, to validate I should: * Have a stable compiler in my PATH (7.6.3) * go to top level directory * run ?sh validate? Am I missing steps? == Start post-build package check Timestamp 2013-12-28 05:00:55 UTC for /home/shana/.ghc/i386-linux-7.7.20131227/package.conf.d/package.cache Timestamp 2013-12-28 05:00:55 UTC for /home/shana/.ghc/i386-linux-7.7.20131227/package.conf.d (same as cache) using cache: /home/shana/.ghc/i386-linux-7.7.20131227/package.conf.d/package.cache Timestamp 2013-12-28 05:22:27 UTC for /home/shana/programming/ghc/inplace/lib/package.conf.d/package.cache Timestamp 2013-12-28 05:22:27 UTC for /home/shana/programming/ghc/inplace/lib/package.conf.d (same as cache) using cache: /home/shana/programming/ghc/inplace/lib/package.conf.d/package.cache There are problems in package xhtml-3000.2.1: dependency "base-4.7.0.0-578628bf142f9304d05ce5581b5f8d76" doesn't exist There are problems in package ghc-paths-0.1.0.9: dependency "base-4.7.0.0-578628bf142f9304d05ce5581b5f8d76" doesn't exist The following packages are broken, either because they have a problem listed above, or because they depend on a broken package. xhtml-3000.2.1 ghc-paths-0.1.0.9 -- Mateusz K. From gergo at erdi.hu Sun Dec 29 06:38:14 2013 From: gergo at erdi.hu (Dr. ERDI Gergo) Date: Sun, 29 Dec 2013 14:38:14 +0800 (SGT) Subject: Preparing for a review of pattern synonyms In-Reply-To: <52A5AAD3.1020200@gmail.com> References: <59543203684B2244980D7E4057D5FBC1486E61B5@DB3EX14MBXC308.europe.corp.microsoft.com> <52A5AAD3.1020200@gmail.com> Message-ID: On Mon, 9 Dec 2013, Simon Marlow wrote: > I think pattern synonyms are great! A couple of questions: > > * what will Haddock show for a pattern export? I eventually ended up implementing the following syntax for Haddock output (code is at https://github.com/gergoerdi/ghc-haddock): pattern (Prov b) => P a b :: (Req a) => T a e.g. pattern a :< (Seq a) :: Seq a for pattern x :< xs <- (Seq.viewl -> x Seq.:< xs) or pattern Zero :: (Num a, Eq a) => a for pattern Zero = 0 Bye, Gergo From simonpj at microsoft.com Mon Dec 30 12:56:08 2013 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Mon, 30 Dec 2013 12:56:08 +0000 Subject: Renaming Void# In-Reply-To: References: <20131217194534.GA16740@sniper> Message-ID: <59543203684B2244980D7E4057D5FBC1486FC94F@DB3EX14MBXC306.europe.corp.microsoft.com> I?d be ok with making this change. If you do, it?d be worth searching for ?void? in comments in GHC?s source code, and updating them appropriately. Simon From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of Edward Kmett Sent: 17 December 2013 20:04 To: Roman Cheplyaka Cc: ghc-devs Subject: Re: Renaming Void# That doesn't seem to be saying anything motivating the choice of name, just motivates the existence of some nullary unboxed type. -Edward On Tue, Dec 17, 2013 at 2:45 PM, Roman Cheplyaka > wrote: Have you read the Note [Nullary unboxed tuple] in compiler/types/Type.lhs? I think it addresses this, although I'm not going to pretend I understand what's going on there. Roman * Krzysztof Gogolewski > [2013-12-17 19:28:14+0100] > Hello, > > Small bikeshedding: I propose to rename recently added Void# (in GHC.Prim) > to Unit#, and void# to unit#. As far as I understand, this type is the > unboxed equivalent of () (i.e. single-element type) rather than Void (i.e. > empty type). The name Void# might be reserved for a type which has > completely no inhabitants. Any comments? > > KG > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://www.haskell.org/mailman/listinfo/ghc-devs _______________________________________________ ghc-devs mailing list ghc-devs at haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs -------------- next part -------------- An HTML attachment was scrubbed... URL: From simonpj at microsoft.com Mon Dec 30 14:13:22 2013 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Mon, 30 Dec 2013 14:13:22 +0000 Subject: whats our timeline for 7.8 release? In-Reply-To: <20131224.151122.806529637268798149.kazu@iij.ad.jp> References: <20131224.151122.806529637268798149.kazu@iij.ad.jp> Message-ID: <59543203684B2244980D7E4057D5FBC1486FDAEE@DB3EX14MBXC306.europe.corp.microsoft.com> I'm just back from holiday. In my last conversation with Austin we were expecting a release candidate before Christmas. I don't think there are any show-stopping bugs; the last one was the irritating limitation to 64k symbols in Windows DLLs which was making it hard to build GHC on Windows, but I think we worked out how to hack around that. I expect Austin is on holiday now, but I'll check with him when he gets back. Simon -----Original Message----- From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of Kazu Yamamoto Sent: 24 December 2013 06:11 To: ghc-devs at haskell.org Subject: Re: whats our timeline for 7.8 release? Hi, > many many folks are wondering about when 7.8 is going to hit RC officially. > What are the bugs / blockers / etc that are left to deal with? > We should at least aim to communicate whats going on instead of > leaving folks wondering. Would somebody answer this question? I'm also wondering. --Kazu _______________________________________________ ghc-devs mailing list ghc-devs at haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs From simonpj at microsoft.com Tue Dec 31 10:07:50 2013 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Tue, 31 Dec 2013 10:07:50 +0000 Subject: More GND + role inference woes In-Reply-To: References: <59543203684B2244980D7E4057D5FBC14864A4A7@DB3EX14MBXC308.europe.corp.microsoft.com> <878uvnuml9.fsf@gmail.com> <8738lvudyg.fsf@gmail.com> Message-ID: <59543203684B2244980D7E4057D5FBC1486FE86F@DB3EX14MBXC306.europe.corp.microsoft.com> So I think we are agreed that what is currently implemented is the right thing; and that it?s expressive enough for now. There?s a lot of interesting stuff in this thread that it would be a shame to lose. It would be great if the wiki page on roles could cover this stuff: https://ghc.haskell.org/trac/ghc/wiki/Roles Specifically, ? the way that GND is implemented (as described in the attached email) by looking at the method types, is manifestly non-obvious (since we missed it for ages) ? Richard?s observations about the things it still doesn?t do are interesting ? Some poster-child examples for where the simple roles we have are insufficiently expressive and a sketch of how it could be extended if necessary (I agree with Richard?s assessment that it?s not worth it right now). Richard, you are the obvious person to do this, if you have time. Maybe just pointers to the right places would do. Simon From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of Edward Kmett Sent: 15 December 2013 09:28 To: Ben Gamari Cc: ghc-devs Subject: Re: More GND + role inference woes Correct. With 7.8 we'll need to hand-implement those instances rather than derive them. On Sat, Dec 14, 2013 at 7:59 PM, Ben Gamari > wrote: Richard Eisenberg > writes: > Yes, I believe that's right. As far as I can figure out, these classes > really *are* problematic, in that if we allowed > GeneralizedNewtypeDeriving for them, there would be a way to subvert > the type system. To make these derivable, we would need to be able to > restrict various type parameters from taking on values that take a > nominal argument. Without the ability to restrict the values in this > way, there could be trouble. > I suppose it's unlikely that the roles mechanism will be extended to allow for such restriction? Cheers, - Ben -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- An embedded message was scrubbed... From: Simon Peyton-Jones Subject: RE: More GND + role inference woes Date: Wed, 16 Oct 2013 13:28:28 +0000 Size: 48528 URL: -------------- next part -------------- An embedded message was scrubbed... From: Richard Eisenberg Subject: Re: More GND + role inference woes Date: Sun, 15 Dec 2013 01:06:08 +0000 Size: 4517 URL: From johan.tibell at gmail.com Tue Dec 31 10:54:04 2013 From: johan.tibell at gmail.com (Johan Tibell) Date: Tue, 31 Dec 2013 11:54:04 +0100 Subject: We need a bugfix release for 7.6 or get 7.8 soon to support OS X Mavericks Message-ID: Hi all, It's getting more urgent to have a working GHC on OS X Mavericks. 35% [1] of OS X users are now on Mavericks and won't have a working GHC unless they jump through some hoops [2]. If we don't think we can have 7.8 out in the next few days, I think we should consider making a minimal 7.6.x release to make things work on OS X again. 1. https://www.gosquared.com/mavericks/ 2. https://gist.github.com/mzero/7245290 -- Johan -------------- next part -------------- An HTML attachment was scrubbed... URL: From simonpj at microsoft.com Tue Dec 31 11:33:26 2013 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Tue, 31 Dec 2013 11:33:26 +0000 Subject: Common Context transformation for join points In-Reply-To: <1386811726.2470.33.camel@kirk> References: <1386811726.2470.33.camel@kirk> Message-ID: <59543203684B2244980D7E4057D5FBC1486FE960@DB3EX14MBXC306.europe.corp.microsoft.com> Joachim Interesting. We can discuss when you get back, but let me jot down one comment. You write: | This will always happen if the join point function gets a richer | CPR property than the function that it belongs to Good observation. Maybe we can exploit it directly rather than figuring out "common contexts"? If we knew, for each local function, whether it was a join point, and if so for what, we could just make its inferred CPR property no richer than its "parent", perhaps. Simon | -----Original Message----- | From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of | Joachim Breitner | Sent: 12 December 2013 01:29 | To: ghc-devs at haskell.org | Subject: Common Context transformation for join points | | Hi all, | | I just came up with this, and unless I write it down I doubt I?ll be | able to fall asleep. | | The problem I?m trying to solve is the bad interaction of the CPR worker | wrapper transformation and join points. Consider, as a running example: | | f x = | let $j n = Just (Int# (n +# 1)) | in case x of | A -> $j 1 | B -> $j 2 | C -> Just undefined | | The join point $j has the important property that in the final code, it | can be jumped to, because its result is also the result of f, so no | function closure has to be allocated for it. It seems that this is | crucial for performance. | | But now lets do CPR, and just for demonstration, do nested CPR (the | effect can also occur with non-nested CPR). Doing w/w we get | | $wf x = case ( | let $w$j n = n +# 1 | $j n = Just (Int# ($w$j n)) | in case x of | A -> $j 1 | B -> $j 2 | C -> Just undefined | ) of Just n -> n | f x = Just ($wf x) | | now we simplify, i.e. move the worker transformation inside, and inline | $j?s wrapper. (I hope I am doing this right; but this is what I expect | to happen): | | $wf x = | let $w$j n = n+1 | in case x of | A -> Int# ($w$j 1) | B -> Int# ($w$j 2) | C -> undefined | f x = Just ($wf x) | | So f?s worker transformation has nicely canceled with the invocations of | Just, but it still leaves a "Int#" invocation around $w$j, so we lose | the no-let-escape property of it and get worse code in the backend. This | will always happen if the join point function gets a richer CPR property | than the function that it belongs to, and is the reason for some hacks | in the CPR code (i.e. no CPR for locally stuff that returns a sum | type... not nice.) | | I think I have a solution for this. One observation is that these $j- | functions are not really functions of their own. For this transformation | (and possibly for others), one should try to treat them so that they | behave as if they were inlined. So here is the idea: | | We do not do any w/w for $j at first, on the premise that it is not a | proper function of its own. We do w/w for f as before, and simplify as | before, ending up with | | $wf x = | let $j n = Just (Int# (n +# 1)) | in case x of | A -> case $j 1 of Just n -> n | B -> case $j 2 of Just n -> n | C -> undefined | f x = Just ($wf x) | | so we temporarily broke the property. Now a new simplifier step kicks | in: For a let that looks like it was or should be a join point (hand | waving here ? one could possibly do it for all non-recursive lets, maybe | there is even more to gain), we find out | | for all uses of $j applied to its arity number of arguments, | what is the largest common context? | | where a context is | * ?, the trivial context, | * case c of ..., where c is a context, and ... does not contain a | call to $j, | * f c, where c is a context and f does not contain a call to $j, | or | * c x, where c is a context and f does not contain a call to $j. | In particular we do not include code here where $j is part of an | alternative of a case. (Casts should ok fine as well, ignoring them for | now.) | | In our example, the context would be "case ? of Just n -> n". | | Once we have found that, I believe it will be always safe and beneficial | to replace the body e of $j by c[e], and in the body of the let replace | every c[$j args..] by $j args. | | In our example, we would obtain | | $wf x = | let ?j n = case Just (Int# (n +# 1)) of Just n -> n in case x of | A -> $j 1 | B -> $j 2 | C -> undefined | f x = Just ($wf x) | | which then in further steps simplifies to the in all respects ideal code | | $wf x = | let ?j n = Int# (n +# 1)) | in case x of | A -> $j 1 | B -> $j 2 | C -> undefined | f x = Just ($wf x) | | | Implementationwise I figured that this will need two traversals (down | and up each) of the let body: Starting from a let binding that looks | promising (e.g. one-shot non-recursive lambda), walk down the body until | invocations of the right arity are found. Then walk back returning a | growing contest, and at case-expressions lub these contexts by taking | their common prefix (or suffix, depends on how they are | represented :-)). Then decide whether the transformation is useful (i.e. | the context is non-trivial), and if so, walk back down to find the $j | invocations again, and then walk back, removing the final context while | doing so. | | | I believe this would make some let-no-escape-related reluctanceness in | the CPR-analysis obsolete, which would be great. And it might be a | worthwhile transformation on its own (if it actually does occur), as it | reduces code size without any downside (as far as I can see). | | | Now it is likely that I thought of something existing here, or of | something that has been tried and found not useful or feasible. If so, | please let me know. | | | Good night, | Joachim | | | -- | Joachim ?nomeata? Breitner | mail at joachim-breitner.de ? http://www.joachim-breitner.de/ | Jabber: nomeata at joachim-breitner.de ? GPG-Key: 0x4743206C | Debian Developer: nomeata at debian.org From mail at joachim-breitner.de Tue Dec 31 11:43:40 2013 From: mail at joachim-breitner.de (Joachim Breitner) Date: Tue, 31 Dec 2013 12:43:40 +0100 Subject: Common Context transformation for join points In-Reply-To: <59543203684B2244980D7E4057D5FBC1486FE960@DB3EX14MBXC306.europe.corp.microsoft.com> References: <1386811726.2470.33.camel@kirk> <59543203684B2244980D7E4057D5FBC1486FE960@DB3EX14MBXC306.europe.corp.microsoft.com> Message-ID: <1388490220.5709.11.camel@kirk> Hi, Am Dienstag, den 31.12.2013, 11:33 +0000 schrieb Simon Peyton-Jones: > Interesting. We can discuss when you get back, but let me jot down > one comment. You write: > > | This will always happen if the join point function gets a richer > | CPR property than the function that it belongs to > > Good observation. Maybe we can exploit it directly rather than > figuring out "common contexts"? If we knew, for each local function, > whether it was a join point, and if so for what, we could just make > its inferred CPR property no richer than its "parent", perhaps. correct, I thought about this as well. It could be a post-processing step, after demand analysis, but before worker-wrapper, that goes through the file and reduces CPR information where it is found to be non-helpful. There is also a related issue with CPR?ing a function whose call is used in a argument position: let f x = ... -- in ... g (f z) ... When is CPR?ing f useful? Only if g will get w/w?ed in a way that cancels with the CPR wrapper of f. And when is that the case? If the demand of g on its first argument is as least as rich as f CPR?s wrapper. Again, if f?s CPR information is richer than g?s demand CPR is not useful. It seems that a generalization of the idea ?fix CPR information to be no richer than useful? will need some kind of demand information on arguments. (In this case, doing CPR of f and then Common Context will clean up any useless unwrapping, if all uses of f have the same problem.) Greetings from Karlsruhe, Joachim -- Joachim ?nomeata? Breitner mail at joachim-breitner.de ? http://www.joachim-breitner.de/ Jabber: nomeata at joachim-breitner.de ? GPG-Key: 0x4743206C Debian Developer: nomeata at debian.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part URL: From carter.schonwald at gmail.com Tue Dec 31 15:26:02 2013 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Tue, 31 Dec 2013 10:26:02 -0500 Subject: We need a bugfix release for 7.6 or get 7.8 soon to support OS X Mavericks In-Reply-To: References: Message-ID: I emphatically agree. I think Darin did some preliminary work back porting fixes to 7.6, but life's gotten busy so he couldn't finish it https://github.com/darinmorrison/ghc On Tuesday, December 31, 2013, Johan Tibell wrote: > Hi all, > > It's getting more urgent to have a working GHC on OS X Mavericks. 35% [1] > of OS X users are now on Mavericks and won't have a working GHC unless they > jump through some hoops [2]. If we don't think we can have 7.8 out in the > next few days, I think we should consider making a minimal 7.6.x release to > make things work on OS X again. > > 1. https://www.gosquared.com/mavericks/ > 2. https://gist.github.com/mzero/7245290 > > -- Johan > > -------------- next part -------------- An HTML attachment was scrubbed... URL: