- ghc-devs - Haskell.org

At long last: 2014.2.0.0 Release Candidate 1
by Mark Lentczner 25 Jul '14

25 Jul '14

*Even I find it hard to believe that it's finally here!* *I'm happy to announce the RC1 release of Haskell Platform 2014.2.0.0.* You can find builds for Windows (32bit and 64bit), Mac (64bit), as well as a source tarball, and a tag in the repo: - source tarball: haskell-platform-2014.2.0.0-RC1.tar.gz <http://www.ozonehouse.com/mark/platform/haskell-platform-2014.2.0.0-RC1.tar…> - source repo: https://github.com/haskell/haskell-platform/tree/2014.2.0.0-RC1 - windows 32bit: HaskellPlatform-2014.2.0.0-i386-RC1-setup.exe <http://www.ozonehouse.com/mark/platform/HaskellPlatform-2014.2.0.0-i386-RC1…> - windows 64bit: HaskellPlatform-2014.2.0.0-x86_64-RC1-setup.exe <http://www.ozonehouse.com/mark/platform/HaskellPlatform-2014.2.0.0-x86_64-R…> - os x 64bit: Haskell Platform 2014.2.0.0 64bit RC1.signed.pkg <http://www.ozonehouse.com/mark/platform/Haskell%20Platform%202014.2.0.0%206…> - travis-ci build: 20 <https://travis-ci.org/haskell/haskell-platform/builds/30723884> *Notes:* General - Built with the new shake based build system - cgi package not included as it doesn't build under 7.8, and no word from the maintainer in quite some time - hscolour is included as a tool, mostly as it is used to build the platform itself on win and mac... but we should probably officially decide to include it - the haskell-platform package itself is not in these releases... not sure if we actually need it as it doesn't contain anything other than dependencies. Windows - The Haskell Platform now provides a native Windows 64-bit installation (haskell-platform issue #54 <https://github.com/haskell/haskell-platform/issues/54>) - All included packages built without --enable-split-objs (GHC 7.8 FAQ <https://ghc.haskell.org/trac/ghc/wiki/GHC-7.8-FAQ#Cabal>) - All included packages built without --enable-shared (GHC ticket #8228 <https://ghc.haskell.org/trac/ghc/ticket/8228>) - All html document links are relative and everything links nicely together now, including the master index and cross-package links - If other Haskell Platform installations are detected during the installation of Haskell Platform 2014.2.0.0, a warning is displayed to the user that this is not recommended since problems will arise due to how the PATH is used in many cases to find ancillary build tools - Using ghci to build an executable that links against a DLL may result in numerous warnings about symbols (GHC ticket #9297 <https://ghc.haskell.org/trac/ghc/ticket/9297>) - On Windows 64-bit, some unneeded python files are included (GHC ticket #9014 <https://ghc.haskell.org/trac/ghc/ticket/9014>) - The Haskell Platform for Windows, both 32-bit and 64-bit, now includes an updated version of the OpenGL Utility Toolkit (GLUT) from the FreeGLUT project, utilizing the pre-built distribution from http://www.transmissionzero.co.uk/software/freeglut-devel/ with the MinGW build (freeglut-MinGW-2.8.1-1.mp.zip). (haskell-platform issue #81 <https://github.com/haskell/haskell-platform/issues/81>) Mac OS X - Distributed with a build of 7.8.3 that differs from the released bindist in two ways: a) it was built split-objs for smaller resulting executables, b) it includes Cabal-1.18.1.4 which fixes a particularly nasty problem with haddock, -XCPP, and clang based systems. This ghc-7.8.3 bindist is available as well: - ghc-7.8.3-x86_64-apple-darwin-r3.tar.bz2 <http://www.ozonehouse.com/mark/platform/ghc-7.8.3-x86_64-apple-darwin-r3.ta…> - haddocks finally cross link between packages correctly - includes a new experimental activate-hs command that can switch between multiple installed versions of the platform - includes a slightly updated uninstall-hs command - the cabal command is wrapped to provide a smoother file layout on the Mac... the wrapping only updates the ~/.cabal/config file the first time you run it.. please pay attention to its output - if you have a custom config file, you'll want to update it, as Cabal's defaults have changed - works on 10.7 (tested), 10.8 (assumed!), 10.9 (tested) - both with gcc and clang based Xcode installs. (Next RC will support back to 10.6!) - 64bit only build this time... anyone still want the 32bit build? Source tarball - Quite some changes from last time - notably now includes the new build machinery, not the old. - The build machinery is well tested (see the travis-ci link above) from a repo... not tested much from a source repo - It isn't clear the source repo is of much interest... anyone need it? anyone need anything beyond the haskell-platform.cabal file in it? Timetable - These can "soak" amongst the intreped on these lists for 48 hours. - On Saturday, I'll release any needed updated RCs, and announce to a wider audience - End of next week (from my vacation, I'll point out), we'll declare success and ship. — Mark P.S.: sha256 sums for the reasonably wary: 860cba2d65bc1790ec3b8a0a62c8aaf19f5b18e9070aa1ec3c468b7c6ca82697 Haskell Platform 2014.2.0.0 64bit RC1.signed.pkg 8ca8a994334bf846ac6a41ada381c51634b2fce0d68dc70b2dadf59cb8748397 haskell-platform-2014.2.0.0-RC1.tar.gz b034e2daa595e0d3827860b062afca05f62df64434b0923559acc99bd82ef1e9 HaskellPlatform-2014.2.0.0-i386-RC1-setup.exe e31fe5e0cb9dca330e6f0c62ac49bf70b79f555bfe11e8f04c47739fef224145 HaskellPlatform-2014.2.0.0-x86_64-RC1-setup.exe 8e479d9dd504b1c603cd51f3be0fa57ecdc996e842d655e39d97faafff3c2d31 ghc-7.8.3-x86_64-apple-darwin-r3.tar.bz2

3 9

Early draft spec of Strict language pragma
by Johan Tibell 25 Jul '14

25 Jul '14

Hi! I started a draft spec for the Strict language pragma we chatted about during our call a while ago. I made the big mistake of writing it much after the actual discussion, so I forgot most of the details. https://ghc.haskell.org/trac/ghc/wiki/StrictPragma Perhaps if you could ask questions that you don't think are answered in the wiki page I can start fleshing it out more? P.S. I've included our chat log at the bottom of the wiki page. -- Johan

3 5

RE: GhcPlugin-writing and "finding things"
by Simon Peyton Jones 25 Jul '14

25 Jul '14

Philip You are right: there are some missing pieces. * First you need to ask where your plugin's special library module "Foo" is in the file system. This is what findImportedModule is for, and it seems quite reasonable. However, it (or some variant) should be available to you in CoreM. * Next, suppose you special library module defines a special type "T". You need to get its Name. For this you a CoreM variant of IfaceEnv.lookupOrig. The function CoreMonad.getOrigNameCache is far too low level and should be killed. Instead, CoreMonad should expose lookupOrig :: Module -> OccName -> CoreM Name It should be an easy function to write, using IfaceEnv.lookupOrig; maybe a tiny bit of refactoring. * Next you want to get from T's Name to T's TyCon. Here CoreMonad is fine: it offers lookupThing :: Name -> CoreM TyThing This function calls TcEnv.tcLookupGlobal, which will automatically load Foo.hi if need be. So your code should look like foo_mod <- findImportedModule "Foo" t_name <- lookupOrig foo_mod (mkTcOcc "T") t_tycon <- lookupThing t_name corresponding to these three steps. I suspect that the error cases of findImported module should be dealt with via exceptions in CoreM, to de-clutter the code. Some of the above suggests a bit of cleaning up of the CoreM API. Would someone like to undertake that? I can advise, but I don't want to lead. Simon | -----Original Message----- | From: Glasgow-haskell-users [mailto:glasgow-haskell-users- | bounces(a)haskell.org] On Behalf Of p.k.f.holzenspies(a)utwente.nl | Sent: 23 July 2014 17:07 | To: glasgow-haskell-users(a)haskell.org | Subject: GhcPlugin-writing and "finding things" | | Dear GHC-ers, | | I'm working on a plugin for GHC that should help compile the library | with which this plugin is to ship. What this plugin does is traverse | the CoreProgram(s) to find things of types defined in my library and | optimizes them. I have worked out how to "find" things, but I was | wondering whether the API could be improved for plugin-writers. | | For the sake of argument, I have the following: | - module Foo: library for users to import, containing functions, ADTs | etc | - module Foo.Plugin: GhcPlugin that compiles out all uses of things in | Foo | | > module Foo where | > | > data Foo x = Foo x | > | > runFoo :: Foo x -> x | > runFoo (Foo x) = x | | | This example is trivial and I imagine GHC will have no trouble | eliminating most cases of this, but imagine more complex stuff. Now, if | I want to traverse the CoreProgram in my plugin, I need to find | occurrences of these, so somewhere there's stuff like: | | > pass tcFoo _ _ (NonRec b expr) | > | varType b `containsTyConAnywhere` tcFoo | > = {- clever stuff to compile out Foo -} | | My problem is "getting" tcFoo in this example. Below is how I do it | now. Maybe I'm being thick, or maybe there's just no simpler way. This | is my 'plugin' function in Foo.Plugin: | | > plugin = Plugin $ \opts todo -> do | > hsc <- getHscEnv | > dfs <- getDynFlags | > fr <- liftIO $ findImportedModule hsc (mkModuleName "Foo") Nothing | > mod <- case fr of | > Found ml m -> return m | > _ -> panic "Failed to (unambiguously) find 'Foo' (using | findImportedModule)" | > onc <- getOrigNameCache | > let nms = lookupWithDefaultModuleEnv nms (panic "No names defined | for module 'Foo'") mod | > find_ d occ fnd nm | > = maybe | > (fail $ "Failed to find " ++ d ++ " '" ++ nm ++ "'") | > fnd | > (lookupOccEnv nms $ occ nm) | > tcFind = find_ "TyCon" mkTcOcc lookupTyCon | > dcFind = find_ "DataCon" mkDataOcc lookupDataCon | > idFind = find_ "Id" mkVarOcc lookupId | > tcFoo <- tcFind "Foo" | > dcFoo <- dcFind "Foo" | > idRunFoo <- idFind "runFoo" | > return $ CoreDoPluginPass "Foo optimisation" (pass tcFoo dcFoo | > idRunFoo) : todo | | I have the following questions: | | 1) Is this a/the right way to "find" those things in the plugin? | 2) There seems to be a lot to gain with quasi-quoting a la Template | Haskell for people writing plugins to go with a library that they | wrote. Can such QQ be done? Has it been considered? | 3) Is findImportedModule the right function to find my starting point | to begin with? | 4) What is the 'Maybe FastString' argument in findImportedModule for? | I've been trying to put in the FSs of PackageIDs, but they make the | lookup fail. This (dumb) example really made me nervous: | | > fr <- liftIO $ findImportedModule hsc (mkModuleName "Foo") Nothing | > mod <- case fr of | > Found ml m -> do | > fr' <- liftIO $ findImportedModule hsc (moduleName m) | > (packageIdFS $ packageId m) | | Here, fr' should always be a "Found ml' m'" such that ml == ml' and m | == m', but... it consistently results in NotFound{} for me. Also, I | find this especially round-about. Shouldn't Paths_Foo.hs (the Cabal- | generated file) maybe contain variables for every module in the | package? In my case it would thus contain some "modFoo :: Module" | | Comments and suggestions more than welcome! | | Regards, | Philip | | | | | | | | _______________________________________________ | Glasgow-haskell-users mailing list | Glasgow-haskell-users(a)haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

1 0

RE: A couple of GHC-API questions
by Eric Seidel 24 Jul '14

24 Jul '14

Sorry for the double email Simon, I hadn’t signed up for ghc-devs so my response was rejected.. --- Thanks for getting back to me so quickly! On July 24, 2014 at 0:33:44, Simon Peyton Jones (simonpj(a)microsoft.com) wrote: > Eric > > I'd like to help but I don't understand the question. What do you mean by "resolve" all > the types that are imported from module A? > > If you have a TyCon (for A.Foo) in your hand, it has a Name. That Name tells you where it comes > from. Inside it you will find its DataCons which also come from A. And so on. Sorry for the confusion, I’m actually asking about how to get the right Name. When we first parse a specification, all of the TyCons etc. are plain Strings, i.e. we have a type data RefType tycon tyvar = … type ParsedRefType = RefType String String But we don’t want to deal with Strings, we want to use GHC’s TyCons and TyVars type GHCRefType = RefType TyCon TyVar so we need a function that maps Strings to Names (and then finding the TyCon is easy). This is what I mean by “resolving” the types. For single-module programs this is trivial, we can do something like resolve x = do rn <- hscParseIdentifier x hscTcRnLookupRdrName rn For multi-module programs it becomes trickier because we also have to resolve the types that we’ve imported from other modules. So, using my example from earlier, when we type-check module B we have to turn the String “Foo” into the Name A.Foo. This is problematic because module B imported module A qualified, so “Foo” is not in scope inside B but “A.Foo” is. I believe GHC might be avoiding this issue via the .hi files, so when you import a Type from another module, it is already using TyCons instead of Strings. > Later you say "is there a simple way to ask GHC to resolve the name x in the context of module > m". You could mean > * Imagine that the unqualified name "x" appeared in module m. How do I look it up, in m's > top-level lexical environment. > but I don’t think that is what you mean. I think this is almost exactly what I mean, except that I want to be able to look up the unqualified “x” as well as the qualified “SomeModuleThatMayHaveBeenRenamed.x” inside m’s top-level environment. This is more or less what the DynamicLoading.lookupRdrNameInModuleForPlugins function that I’ve copied and tweaked does, but it requires the presence of the original source code. I’m hoping there may be some other function out there that does the same thing without requiring the source code, so we can use it for the base libraries as well. > I'm confused. Could you be more concrete? > Possibly this may help? https://ghc.haskell.org/trac/ghc/wiki/Commentary/Compiler/NameType Thanks for the reference, I’m familiar with most of the info there already from browsing GHC’s source, but this is laid out much more newcomer-friendly manner :) Hopefully I’ve made my question a bit clearer. Eric

1 0

Re: Removing GHC's dependency on Cabal
by Yuri de Wit 24 Jul '14

24 Jul '14

On Thu, Jul 24, 2014 at 11:59 AM, Brandon Allbery <allbery.b(a)gmail.com> wrote: > On Thu, Jul 24, 2014 at 10:55 AM, Simon Peyton Jones < > simonpj(a)microsoft.com> wrote: > >> To me it seems simple and obvious! Why are we going round the houses to >> do something so simple? > > > So cabal can maintain its conceit that it supports more than just ghc. > I don't understand this as an argument against the ghc-db library, which to me also seems the simple and obvious solution. Having a ghc-db library will mean one of two options: 1. The *ghc-db* is GHC-specific and will be used by the GHC specific wrappers in Cabal: doesn't cabal already deals with each compiler differently? 2. The ghc-db is really *hs-db* and a library contract that can be reused by all haskell compilers (i.e. part of The Haskell Cabal) In both cases, the assumption is that ghc-db/hs-db should have a stable API. Now, choosing option (1) doesn't eliminate option (2). When and if there is a broad agreement across all compilers, ghc-db could become hs-db and be incorporate into The Haskell Cabal. > > -- > brandon s allbery kf8nh sine nomine > associates > allbery.b(a)gmail.com > ballbery(a)sinenomine.net > unix, openafs, kerberos, infrastructure, xmonad > http://sinenomine.net > > _______________________________________________ > cabal-devel mailing list > cabal-devel(a)haskell.org > http://www.haskell.org/mailman/listinfo/cabal-devel > >

1 0

Removing GHC's dependency on Cabal
by Edward Z. Yang 24 Jul '14

24 Jul '14

Hello all, I know Duncan and SPJ have been keen on removing GHC's dependency on Cabal for some time now. Simon and I were chatting about the subject today, and we wanted to propose an alternative way of doing the remodularization. Here are diagrams of the proposals: http://web.mit.edu/~ezyang/Public/ghc-cabal-refactor.pdf As I understand it, Duncan's proposal is to take the current constellation of libraries, and just remove the dependency to Cabal from GHC and bin-package-db, duplicating data structures as necessary. ghc-pkg is now responsible for converting between Cabal's format and GHC's format. Simon suggested that this 'ghc-pkg' functionality (which specifies the database format and how to handle it) should be placed in a library of its own. So in the third graph, we have a new package ghc-db which everyone depends on. Cabal no longers shells out to ghc-pkg to modify database, instead it directly converts to ghc-db's format and then invokes library functions in the library. We were wondering if there was any reason to prefer the former situation over the latter. One answer might be that Cabal is less keen to have a dependency on a very GHC specific library (although the ghc-pkg dependency is quite a fairly tightly coupled one.) Cheers, Edward

4 4

Re: At long last: 2014.2.0.0 Release Candidate 1
by Mark Lentczner 24 Jul '14

24 Jul '14

On Thu, Jul 24, 2014 at 5:30 AM, Brandon Allbery <allbery.b(a)gmail.com> wrote: > Errrr. Whoever is making the Mac bindist should take care to avoid any > MacPorts (or for that matter Homebrew) components slipping in to it; this > will cause problems down the road. > That would be makin' that bindist! And your advice about other package systems is the same as my own. The bindist used in the release was built on a very clean machine that has only stock OS X and stock Xcode installed... never Homebrew or MacPorts. That machine doesn't even have a /opt directory! - Mark

1 0

RE: GHC contribution guidelines and infrastructure talk on 6th September at HIW?
by Jost Berthold 24 Jul '14

24 Jul '14

(Sorry for joining this late... I figured we would be in dialogue off the list eventually) Joachim wrote and posted a proposal, and I think this proposal is indeed a good idea (and one of the purposes of HIW, definite yes). We shall make room for it in the programme, possibly in the last session, which can turn into the "Haskell release discussion evening". Best regards Jost On 07/22/2014 11:06 AM, ghc-devs-request(a)haskell.org wrote: > Date: Tue, 22 Jul 2014 08:38:22 +0000 > From: Simon Peyton Jones <simonpj(a)microsoft.com> > To: Mark Lentczner <mark.lentczner(a)gmail.com>, "ghc-devs(a)haskell.org" > <ghc-devs(a)haskell.org> > Subject: RE: GHC contribution guidelines and infrastructure talk on > 6th September at HIW? > Message-ID: > <618BE556AADD624C9C918AA5D5911BEF10435304(a)DB3PRD3001MB020.064d.mgd.msft.net> > > Content-Type: text/plain; charset="utf-8" > > I think such a discussion would be a Good Thing, and just what HIW is for. > > Simon > > From: ghc-devs [mailto:ghc-devs-bounces@haskell.org] On Behalf Of Mark Lentczner > Sent: 22 July 2014 02:03 > To: ghc-devs(a)haskell.org > Subject: Re: GHC contribution guidelines and infrastructure talk on 6th September at HIW? > > On a related front... I don't have a talk to give (hence I didn't submit a proposal)... But I'd love it if some of us could have a group discussion about coordinating releases, and our approach to putting out "Haskell": > > In short, we see it as several related peices (GHC, Cabal, Haddock, core libs, platform, etc...) but my guess is that most developers considering using Haskell see it as one thing: "Can I haz the Haskellz on my machine? kthxbai?" Therefore, I think we could put some thought into how we manage these pieces into a cohesive whole whose release more or less "just works". > > Not sure if this should be a "session", a "workshop", a long hallway disucssion, a night of good food and beer, or what. I'm happy to put some effort into organizing, and setting the context for the discussion. > > - Mark

3 3

RE: A couple of GHC-API questions
by Simon Peyton Jones 24 Jul '14

24 Jul '14

Eric I'd like to help but I don't understand the question. What do you mean by "resolve" all the types that are imported from module A? If you have a TyCon (for A.Foo) in your hand, it has a Name. That Name tells you where it comes from. Inside it you will find its DataCons which also come from A. And so on. Later you say "is there a simple way to ask GHC to resolve the name x in the context of module m". You could mean * Imagine that the unqualified name "x" appeared in module m. How do I look it up, in m's top-level lexical environment. but I don’t think that is what you mean. I'm confused. Could you be more concrete? Possibly this may help? https://ghc.haskell.org/trac/ghc/wiki/Commentary/Compiler/NameType I'm cc'ing ghc-devs. Simon | -----Original Message----- | From: Eric Seidel [mailto:eseidel@cs.ucsd.edu] | Sent: 23 July 2014 19:01 | To: Simon Peyton Jones | Subject: A couple of GHC-API questions | | Hi Simon, | | I have a couple of questions about how to use GHC’s API properly. | There’s nothing urgent here as we’re making due just fine in | LiquidHaskell, but I’m pretty sure we’re hacking around GHC when we | don’t need to :) | | As you probably know, we basically use GHC to get the Core binders of a | module, and to resolve a bunch of names. Translating to Core has never | been an issue for us as far as I know, but our name-resolution code is | very haphazard. The core of our problems with name-resolution comes | down to resolving the names in specifications that have been imported | from another module, e.g. | | module A where | data Foo | mkFoo :: {v:Int | v >= 0} -> Foo | ... | | module B where | import qualified A | ... | | When we verify module B we have to first resolve all of the types that | were imported from module A, *but* we can’t do that in the context of | module B due to the qualified import. So I’ve been using a slightly | modified version of GHC’s DynamicLoading.lookupRdrNameInModule to | handle the change of context, but this seems to require that we use the | HscInterpreted flag, which causes further problems for a few of our | benchmarks that make use of the C FFI.. This method also only works for | modules where we actually have the source code available, i.e. we have | to use a different method of looking up names to attach specifications | to functions from the base libraries. | | So I guess my question is this: is there a simple way to ask GHC to | resolve the name x in the context of module m, without invoking the | code generator or any other part of GHC’s functionality? I suppose a | more principled solution would be to somehow hook into the .hi files | that GHC generates, but I’m not sure if that’s possible. | | Again, the code we have right now works, it’s just very fragile and I’d | like to clean things up. | | Thanks! | | Eric

2 1

Repositories page
by Simon Peyton Jones 24 Jul '14

24 Jul '14

Austin I know that you have been working on * https://ghc.haskell.org/trac/ghc/wiki/WorkingConventions/Git * https://ghc.haskell.org/trac/ghc/wiki/WorkingConventions/Git/Submodules But what about the main "Repositories" page * https://ghc.haskell.org/trac/ghc/wiki/Repositories which is linked directly from the LH Margin bar? Is this page fully upd to date, including the "Full repository breakdown" table? Presumably not... I'm pretty sure that you said that Repositories/Upstream is fully out of date and should be retired. Also the Git/Submodules page also has a similar table, but with fewer columns. But some of the columns in the Repositories page ("reqd to build", "installed") are still relevant. Shouldn't there be just one master table with all this info? Could you perhaps clear this up --- in the wiki, not by replying to me :)? Thanks There is also https://ghc.haskell.org/trac/ghc/wiki/Commentary/Libraries, which is useful, and I think is still up to date. Indeed Edward and I have just updated it. But it's not that easy to find. It would be good if the Master Table (see above) had a column for each of the four properties of the boot packages that this page describes. Thanks Simon

1 0