From tullsen at galois.com Fri Aug 1 23:06:00 2008 From: tullsen at galois.com (Mark Tullsen) Date: Fri Aug 1 23:05:56 2008 Subject: Need help with GHC API and GHC internals Message-ID: I'm attempting to write a call-graph generator for Haskell using the GHC API. I.e., for each top level value definition, I want a list of the top-level names used in the definition. Using GHC API, once I have a 'CheckedModule', I have a dilemma: a) If I use this field parsedSource :: ParsedSource I've got a giant AST that I need to traverse for names, there being no help in the compiler to do so, AFAIK. b) If I use this field coreBinds :: Maybe [CoreBind] although I've got a simpler type to deal with, and some useful functions (e.g. exprFreeNames), I believe I'm now swimming in waters a bit deep for me or maybe this is just a flawed approach: - the core bindings created do not correspond exactly to the bindings in the source and 'exprFreeNames' is acting in surprising ways. - etc, etc. Does anyone have any advice for me here? Is there some way I can get approach (b) to work without becoming a wizard in GHC internals? Is there anything I'm missing? Thanks, Mark From claus.reinke at talk21.com Sat Aug 2 05:03:11 2008 From: claus.reinke at talk21.com (Claus Reinke) Date: Sat Aug 2 05:03:09 2008 Subject: Need help with GHC API and GHC internals References: Message-ID: <004101c8f47e$981cf3b0$2a307ad5@cr3lt> > API. I.e., for each top level value definition, I want a list of the > top-level names used in the definition. > > Using GHC API, once I have a 'CheckedModule', I have a dilemma: > a) If I use this field > parsedSource :: ParsedSource > I've got a giant AST that I need to traverse for names, there > being no help in the compiler to do so, AFAIK. Have a look at http://hackage.haskell.org/trac/ghc/wiki/GhcApiAstTraversals and its attachments (Instances.hs/Instances0.hs provides some Data/Typeable instances for Ghc's Ast types using standalone deriving, Utils.hs/APSSybTesting.hs show some uses). There seems to be agreement that Data/Typeable instances (though not necessarily these) should come with the Ghc Api in the future. If you stop with the parsed AST, there is no scope information, so you might still want to use the output of later phases for your task (renamedSource might be suitable). Hth, Claus > b) If I use this field > coreBinds :: Maybe [CoreBind] > although I've got a simpler type to deal with, and some useful > functions > (e.g. exprFreeNames), I believe I'm now swimming in waters a bit > deep for me or maybe this is just a flawed approach: > - the core bindings created do not correspond exactly to the > bindings > in the source and 'exprFreeNames' is acting in surprising ways. > - etc, etc. > > Does anyone have any advice for me here? Is there some way I can get > approach > (b) to work without becoming a wizard in GHC internals? Is there > anything I'm > missing? > > Thanks, > > Mark > > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users@haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users From DekuDekuplex at Yahoo.com Mon Aug 4 02:54:31 2008 From: DekuDekuplex at Yahoo.com (Benjamin L.Russell) Date: Mon Aug 4 02:59:52 2008 Subject: Any release date for GHC 6.8.3 for Mac OS X 10.5 (Leopard) on PowerPC G4 machines? Message-ID: <7e9d94d3c5vb7na7k02d6rn5i5hqbqsoba@4ax.com> Is there any scheduled release date for GHC 6.8.3 for Mac OS X 10.5 (Leopard) on PowerPC G4 machines? I have a G4 PowerBook, currently running Mac OS X 10.2.8 (Jaguar), which I plan to upgrade next week. I also have the upgrade discs for both Mac OS X 10.4 (Tiger) and Mac OS X 10.5 (Leopard). Backing up my hard disk before upgrading takes about 20 hours; it seems a pity to upgrade to Tiger before eventually upgrading to Leopard (unless GHC is never going to be released for Tiger on PowerPC G4 machines, which would be much worse). -- Benjamin L. Russell From DekuDekuplex at Yahoo.com Mon Aug 4 03:04:15 2008 From: DekuDekuplex at Yahoo.com (Benjamin L.Russell) Date: Mon Aug 4 03:04:50 2008 Subject: Any release date for GHC 6.8.3 for Mac OS X 10.5 (Leopard) on PowerPC G4 machines? References: <7e9d94d3c5vb7na7k02d6rn5i5hqbqsoba@4ax.com> Message-ID: On Mon, 04 Aug 2008 15:54:31 +0900, Benjamin L.Russell wrote: >[...] >(unless GHC is >never going to be released for Tiger on PowerPC G4 machines My apologies; I meant "Leopard" in the above-referenced sentence. -- Benjamin L. Russell From simonpj at microsoft.com Mon Aug 4 07:46:55 2008 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Mon Aug 4 07:46:42 2008 Subject: Need help with GHC API and GHC internals In-Reply-To: References: Message-ID: <638ABD0A29C8884A91BC5FB5C349B1C32AE77BC3F1@EA-EXMSG-C334.europe.corp.microsoft.com> * Claus is right to say that you want the *renamed* tree, not the *parsed* tree. * He's also right to point to the under-development generic programming stuff for the GHC API. I'm not certain about how settled they are right now though. * But in fact you can get exactly what you want from the mg_used_names fields of the ModGuts (post desugaring). Simon | -----Original Message----- | From: glasgow-haskell-users-bounces@haskell.org [mailto:glasgow-haskell-users-bounces@haskell.org] On | Behalf Of Mark Tullsen | Sent: 02 August 2008 04:06 | To: glasgow-haskell-users@haskell.org | Subject: Need help with GHC API and GHC internals | | I'm attempting to write a call-graph generator for Haskell using the GHC | API. I.e., for each top level value definition, I want a list of the | top-level | names used in the definition. | | Using GHC API, once I have a 'CheckedModule', I have a dilemma: | a) If I use this field | parsedSource :: ParsedSource | I've got a giant AST that I need to traverse for names, there | being no | help in the compiler to do so, AFAIK. | b) If I use this field | coreBinds :: Maybe [CoreBind] | although I've got a simpler type to deal with, and some useful | functions | (e.g. exprFreeNames), I believe I'm now swimming in waters a bit | deep for me or maybe this is just a flawed approach: | - the core bindings created do not correspond exactly to the | bindings | in the source and 'exprFreeNames' is acting in surprising ways. | - etc, etc. | | Does anyone have any advice for me here? Is there some way I can get | approach | (b) to work without becoming a wizard in GHC internals? Is there | anything I'm | missing? | | Thanks, | | Mark | | _______________________________________________ | Glasgow-haskell-users mailing list | Glasgow-haskell-users@haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users From Christian.Maeder at dfki.de Mon Aug 4 12:47:51 2008 From: Christian.Maeder at dfki.de (Christian Maeder) Date: Mon Aug 4 12:47:36 2008 Subject: Any release date for GHC 6.8.3 for Mac OS X 10.5 (Leopard) on PowerPC G4 machines? In-Reply-To: <7e9d94d3c5vb7na7k02d6rn5i5hqbqsoba@4ax.com> References: <7e9d94d3c5vb7na7k02d6rn5i5hqbqsoba@4ax.com> Message-ID: <489732B7.9020203@dfki.de> Benjamin L.Russell wrote: > Is there any scheduled release date for GHC 6.8.3 for Mac OS X 10.5 > (Leopard) on PowerPC G4 machines? No, but I could rebuild ghc-6.8.3 on Tiger (G5) so that it also runs on a G4. (The G5 dependency of http://www.haskell.org/ghc/dist/6.8.3/maeder/ghc-6.8.3-powerpc-apple-darwin.tar.bz2 was an accident, that happened by wrongly building libgmp, too.) Alternatively you can install ghc-6.8.2 and build ghc-6.8.3 yourself. http://www.haskell.org/ghc/download_ghc_682.html#macosxppc (that relies on old frameworks, though). Or has someone else done this already? The Tiger binaries and ghcs also run under Leopard (but not vice versa). Cheers Christian > > I have a G4 PowerBook, currently running Mac OS X 10.2.8 (Jaguar), > which I plan to upgrade next week. I also have the upgrade discs for > both Mac OS X 10.4 (Tiger) and Mac OS X 10.5 (Leopard). Backing up my > hard disk before upgrading takes about 20 hours; it seems a pity to > upgrade to Tiger before eventually upgrading to Leopard (unless GHC is > never going to be released for Tiger on PowerPC G4 machines, which > would be much worse). > > -- Benjamin L. Russell From Christian.Maeder at dfki.de Tue Aug 5 03:11:25 2008 From: Christian.Maeder at dfki.de (Christian Maeder) Date: Tue Aug 5 03:11:07 2008 Subject: Any release date for GHC 6.8.3 for Mac OS X 10.5 (Leopard) on PowerPC G4 machines? In-Reply-To: <489732B7.9020203@dfki.de> References: <7e9d94d3c5vb7na7k02d6rn5i5hqbqsoba@4ax.com> <489732B7.9020203@dfki.de> Message-ID: <4897FD1D.8000308@dfki.de> I've rebuild the binary without statically linked gmp. http://www.dfki.de/sks/hets/mac/ghcs/ghc-6.8.3-powerpc-apple-darwin.tar.bz2 So in addition to readline (and ncurses) you need gmp from MacPorts. (Otherwise even installation will fail, because pwd needs gmp.) If you want ghc to produce static binaries then move the static library libgmp.a into your installed ghc's libdir. Cheers Christian Christian Maeder wrote: > Benjamin L.Russell wrote: >> Is there any scheduled release date for GHC 6.8.3 for Mac OS X 10.5 >> (Leopard) on PowerPC G4 machines? > > No, but I could rebuild ghc-6.8.3 on Tiger (G5) so that it also runs on > a G4. (The G5 dependency of > http://www.haskell.org/ghc/dist/6.8.3/maeder/ghc-6.8.3-powerpc-apple-darwin.tar.bz2 > > was an accident, that happened by wrongly building libgmp, too.) [...] > The Tiger binaries and ghcs also run under Leopard (but not vice versa). From DekuDekuplex at Yahoo.com Tue Aug 5 04:49:48 2008 From: DekuDekuplex at Yahoo.com (Benjamin L.Russell) Date: Tue Aug 5 04:49:40 2008 Subject: Any release date for GHC 6.8.3 for Mac OS X 10.5 (Leopard) on PowerPC G4 machines? References: <7e9d94d3c5vb7na7k02d6rn5i5hqbqsoba@4ax.com> <489732B7.9020203@dfki.de> <4897FD1D.8000308@dfki.de> Message-ID: <1s4g94ltjp7goe83lsgehgp204odhl0da2@4ax.com> On Tue, 05 Aug 2008 09:11:25 +0200, Christian Maeder wrote: >I've rebuild the binary without statically linked gmp. > >http://www.dfki.de/sks/hets/mac/ghcs/ghc-6.8.3-powerpc-apple-darwin.tar.bz2 > >So in addition to readline (and ncurses) you need gmp from MacPorts. >(Otherwise even installation will fail, because pwd needs gmp.) > >If you want ghc to produce static binaries then move the static library >libgmp.a into your installed ghc's libdir. Thank you very much for the update. I'll be sure to fetch gmp from MaPorts when I install GHC 6.8.3 on Mac OS X 10.5 (Leopard), and to move libgmp.a into my installed GHC's libdir. If I run into problems, I'll post them in this thread. -- Benjamin L. Russell From marlowsd at gmail.com Tue Aug 5 05:23:15 2008 From: marlowsd at gmail.com (Simon Marlow) Date: Tue Aug 5 05:23:01 2008 Subject: Version control systems Message-ID: <48981C03.10908@gmail.com> Following lots of useful discussion and evaluation of the available DVCSs out there, the GHC team have made a decision: we're going to switch to git. It came down to two things: the degree of support available, and flexibility of the tools (git is much happier to let you modify the history than Mercurial). Speed ruled out bzr, and Windows support is less of an issue: git appears to work reasonably well on Windows these days. So we need a plan for switching. We aim to make the switch shortly before branching the repository for 6.10, which would mean we need to make the switch early September, in around 5 weeks time. Before then, the goal is to get the infrastructure to the point where we can switch with minimum fuss. We already have an up-to-date git mirror thanks to Thomas Schilling: git clone http://darcs.haskell.org/ghc.git (notice how fast that is :-) darcs-all will be able to work with either the git repository or the darcs repository (Max Bolingbroke is working on this, I believe). We can switch the automatic builds over to git as soon as darcs-all is working, and as long as the git mirror is kept up to date (Thomas: is the mirror being automatically updated now?). I'd urge people to try out the git mirror and let us know how you get on. We'll also work on updating the build documentation on the wiki and creating a page of getting-started info on using git. Cheers, Simon From nominolo at googlemail.com Tue Aug 5 05:46:36 2008 From: nominolo at googlemail.com (Thomas Schilling) Date: Tue Aug 5 05:46:31 2008 Subject: Version control systems In-Reply-To: <48981C03.10908@gmail.com> References: <48981C03.10908@gmail.com> Message-ID: <2F633EE2-0031-41BC-8DDB-E1B748E17963@googlemail.com> On 5 Aug 2008, at 11:23, Simon Marlow wrote: > (Thomas: is the mirror being automatically updated now?). No. I have added the sync script as a post-apply hook, but it doesn't seem to work. Maybe I can debug this with Igloo today. / Thomas -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 194 bytes Desc: This is a digitally signed message part Url : http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20080805/5f43b66a/PGP.bin From gwright at comcast.net Tue Aug 5 15:50:26 2008 From: gwright at comcast.net (Gregory Wright) Date: Tue Aug 5 15:50:17 2008 Subject: ANN: prof2dot, version 0.4.1 Message-ID: I am pleased to announce the release of prof2dot version 0.4.1, a graphical profiling tool for use with GHC. The program is a filter that takes the profiling output generated by running a GHC-compiled program with the "+RTS -px -RTS" option and turns it into a dot file. (The "dot" format is a textual representation of a directed or undirected graph.) The dot file can rendered in any format supported by Graphviz's dot program, and the file itself can be post-processed or edited to adjust the layout. The new release fixes a number of bugs and has some significant improvements in its internal organization over the previous 0.3.1 ("Premature Optimizations 'r' Us") release. Version 0.4.1 ("Triumph of Hope Over Experience") defaults to generating a call graph colored by number of entries into each call center. There is now an option to annotate the graph edges with the triple of (cost center entries, ticks, allocations). Module names are also given in each cost center. The latest version has been tested on the profiling output of some moderately large programs, e.g., the profile produced by a "darcs get" of the entire ghc repository: $ darcs get http://darcs.haskell.org/ghc +RTS -px -RTS There is also better error reporting of parser errors and consistency checking of the internal graph data structure. If anyone comes across a parse failure or an assertion failure, please report it to the author. The "dot" program from the graphviz tools is required to render the output of prof2dot. Very large graphs, or graphs with extensive annotations, can exceed the capabilities of dot. Prof2dot is available from Hackage in the "development" category. -Greg From ndmitchell at gmail.com Tue Aug 5 16:02:18 2008 From: ndmitchell at gmail.com (Neil Mitchell) Date: Tue Aug 5 16:02:00 2008 Subject: ANN: prof2dot, version 0.4.1 In-Reply-To: References: Message-ID: <404396ef0808051302v602ea943j5db164b1b75c7d7@mail.gmail.com> Hi Gregory, Sounds fantastic. I'd love to see a single example of the resultant .dot file, so I can figure out just how useful this might be to me. Thanks Neil On Tue, Aug 5, 2008 at 8:50 PM, Gregory Wright wrote: > > I am pleased to announce the release of prof2dot version 0.4.1, > a graphical profiling tool for use with GHC. > > The program is a filter that takes the profiling output generated by running > a GHC-compiled program with the "+RTS -px -RTS" option and turns it into > a dot file. (The "dot" format is a textual representation of a directed or > undirected graph.) > The dot file can rendered in any format supported by Graphviz's > dot program, and the file itself can be post-processed or edited to adjust > the > layout. > > The new release fixes a number of bugs and has some significant > improvements in its internal organization over the previous 0.3.1 > ("Premature Optimizations 'r' Us") release. > > Version 0.4.1 ("Triumph of Hope Over Experience") defaults to generating > a call graph colored by number of entries into each call center. There > is now an option to annotate the graph edges with the triple of > (cost center entries, ticks, allocations). Module names are also given > in each cost center. > > The latest version has been tested on the profiling output of some > moderately > large programs, e.g., the profile produced by a "darcs get" of the entire > ghc repository: > > $ darcs get http://darcs.haskell.org/ghc +RTS -px -RTS > > There is also better error reporting of parser errors and consistency > checking > of the internal graph data structure. If anyone comes across a parse > failure > or an assertion failure, please report it to the author. > > The "dot" program from the graphviz tools is required to render the output > of prof2dot. > Very large graphs, or graphs with extensive annotations, can exceed the > capabilities of dot. > > Prof2dot is available from Hackage in the "development" category. > > -Greg > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users@haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > From gwright at comcast.net Tue Aug 5 16:27:41 2008 From: gwright at comcast.net (Gregory Wright) Date: Tue Aug 5 16:27:26 2008 Subject: ANN: prof2dot, version 0.4.1 In-Reply-To: <404396ef0808051302v602ea943j5db164b1b75c7d7@mail.gmail.com> References: <404396ef0808051302v602ea943j5db164b1b75c7d7@mail.gmail.com> Message-ID: Hi Neil, Here's the (compressed) dot file from using darcs to get the whole ghc repo. It was generated by # prof2dot darcs.prof > darcs.dot -------------- next part -------------- A non-text attachment was scrubbed... Name: darcs.dot.bz2 Type: application/bzip2 Size: 12205 bytes Desc: not available Url : http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20080805/5a523370/darcs.dot-0001.bin -------------- next part -------------- The structure of the file is lines defining the edges followed by lines defining the nodes, optionally followed by subgraph definitions that group the nodes into modules. If there is a format that would make post- processing easier, I can change it. -Greg On Aug 5, 2008, at 4:02 PM, Neil Mitchell wrote: > Hi Gregory, > > Sounds fantastic. I'd love to see a single example of the resultant > .dot file, so I can figure out just how useful this might be to me. > > Thanks > > Neil > > On Tue, Aug 5, 2008 at 8:50 PM, Gregory Wright > wrote: >> >> I am pleased to announce the release of prof2dot version 0.4.1, >> a graphical profiling tool for use with GHC. >> >> The program is a filter that takes the profiling output generated >> by running >> a GHC-compiled program with the "+RTS -px -RTS" option and turns it >> into >> a dot file. (The "dot" format is a textual representation of a >> directed or >> undirected graph.) >> The dot file can rendered in any format supported by Graphviz's >> dot program, and the file itself can be post-processed or edited to >> adjust >> the >> layout. >> >> Prof2dot is available from Hackage in the "development" category. >> >> -Greg >> _______________________________________________ >> From garious at gmail.com Tue Aug 5 16:46:48 2008 From: garious at gmail.com (Greg Fitzgerald) Date: Tue Aug 5 16:46:32 2008 Subject: ANN: prof2dot, version 0.4.1 In-Reply-To: <404396ef0808051302v602ea943j5db164b1b75c7d7@mail.gmail.com> References: <404396ef0808051302v602ea943j5db164b1b75c7d7@mail.gmail.com> Message-ID: <1f3dc80d0808051346x316e8795n5bdec6ba11adf63e@mail.gmail.com> > Sounds fantastic I'm using 'prof2dot' on a ~3000 LOC project and it's working well. Visual quality metrics like this and Haskell Program Coverage makes using Haskell in the corporate world a little easier to pull off. Zero crash reports helps too. ;-) -Greg F On Tue, Aug 5, 2008 at 1:02 PM, Neil Mitchell wrote: > Hi Gregory, > > Sounds fantastic. I'd love to see a single example of the resultant > .dot file, so I can figure out just how useful this might be to me. > > Thanks > > Neil > > On Tue, Aug 5, 2008 at 8:50 PM, Gregory Wright > wrote: > > > > I am pleased to announce the release of prof2dot version 0.4.1, > > a graphical profiling tool for use with GHC. > > > > The program is a filter that takes the profiling output generated by > running > > a GHC-compiled program with the "+RTS -px -RTS" option and turns it into > > a dot file. (The "dot" format is a textual representation of a directed > or > > undirected graph.) > > The dot file can rendered in any format supported by Graphviz's > > dot program, and the file itself can be post-processed or edited to > adjust > > the > > layout. > > > > The new release fixes a number of bugs and has some significant > > improvements in its internal organization over the previous 0.3.1 > > ("Premature Optimizations 'r' Us") release. > > > > Version 0.4.1 ("Triumph of Hope Over Experience") defaults to generating > > a call graph colored by number of entries into each call center. There > > is now an option to annotate the graph edges with the triple of > > (cost center entries, ticks, allocations). Module names are also given > > in each cost center. > > > > The latest version has been tested on the profiling output of some > > moderately > > large programs, e.g., the profile produced by a "darcs get" of the entire > > ghc repository: > > > > $ darcs get http://darcs.haskell.org/ghc +RTS -px -RTS > > > > There is also better error reporting of parser errors and consistency > > checking > > of the internal graph data structure. If anyone comes across a parse > > failure > > or an assertion failure, please report it to the author. > > > > The "dot" program from the graphviz tools is required to render the > output > > of prof2dot. > > Very large graphs, or graphs with extensive annotations, can exceed the > > capabilities of dot. > > > > Prof2dot is available from Hackage in the "development" category. > > > > -Greg > > _______________________________________________ > > Glasgow-haskell-users mailing list > > Glasgow-haskell-users@haskell.org > > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > > > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users@haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20080805/ffd40707/attachment.htm From dons at galois.com Wed Aug 6 01:12:32 2008 From: dons at galois.com (Don Stewart) Date: Wed Aug 6 01:12:17 2008 Subject: Version control systems In-Reply-To: <48981C03.10908@gmail.com> References: <48981C03.10908@gmail.com> Message-ID: <20080806051232.GD17673@scytale.galois.com> marlowsd: > Following lots of useful discussion and evaluation of the available DVCSs > out there, the GHC team have made a decision: we're going to switch to git. Hooray, this will generate a lot of open source good will, and help make GHC more accessible to the outside world. Just see the comments here, http://www.reddit.com/comments/6v2nl/ghc_project_switches_to_git/ "Great news!" "I'm trying to clone this now," If this means a few more eyes on the code, then that's all win. -- Don From alexander.dunlap at gmail.com Wed Aug 6 01:36:30 2008 From: alexander.dunlap at gmail.com (Alexander Dunlap) Date: Wed Aug 6 01:36:11 2008 Subject: Version control systems In-Reply-To: <48981C03.10908@gmail.com> References: <48981C03.10908@gmail.com> Message-ID: <57526e770808052236k2e5039b6p389770a977930b38@mail.gmail.com> On Tue, Aug 5, 2008 at 2:23 AM, Simon Marlow wrote: > (notice how fast that is :-) git clone has gone about 45 minutes so far without finishing...is that an improvement over darcs? Alex From marlowsd at gmail.com Wed Aug 6 04:08:55 2008 From: marlowsd at gmail.com (Simon Marlow) Date: Wed Aug 6 04:08:39 2008 Subject: Version control systems In-Reply-To: <57526e770808052236k2e5039b6p389770a977930b38@mail.gmail.com> References: <48981C03.10908@gmail.com> <57526e770808052236k2e5039b6p389770a977930b38@mail.gmail.com> Message-ID: <48995C17.1060000@gmail.com> Alexander Dunlap wrote: > On Tue, Aug 5, 2008 at 2:23 AM, Simon Marlow wrote: >> (notice how fast that is :-) > > git clone has gone about 45 minutes so far without finishing...is that > an improvement over darcs? I think http is still bandwidth-throttled on darcs.haskell.org. You should get better results cloning the github mirror: git://github.com/ghc-hq/ghc.git Thomas Schilling set this up yesterday. Cheers, Simon From dav.vire+haskell at gmail.com Wed Aug 6 04:29:35 2008 From: dav.vire+haskell at gmail.com (david48) Date: Wed Aug 6 04:29:27 2008 Subject: Version control systems References: <48981C03.10908@gmail.com> Message-ID: Simon Marlow gmail.com> writes: Hello, This is how I get on : $ git clone http://darcs.haskell.org/ghc.git ok, and fast ! $ cd ghc $ sh boot Looks like you're missing libraries/utils/hsc2hs. Maybe you haven't done './darcs-all get'? $ ./darcs-all get cat: _darcs/prefs/defaultrepo: No such file or directory Couldn't work out defaultrepo at ./darcs-all line 27. Cheers, From duncan.coutts at worc.ox.ac.uk Wed Aug 6 05:53:50 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Wed Aug 6 05:53:19 2008 Subject: Version control systems In-Reply-To: <20080806051232.GD17673@scytale.galois.com> References: <48981C03.10908@gmail.com> <20080806051232.GD17673@scytale.galois.com> Message-ID: <1218016430.7661.189.camel@localhost> On Tue, 2008-08-05 at 22:12 -0700, Don Stewart wrote: > marlowsd: > > Following lots of useful discussion and evaluation of the available DVCSs > > out there, the GHC team have made a decision: we're going to switch to git. > > Hooray, this will generate a lot of open source good will, and help make > GHC more accessible to the outside world. Heh, you still need darcs to build it, because all the libs are using darcs, and that's not going to change any time soon. > Just see the comments here, > > http://www.reddit.com/comments/6v2nl/ghc_project_switches_to_git/ > > "Great news!" > > "I'm trying to clone this now," Let's see what they say when they find out :-) Duncan From Alistair.Bayley at invesco.com Wed Aug 6 06:00:31 2008 From: Alistair.Bayley at invesco.com (Bayley, Alistair) Date: Wed Aug 6 06:00:45 2008 Subject: [Haskell-cafe] Haskell garbage collector notes? In-Reply-To: <5ae4f2ba0808060209u7542cf6bpa42571e91397a61f@mail.gmail.com> References: <5ae4f2ba0808060209u7542cf6bpa42571e91397a61f@mail.gmail.com> Message-ID: <125EACD0CAE4D24ABDB4D148C4593DA9049E950B@GBLONXMB02.corp.amvescap.net> > From: haskell-cafe-bounces@haskell.org > [mailto:haskell-cafe-bounces@haskell.org] On Behalf Of Galchin, Vasili > > Is > http://hackage.haskell.org/trac/ghc/wiki/GarbageCollectorNotes > a reliable source of info on the ghc garbage collector? Depends which version of GHC... the next release (6.10) will include the new parallel GC: http://research.microsoft.com/~simonpj/papers/parallel-gc/index.htm http://hackage.haskell.org/trac/ghc/wiki/Status/Releases Alistair ***************************************************************** Confidentiality Note: The information contained in this message, and any attachments, may contain confidential and/or privileged material. It is intended solely for the person(s) or entity to which it is addressed. Any review, retransmission, dissemination, or taking of any action in reliance upon this information by persons or entities other than the intended recipient(s) is prohibited. If you received this in error, please contact the sender and delete the material from any computer. ***************************************************************** From batterseapower at hotmail.com Wed Aug 6 06:29:59 2008 From: batterseapower at hotmail.com (Max Bolingbroke) Date: Wed Aug 6 06:29:39 2008 Subject: Version control systems In-Reply-To: References: <48981C03.10908@gmail.com> Message-ID: <9d4d38820808060329o12acd28ci6c73208a0476c165@mail.gmail.com> 2008/8/6 david48 : > cat: _darcs/prefs/defaultrepo: No such file or directory > Couldn't work out defaultrepo at ./darcs-all line 27. You can't yet build from the Git repo, alas. I've added the necessary patches and scripts (you need sync-all, not darcs-all) to http://hackage.haskell.org/trac/ghc/wiki/DarcsConversion but they haven't yet been commited to HEAD. Cheers, Max From batterseapower at hotmail.com Wed Aug 6 06:31:58 2008 From: batterseapower at hotmail.com (Max Bolingbroke) Date: Wed Aug 6 06:31:38 2008 Subject: Version control systems In-Reply-To: <1218016430.7661.189.camel@localhost> References: <48981C03.10908@gmail.com> <20080806051232.GD17673@scytale.galois.com> <1218016430.7661.189.camel@localhost> Message-ID: <9d4d38820808060331h4758c8a4y2bc6e79d14b8ae3d@mail.gmail.com> 2008/8/6 Duncan Coutts : > On Tue, 2008-08-05 at 22:12 -0700, Don Stewart wrote: >> marlowsd: >> > Following lots of useful discussion and evaluation of the available DVCSs >> > out there, the GHC team have made a decision: we're going to switch to git. >> >> Hooray, this will generate a lot of open source good will, and help make >> GHC more accessible to the outside world. > > Heh, you still need darcs to build it, because all the libs are using > darcs, and that's not going to change any time soon. One thing that might be a good idea is setting up Git mirrors of the libraries etc that we cannot convert to Git since other people depend on them. This would give us nice integration with Gits submodule support, allowing us to check out a consistent snapshot of the entire tree (including the libraries, Cabal etc) at any point in time straightforwardly. Of course, as a bonus you wouldn't have to install Darcs to clone. Cheers, Max From fmartini at gmail.com Wed Aug 6 06:44:35 2008 From: fmartini at gmail.com (Felix Martini) Date: Wed Aug 6 06:44:14 2008 Subject: Version control systems Message-ID: <6c0416190808060344kf15b273pd80078db84bf3c1f@mail.gmail.com> > and Windows support is less of an issue: git appears to work reasonably well on Windows these days. Congratulations on the switch, but isn't the decision a bit premature? I have read the log of last week's GHC meeting on IRC and nobody seemed to know if Git runs well on Windows with a large project like GHC. I also prefer Git to Darcs or Mercurial on Linux, but this rather quick decision makes it look like Windows support of GHC is an afterthought. Regards, Felix From duncan.coutts at worc.ox.ac.uk Wed Aug 6 07:08:19 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Wed Aug 6 07:07:54 2008 Subject: Version control systems In-Reply-To: <9d4d38820808060331h4758c8a4y2bc6e79d14b8ae3d@mail.gmail.com> References: <48981C03.10908@gmail.com> <20080806051232.GD17673@scytale.galois.com> <1218016430.7661.189.camel@localhost> <9d4d38820808060331h4758c8a4y2bc6e79d14b8ae3d@mail.gmail.com> Message-ID: <1218020899.7661.191.camel@localhost> On Wed, 2008-08-06 at 11:31 +0100, Max Bolingbroke wrote: > 2008/8/6 Duncan Coutts : > > On Tue, 2008-08-05 at 22:12 -0700, Don Stewart wrote: > >> marlowsd: > >> > Following lots of useful discussion and evaluation of the available DVCSs > >> > out there, the GHC team have made a decision: we're going to switch to git. > >> > >> Hooray, this will generate a lot of open source good will, and help make > >> GHC more accessible to the outside world. > > > > Heh, you still need darcs to build it, because all the libs are using > > darcs, and that's not going to change any time soon. > > One thing that might be a good idea is setting up Git mirrors of the > libraries etc that we cannot convert to Git since other people depend > on them. This would give us nice integration with Gits submodule > support, allowing us to check out a consistent snapshot of the entire > tree (including the libraries, Cabal etc) at any point in time > straightforwardly. Of course, as a bonus you wouldn't have to install > Darcs to clone. If that means I can continue to use darcs for Cabal development then I'm happy. Duncan From sam at rfc1149.net Wed Aug 6 06:35:09 2008 From: sam at rfc1149.net (Samuel Tardieu) Date: Wed Aug 6 07:15:00 2008 Subject: Version control systems References: <48981C03.10908@gmail.com> Message-ID: <87od46e8iq.fsf@willow.rfc1149.net> >>>>> "Simon" == Simon Marlow writes: Simon> We already have an up-to-date git mirror thanks to Thomas Simon> Schilling: Simon> git clone http://darcs.haskell.org/ghc.git Simon> (notice how fast that is :-) It would be even much faster if you (Thomas?) setup a git server. It is as easy as "touch git-daemon-export-ok" in the GIT repository and launching "git-daemon /path/to/parent/of/git/repo" at boot time, as shown by Chris Double at http://www.bluishcoder.co.nz/2007/09/how-to-publish-git-repository.html Then the "git://" protocol can be used, which makes intelligent decisions on what needs to be transferred. Sam -- Samuel Tardieu -- sam@rfc1149.net -- http://www.rfc1149.net/ From igloo at earth.li Wed Aug 6 07:16:27 2008 From: igloo at earth.li (Ian Lynagh) Date: Wed Aug 6 07:16:15 2008 Subject: Version control systems In-Reply-To: <6c0416190808060344kf15b273pd80078db84bf3c1f@mail.gmail.com> References: <6c0416190808060344kf15b273pd80078db84bf3c1f@mail.gmail.com> Message-ID: <20080806111627.GA30067@matrix.chaos.earth.li> On Wed, Aug 06, 2008 at 12:44:35PM +0200, Felix Martini wrote: > > and Windows support is less of an issue: git appears to work reasonably well on Windows these days. > > Congratulations on the switch, but isn't the decision a bit premature? > I have read the log of last week's GHC meeting on IRC and nobody > seemed to know if Git runs well on Windows with a large project like > GHC. I also prefer Git to Darcs or Mercurial on Linux, but this rather > quick decision makes it look like Windows support of GHC is an > afterthought. I tried git on Windows and it seemed to basically work. If anyone finds any problems with it, on Windows or otherwise, then this is the time to shout, before we have actually made the move. Thanks Ian From marlowsd at gmail.com Wed Aug 6 08:38:22 2008 From: marlowsd at gmail.com (Simon Marlow) Date: Wed Aug 6 08:38:06 2008 Subject: Version control systems In-Reply-To: <20080806111627.GA30067@matrix.chaos.earth.li> References: <6c0416190808060344kf15b273pd80078db84bf3c1f@mail.gmail.com> <20080806111627.GA30067@matrix.chaos.earth.li> Message-ID: <48999B3E.5060506@gmail.com> Ian Lynagh wrote: > On Wed, Aug 06, 2008 at 12:44:35PM +0200, Felix Martini wrote: >>> and Windows support is less of an issue: git appears to work reasonably well on Windows these days. >> Congratulations on the switch, but isn't the decision a bit premature? >> I have read the log of last week's GHC meeting on IRC and nobody >> seemed to know if Git runs well on Windows with a large project like >> GHC. I also prefer Git to Darcs or Mercurial on Linux, but this rather >> quick decision makes it look like Windows support of GHC is an >> afterthought. > > I tried git on Windows and it seemed to basically work. If anyone finds > any problems with it, on Windows or otherwise, then this is the time to > shout, before we have actually made the move. I also tried it out a bit, and didn't have any problems cloning repositories on a local drive, network drive, or remotely. I tried both the cygwin git and the MSYS git. Cheers, Simon From marlowsd at gmail.com Wed Aug 6 09:43:35 2008 From: marlowsd at gmail.com (Simon Marlow) Date: Wed Aug 6 09:43:19 2008 Subject: IRC meeting Message-ID: <4899AA87.5060806@gmail.com> IRC Meeting today at 1600 UK time as usual (1500 UTC, 0800 PDT, 1100 EDT). A couple of suggestions for topics; - HEAD stability (re previous disccusion on cvs-ghc) - mechanics of the git switchover Cheers, Simon From nominolo at googlemail.com Wed Aug 6 11:12:29 2008 From: nominolo at googlemail.com (Thomas Schilling) Date: Wed Aug 6 11:12:20 2008 Subject: Version control systems In-Reply-To: <87od46e8iq.fsf@willow.rfc1149.net> References: <48981C03.10908@gmail.com> <87od46e8iq.fsf@willow.rfc1149.net> Message-ID: On 6 Aug 2008, at 12:35, Samuel Tardieu wrote: >>>>>> "Simon" == Simon Marlow writes: > > Simon> We already have an up-to-date git mirror thanks to Thomas > Simon> Schilling: > > Simon> git clone http://darcs.haskell.org/ghc.git > > Simon> (notice how fast that is :-) > > It would be even much faster if you (Thomas?) setup a git server. It > is as easy as "touch git-daemon-export-ok" in the GIT repository and > launching "git-daemon /path/to/parent/of/git/repo" at boot time, as > shown by Chris Double at > > http://www.bluishcoder.co.nz/2007/09/how-to-publish-git- > repository.html > > Then the "git://" protocol can be used, which makes intelligent > decisions on what needs to be transferred. > Thanks, I will look into it. I need to talk to our admin anyway. / Thomas -- My shadow / Change is coming. / Now is my time. / Listen to my muscle memory. / Contemplate what I've been clinging to. / Forty-six and two ahead of me. -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 194 bytes Desc: This is a digitally signed message part Url : http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20080806/0ab4d386/PGP.bin From marco-oweber at gmx.de Thu Aug 7 05:44:33 2008 From: marco-oweber at gmx.de (Marc Weber) Date: Thu Aug 7 05:44:12 2008 Subject: somewhat OT: maybe useful git script "git-test-merge" In-Reply-To: <48981C03.10908@gmail.com> References: <48981C03.10908@gmail.com> Message-ID: <20080807094433.GB21686@gmx.de> Hi @ll, I'd like to tell you about a small script I've written to make life easier with git: git clone git://mawercer.de/git-test-merge It remembers test merge setups so that you can merge different feature branches by typing: $ gtm set setup1 branch1 remotes/branch2 branch3 $ gtm update setup1 $ gtm continue # after resolving conflicts To remove brances from the setup you have to edit .git/config Additionally it uses a commit message warning about it beeing a test merge only. Unfortunately I don't know a nice way to share the git-rerere cache yet which remembers conflict resolutions automatically. It works best on orthogonal branches of course :) Read about Linus complaint in man git-rerere to find out why I've written this script Sincerly Marc Weber From bdonlan at gmail.com Thu Aug 7 14:07:07 2008 From: bdonlan at gmail.com (Bryan Donlan) Date: Thu Aug 7 14:06:42 2008 Subject: git and sync-all: Why not merge in libraries? Message-ID: <3e8340490808071107r7cd222d0od614c5f0b377527a@mail.gmail.com> Hi all, With the upcoming switchover to git, has any thought gone into merging in the libraries into the main ghc tree (eliminating the need for a 'git-all')? git can merge two histories with no common ancestor, so no history would be lost - though you'd have to ask greater gurus than I the proper procedure. It's been done a few times on git itself to fold in externally developed tools. As I understand it, you could even continue development of the libraries on a seperate tree, as long as you don't try merging changes on ghc.git to $library.git, unless you filter out the GHC-only changes first somehow (merging $library.git back into ghc.git, as I understand it, should work...). Not sure if I'm missing something here, or if it's impractical for some reason... Thanks, Bryan Donlan From malcolm.wallace at cs.york.ac.uk Thu Aug 7 18:20:13 2008 From: malcolm.wallace at cs.york.ac.uk (Malcolm Wallace) Date: Thu Aug 7 18:19:53 2008 Subject: git and sync-all: Why not merge in libraries? In-Reply-To: <3e8340490808071107r7cd222d0od614c5f0b377527a@mail.gmail.com> References: <3e8340490808071107r7cd222d0od614c5f0b377527a@mail.gmail.com> Message-ID: <5A39F883-79C3-4392-9A43-3FFC048DACD6@cs.york.ac.uk> > With the upcoming switchover to git, has any thought gone into merging > in the libraries into the main ghc tree The libraries are going to remain under darcs, because they are shared with other haskell compilers. Regards, Malcolm From chak at cse.unsw.edu.au Thu Aug 7 22:04:15 2008 From: chak at cse.unsw.edu.au (Manuel M T Chakravarty) Date: Thu Aug 7 22:03:55 2008 Subject: Version control systems In-Reply-To: <9d4d38820808060331h4758c8a4y2bc6e79d14b8ae3d@mail.gmail.com> References: <48981C03.10908@gmail.com> <20080806051232.GD17673@scytale.galois.com> <1218016430.7661.189.camel@localhost> <9d4d38820808060331h4758c8a4y2bc6e79d14b8ae3d@mail.gmail.com> Message-ID: <18DB9581-AA5B-433C-9036-34EC2674C2CB@cse.unsw.edu.au> Max Bolingbroke: > 2008/8/6 Duncan Coutts : >> On Tue, 2008-08-05 at 22:12 -0700, Don Stewart wrote: >>> marlowsd: >>>> Following lots of useful discussion and evaluation of the >>>> available DVCSs >>>> out there, the GHC team have made a decision: we're going to >>>> switch to git. >>> >>> Hooray, this will generate a lot of open source good will, and >>> help make >>> GHC more accessible to the outside world. >> >> Heh, you still need darcs to build it, because all the libs are using >> darcs, and that's not going to change any time soon. > > One thing that might be a good idea is setting up Git mirrors of the > libraries etc that we cannot convert to Git since other people depend > on them. This would give us nice integration with Gits submodule > support, allowing us to check out a consistent snapshot of the entire > tree (including the libraries, Cabal etc) at any point in time > straightforwardly. Of course, as a bonus you wouldn't have to install > Darcs to clone. I seriously hope the plan is to move all *core* libraries (including GHC's cabal repo) etc over to git, too. In other word, everything that you need to build the development version of GHC should come via git. Having a mix of VCSs would be the worst option of all. Manuel From igloo at earth.li Fri Aug 8 09:03:29 2008 From: igloo at earth.li (Ian Lynagh) Date: Fri Aug 8 09:03:02 2008 Subject: Version control systems In-Reply-To: <18DB9581-AA5B-433C-9036-34EC2674C2CB@cse.unsw.edu.au> References: <48981C03.10908@gmail.com> <20080806051232.GD17673@scytale.galois.com> <1218016430.7661.189.camel@localhost> <9d4d38820808060331h4758c8a4y2bc6e79d14b8ae3d@mail.gmail.com> <18DB9581-AA5B-433C-9036-34EC2674C2CB@cse.unsw.edu.au> Message-ID: <20080808130329.GA15063@matrix.chaos.earth.li> On Fri, Aug 08, 2008 at 12:04:15PM +1000, Manuel M T Chakravarty wrote: > > I seriously hope the plan is to move all *core* libraries (including > GHC's cabal repo) etc over to git, too. In other word, everything > that you need to build the development version of GHC should come via > git. Having a mix of VCSs would be the worst option of all. No, the plan is to move only the GHC and testsuite repos to git, as the others are also used by hugs, nhc98, etc. It would be possible to move GHC's Cabal repo over too, as that is private to GHC, but given the other libraries will be using darcs anyway I think it is simpler to keep all darcs repos using the same VCS. Thanks Ian From duncan.coutts at worc.ox.ac.uk Fri Aug 8 20:32:51 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Fri Aug 8 20:31:46 2008 Subject: Version control systems In-Reply-To: <20080808130329.GA15063@matrix.chaos.earth.li> References: <48981C03.10908@gmail.com> <20080806051232.GD17673@scytale.galois.com> <1218016430.7661.189.camel@localhost> <9d4d38820808060331h4758c8a4y2bc6e79d14b8ae3d@mail.gmail.com> <18DB9581-AA5B-433C-9036-34EC2674C2CB@cse.unsw.edu.au> <20080808130329.GA15063@matrix.chaos.earth.li> Message-ID: <1218241971.7661.233.camel@localhost> On Fri, 2008-08-08 at 14:03 +0100, Ian Lynagh wrote: > On Fri, Aug 08, 2008 at 12:04:15PM +1000, Manuel M T Chakravarty wrote: > > > > I seriously hope the plan is to move all *core* libraries (including > > GHC's cabal repo) etc over to git, too. In other word, everything > > that you need to build the development version of GHC should come via > > git. Having a mix of VCSs would be the worst option of all. > > No, the plan is to move only the GHC and testsuite repos to git, as the > others are also used by hugs, nhc98, etc. > > It would be possible to move GHC's Cabal repo over too, as that is > private to GHC, but given the other libraries will be using darcs anyway > I think it is simpler to keep all darcs repos using the same VCS. If there's some way of having automated git mirrors of the upstream darcs repos then that's might be convenient for people building ghc. Asking the maintainers of ?all other libs to switch is a bit much though. Duncan From chak at cse.unsw.edu.au Sat Aug 9 01:46:50 2008 From: chak at cse.unsw.edu.au (Manuel M T Chakravarty) Date: Sat Aug 9 01:46:27 2008 Subject: Version control systems In-Reply-To: <20080808130329.GA15063@matrix.chaos.earth.li> References: <48981C03.10908@gmail.com> <20080806051232.GD17673@scytale.galois.com> <1218016430.7661.189.camel@localhost> <9d4d38820808060331h4758c8a4y2bc6e79d14b8ae3d@mail.gmail.com> <18DB9581-AA5B-433C-9036-34EC2674C2CB@cse.unsw.edu.au> <20080808130329.GA15063@matrix.chaos.earth.li> Message-ID: <5FEA1F32-9C34-4888-A5BE-D0460D55C307@cse.unsw.edu.au> Ian Lynagh: > On Fri, Aug 08, 2008 at 12:04:15PM +1000, Manuel M T Chakravarty > wrote: >> >> I seriously hope the plan is to move all *core* libraries (including >> GHC's cabal repo) etc over to git, too. In other word, everything >> that you need to build the development version of GHC should come via >> git. Having a mix of VCSs would be the worst option of all. > > No, the plan is to move only the GHC and testsuite repos to git, as > the > others are also used by hugs, nhc98, etc. > > It would be possible to move GHC's Cabal repo over too, as that is > private to GHC, but given the other libraries will be using darcs > anyway > I think it is simpler to keep all darcs repos using the same VCS. I think all *core* libraries must switch. Seriously, requiring GHC developer to use a mix of two vcs during development is a Very Bad Idea. Don was excited about getting more people to look at the source when it is in git (see the comments he posted from reddit). By requiring two vcs you will get *less* people to look at the source. This is not only to get the sources to hack them, but you effectively require developers to learn the commands for two vcs (when they are already reluctant to learn one). For example, often enough somebody who changes something in GHC will modify the base package, too. Then, to commit the overall work, you need to commit using both vcs. If you need to branch for your work, you need to create branches in two vcs (no idea whether the semantics of a branch in git and darcs is anywhere similar). When you merge your branch, you need to merge in both vcs. You can't seriously propose such a set up! Duncan wrote, > If there's some way of having automated git mirrors of the upstream > darcs repos then that's might be convenient for people building ghc. > Asking the maintainers of all other libs to switch is a bit much > though. I am not talking about all libs, I am talking about the core libs. Most developers of the core libs are also GHC developers. So, you ask them to change already by changing the vcs of GHC. Asking them to work with two vcs at the same time is worse IMHO. I *strongly* object to moving to git before this isn't sorted out. As Roman said before, GHC is heading into a dangerous direction. It gets progressively harder to contribute to the project at the moment. First, changing the build system to Cabal. Now, proposing to use two vcs. Somebody who is new to the project not only has to learn the internals of GHC, but they also have to learn two new vcs, and if they need to change the build system, they need to learn a new build tool. Raising the bar for developers to contribute to a project has been proven to be a very bad idea many times. Let's not take GHC down that path. Manuel From duncan.coutts at worc.ox.ac.uk Sat Aug 9 05:51:56 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Sat Aug 9 05:50:51 2008 Subject: Version control systems In-Reply-To: <5FEA1F32-9C34-4888-A5BE-D0460D55C307@cse.unsw.edu.au> References: <48981C03.10908@gmail.com> <20080806051232.GD17673@scytale.galois.com> <1218016430.7661.189.camel@localhost> <9d4d38820808060331h4758c8a4y2bc6e79d14b8ae3d@mail.gmail.com> <18DB9581-AA5B-433C-9036-34EC2674C2CB@cse.unsw.edu.au> <20080808130329.GA15063@matrix.chaos.earth.li> <5FEA1F32-9C34-4888-A5BE-D0460D55C307@cse.unsw.edu.au> Message-ID: <1218275516.7661.236.camel@localhost> On Sat, 2008-08-09 at 15:46 +1000, Manuel M T Chakravarty wrote: > Raising the bar for developers to contribute to a project has been > proven to be a very bad idea many times. Let's not take GHC down that > path. I don't especially relish having to learn another vcs tool or raising the bar for contributions to Cabal either (we have lots of people who make small one-off contributions). Duncan From isaacdupree at charter.net Sat Aug 9 10:50:40 2008 From: isaacdupree at charter.net (Isaac Dupree) Date: Sat Aug 9 10:50:24 2008 Subject: Version control systems In-Reply-To: <1218275516.7661.236.camel@localhost> References: <48981C03.10908@gmail.com> <20080806051232.GD17673@scytale.galois.com> <1218016430.7661.189.camel@localhost> <9d4d38820808060331h4758c8a4y2bc6e79d14b8ae3d@mail.gmail.com> <18DB9581-AA5B-433C-9036-34EC2674C2CB@cse.unsw.edu.au> <20080808130329.GA15063@matrix.chaos.earth.li> <5FEA1F32-9C34-4888-A5BE-D0460D55C307@cse.unsw.edu.au> <1218275516.7661.236.camel@localhost> Message-ID: <489DAEC0.5090407@charter.net> Duncan Coutts wrote: > On Sat, 2008-08-09 at 15:46 +1000, Manuel M T Chakravarty wrote: > >> Raising the bar for developers to contribute to a project has been >> proven to be a very bad idea many times. Let's not take GHC down that >> path. > > I don't especially relish having to learn another vcs tool or raising > the bar for contributions to Cabal either (we have lots of people who > make small one-off contributions). I wonder how many of the libraries are "core" in that they need to be changed a lot for GHC? - all the ones that depend on GHC internals, such as base. (Except the current system has many of them use preprocessor conditionals so that can they depend on various compilers' internals, including nhc98 and hugs? Because a lot of that code is actually shared between implementations) - Cabal, since it's needing a lot of extension to make GHC work with it. Do boot-libraries like unix typically need work by GHC devs? On the other hand, it's looking like there's enough intersection between GHC and other-haskell that it's not such a helpful path to pursue. not quite related: I wonder about various haskell libs switching to darcs2 format. A few new programs use it already. As distros include darcs2, it should become less painful. The conversion is less painful for code that's branched less. So maybe in the future a lot of Haskell libs will be in the superior darcs2 format. what an unpleasant situation! But cross-converting between darcs and git format for the same repo is probably even worse. Last time I tried the darcs-all script (maybe a month ago, using darcs 2.0.2), IIRC, it hung, or had some other problem in one of the libraries. Even though it was a clean copy that I'd only ever pulled into (many times, and was getted by darcs-1.0.9, but still). And darcs-all on the libraries has always been a slow sequential task. So I'm not actually all that enamoured of darcs for ghc development, even for the libs. Since I couldn't update anymore (despite going into ghc-head/libraries/something and mucking around with darcs-revert and such), I just deleted the tree and decided to wait until GHC switches VCS before getting a new copy. (trying git-cloning ghc.git sometime, took about 10 minutes, nearly no CPU time, and 80 MB, so I'm pretty happy about that random experience, but I didn't try to do anything with the repo) -Isaac From igloo at earth.li Sat Aug 9 11:39:21 2008 From: igloo at earth.li (Ian Lynagh) Date: Sat Aug 9 11:38:52 2008 Subject: Version control systems In-Reply-To: <1218241971.7661.233.camel@localhost> References: <48981C03.10908@gmail.com> <20080806051232.GD17673@scytale.galois.com> <1218016430.7661.189.camel@localhost> <9d4d38820808060331h4758c8a4y2bc6e79d14b8ae3d@mail.gmail.com> <18DB9581-AA5B-433C-9036-34EC2674C2CB@cse.unsw.edu.au> <20080808130329.GA15063@matrix.chaos.earth.li> <1218241971.7661.233.camel@localhost> Message-ID: <20080809153921.GA15225@matrix.chaos.earth.li> On Sat, Aug 09, 2008 at 01:32:51AM +0100, Duncan Coutts wrote: > > If there's some way of having automated git mirrors of the upstream > darcs repos then that's might be convenient for people building ghc. I don't think that that really helps. If all you want to do is build then the sync-all script will do the get/pull for you (as long as you have both git and darcs installed). If you want to make any changes at all then you really need to be using the "native" repo format. If someone thinks it is worth doing then it is possible, though. Thanks Ian From igloo at earth.li Sat Aug 9 12:08:01 2008 From: igloo at earth.li (Ian Lynagh) Date: Sat Aug 9 12:07:31 2008 Subject: Version control systems In-Reply-To: <5FEA1F32-9C34-4888-A5BE-D0460D55C307@cse.unsw.edu.au> References: <48981C03.10908@gmail.com> <20080806051232.GD17673@scytale.galois.com> <1218016430.7661.189.camel@localhost> <9d4d38820808060331h4758c8a4y2bc6e79d14b8ae3d@mail.gmail.com> <18DB9581-AA5B-433C-9036-34EC2674C2CB@cse.unsw.edu.au> <20080808130329.GA15063@matrix.chaos.earth.li> <5FEA1F32-9C34-4888-A5BE-D0460D55C307@cse.unsw.edu.au> Message-ID: <20080809160801.GB15225@matrix.chaos.earth.li> On Sat, Aug 09, 2008 at 03:46:50PM +1000, Manuel M T Chakravarty wrote: > > Don was excited about getting more people to look at the source > when it is in git (see the comments he posted from reddit). I am skeptical that this initial excitement and cloning will translate into more developers. Also, for someone who's never used either VCS, I think the overhead of learning to use darcs is far lower than of learning to use git. The move to git is more likely to help by not driving away people who have had problems working with GHC in darcs, than by attracting developers in the first place. New GHC developers come from GHC users, not darcs/git users. > I am not talking about all libs, I am talking about the core libs. > Most developers of the core libs are also GHC developers. I'm not sure that's true. e.g. Malcolm and Ross both commit to the bootlibs, and we get a lot of patches from various people in the community. > I *strongly* object to moving to git before this isn't sorted out. FWIW, personally I would prefer staying with darcs. I prefer its underlying philosophy, and I find its UI far more intuitive and easy to use. I don't suffer from its problems, though - but then, I don't maintain a long-running HEAD branch, and I mostly don't use it on Windows. However, there certainly are a number of people who are having problems working with darcs (although in some cases this may be because they are working in a way incompatible with darcs, e.g. one person had replaced libraries/ with a symlink, for reasons he didn't explain). Given darcs certainly has some problems, and I seem to be in a minority, I don't feel I can stand in the way of a move. But I think we need a wider discussion before we can think about moving the bootlibs to git. If we are going to have a changeover, then the most convenient time in GHC's development cycle to make it is in 4 or 5 weeks time. Thanks Ian From dons at galois.com Sat Aug 9 15:06:51 2008 From: dons at galois.com (Don Stewart) Date: Sat Aug 9 15:06:28 2008 Subject: Version control systems In-Reply-To: <5FEA1F32-9C34-4888-A5BE-D0460D55C307@cse.unsw.edu.au> References: <48981C03.10908@gmail.com> <20080806051232.GD17673@scytale.galois.com> <1218016430.7661.189.camel@localhost> <9d4d38820808060331h4758c8a4y2bc6e79d14b8ae3d@mail.gmail.com> <18DB9581-AA5B-433C-9036-34EC2674C2CB@cse.unsw.edu.au> <20080808130329.GA15063@matrix.chaos.earth.li> <5FEA1F32-9C34-4888-A5BE-D0460D55C307@cse.unsw.edu.au> Message-ID: <20080809190651.GC3902@scytale.galois.com> chak: > Ian Lynagh: > >On Fri, Aug 08, 2008 at 12:04:15PM +1000, Manuel M T Chakravarty > >wrote: > >> > >>I seriously hope the plan is to move all *core* libraries (including > >>GHC's cabal repo) etc over to git, too. In other word, everything > >>that you need to build the development version of GHC should come via > >>git. Having a mix of VCSs would be the worst option of all. > > > >No, the plan is to move only the GHC and testsuite repos to git, as > >the > >others are also used by hugs, nhc98, etc. > > > >It would be possible to move GHC's Cabal repo over too, as that is > >private to GHC, but given the other libraries will be using darcs > >anyway > >I think it is simpler to keep all darcs repos using the same VCS. > > I think all *core* libraries must switch. Seriously, requiring GHC > developer to use a mix of two vcs during development is a Very Bad > Idea. I agree with this. As Audrey says, you have to lower the barrier to entry. That means: * one build system * one vcs to build ghc (and anything it requires, such as the core libraries). This is a chance to make a big step towards accessibility, let's make that step. -- Don From dons at galois.com Sat Aug 9 15:38:41 2008 From: dons at galois.com (Don Stewart) Date: Sat Aug 9 15:38:14 2008 Subject: Version control systems In-Reply-To: <20080809190651.GC3902@scytale.galois.com> References: <48981C03.10908@gmail.com> <20080806051232.GD17673@scytale.galois.com> <1218016430.7661.189.camel@localhost> <9d4d38820808060331h4758c8a4y2bc6e79d14b8ae3d@mail.gmail.com> <18DB9581-AA5B-433C-9036-34EC2674C2CB@cse.unsw.edu.au> <20080808130329.GA15063@matrix.chaos.earth.li> <5FEA1F32-9C34-4888-A5BE-D0460D55C307@cse.unsw.edu.au> <20080809190651.GC3902@scytale.galois.com> Message-ID: <20080809193841.GD3902@scytale.galois.com> dons: > chak: > > Ian Lynagh: > > >On Fri, Aug 08, 2008 at 12:04:15PM +1000, Manuel M T Chakravarty > > >wrote: > > >> > > >>I seriously hope the plan is to move all *core* libraries (including > > >>GHC's cabal repo) etc over to git, too. In other word, everything > > >>that you need to build the development version of GHC should come via > > >>git. Having a mix of VCSs would be the worst option of all. > > > > > >No, the plan is to move only the GHC and testsuite repos to git, as > > >the > > >others are also used by hugs, nhc98, etc. > > > > > >It would be possible to move GHC's Cabal repo over too, as that is > > >private to GHC, but given the other libraries will be using darcs > > >anyway > > >I think it is simpler to keep all darcs repos using the same VCS. > > > > I think all *core* libraries must switch. Seriously, requiring GHC > > developer to use a mix of two vcs during development is a Very Bad > > Idea. > > I agree with this. > > As Audrey says, you have to lower the barrier to entry. That means: > > * one build system > * one vcs > > to build ghc (and anything it requires, such as the core libraries). > > This is a chance to make a big step towards accessibility, let's make that step. I just want to add to this. We're offering an unusual product: a lazy, purely functional language. This already separates us from the mainstream. So how to we ensure we minimise the stress of adopting something so unfamiliar? By ensuring that in all other respects the environment they have to learn is familiar and simple. I think we risk isolating oursevles yet further -- and creating new barriers to adoption, beyond those we can't avoid -- by adding more complicated dependencies (two revision control systems, one of which, darcs, is now firmly out of the maintstream). Instead, if we just use ubiquitous, common tools -- like git -- for everything, we minimise the pain for people, and sit firmly in the mainstream of open source. If anything has been learnt by Spencer and I while working on xmonad, is: dependencies, dependencies, dependencies reduce these, and you gain eyeballs, and ultimately developers. Increase these, and you end up isolated and marginalised. So let's capitalise on this switch to git, and take the opportunity to remove one big dependency from the system. -- Don From Malcolm.Wallace at cs.york.ac.uk Sat Aug 9 16:30:52 2008 From: Malcolm.Wallace at cs.york.ac.uk (Malcolm Wallace) Date: Sat Aug 9 16:30:23 2008 Subject: Version control systems In-Reply-To: <20080809190651.GC3902@scytale.galois.com> References: <48981C03.10908@gmail.com> <20080806051232.GD17673@scytale.galois.com> <1218016430.7661.189.camel@localhost> <9d4d38820808060331h4758c8a4y2bc6e79d14b8ae3d@mail.gmail.com> <18DB9581-AA5B-433C-9036-34EC2674C2CB@cse.unsw.edu.au> <20080808130329.GA15063@matrix.chaos.earth.li> <5FEA1F32-9C34-4888-A5BE-D0460D55C307@cse.unsw.edu.au> <20080809190651.GC3902@scytale.galois.com> Message-ID: <36A0EEA6-5E34-4A1A-A008-7F847D84A1E2@cs.york.ac.uk> >>>> I seriously hope the plan is to move all *core* libraries >>>> (including >>>> GHC's cabal repo) etc over to git, too. > * one build system > * one vcs > This is a chance to make a big step towards accessibility, let's > make that step. Ultimately, I don't think git would make ghc any more accessible to new contributors. Darcs is not especially offputting to any beginner who already knows something about VCS in general. What the move to git is about, is making life easier for the *existing* HQ and core contributors. Evaluate it on that basis, and not in terms of unknown (and unknowable) benefits to current non- contributors. Indeed, you should also consider how many contributors you might lose in a move. I do hear some significant current contributors having doubts. I can certainly appreciate that having to run 2 VCS in parallel might be confusing and simply make matters worse than at present. The libraries question is a difficult one. We have made a lot of effort over the last 5 years to build infrastructure and code that is shared and portable across multiple implementations of the language. Is this the time to fork those supposedly "common" core libraries into ghc versions vs the rest? As someone who is not a contributor to GHC, and has never experienced anything more than trivial problems with darcs, I have not felt qualified to comment on the proposal to change GHC's VCS. But as a frequent fixer of breakage in the core libraries, I would be reluctant to have to move to a different VCS there. If the core libraries do move, it will be increasingly difficult to avoid also needing to move nhc98 and Hugs and goodness-knows how many other libraries. For me, it would be un-forced, annoying, and I may not have the extra time available to keep up. So there is a danger that the community will be left with a single (albeit very high quality) compiler, with no need for a Haskell Prime (or any other Standard) in future. If there are technical solutions that can reduce the pain, whilst keeping multiple stake-holders happy, then I think they should be investigated. Regards, Malcolm From nr at eecs.harvard.edu Sat Aug 9 18:56:23 2008 From: nr at eecs.harvard.edu (Norman Ramsey) Date: Sat Aug 9 18:55:52 2008 Subject: Version control systems In-Reply-To: <36A0EEA6-5E34-4A1A-A008-7F847D84A1E2@cs.york.ac.uk> (sfid-H-20080809-163309-+87.16-1@multi.osbf.lua) References: <48981C03.10908@gmail.com> <20080806051232.GD17673@scytale.galois.com> <1218016430.7661.189.camel@localhost> <9d4d38820808060331h4758c8a4y2bc6e79d14b8ae3d@mail.gmail.com> <18DB9581-AA5B-433C-9036-34EC2674C2CB@cse.unsw.edu.au> <20080808130329.GA15063@matrix.chaos.earth.li> <5FEA1F32-9C34-4888-A5BE-D0460D55C307@cse.unsw.edu.au> <20080809190651.GC3902@scytale.galois.com> <36A0EEA6-5E34-4A1A-A008-7F847D84A1E2@cs.york.ac.uk> (sfid-H-20080809-163309-+87.16-1@multi.osbf.lua) Message-ID: <20080809225624.BDD6613833F@drdoom.eecs.harvard.edu> As a very part-time, temporarily inactive GHC developer I will offer some opinions which should carry no weight: * When I saw the announcement, I cheered! Last fall, I lost 2 weeks of a 9-week visit to darcs hell. While the alleged features may be alluring, the software simply doesn't do what it says on the box. The highly touted 'theory of patches' is not published anywhere in any form that can be understood and checked by anyone with a little bit of mathematics (e.g., group theory or algebra). All these truths make me eager to be rid of darcs. * It seems clear that git offers a richer user interface than darcs and that the UI is harder to master. Moreover, because everyone I have talked to finds the git documentation less than completely helpful, git is probably harder to learn than darcs. Git's advantages are that it is robust, fast, and popular. * A number of people I trust and respect have urged me to adopt git. Since 2005, nobody has urged me to adopt darcs. A number of people I trust and respect have said they wished to abandon darcs. Nobody has suggested abandoning git. * I violently agree with whomever (Don? Malcolm?) said that the Haskell community will prosper to the degree that we have *one* build system and *one* version-control system. And when the build system or version-control system is standard, we gain eyeballs and developers. I haven't found a standard build system that I am willing to use, but I think git is good enough to be used. * Our long-term goal should be to get the *entire* Haskell development community to agree on a version-control system---one that is not darcs. We should expect this process to take several years, and we should expect it to cost money. Would Microsoft or Galois or York or other large players be willing to donate part of an expert's time to migrate to the new version-control system? I'm no particular fan of git. But in a worse-is-better sort of way, I think it's in---it will fill the niche of free, distributed version control. It would be good to identify a way of helping to smooth the path not only for GHC and *all* the libraries but for Hugs, York, xmonad, everybody. Norman, whose most popular open-source software still lives under RCS! From chak at cse.unsw.edu.au Sun Aug 10 00:16:25 2008 From: chak at cse.unsw.edu.au (Manuel M T Chakravarty) Date: Sun Aug 10 00:16:02 2008 Subject: Version control systems In-Reply-To: <1218275516.7661.236.camel@localhost> References: <48981C03.10908@gmail.com> <20080806051232.GD17673@scytale.galois.com> <1218016430.7661.189.camel@localhost> <9d4d38820808060331h4758c8a4y2bc6e79d14b8ae3d@mail.gmail.com> <18DB9581-AA5B-433C-9036-34EC2674C2CB@cse.unsw.edu.au> <20080808130329.GA15063@matrix.chaos.earth.li> <5FEA1F32-9C34-4888-A5BE-D0460D55C307@cse.unsw.edu.au> <1218275516.7661.236.camel@localhost> Message-ID: <0D35A7C8-71C6-431D-A5FB-78704B628147@cse.unsw.edu.au> Duncan Coutts: > On Sat, 2008-08-09 at 15:46 +1000, Manuel M T Chakravarty wrote: > >> Raising the bar for developers to contribute to a project has been >> proven to be a very bad idea many times. Let's not take GHC down >> that >> path. > > I don't especially relish having to learn another vcs tool or raising > the bar for contributions to Cabal either (we have lots of people who > make small one-off contributions). I don't think it matters what vcs Cabal uses. GHC does already for a while use a separate repo for its version of Cabal, and the GHC Cabal repo needs to be explicitly updated to ensure that changes to Cabal do not randomly break GHC. To be honest, if I had to say anything, I would say that GHC has to uses fixed, stable versions of Cabal (like it does of gmp). So, it really doesn't matter what vcs Cabal uses. A completely different matter are libraries like base which are deeply connected to GHC. Manuel From chak at cse.unsw.edu.au Sun Aug 10 00:22:06 2008 From: chak at cse.unsw.edu.au (Manuel M T Chakravarty) Date: Sun Aug 10 00:21:51 2008 Subject: Version control systems In-Reply-To: <489DAEC0.5090407@charter.net> References: <48981C03.10908@gmail.com> <20080806051232.GD17673@scytale.galois.com> <1218016430.7661.189.camel@localhost> <9d4d38820808060331h4758c8a4y2bc6e79d14b8ae3d@mail.gmail.com> <18DB9581-AA5B-433C-9036-34EC2674C2CB@cse.unsw.edu.au> <20080808130329.GA15063@matrix.chaos.earth.li> <5FEA1F32-9C34-4888-A5BE-D0460D55C307@cse.unsw.edu.au> <1218275516.7661.236.camel@localhost> <489DAEC0.5090407@charter.net> Message-ID: Isaac Dupree: > Duncan Coutts wrote: >> On Sat, 2008-08-09 at 15:46 +1000, Manuel M T Chakravarty wrote: >>> Raising the bar for developers to contribute to a project has >>> been proven to be a very bad idea many times. Let's not take GHC >>> down that path. >> I don't especially relish having to learn another vcs tool or raising >> the bar for contributions to Cabal either (we have lots of people who >> make small one-off contributions). > > I wonder how many of the libraries are "core" in that they need to > be changed a lot for GHC? The boot libraries, ie, those needed to build the HEAD of the ghc repo: SUBDIRS = ghc-prim $(INTEGER_LIBRARY) base array packedstring SUBDIRS += containers bytestring old-locale old-time filepath directory ifeq "$(GhcLibsWithUnix)" "YES" SUBDIRS += unix endif ifeq "$(Windows)" "YES" SUBDIRS += $(wildcard Win32) endif SUBDIRS += process pretty hpc template-haskell editline Cabal random haskell98 Here Cabal, is ghc variant of the Cabal repo, not the actually Cabal head. The whole point is to make sure that anybody who decides to hack GHC needs to install and learn just one vcs, not two. Manuel From chak at cse.unsw.edu.au Sun Aug 10 00:40:27 2008 From: chak at cse.unsw.edu.au (Manuel M T Chakravarty) Date: Sun Aug 10 00:39:59 2008 Subject: Version control systems In-Reply-To: <20080809160801.GB15225@matrix.chaos.earth.li> References: <48981C03.10908@gmail.com> <20080806051232.GD17673@scytale.galois.com> <1218016430.7661.189.camel@localhost> <9d4d38820808060331h4758c8a4y2bc6e79d14b8ae3d@mail.gmail.com> <18DB9581-AA5B-433C-9036-34EC2674C2CB@cse.unsw.edu.au> <20080808130329.GA15063@matrix.chaos.earth.li> <5FEA1F32-9C34-4888-A5BE-D0460D55C307@cse.unsw.edu.au> <20080809160801.GB15225@matrix.chaos.earth.li> Message-ID: <960585F5-2454-40FE-8B6A-8E2198904BB6@cse.unsw.edu.au> Ian Lynagh: > On Sat, Aug 09, 2008 at 03:46:50PM +1000, Manuel M T Chakravarty > wrote: >> I am not talking about all libs, I am talking about the core libs. >> Most developers of the core libs are also GHC developers. > > I'm not sure that's true. e.g. Malcolm and Ross both commit to the > bootlibs, and we get a lot of patches from various people in the > community. Ross does commit patches to ghc (according to darcs changes). So, either he stops that or has to learn git anyway. I don't think we are talking about random contributions from the community. If anything, we need to compare two numbers (1) developers who need to start using git when the ghc repo changes and (2) library developers (ie, people with commit bits regularly contributing to the boot libs) who do not contribute to ghc and hence could avoid learning git if the boot libs stay in a darcs repo. >> I *strongly* object to moving to git before this isn't sorted out. > > FWIW, personally I would prefer staying with darcs. I prefer its > underlying philosophy, and I find its UI far more intuitive and easy > to > use. Personally, I am more than happy to stay with darcs, too, but my understanding was that at least the Simons decided that we are going to move from darcs to git. All I am saying is that whatever vcs ghc uses, you need to be able to *easily* get, modify, and commit patches to the HEAD and the boot libs with *just one* vcs. Using two vcs is going to make the current situation worse, not better. For example, SimonPJ said one reason for switching vcs is that interns had trouble getting started because they did have trouble obtaining the head as darcs caused them grief. If the boot libs stay under darcs control. Nothing is one, the same interns still won't get going any quicker. Presumably, they are going to take even longer, because they can now get into trouble with darcs and git. We want to lower the barrier to entry, not raise it. By effectively adding a complications (namely git) and not removing any, matters will get worse. Manuel From chak at cse.unsw.edu.au Sun Aug 10 00:42:39 2008 From: chak at cse.unsw.edu.au (Manuel M T Chakravarty) Date: Sun Aug 10 00:42:17 2008 Subject: Version control systems In-Reply-To: <20080809193841.GD3902@scytale.galois.com> References: <48981C03.10908@gmail.com> <20080806051232.GD17673@scytale.galois.com> <1218016430.7661.189.camel@localhost> <9d4d38820808060331h4758c8a4y2bc6e79d14b8ae3d@mail.gmail.com> <18DB9581-AA5B-433C-9036-34EC2674C2CB@cse.unsw.edu.au> <20080808130329.GA15063@matrix.chaos.earth.li> <5FEA1F32-9C34-4888-A5BE-D0460D55C307@cse.unsw.edu.au> <20080809190651.GC3902@scytale.galois.com> <20080809193841.GD3902@scytale.galois.com> Message-ID: Listen to Don, he is a wise man! Manuel Don Stewart: >> I agree with this. >> >> As Audrey says, you have to lower the barrier to entry. That means: >> >> * one build system >> * one vcs >> >> to build ghc (and anything it requires, such as the core libraries). >> >> This is a chance to make a big step towards accessibility, let's >> make that step. > > I just want to add to this. We're offering an unusual product: a lazy, > purely functional language. This already separates us from the > mainstream. So how to we ensure we minimise the stress of adopting > something so unfamiliar? > > By ensuring that in all other respects the environment they have to > learn is familiar and simple. > > I think we risk isolating oursevles yet further -- and creating new > barriers to adoption, beyond those we can't avoid -- by adding more > complicated dependencies (two revision control systems, one of which, > darcs, is now firmly out of the maintstream). > > Instead, if we just use ubiquitous, common tools -- like git -- for > everything, we minimise the pain for people, and sit firmly in the > mainstream of open source. > > If anything has been learnt by Spencer and I while working on xmonad, > is: > dependencies, dependencies, dependencies > > reduce these, and you gain eyeballs, and ultimately developers. > Increase > these, and you end up isolated and marginalised. > > So let's capitalise on this switch to git, and take the opportunity to > remove one big dependency from the system. > > -- Don From rl at cse.unsw.edu.au Sun Aug 10 01:44:10 2008 From: rl at cse.unsw.edu.au (Roman Leshchinskiy) Date: Sun Aug 10 01:43:51 2008 Subject: Version control systems In-Reply-To: <960585F5-2454-40FE-8B6A-8E2198904BB6@cse.unsw.edu.au> References: <48981C03.10908@gmail.com> <20080806051232.GD17673@scytale.galois.com> <1218016430.7661.189.camel@localhost> <9d4d38820808060331h4758c8a4y2bc6e79d14b8ae3d@mail.gmail.com> <18DB9581-AA5B-433C-9036-34EC2674C2CB@cse.unsw.edu.au> <20080808130329.GA15063@matrix.chaos.earth.li> <5FEA1F32-9C34-4888-A5BE-D0460D55C307@cse.unsw.edu.au> <20080809160801.GB15225@matrix.chaos.earth.li> <960585F5-2454-40FE-8B6A-8E2198904BB6@cse.unsw.edu.au> Message-ID: <4255399A-EE1F-4E2A-B54E-188D456748FF@cse.unsw.edu.au> On 10/08/2008, at 14:40, Manuel M T Chakravarty wrote: > Personally, I am more than happy to stay with darcs, too, but my > understanding was that at least the Simons decided that we are going > to move from darcs to git. All I am saying is that whatever vcs ghc > uses, you need to be able to *easily* get, modify, and commit > patches to the HEAD and the boot libs with *just one* vcs. Using > two vcs is going to make the current situation worse, not better. I suspect that if GHC switches to git, it will become the standard vcs in the Haskell community sooner or later. Expecting that people (especially newcomers) will use different vcs for different libraries/ compilers is just unrealistic. Really, why should they? Any advantages in usability that darcs might have over git will be overshadowed by the inconvenience of having to remember two different sets of commands. I expect that many new projects will use git and old projects will start switching to it over time. So if the move is made, it should IMO include as big a chunk of the infrastructure as possible. Eventually, it will migrate to git anyway and the earlier it does, the simpler life will be for the developers. As to whether the switch should be made at all, I'm not sure. I've had my share of problems with darcs and I don't think it's suitable for a project of GHC's size at the moment. On the other hand, I suspect that a mixture of git and darcs repos will be even more problematic than what we have now. Maybe investing some time in fixing the most obvious darcs problems would be a better solution? Roman From rl at cse.unsw.edu.au Sun Aug 10 01:53:00 2008 From: rl at cse.unsw.edu.au (Roman Leshchinskiy) Date: Sun Aug 10 01:52:47 2008 Subject: Version control systems In-Reply-To: <20080809193841.GD3902@scytale.galois.com> References: <48981C03.10908@gmail.com> <20080806051232.GD17673@scytale.galois.com> <1218016430.7661.189.camel@localhost> <9d4d38820808060331h4758c8a4y2bc6e79d14b8ae3d@mail.gmail.com> <18DB9581-AA5B-433C-9036-34EC2674C2CB@cse.unsw.edu.au> <20080808130329.GA15063@matrix.chaos.earth.li> <5FEA1F32-9C34-4888-A5BE-D0460D55C307@cse.unsw.edu.au> <20080809190651.GC3902@scytale.galois.com> <20080809193841.GD3902@scytale.galois.com> Message-ID: On 10/08/2008, at 05:38, Don Stewart wrote: > Instead, if we just use ubiquitous, common tools -- like git -- for > everything, we minimise the pain for people, and sit firmly in the > mainstream of open source. While I agree with this in general, I'm not sure it really applies to vcs (especially darcs) all that much. I don't think anyone who has ever worked with a vcs will need more than a day to learn how to use darcs (or any other sane vcs, for that matter). Really, the problem with darcs is not that it is not mainstream; rather, it's just that it simply doesn't work sometimes. Roman From dagit at codersbase.com Sun Aug 10 02:12:30 2008 From: dagit at codersbase.com (Jason Dagit) Date: Sun Aug 10 02:11:59 2008 Subject: Version control systems In-Reply-To: <4255399A-EE1F-4E2A-B54E-188D456748FF@cse.unsw.edu.au> References: <48981C03.10908@gmail.com> <20080806051232.GD17673@scytale.galois.com> <1218016430.7661.189.camel@localhost> <9d4d38820808060331h4758c8a4y2bc6e79d14b8ae3d@mail.gmail.com> <18DB9581-AA5B-433C-9036-34EC2674C2CB@cse.unsw.edu.au> <20080808130329.GA15063@matrix.chaos.earth.li> <5FEA1F32-9C34-4888-A5BE-D0460D55C307@cse.unsw.edu.au> <20080809160801.GB15225@matrix.chaos.earth.li> <960585F5-2454-40FE-8B6A-8E2198904BB6@cse.unsw.edu.au> <4255399A-EE1F-4E2A-B54E-188D456748FF@cse.unsw.edu.au> Message-ID: On Sat, Aug 9, 2008 at 10:44 PM, Roman Leshchinskiy wrote: Maybe investing some time in fixing the most obvious darcs problems would be > a better solution? We're working on that over at Darcs HQ, but there is no guarantee that we'd come close to fixing the problems within the 4-5 week window that Ian mentioned. Supposing that the main problems GHC has with darcs 2 format get solved in the next month, would that give GHC reason enough to keep using darcs? It seems many of you are eager to use git; perhaps even if darcs was working to satisfaction. People will be working on making darcs work better with the GHC repo as a test case either way. And personally, since I'm not a GHC dev, the decision doesn't affect my life. Having said that, I'm still obviously biased. I'd love for darcs to work well enough that this never came up. Let me throw out one more idea: What if, as a GHC contributor, I could pick equally between git and darcs? My understanding is that, while not optimal, you could use tailor[1] to synchronize a darcs repository with a git one. Offer up both repositories and keep them in sync. Let the masses decide? Jason [1] http://progetti.arstecnica.it/tailor -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20080809/ad3974e0/attachment.htm From allbery at ece.cmu.edu Sun Aug 10 02:47:57 2008 From: allbery at ece.cmu.edu (Brandon S. Allbery KF8NH) Date: Sun Aug 10 02:47:30 2008 Subject: Version control systems In-Reply-To: References: <48981C03.10908@gmail.com> <20080806051232.GD17673@scytale.galois.com> <1218016430.7661.189.camel@localhost> <9d4d38820808060331h4758c8a4y2bc6e79d14b8ae3d@mail.gmail.com> <18DB9581-AA5B-433C-9036-34EC2674C2CB@cse.unsw.edu.au> <20080808130329.GA15063@matrix.chaos.earth.li> <5FEA1F32-9C34-4888-A5BE-D0460D55C307@cse.unsw.edu.au> <20080809160801.GB15225@matrix.chaos.earth.li> <960585F5-2454-40FE-8B6A-8E2198904BB6@cse.unsw.edu.au> <4255399A-EE1F-4E2A-B54E-188D456748FF@cse.unsw.edu.au> Message-ID: On 2008 Aug 10, at 2:12, Jason Dagit wrote: > On Sat, Aug 9, 2008 at 10:44 PM, Roman Leshchinskiy > wrote: > > Maybe investing some time in fixing the most obvious darcs problems > would be a better solution? > > We're working on that over at Darcs HQ, but there is no guarantee > that we'd come close to fixing the problems within the 4-5 week > window that Ian mentioned. Supposing that the main problems GHC has > with darcs 2 format get solved in the next month, would that give > GHC reason enough to keep using darcs? It seems many of you are > eager to use git; perhaps even if darcs was working to satisfaction. Some people are. I'm more on the side of "are we creating a bigger problem than we already have?" It's not at all clear to me that switching to git would solve more problems than it would cause --- and if you toss in core libraries possibly needing to stay in darcs, or other projects being abruptly forced to switch to git because the core libs did, it's pretty clearly on the "biting off more than we can chew" side of things. > Let me throw out one more idea: > What if, as a GHC contributor, I could pick equally between git and > darcs? My understanding is that, while not optimal, you could use > tailor[1] to synchronize a darcs repository with a git one. Offer > up both repositories and keep them in sync. Let the masses decide? There has been some discussion along those lines, but doing that bidirectionally is logitically difficult. -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20080810/e0707a3b/attachment.htm From chak at cse.unsw.edu.au Sun Aug 10 04:40:42 2008 From: chak at cse.unsw.edu.au (Manuel M T Chakravarty) Date: Sun Aug 10 04:40:13 2008 Subject: Version control systems In-Reply-To: <36A0EEA6-5E34-4A1A-A008-7F847D84A1E2@cs.york.ac.uk> References: <48981C03.10908@gmail.com> <20080806051232.GD17673@scytale.galois.com> <1218016430.7661.189.camel@localhost> <9d4d38820808060331h4758c8a4y2bc6e79d14b8ae3d@mail.gmail.com> <18DB9581-AA5B-433C-9036-34EC2674C2CB@cse.unsw.edu.au> <20080808130329.GA15063@matrix.chaos.earth.li> <5FEA1F32-9C34-4888-A5BE-D0460D55C307@cse.unsw.edu.au> <20080809190651.GC3902@scytale.galois.com> <36A0EEA6-5E34-4A1A-A008-7F847D84A1E2@cs.york.ac.uk> Message-ID: <692C2D8A-5DF0-4DE8-BE3A-3DF30C874FA8@cse.unsw.edu.au> Malcolm Wallace: >>>>> I seriously hope the plan is to move all *core* libraries >>>>> (including >>>>> GHC's cabal repo) etc over to git, too. > >> * one build system >> * one vcs >> This is a chance to make a big step towards accessibility, let's >> make that step. > > Ultimately, I don't think git would make ghc any more accessible to > new contributors. Darcs is not especially offputting to any > beginner who already knows something about VCS in general. > > What the move to git is about, is making life easier for the > *existing* HQ and core contributors. Evaluate it on that basis, and > not in terms of unknown (and unknowable) benefits to current non- > contributors. Indeed, you should also consider how many > contributors you might lose in a move. I am not advocating to move. I am just saying, if ghc moves, every component needs to move on which the HEAD build depends and that is needed in its current development form (eg, *not* alex, happy, cabal). > I do hear some significant current contributors having doubts. I can > certainly appreciate that having to run 2 VCS in parallel might be > confusing and simply make matters worse than at present. It is confusing and it is going to make matters worse as two failure points are worse than one. And two extra tools to learn worse than one. > The libraries question is a difficult one. We have made a lot of > effort over the last 5 years to build infrastructure and code that > is shared and portable across multiple implementations of the > language. Is this the time to fork those supposedly "common" core > libraries into ghc versions vs the rest? It would be a pity to fork, but to be honest, I'd rather fork the libs than have to use two vcs for GHC. The only other alternative is to decouple more library releases from ghc releases. Manuel From chak at cse.unsw.edu.au Sun Aug 10 05:06:58 2008 From: chak at cse.unsw.edu.au (Manuel M T Chakravarty) Date: Sun Aug 10 05:06:41 2008 Subject: Version control systems In-Reply-To: References: <48981C03.10908@gmail.com> <20080806051232.GD17673@scytale.galois.com> <1218016430.7661.189.camel@localhost> <9d4d38820808060331h4758c8a4y2bc6e79d14b8ae3d@mail.gmail.com> <18DB9581-AA5B-433C-9036-34EC2674C2CB@cse.unsw.edu.au> <20080808130329.GA15063@matrix.chaos.earth.li> <5FEA1F32-9C34-4888-A5BE-D0460D55C307@cse.unsw.edu.au> <20080809160801.GB15225@matrix.chaos.earth.li> <960585F5-2454-40FE-8B6A-8E2198904BB6@cse.unsw.edu.au> <4255399A-EE1F-4E2A-B54E-188D456748FF@cse.unsw.edu.au> Message-ID: <7E3745B6-263C-43EA-8DE2-7DC924AAA15E@cse.unsw.edu.au> Jason Dagit: > On Sat, Aug 9, 2008 at 10:44 PM, Roman Leshchinskiy > wrote: > > Maybe investing some time in fixing the most obvious darcs problems > would be a better solution? > > We're working on that over at Darcs HQ, but there is no guarantee > that we'd come close to fixing the problems within the 4-5 week > window that Ian mentioned. Supposing that the main problems GHC has > with darcs 2 format get solved in the next month, would that give > GHC reason enough to keep using darcs? It seems many of you are > eager to use git; perhaps even if darcs was working to satisfaction. > > People will be working on making darcs work better with the GHC repo > as a test case either way. And personally, since I'm not a GHC dev, > the decision doesn't affect my life. Having said that, I'm still > obviously biased. I'd love for darcs to work well enough that this > never came up. Same here, and fwiw I won't change any of my many other darcs repos any time soon. However, as I have said before, if ghc is to switch, it must be a clean switch, and no messy use of two vcs at the same time for ghc and boot libs. > Let me throw out one more idea: > What if, as a GHC contributor, I could pick equally between git and > darcs? My understanding is that, while not optimal, you could use > tailor[1] to synchronize a darcs repository with a git one. Offer > up both repositories and keep them in sync. Let the masses decide? I don't think that this technical feasible. I used tailor once to convert a CVS repo to darcs, and while that was better than throwing away the history, it was pretty messy and nothing that you would want to do on a regular basis. Besides, even if the actual conversion would work smoothly (which I strongly doubt), you'd immediately be faced with problems of atomicity and associated race conditions of commits to the two repos. Manuel From igloo at earth.li Sun Aug 10 07:32:00 2008 From: igloo at earth.li (Ian Lynagh) Date: Sun Aug 10 07:31:28 2008 Subject: Version control systems In-Reply-To: <20080809225624.BDD6613833F@drdoom.eecs.harvard.edu> References: <20080806051232.GD17673@scytale.galois.com> <1218016430.7661.189.camel@localhost> <9d4d38820808060331h4758c8a4y2bc6e79d14b8ae3d@mail.gmail.com> <18DB9581-AA5B-433C-9036-34EC2674C2CB@cse.unsw.edu.au> <20080808130329.GA15063@matrix.chaos.earth.li> <5FEA1F32-9C34-4888-A5BE-D0460D55C307@cse.unsw.edu.au> <20080809190651.GC3902@scytale.galois.com> <36A0EEA6-5E34-4A1A-A008-7F847D84A1E2@cs.york.ac.uk> <20080809225624.BDD6613833F@drdoom.eecs.harvard.edu> Message-ID: <20080810113200.GA16357@matrix.chaos.earth.li> On Sat, Aug 09, 2008 at 06:56:23PM -0400, Norman Ramsey wrote: > > * I violently agree with whomever (Don? Malcolm?) said that the > Haskell community will prosper to the degree that we have *one* > build system and *one* version-control system. And when the build > system or version-control system is standard, we gain eyeballs and > developers. I haven't found a standard build system that I am > willing to use, but I think git is good enough to be used. > > * Our long-term goal should be to get the *entire* Haskell > development community to agree on a version-control system---one > that is not darcs. We should expect this process to take several > years, and we should expect it to cost money. Would Microsoft or > Galois or York or other large players be willing to donate part of > an expert's time to migrate to the new version-control system? It is, of course, up to people with money what they spend it on, but personally I would much prefer to see money spent on making darcs better, for reasons I won't repeat again. If it makes a difference, I would expect a research paper on how conflictors work would be easy to produce as a side-effect, as we would need to get a good description of how it works, and proofs that it does, anyway. Also, I expect we could get a BSDed darcs as a result. Thanks Ian From igloo at earth.li Sun Aug 10 07:59:07 2008 From: igloo at earth.li (Ian Lynagh) Date: Sun Aug 10 07:58:40 2008 Subject: Version control systems In-Reply-To: <0D35A7C8-71C6-431D-A5FB-78704B628147@cse.unsw.edu.au> References: <48981C03.10908@gmail.com> <20080806051232.GD17673@scytale.galois.com> <1218016430.7661.189.camel@localhost> <9d4d38820808060331h4758c8a4y2bc6e79d14b8ae3d@mail.gmail.com> <18DB9581-AA5B-433C-9036-34EC2674C2CB@cse.unsw.edu.au> <20080808130329.GA15063@matrix.chaos.earth.li> <5FEA1F32-9C34-4888-A5BE-D0460D55C307@cse.unsw.edu.au> <1218275516.7661.236.camel@localhost> <0D35A7C8-71C6-431D-A5FB-78704B628147@cse.unsw.edu.au> Message-ID: <20080810115907.GB16357@matrix.chaos.earth.li> On Sun, Aug 10, 2008 at 02:16:25PM +1000, Manuel M T Chakravarty wrote: > Duncan Coutts: > > > >I don't especially relish having to learn another vcs tool or raising > >the bar for contributions to Cabal either (we have lots of people who > >make small one-off contributions). > > I don't think it matters what vcs Cabal uses. GHC does already for a > while use a separate repo for its version of Cabal, and the GHC Cabal > repo needs to be explicitly updated to ensure that changes to Cabal do > not randomly break GHC. To be honest, if I had to say anything, I > would say that GHC has to uses fixed, stable versions of Cabal (like > it does of gmp). So, it really doesn't matter what vcs Cabal uses. Unless we do get to a point where we are literally using tarballs[1] of Cabal, I don't think using a mixture of VCSs for Cabal is a good idea. Having to convert patches from one VCS format to the other sounds like a recipe for a lot of pain and suffering. [1] which I think is a bad idea anyway, as it makes it a lot more hassle to fix Cabal bugs that GHC+bootlibs expose. Thanks Ian From igloo at earth.li Sun Aug 10 08:05:34 2008 From: igloo at earth.li (Ian Lynagh) Date: Sun Aug 10 08:05:01 2008 Subject: Version control systems In-Reply-To: <36A0EEA6-5E34-4A1A-A008-7F847D84A1E2@cs.york.ac.uk> References: <48981C03.10908@gmail.com> <20080806051232.GD17673@scytale.galois.com> <1218016430.7661.189.camel@localhost> <9d4d38820808060331h4758c8a4y2bc6e79d14b8ae3d@mail.gmail.com> <18DB9581-AA5B-433C-9036-34EC2674C2CB@cse.unsw.edu.au> <20080808130329.GA15063@matrix.chaos.earth.li> <5FEA1F32-9C34-4888-A5BE-D0460D55C307@cse.unsw.edu.au> <20080809190651.GC3902@scytale.galois.com> <36A0EEA6-5E34-4A1A-A008-7F847D84A1E2@cs.york.ac.uk> Message-ID: <20080810120534.GC16357@matrix.chaos.earth.li> On Sat, Aug 09, 2008 at 09:30:52PM +0100, Malcolm Wallace wrote: > > The libraries question is a difficult one. We have made a lot of > effort over the last 5 years to build infrastructure and code that is > shared and portable across multiple implementations of the language. > Is this the time to fork those supposedly "common" core libraries into > ghc versions vs the rest? I think the non-GHC implementations have been struggling for development time as it is. As you say, we've been trying to increase the amount of shared code, to reduce the burden on them. I think forking the bootlibs would represent a huge step the other way, and, as you said later in your e-mail, may be what finally kills them off. Thanks Ian From nominolo at googlemail.com Sun Aug 10 10:24:49 2008 From: nominolo at googlemail.com (Thomas Schilling) Date: Sun Aug 10 10:24:28 2008 Subject: Version control systems In-Reply-To: <5FEA1F32-9C34-4888-A5BE-D0460D55C307@cse.unsw.edu.au> References: <48981C03.10908@gmail.com> <20080806051232.GD17673@scytale.galois.com> <1218016430.7661.189.camel@localhost> <9d4d38820808060331h4758c8a4y2bc6e79d14b8ae3d@mail.gmail.com> <18DB9581-AA5B-433C-9036-34EC2674C2CB@cse.unsw.edu.au> <20080808130329.GA15063@matrix.chaos.earth.li> <5FEA1F32-9C34-4888-A5BE-D0460D55C307@cse.unsw.edu.au> Message-ID: <4BF2D191-FAC5-4285-8638-86D0A8366305@googlemail.com> I had my share of problems with Darcs; working on the GHC API I constantly have to avoid conflicts. My temporary workaround is to not update at all. Maybe switching to Darcs 2 format would help here, but there are other issues. I initially converted GHC to Git to be able to more easily checkout older versions (e.g., to find a build bug using git-bisect) but with external core libraries this just doesn't work. Right now, there is simply no practical way to check out an old, building version of GHC! Even if we'd switch to Darcs 2 this problem could not be solved. We would also still need turn to the Git repo to get change histories for specific files or to run commands such as 'git-blame' (unless you don't mind getting a cup of coffee and some biscuits each time you run those commands). I think we can make things easier for existing library contributors by providing a darcs/git cheat sheet or even a command line wrapper. Previous attempts at creating such a wrapper have been abandoned, possibly because some commands cannot easily be modelled in Git. However, if we accept some limitations this is doable. In particular the tricky commands are: darcs pull -- (save) cherry picking requires patch dependency information darcs push -- same as above (darcs pull -a and darcs push -a both can be modelled easily) darcs replace -- not directly supported in Git, but could be modelled -- with a script. If these missing features don't feel like too big a handicap the change should be fairly easy for existing contributors. (And with some time they can start and learn Git's other features.) For our build woes integrating the libraries and the main GHC repo in one Git repo will be very helpful, since we can now just instruct build bots to try and build revision 12345deadbeef and be happy. / Thomas -- My shadow / Change is coming. / Now is my time. / Listen to my muscle memory. / Contemplate what I've been clinging to. / Forty-six and two ahead of me. -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 194 bytes Desc: This is a digitally signed message part Url : http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20080810/8e456ecd/PGP.bin From iavor.diatchki at gmail.com Sun Aug 10 14:01:28 2008 From: iavor.diatchki at gmail.com (Iavor Diatchki) Date: Sun Aug 10 14:00:57 2008 Subject: Version control systems In-Reply-To: <4BF2D191-FAC5-4285-8638-86D0A8366305@googlemail.com> References: <48981C03.10908@gmail.com> <20080806051232.GD17673@scytale.galois.com> <1218016430.7661.189.camel@localhost> <9d4d38820808060331h4758c8a4y2bc6e79d14b8ae3d@mail.gmail.com> <18DB9581-AA5B-433C-9036-34EC2674C2CB@cse.unsw.edu.au> <20080808130329.GA15063@matrix.chaos.earth.li> <5FEA1F32-9C34-4888-A5BE-D0460D55C307@cse.unsw.edu.au> <4BF2D191-FAC5-4285-8638-86D0A8366305@googlemail.com> Message-ID: <5ab17e790808101101o732d2a3bu9776f055b3c9895b@mail.gmail.com> Hello, I think that we should switch the repositories of the core libraries to git too, not just because GHC is switching, but simply because git is a more reliable RCS. It seems that this does not prevent other implementations from using them---the code in the repositories will be still the same! -Iavor From nr at eecs.harvard.edu Sun Aug 10 20:17:50 2008 From: nr at eecs.harvard.edu (Norman Ramsey) Date: Sun Aug 10 20:17:15 2008 Subject: Version control systems In-Reply-To: <20080810113200.GA16357@matrix.chaos.earth.li> (sfid-H-20080810-073312-+70.85-1@multi.osbf.lua) References: <20080806051232.GD17673@scytale.galois.com> <1218016430.7661.189.camel@localhost> <9d4d38820808060331h4758c8a4y2bc6e79d14b8ae3d@mail.gmail.com> <18DB9581-AA5B-433C-9036-34EC2674C2CB@cse.unsw.edu.au> <20080808130329.GA15063@matrix.chaos.earth.li> <5FEA1F32-9C34-4888-A5BE-D0460D55C307@cse.unsw.edu.au> <20080809190651.GC3902@scytale.galois.com> <36A0EEA6-5E34-4A1A-A008-7F847D84A1E2@cs.york.ac.uk> <20080809225624.BDD6613833F@drdoom.eecs.harvard.edu> <20080810113200.GA16357@matrix.chaos.earth.li> (sfid-H-20080810-073312-+70.85-1@multi.osbf.lua) Message-ID: <20080811001751.28DA31383C3@drdoom.eecs.harvard.edu> > On Sat, Aug 09, 2008 at 06:56:23PM -0400, Norman Ramsey wrote: > > > > * Our long-term goal should be to get the *entire* Haskell > > development community to agree on a version-control system---one > > that is not darcs. We should expect this process to take several > > years, and we should expect it to cost money. Would Microsoft or > > Galois or York or other large players be willing to donate part of > > an expert's time to migrate to the new version-control system? > > It is, of course, up to people with money what they spend it on, but > personally I would much prefer to see money spent on making darcs > better, for reasons I won't repeat again. I missed them and wouldn't mind receiving a private note. For the last year I have been hoping to make 'a new darcs-like thing, with a real theory founding it' an important part (one of three) of a grant proposal in distributed computing. So you can see I am in favor of spending money to create a better darcs (which is not quite the same thing as making darcs better; I want to start with a new theory). But I am having second thoughts because I think by the time a proposal reaches a review committee, git may be so firmly entrenched (worse is better) that the work would be considered not worth funding. I realize that I am now firmly off topic, but if people here have opinions, I would be grateful to receive them (perhaps off-list). Norman From allbery at ece.cmu.edu Sun Aug 10 20:19:58 2008 From: allbery at ece.cmu.edu (Brandon S. Allbery KF8NH) Date: Sun Aug 10 20:19:31 2008 Subject: Version control systems In-Reply-To: <20080811001751.28DA31383C3@drdoom.eecs.harvard.edu> References: <20080806051232.GD17673@scytale.galois.com> <1218016430.7661.189.camel@localhost> <9d4d38820808060331h4758c8a4y2bc6e79d14b8ae3d@mail.gmail.com> <18DB9581-AA5B-433C-9036-34EC2674C2CB@cse.unsw.edu.au> <20080808130329.GA15063@matrix.chaos.earth.li> <5FEA1F32-9C34-4888-A5BE-D0460D55C307@cse.unsw.edu.au> <20080809190651.GC3902@scytale.galois.com> <36A0EEA6-5E34-4A1A-A008-7F847D84A1E2@cs.york.ac.uk> <20080809225624.BDD6613833F@drdoom.eecs.harvard.edu> <20080810113200.GA16357@matrix.chaos.earth.li> (sfid-H-20080810-073312-+70.85-1@multi.osbf.lua) <20080811001751.28DA31383C3@drdoom.eecs.harvard.edu> Message-ID: On 2008 Aug 10, at 20:17, Norman Ramsey wrote: >> For the last year I have been hoping to make 'a new darcs-like thing, > with a real theory founding it' an important part (one of three) of a > grant proposal in distributed computing. So you can see I am in favor > of spending money to create a better darcs (which is not quite the > same thing as making darcs better; I want to start with a new theory). Can you elucidate what's wrong with the current one? -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH From chak at cse.unsw.edu.au Sun Aug 10 23:35:04 2008 From: chak at cse.unsw.edu.au (Manuel M T Chakravarty) Date: Sun Aug 10 23:34:41 2008 Subject: Version control systems In-Reply-To: <20080810115907.GB16357@matrix.chaos.earth.li> References: <48981C03.10908@gmail.com> <20080806051232.GD17673@scytale.galois.com> <1218016430.7661.189.camel@localhost> <9d4d38820808060331h4758c8a4y2bc6e79d14b8ae3d@mail.gmail.com> <18DB9581-AA5B-433C-9036-34EC2674C2CB@cse.unsw.edu.au> <20080808130329.GA15063@matrix.chaos.earth.li> <5FEA1F32-9C34-4888-A5BE-D0460D55C307@cse.unsw.edu.au> <1218275516.7661.236.camel@localhost> <0D35A7C8-71C6-431D-A5FB-78704B628147@cse.unsw.edu.au> <20080810115907.GB16357@matrix.chaos.earth.li> Message-ID: <1C0EF74C-BC7A-4370-B8DD-049B3336CE15@cse.unsw.edu.au> Ian Lynagh: > On Sun, Aug 10, 2008 at 02:16:25PM +1000, Manuel M T Chakravarty > wrote: >> Duncan Coutts: >>> >>> I don't especially relish having to learn another vcs tool or >>> raising >>> the bar for contributions to Cabal either (we have lots of people >>> who >>> make small one-off contributions). >> >> I don't think it matters what vcs Cabal uses. GHC does already for a >> while use a separate repo for its version of Cabal, and the GHC Cabal >> repo needs to be explicitly updated to ensure that changes to Cabal >> do >> not randomly break GHC. To be honest, if I had to say anything, I >> would say that GHC has to uses fixed, stable versions of Cabal (like >> it does of gmp). So, it really doesn't matter what vcs Cabal uses. > > Unless we do get to a point where we are literally using tarballs[1] > of > Cabal, I don't think using a mixture of VCSs for Cabal is a good idea. > Having to convert patches from one VCS format to the other sounds > like a > recipe for a lot of pain and suffering. > > [1] which I think is a bad idea anyway, as it makes it a lot more > hassle > to fix Cabal bugs that GHC+bootlibs expose. The hassle that having two different repo types for Cabal head and Cabal GHC is part of the price of switching from darcs to git for ghc. Incidentally, that you are concerned about Cabal devel in the GHC tree is a consequence out of using GHC as a guinea pig for Cabal development, which by itself is IMHO a Very Bad Idea. Cabal is supposed to be a tool like Happy or Alex. If Cabal *were* mature enough to be used in GHC's build system in the way it is now, GHC would just use the latest stable release of Cabal and we wouldn't have a problem. So, let's please not use one bad idea (using an immature and constantly changing build tool whose use in GHC's build tree barely anybody understands) to justify another bad idea (using two vcs for one project). Manuel From chak at cse.unsw.edu.au Sun Aug 10 23:38:37 2008 From: chak at cse.unsw.edu.au (Manuel M T Chakravarty) Date: Sun Aug 10 23:38:07 2008 Subject: Version control systems In-Reply-To: <4BF2D191-FAC5-4285-8638-86D0A8366305@googlemail.com> References: <48981C03.10908@gmail.com> <20080806051232.GD17673@scytale.galois.com> <1218016430.7661.189.camel@localhost> <9d4d38820808060331h4758c8a4y2bc6e79d14b8ae3d@mail.gmail.com> <18DB9581-AA5B-433C-9036-34EC2674C2CB@cse.unsw.edu.au> <20080808130329.GA15063@matrix.chaos.earth.li> <5FEA1F32-9C34-4888-A5BE-D0460D55C307@cse.unsw.edu.au> <4BF2D191-FAC5-4285-8638-86D0A8366305@googlemail.com> Message-ID: <4E23A401-E5D4-4589-8334-D8B21BDDCA44@cse.unsw.edu.au> Thomas Schilling: > I had my share of problems with Darcs; working on the GHC API I > constantly have to avoid conflicts. My temporary workaround is to > not update at all. Maybe switching to Darcs 2 format would help > here, but there are other issues. > > I initially converted GHC to Git to be able to more easily checkout > older versions (e.g., to find a build bug using git-bisect) but with > external core libraries this just doesn't work. Right now, there is > simply no practical way to check out an old, building version of GHC! Correct me if I am wrong, but this sounds as if you support my point that switching the GHC repo to git without doing the same for the core libs (in an integrated way) would not address the problems you experienced with darcs. Manuel From ganesh.sittampalam at credit-suisse.com Mon Aug 11 03:05:08 2008 From: ganesh.sittampalam at credit-suisse.com (Sittampalam, Ganesh) Date: Mon Aug 11 03:05:28 2008 Subject: Version control systems In-Reply-To: References: <20080806051232.GD17673@scytale.galois.com> <1218016430.7661.189.camel@localhost> <9d4d38820808060331h4758c8a4y2bc6e79d14b8ae3d@mail.gmail.com> <18DB9581-AA5B-433C-9036-34EC2674C2CB@cse.unsw.edu.au> <20080808130329.GA15063@matrix.chaos.earth.li> <5FEA1F32-9C34-4888-A5BE-D0460D55C307@cse.unsw.edu.au> <20080809190651.GC3902@scytale.galois.com> <36A0EEA6-5E34-4A1A-A008-7F847D84A1E2@cs.york.ac.uk> <20080809225624.BDD6613833F@drdoom.eecs.harvard.edu> <20080810113200.GA16357@matrix.chaos.earth.li> ( sfid-H-20080810-073312-+70.85-1@multi.osbf.lua) <20080811001751.28DA31383C3@drdoom.eecs.harvard.edu> Message-ID: <78A3C5650E28124399107F21A1FA419401D3B7B2@ELON17P32002A.csfb.cs-group.com> Brandon S Allbery wrote: > On 2008 Aug 10, at 20:17, Norman Ramsey wrote: > > For the last year I have been hoping to make 'a new darcs-like thing, > > with a real theory founding it' an important part (one of three) of a > > grant proposal in distributed computing. So you can see I am in favor > > of spending money to create a better darcs (which is not quite the > > same thing as making darcs better; I want to start with a new theory). > Can you elucidate what's wrong with the current one? Noone knows how to formalise it, and (AFAIK) only David understands the new conflicts handling, and hasn't managed to completely communicate that understanding to anyone else. Ganesh ============================================================================== Please access the attached hyperlink for an important electronic communications disclaimer: http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html ============================================================================== From nominolo at googlemail.com Mon Aug 11 06:21:50 2008 From: nominolo at googlemail.com (Thomas Schilling) Date: Mon Aug 11 06:21:26 2008 Subject: Version control systems In-Reply-To: <4E23A401-E5D4-4589-8334-D8B21BDDCA44@cse.unsw.edu.au> References: <48981C03.10908@gmail.com> <20080806051232.GD17673@scytale.galois.com> <1218016430.7661.189.camel@localhost> <9d4d38820808060331h4758c8a4y2bc6e79d14b8ae3d@mail.gmail.com> <18DB9581-AA5B-433C-9036-34EC2674C2CB@cse.unsw.edu.au> <20080808130329.GA15063@matrix.chaos.earth.li> <5FEA1F32-9C34-4888-A5BE-D0460D55C307@cse.unsw.edu.au> <4BF2D191-FAC5-4285-8638-86D0A8366305@googlemail.com> <4E23A401-E5D4-4589-8334-D8B21BDDCA44@cse.unsw.edu.au> Message-ID: <55163A6F-9F46-450F-888D-BD52479B296E@googlemail.com> On 11 Aug 2008, at 05:38, Manuel M T Chakravarty wrote: > Correct me if I am wrong, but this sounds as if you support my > point that switching the GHC repo to git without doing the same for > the core libs (in an integrated way) would not address the problems > you experienced with darcs. Partly. It does address some issues (fear of conflict, speed, case- sensitivity bugs, easier branches). I personally wouldn't mind having both Darcs and Git repositories, although I can understand why having a mixture of both is bad. I was just mentioning some other advantages of also having the libraries in Git. However, I think that it would be really disappointing if we would not move to Git for the main GHC repository. Simon M reported that a merge took him over a whole day, Norman reported two weeks of lost work, Don reported corrupted repos, Simon PJ reported that in order to avoid conflicts he constantly unrecords and re-records one big patch; all that doesn't give much confidence in Darcs. Additionally, no-one except David seems to actually understand Darcs' theory (and we don't even know if David actually does.) Darcs 2 claims to fix those problems, but I don't know how many are actually using it. Darcs 1 had the exponential runtime bug and it wasn't discovered right away. I don't believe that Darcs 2 can fulfil GHC's needs anytime soon, especially since it is always a bad idea to use a brand-new release of a not much used VCS. (I am also no longer convinced that Darcs' automatic patch dependency calculations are actually a good idea. Just because two patches don't touch the same files, doesn't mean they aren't semantically dependent. Take for example "monadification" patches, which are typically submitted split up for each file. A branch captures those dependencies just fine.) / Thomas -- Push the envelope. Watch it bend. -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 194 bytes Desc: This is a digitally signed message part Url : http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20080811/6c61c522/PGP.bin From ganesh.sittampalam at credit-suisse.com Mon Aug 11 06:38:16 2008 From: ganesh.sittampalam at credit-suisse.com (Sittampalam, Ganesh) Date: Mon Aug 11 06:38:48 2008 Subject: Version control systems In-Reply-To: <55163A6F-9F46-450F-888D-BD52479B296E@googlemail.com> References: <48981C03.10908@gmail.com> <20080806051232.GD17673@scytale.galois.com> <1218016430.7661.189.camel@localhost> <9d4d38820808060331h4758c8a4y2bc6e79d14b8ae3d@mail.gmail.com> <18DB9581-AA5B-433C-9036-34EC2674C2CB@cse.unsw.edu.au> <20080808130329.GA15063@matrix.chaos.earth.li> <5FEA1F32-9C34-4888-A5BE-D0460D55C307@cse.unsw.edu.au> <4BF2D191-FAC5-4285-8638-86D0A8366305@googlemail.com> <4E23A401-E5D4-4589-8334-D8B21BDDCA44@cse.unsw.edu.au> <55163A6F-9F46-450F-888D-BD52479B296E@googlemail.com> Message-ID: <78A3C5650E28124399107F21A1FA419401D3B7B8@ELON17P32002A.csfb.cs-group.com> Thomas Schilling wrote: > (I am also no longer convinced that Darcs' > automatic patch dependency calculations are > actually a good idea. Just because two patches > don't touch the same files, doesn't mean they > aren't semantically dependent. Take for > example "monadification" patches, which are > typically submitted split up for each file. > A branch captures those dependencies just fine.) But the darcs approach to dependency is what underlies cherry-picking, which many people consider the most worthwhile feature of darcs. In fact many people would like it to be possible to override even the dependencies that darcs *does* find to cherry-pick patch A without patch B that A depends on, at the expense of producing a conflict that then has to be fixed up by hand. Ganesh ============================================================================== Please access the attached hyperlink for an important electronic communications disclaimer: http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html ============================================================================== From duncan.coutts at worc.ox.ac.uk Mon Aug 11 07:00:24 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Mon Aug 11 06:59:01 2008 Subject: Version control systems In-Reply-To: <55163A6F-9F46-450F-888D-BD52479B296E@googlemail.com> References: <48981C03.10908@gmail.com> <20080806051232.GD17673@scytale.galois.com> <1218016430.7661.189.camel@localhost> <9d4d38820808060331h4758c8a4y2bc6e79d14b8ae3d@mail.gmail.com> <18DB9581-AA5B-433C-9036-34EC2674C2CB@cse.unsw.edu.au> <20080808130329.GA15063@matrix.chaos.earth.li> <5FEA1F32-9C34-4888-A5BE-D0460D55C307@cse.unsw.edu.au> <4BF2D191-FAC5-4285-8638-86D0A8366305@googlemail.com> <4E23A401-E5D4-4589-8334-D8B21BDDCA44@cse.unsw.edu.au> <55163A6F-9F46-450F-888D-BD52479B296E@googlemail.com> Message-ID: <1218452424.7661.366.camel@localhost> On Mon, 2008-08-11 at 12:21 +0200, Thomas Schilling wrote: > However, I think that it would be really disappointing if we would > not move to Git for the main GHC repository. Simon M reported that a > merge took him over a whole day, Norman reported two weeks of lost > work, Don reported corrupted repos, Simon PJ reported that in order > to avoid conflicts he constantly unrecords and re-records one big > patch; all that doesn't give much confidence in Darcs. We all accept there are problems with darcs v1 and the darcs v1 repo format for larger projects that do lots of development in branches and then merge back. > Additionally, no-one except David seems to actually understand Darcs' > theory (and we don't even know if David actually does.) Darcs 2 > claims to fix those problems, but I don't know how many are actually > using it. It's not clear to me that we've really bothered to find out. The last evaluation in relation to ghc that I'm aware of was prior to the 2.0 release. My impression is that we've all complained about the darcs v1 problems (justly) but spent the most effort investigating things other than darcs v2 which would be the easiest to upgrade to and not have the problems of using two different systems for ghc vs other libs. On a slightly related issue, we're currently evaluating upgrading to darcs 2 for code.h.o. We'll let people know how that goes. It's not directly relevant to ghc since we'd not be switching to darcs v2 format (that's the prerogative of the repo owners, not code.h.o admins). Duncan From nominolo at googlemail.com Mon Aug 11 07:18:17 2008 From: nominolo at googlemail.com (Thomas Schilling) Date: Mon Aug 11 07:17:56 2008 Subject: Version control systems In-Reply-To: <78A3C5650E28124399107F21A1FA419401D3B7B8@ELON17P32002A.csfb.cs-group.com> References: <48981C03.10908@gmail.com> <20080806051232.GD17673@scytale.galois.com> <1218016430.7661.189.camel@localhost> <9d4d38820808060331h4758c8a4y2bc6e79d14b8ae3d@mail.gmail.com> <18DB9581-AA5B-433C-9036-34EC2674C2CB@cse.unsw.edu.au> <20080808130329.GA15063@matrix.chaos.earth.li> <5FEA1F32-9C34-4888-A5BE-D0460D55C307@cse.unsw.edu.au> <4BF2D191-FAC5-4285-8638-86D0A8366305@googlemail.com> <4E23A401-E5D4-4589-8334-D8B21BDDCA44@cse.unsw.edu.au> <55163A6F-9F46-450F-888D-BD52479B296E@googlemail.com> <78A3C5650E28124399107F21A1FA419401D3B7B8@ELON17P32002A.csfb.cs-group.com> Message-ID: On 11 Aug 2008, at 12:38, Sittampalam, Ganesh wrote: > Thomas Schilling wrote: > >> (I am also no longer convinced that Darcs' >> automatic patch dependency calculations are >> actually a good idea. Just because two patches >> don't touch the same files, doesn't mean they >> aren't semantically dependent. Take for >> example "monadification" patches, which are >> typically submitted split up for each file. >> A branch captures those dependencies just fine.) > > But the darcs approach to dependency is what underlies cherry-picking, > which many people consider the most worthwhile feature of darcs. In > fact > many people would like it to be possible to override even the > dependencies that darcs *does* find to cherry-pick patch A without > patch > B that A depends on, at the expense of producing a conflict that then > has to be fixed up by hand. Cherry-picking just a single patch is simple in Git: "git cherry-pick "[1]. What's missing in Git is the automatic detection of dependent patches. Otherwise it would be straightforward to write a Darcs frontend for Git. [1]: http://www.kernel.org/pub/software/scm/git/docs/git-cherry- pick.html / Thomas -- Push the envelope. Watch it bend. -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 194 bytes Desc: This is a digitally signed message part Url : http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20080811/93217baf/PGP.bin From simonpj at microsoft.com Mon Aug 11 08:14:47 2008 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Mon Aug 11 08:14:12 2008 Subject: Confusing flags for RULES in GHC Message-ID: <638ABD0A29C8884A91BC5FB5C349B1C32AE80660FF@EA-EXMSG-C334.europe.corp.microsoft.com> Friends The use of flags to control rewrite rules in GHC is very confusing. Several bug reports arise from this. There is a summary here: http://hackage.haskell.org/trac/ghc/ticket/2497 The final comment is a proposal, which I append below. This email is just to allow others to comment on the proposed change. It's all minor and tiresome, but I don't want to change it and then find it's still awkward. NB: please read the whole ticket if you want to comment on these proposals. And add your comments to the ticket. Simon * Do not add -XRewriteRules. A RULE is in a pragma, and so is silently ignored by other compilers anyway. Other pragmas like SPECIALISE do not have a language extension flag. They will generate errors if they are plain wrong (e.g. variables out of scope). But adding a language flag would be inconsistent. * Inside a RULE, switch on the forall-as-keyword in the lexer, unconditionally. Simon M will do this, and send a patch to Simon PJ for validation. * Merge the -XScopedTypeVariables and -XPatternSignatures flags. Distinguishing them isn't senseless, but it's jolly confusing. * Inside a RULE, switch on -XScopedTypeVariables unconditionally. * Change -frewrite-rules to -fuse-rewrite-rules; deprecate the former. From nominolo at googlemail.com Mon Aug 11 08:29:47 2008 From: nominolo at googlemail.com (Thomas Schilling) Date: Mon Aug 11 08:29:24 2008 Subject: Version control systems In-Reply-To: <1218452424.7661.366.camel@localhost> References: <48981C03.10908@gmail.com> <20080806051232.GD17673@scytale.galois.com> <1218016430.7661.189.camel@localhost> <9d4d38820808060331h4758c8a4y2bc6e79d14b8ae3d@mail.gmail.com> <18DB9581-AA5B-433C-9036-34EC2674C2CB@cse.unsw.edu.au> <20080808130329.GA15063@matrix.chaos.earth.li> <5FEA1F32-9C34-4888-A5BE-D0460D55C307@cse.unsw.edu.au> <4BF2D191-FAC5-4285-8638-86D0A8366305@googlemail.com> <4E23A401-E5D4-4589-8334-D8B21BDDCA44@cse.unsw.edu.au> <55163A6F-9F46-450F-888D-BD52479B296E@googlemail.com> <1218452424.7661.366.camel@localhost> Message-ID: On 11 Aug 2008, at 13:00, Duncan Coutts wrote: > It's not clear to me that we've really bothered to find out. The last > evaluation in relation to ghc that I'm aware of was prior to the 2.0 > release. My impression is that we've all complained about the darcs v1 > problems (justly) but spent the most effort investigating things other > than darcs v2 which would be the easiest to upgrade to and not have > the > problems of using two different systems for ghc vs other libs. I converted the ghc repo to darcs2 (locally): Getting file local history: * darcs changes --last 20 compiler/main/HscTypes.lhs very quick but prints only two patches * darcs changes compiler/hsSyn/HsTypes.lhs 1m22s (16s for the second time) Git <1s * darcs get ghc2 ghc-test (creating a *local* branch) real 13m25.365s user 0m14.677s sys 0m29.541s (at least it seems it actually worked, though) git clone ghc g2 (the slow method of creating a local branch) real 0m6.742s user 0m0.335s sys 0m0.652s * I haven't tested a remote pull yet. At 80 Kb/s, it should take about 15min to clone via Git (70 MB). A test of darcs would be interesting. Finally, of course, we have to hope that Darcs2's conflict problems are actually solved. I also had some weird automerges with Darcs when pulling from Max' repository, so Darcs isn't flawless there, either (this seemed to be one of the main critiques of Git). / Thomas -- Awareness is the enemy of sanity, for once you hear the screaming, it never stops. -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 194 bytes Desc: This is a digitally signed message part Url : http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20080811/396cb2ea/PGP.bin From ganesh.sittampalam at credit-suisse.com Mon Aug 11 08:34:22 2008 From: ganesh.sittampalam at credit-suisse.com (Sittampalam, Ganesh) Date: Mon Aug 11 08:37:22 2008 Subject: Version control systems In-Reply-To: References: <48981C03.10908@gmail.com> <20080806051232.GD17673@scytale.galois.com> <1218016430.7661.189.camel@localhost> <9d4d38820808060331h4758c8a4y2bc6e79d14b8ae3d@mail.gmail.com> <18DB9581-AA5B-433C-9036-34EC2674C2CB@cse.unsw.edu.au> <20080808130329.GA15063@matrix.chaos.earth.li> <5FEA1F32-9C34-4888-A5BE-D0460D55C307@cse.unsw.edu.au> <4BF2D191-FAC5-4285-8638-86D0A8366305@googlemail.com> <4E23A401-E5D4-4589-8334-D8B21BDDCA44@cse.unsw.edu.au> <55163A6F-9F46-450F-888D-BD52479B296E@googlemail.com> <78A3C5650E28124399107F21A1FA419401D3B7B8@ELON17P32002A.csfb.cs-group.com> Message-ID: <78A3C5650E28124399107F21A1FA419401D3B7BC@ELON17P32002A.csfb.cs-group.com> -----Original Message----- From: Thomas Schilling [mailto:nominolo@googlemail.com] Sent: 11 August 2008 12:18 To: Sittampalam, Ganesh Cc: Manuel Chakravarty; Don Stewart; Ian Lynagh; Simon Peyton-Jones; GHC Users Mailing List Subject: Re: Version control systems Thomas Schilling wrote: > On 11 Aug 2008, at 12:38, Sittampalam, Ganesh wrote: >> Thomas Schilling wrote: >> >>> (I am also no longer convinced that Darcs' >>> automatic patch dependency calculations are actually a good idea. >>> Just because two patches don't touch the same files, doesn't mean >>> they aren't semantically dependent. Take for example >>> "monadification" patches, which are typically submitted split up for >>> each file. >>> A branch captures those dependencies just fine.) >> >> But the darcs approach to dependency is what underlies cherry-picking, >> which many people consider the most worthwhile feature of darcs. In >> fact many people would like it to be possible to override even the >> dependencies that darcs *does* find to cherry-pick patch A without >> patch B that A depends on, at the expense of producing a conflict that >> then has to be fixed up by hand. > Cherry-picking just a single patch is simple in Git: "git cherry-pick "[1]. I wasn't saying that Git doesn't support cherry-picking, just that you would expect dependencies to restrict what you can and can't cherry-pick; if you specify dependencies just in a linear fashion along each branch (i.e. each patch depends on all those before it on that branch) as I thought you were suggesting, then you enormously restrict what cherry-picks are possible. Ganesh ============================================================================== Please access the attached hyperlink for an important electronic communications disclaimer: http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html ============================================================================== From marlowsd at gmail.com Mon Aug 11 08:57:01 2008 From: marlowsd at gmail.com (Simon Marlow) Date: Mon Aug 11 08:56:30 2008 Subject: Version control systems In-Reply-To: <1218452424.7661.366.camel@localhost> References: <48981C03.10908@gmail.com> <20080806051232.GD17673@scytale.galois.com> <1218016430.7661.189.camel@localhost> <9d4d38820808060331h4758c8a4y2bc6e79d14b8ae3d@mail.gmail.com> <18DB9581-AA5B-433C-9036-34EC2674C2CB@cse.unsw.edu.au> <20080808130329.GA15063@matrix.chaos.earth.li> <5FEA1F32-9C34-4888-A5BE-D0460D55C307@cse.unsw.edu.au> <4BF2D191-FAC5-4285-8638-86D0A8366305@googlemail.com> <4E23A401-E5D4-4589-8334-D8B21BDDCA44@cse.unsw.edu.au> <55163A6F-9F46-450F-888D-BD52479B296E@googlemail.com> <1218452424.7661.366.camel@localhost> Message-ID: <48A0371D.1040407@gmail.com> Duncan Coutts wrote: > It's not clear to me that we've really bothered to find out. The last > evaluation in relation to ghc that I'm aware of was prior to the 2.0 > release. My impression is that we've all complained about the darcs v1 > problems (justly) but spent the most effort investigating things other > than darcs v2 which would be the easiest to upgrade to and not have the > problems of using two different systems for ghc vs other libs. I promised to put together our reasoning on why we don't think moving to darcs2 would help enough. Here's a summary: - using the darcs2 format may well fix the exponential-time merge problem, but the UI for merging conflicts is still lacking in many important ways in darcs: * The conflict markers are not annotated with the patch that they came from, and the ordering of patches in conflict markers is non-deterministic (when I asked about this problem, I was told it was hard to fix). * The 'darcs changes' output only shows one of the patches that is conflicting, you have to guess at the other one(s). Also, it doesn't show which patches are conflict resolutions. - Performance. darcs2 regressed in performance for many operations we commonly use. I've submitted some measurements for some things, but it's pretty easy to find your own test cases: things like "darcs add", "darcs whatsnew", "darcs unrecord" are all slower than darcs 1. When simple operations take multiple seconds to complete, it really slows down your workflow. - I still can't use 'darcs annotate' because it's too slow. Also, we can't browse the GHC repository on the web because the web interface wants to do 'darcs changes ', and that takes minutes. It's possible with caching, but you still have to regenerate the cache after a change. - why can I do a complete git clone of a remote GHC repo in a few minutes, but it takes hours to do a complete 'darcs get'? - Bugs. Many bugs have been fixed in darcs2, which is great, but we did already encounter one (hard to reproduce) bug on Windows, when trying to get an up-to-date repo. Perhaps bugs will be less of an issue in the future, but we have had painful experiences particularly on Windows and I know the darcs developers are still not actively testing on Windows. FWIW, I'd also like to stay with darcs because it has the right model, but unfortunately the current implementation is not useable for us, and it's holding us back. I'll say something about core libs in a separate mail. Cheers, Simon From marlowsd at gmail.com Mon Aug 11 11:17:59 2008 From: marlowsd at gmail.com (Simon Marlow) Date: Mon Aug 11 11:17:29 2008 Subject: Version control systems In-Reply-To: <5FEA1F32-9C34-4888-A5BE-D0460D55C307@cse.unsw.edu.au> References: <48981C03.10908@gmail.com> <20080806051232.GD17673@scytale.galois.com> <1218016430.7661.189.camel@localhost> <9d4d38820808060331h4758c8a4y2bc6e79d14b8ae3d@mail.gmail.com> <18DB9581-AA5B-433C-9036-34EC2674C2CB@cse.unsw.edu.au> <20080808130329.GA15063@matrix.chaos.earth.li> <5FEA1F32-9C34-4888-A5BE-D0460D55C307@cse.unsw.edu.au> Message-ID: <48A05827.5020200@gmail.com> Manuel M T Chakravarty wrote: > I think all *core* libraries must switch. Seriously, requiring GHC > developer to use a mix of two vcs during development is a Very Bad > Idea. Don was excited about getting more people to look at the source > when it is in git (see the comments he posted from reddit). By > requiring two vcs you will get *less* people to look at the source. > > This is not only to get the sources to hack them, but you effectively > require developers to learn the commands for two vcs (when they are > already reluctant to learn one). For example, often enough somebody who > changes something in GHC will modify the base package, too. Then, to > commit the overall work, you need to commit using both vcs. If you need > to branch for your work, you need to create branches in two vcs (no idea > whether the semantics of a branch in git and darcs is anywhere > similar). When you merge your branch, you need to merge in both vcs. > You can't seriously propose such a set up! I completely agree this is a problem. The main obstacle with just switching the core libraries is that they are shared by other implementations and other maintainers. So I see no alternative but to create forks of those repositories for use by GHC, unless/until the other projects/maintainers want to migrate to git. Some of the repositories are not shared - for example ghc-prim, integer-gmp, template-haskell, and these don't need to be forked. One way we could create the forks would be to create a git repo for each package with two branches: the master branch that GHC builds, and a separate branch that tracks the main darcs repository, and is synced automatically whenever patches are pushed to the main darcs repo. We'd have to explicitly merge the tracking branch into the master branch from time to time. When we want to make changes locally, we can just commit them to the GHC branch and push the changes upstream in a batch later (and then we'd end up having to merge them back in to the GHC branch... but hopefully git's merge is clever enough to avoid manual intervention here). This is complicated and ugly of course; better suggestions welcome. > I *strongly* object to moving to git before this isn't sorted out. As > Roman said before, GHC is heading into a dangerous direction. It gets > progressively harder to contribute to the project at the moment. First, > changing the build system to Cabal. Now, proposing to use two vcs. > Somebody who is new to the project not only has to learn the internals > of GHC, but they also have to learn two new vcs, and if they need to > change the build system, they need to learn a new build tool. Raising > the bar for developers to contribute to a project has been proven to be > a very bad idea many times. Let's not take GHC down that path. I'm not completely convinced we need to have this all worked out before GHC switches, although it would be nice of course. We currently have infastructure in place for the build to work with a mixture of darcs and git repositories, and existing developers already have to learn git anyway. They just need to remember to use darcs for libraries and git for the main GHC repo, and this is only a temporary situation. As for Cabal - we had a thread on cvs-ghc last week, and as I said there we'd love to hear suggestions for how to improve things, including wild and crazy ideas for throwing it all away and starting again. However, as I explained, there are good reasons for the way things are done now, the main one being that the build system for packages is not written twice. Cheers, Simon From ross at soi.city.ac.uk Mon Aug 11 13:27:35 2008 From: ross at soi.city.ac.uk (Ross Paterson) Date: Mon Aug 11 13:27:01 2008 Subject: Version control systems In-Reply-To: <48A05827.5020200@gmail.com> References: <48981C03.10908@gmail.com> <20080806051232.GD17673@scytale.galois.com> <1218016430.7661.189.camel@localhost> <9d4d38820808060331h4758c8a4y2bc6e79d14b8ae3d@mail.gmail.com> <18DB9581-AA5B-433C-9036-34EC2674C2CB@cse.unsw.edu.au> <20080808130329.GA15063@matrix.chaos.earth.li> <5FEA1F32-9C34-4888-A5BE-D0460D55C307@cse.unsw.edu.au> <48A05827.5020200@gmail.com> Message-ID: <20080811172735.GA13912@soi.city.ac.uk> On Mon, Aug 11, 2008 at 04:17:59PM +0100, Simon Marlow wrote: > The main obstacle with just switching the core libraries is that they > are shared by other implementations and other maintainers. So I see no > alternative but to create forks of those repositories for use by GHC, > unless/until the other projects/maintainers want to migrate to git. Forking is much worse than using multiple vcs's, and if we don't fork, anyone working on those libraries will have to use git at least to get GHC HEAD to check that they're not breaking it. And clearly GHC developers outnumber developers of other implementations. (I don't think a move to git will lead to more GHC developers, but I buy the interns argument.) My concern is that there are rather more developers of libraries and assorted other packages, and this will place an arbitrary divide across those. Unless everyone moves to git, of course. From dagit at codersbase.com Mon Aug 11 14:22:25 2008 From: dagit at codersbase.com (Jason Dagit) Date: Mon Aug 11 14:21:47 2008 Subject: Version control systems In-Reply-To: <55163A6F-9F46-450F-888D-BD52479B296E@googlemail.com> References: <48981C03.10908@gmail.com> <20080806051232.GD17673@scytale.galois.com> <1218016430.7661.189.camel@localhost> <9d4d38820808060331h4758c8a4y2bc6e79d14b8ae3d@mail.gmail.com> <18DB9581-AA5B-433C-9036-34EC2674C2CB@cse.unsw.edu.au> <20080808130329.GA15063@matrix.chaos.earth.li> <5FEA1F32-9C34-4888-A5BE-D0460D55C307@cse.unsw.edu.au> <4BF2D191-FAC5-4285-8638-86D0A8366305@googlemail.com> <4E23A401-E5D4-4589-8334-D8B21BDDCA44@cse.unsw.edu.au> <55163A6F-9F46-450F-888D-BD52479B296E@googlemail.com> Message-ID: 2008/8/11 Thomas Schilling > > (I am also no longer convinced that Darcs' automatic patch dependency > calculations are actually a good idea. Just because two patches don't touch > the same files, doesn't mean they aren't semantically dependent. Take for > example "monadification" patches, which are typically submitted split up for > each file. A branch captures those dependencies just fine.) Darcs has a feature to deal with patches that are unrelated in patch theory but are related from the user's point of view. When you record you can use --ask-deps to specify dependent patches. These dependencies are then artificially enforced in commute (where dependencies are normally detected). Note: I'm not trying to advocate anything here, I just wanted to let you know that others noticed this and added a feature for it long ago. Jason -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20080811/2add15ce/attachment-0001.htm From dons at galois.com Mon Aug 11 17:15:37 2008 From: dons at galois.com (Don Stewart) Date: Mon Aug 11 17:14:58 2008 Subject: Faster checkout times under Git Message-ID: <20080811211537.GG18593@scytale.galois.com> Eric Mertens kindly did some experiments on the various git repos, and servers, and approaches to serving. * We're looking at >45 mins for a full history darcs get of ghc, over http, from darcs.haskell.org. * git clone of full ghc over http, from darcs.haskell.org, completes in the range of 6-7 minutes (roughly 150KiB/s) * git clone over git protocol, using github's bandwidth, completes in 2.1 minutes. (roughly 560KiB/s) So that indicates a significant improvment by switching to the git:// server protocol. Can we get that on darcs.haskell.org? In general git is doing a good job here addressing slow 'darcs get ' times, which are now way way down. This will make life easier for some of us. Mirroring automatically to github could also address some of our redundancy concerns. -- Don From kili at outback.escape.de Mon Aug 11 17:22:29 2008 From: kili at outback.escape.de (Matthias Kilian) Date: Mon Aug 11 17:24:49 2008 Subject: Version control systems In-Reply-To: <48A05827.5020200@gmail.com> References: <48981C03.10908@gmail.com> <20080806051232.GD17673@scytale.galois.com> <1218016430.7661.189.camel@localhost> <9d4d38820808060331h4758c8a4y2bc6e79d14b8ae3d@mail.gmail.com> <18DB9581-AA5B-433C-9036-34EC2674C2CB@cse.unsw.edu.au> <20080808130329.GA15063@matrix.chaos.earth.li> <5FEA1F32-9C34-4888-A5BE-D0460D55C307@cse.unsw.edu.au> <48A05827.5020200@gmail.com> Message-ID: <20080811212229.GA11669@petunia.outback.escape.de> On Mon, Aug 11, 2008 at 04:17:59PM +0100, Simon Marlow wrote: [...] > As for Cabal - we had a thread on cvs-ghc last week, and as I said there > we'd love to hear suggestions for how to improve things, including wild > and crazy ideas for throwing it all away and starting again. However, as > I explained, there are good reasons for the way things are done now, the > main one being that the build system for packages is not written twice. Well, at least the Makefile creation was a step (the first step?) into the wrong direction, IMHO. I'll run a GHC build to get some of those generated Makefiles and followup on cvs-ghc, but for a starter, Cabal shouldn't know anything about implementation-specific internal build systems; instead it should rely only on it's own metadata. Implementation-specific stuff (such as how to run the compiler) should be supplied by the implementation, not by Cabal. I see more and more workarounds for workarounds for an unmaintainable (and unusable) build system, and after the latest discussions about git vs. darcs, maintaining GHC-specific branches of libraries etc., I think I'll just drop maintainership from all GHC-related OpenBSD ports until the GHC build system chaos settles down a little bit. Ciao, Kili From dons at galois.com Mon Aug 11 17:40:31 2008 From: dons at galois.com (Don Stewart) Date: Mon Aug 11 17:40:03 2008 Subject: Version control systems In-Reply-To: <20080811212229.GA11669@petunia.outback.escape.de> References: <48981C03.10908@gmail.com> <20080806051232.GD17673@scytale.galois.com> <1218016430.7661.189.camel@localhost> <9d4d38820808060331h4758c8a4y2bc6e79d14b8ae3d@mail.gmail.com> <18DB9581-AA5B-433C-9036-34EC2674C2CB@cse.unsw.edu.au> <20080808130329.GA15063@matrix.chaos.earth.li> <5FEA1F32-9C34-4888-A5BE-D0460D55C307@cse.unsw.edu.au> <48A05827.5020200@gmail.com> <20080811212229.GA11669@petunia.outback.escape.de> Message-ID: <20080811214031.GH18593@scytale.galois.com> kili: > On Mon, Aug 11, 2008 at 04:17:59PM +0100, Simon Marlow wrote: > [...] > > As for Cabal - we had a thread on cvs-ghc last week, and as I said there > > we'd love to hear suggestions for how to improve things, including wild > > and crazy ideas for throwing it all away and starting again. However, as > > I explained, there are good reasons for the way things are done now, the > > main one being that the build system for packages is not written twice. > > Well, at least the Makefile creation was a step (the first step?) > into the wrong direction, IMHO. I'll run a GHC build to get some > of those generated Makefiles and followup on cvs-ghc, but for a > starter, Cabal shouldn't know anything about implementation-specific > internal build systems; instead it should rely only on it's own > metadata. Implementation-specific stuff (such as how to run the > compiler) should be supplied by the implementation, not by Cabal. > > I see more and more workarounds for workarounds for an unmaintainable > (and unusable) build system, and after the latest discussions about > git vs. darcs, maintaining GHC-specific branches of libraries etc., > I think I'll just drop maintainership from all GHC-related OpenBSD > ports until the GHC build system chaos settles down a little bit. Ian, please read this. The inability to build GHC reliably is a problem. Can someone with a plan please describe what measures are in place to ensure GHC emerges buildable, and the tree regains the status of a tree that *does not break*? -- Don From igloo at earth.li Mon Aug 11 19:00:42 2008 From: igloo at earth.li (Ian Lynagh) Date: Mon Aug 11 19:00:06 2008 Subject: Version control systems In-Reply-To: <48A05827.5020200@gmail.com> References: <48981C03.10908@gmail.com> <20080806051232.GD17673@scytale.galois.com> <1218016430.7661.189.camel@localhost> <9d4d38820808060331h4758c8a4y2bc6e79d14b8ae3d@mail.gmail.com> <18DB9581-AA5B-433C-9036-34EC2674C2CB@cse.unsw.edu.au> <20080808130329.GA15063@matrix.chaos.earth.li> <5FEA1F32-9C34-4888-A5BE-D0460D55C307@cse.unsw.edu.au> <48A05827.5020200@gmail.com> Message-ID: <20080811230042.GA7919@matrix.chaos.earth.li> On Mon, Aug 11, 2008 at 04:17:59PM +0100, Simon Marlow wrote: > > One way we could create the forks would be to create a git repo for each > package with two branches: the master branch that GHC builds, and a > separate branch that tracks the main darcs repository, and is synced > automatically whenever patches are pushed to the main darcs repo. We'd > have to explicitly merge the tracking branch into the master branch from > time to time. When we want to make changes locally, we can just commit > them to the GHC branch and push the changes upstream in a batch later (and > then we'd end up having to merge them back in to the GHC branch... but > hopefully git's merge is clever enough to avoid manual intervention here). > This is complicated and ugly of course; better suggestions welcome. I don't think that this will work well. At some point we'll have to resolve conflicts that accumulate (by rebasing GHC-only patches after conflicting upstream patches come in? This may not be trivial, as the rebaser may not be familiar with the patches), and I suspect that the forks will end up diverging for significant periods of time, as there's little impetus to merge them. Even the current situation with Cabal is a bit of a pain, as it's easy to forget to push patches upstream as well as GHC's repo, and that's just with 2 repos of the same VCS. I actually think the original plan, where only the ghc repo (plus one or two others) is in git is preferable. You may have to use a different VCS for different subprojects, but after that it's downhill all the way. You don't have to worry about patches being converted from one VCS to another, moved to another repo, converted back and merged back into the first repo. I expect people will be using different VCSs for different /projects/, if not subprojects, anyway. Thanks Ian From mahogny at areta.org Mon Aug 11 19:15:26 2008 From: mahogny at areta.org (Johan Henriksson) Date: Mon Aug 11 19:14:53 2008 Subject: Version control systems In-Reply-To: <20080811214031.GH18593@scytale.galois.com> References: <48981C03.10908@gmail.com> <20080806051232.GD17673@scytale.galois.com> <1218016430.7661.189.camel@localhost> <9d4d38820808060331h4758c8a4y2bc6e79d14b8ae3d@mail.gmail.com> <18DB9581-AA5B-433C-9036-34EC2674C2CB@cse.unsw.edu.au> <20080808130329.GA15063@matrix.chaos.earth.li> <5FEA1F32-9C34-4888-A5BE-D0460D55C307@cse.unsw.edu.au> <48A05827.5020200@gmail.com> <20080811212229.GA11669@petunia.outback.escape.de> <20080811214031.GH18593@scytale.galois.com> Message-ID: <48A0C80E.7010205@areta.org> Don Stewart wrote: > kili: > >> On Mon, Aug 11, 2008 at 04:17:59PM +0100, Simon Marlow wrote: >> [...] >> >>> As for Cabal - we had a thread on cvs-ghc last week, and as I said there >>> we'd love to hear suggestions for how to improve things, including wild >>> and crazy ideas for throwing it all away and starting again. However, as >>> I explained, there are good reasons for the way things are done now, the >>> main one being that the build system for packages is not written twice. >>> >> Well, at least the Makefile creation was a step (the first step?) >> into the wrong direction, IMHO. I'll run a GHC build to get some >> of those generated Makefiles and followup on cvs-ghc, but for a >> starter, Cabal shouldn't know anything about implementation-specific >> internal build systems; instead it should rely only on it's own >> metadata. Implementation-specific stuff (such as how to run the >> compiler) should be supplied by the implementation, not by Cabal. if we're going to kick on cabal I might throw in my two cents. I see an increasing problem in that every community comes up with their own package system, instead of reusing existing frameworks. dependencies to other non-haskell libraries has to be addressed for every other coexisting package system (such as apt-get), if it is addressed at all. likewise, other languages depending on haskell will have trouble resolving dependencies. so my point is, if there will be any bigger reworking of cabal, I think one should consider how it could work as a module in a bigger (maybe future) meta-packaging framework, lifting up binaries to for example .deb, .exe-installer, .dmg or whatever is the most native for the platform. I see a point in language specific package systems as they have more insight into the build process, but the current implementations assume a very ideal world in which there are no other dependencies involved. /Johan From chak at cse.unsw.edu.au Mon Aug 11 20:07:37 2008 From: chak at cse.unsw.edu.au (Manuel M T Chakravarty) Date: Mon Aug 11 20:07:19 2008 Subject: Version control systems In-Reply-To: <20080811212229.GA11669@petunia.outback.escape.de> References: <48981C03.10908@gmail.com> <20080806051232.GD17673@scytale.galois.com> <1218016430.7661.189.camel@localhost> <9d4d38820808060331h4758c8a4y2bc6e79d14b8ae3d@mail.gmail.com> <18DB9581-AA5B-433C-9036-34EC2674C2CB@cse.unsw.edu.au> <20080808130329.GA15063@matrix.chaos.earth.li> <5FEA1F32-9C34-4888-A5BE-D0460D55C307@cse.unsw.edu.au> <48A05827.5020200@gmail.com> <20080811212229.GA11669@petunia.outback.escape.de> Message-ID: <74C1203B-9360-4BCB-941E-8E12F7923B22@cse.unsw.edu.au> Matthias Kilian: > On Mon, Aug 11, 2008 at 04:17:59PM +0100, Simon Marlow wrote: > [...] >> As for Cabal - we had a thread on cvs-ghc last week, and as I said >> there >> we'd love to hear suggestions for how to improve things, including >> wild >> and crazy ideas for throwing it all away and starting again. >> However, as >> I explained, there are good reasons for the way things are done >> now, the >> main one being that the build system for packages is not written >> twice. > > Well, at least the Makefile creation was a step (the first step?) > into the wrong direction, IMHO. I'll run a GHC build to get some > of those generated Makefiles and followup on cvs-ghc, but for a > starter, Cabal shouldn't know anything about implementation-specific > internal build systems; instead it should rely only on it's own > metadata. Implementation-specific stuff (such as how to run the > compiler) should be supplied by the implementation, not by Cabal. > > I see more and more workarounds for workarounds for an unmaintainable > (and unusable) build system, and after the latest discussions about > git vs. darcs, maintaining GHC-specific branches of libraries etc., > I think I'll just drop maintainership from all GHC-related OpenBSD > ports until the GHC build system chaos settles down a little bit. Thanks for demonstrating my point... Complicated build infrastructure and lack of portability used to be a big problem for GHC in the past. Over the last years, the situation got much better (to a large extent due to SimonM sanitising the makefile-based build system). Why are we so keen to throw it all away now? Manuel From chak at cse.unsw.edu.au Mon Aug 11 20:20:14 2008 From: chak at cse.unsw.edu.au (Manuel M T Chakravarty) Date: Mon Aug 11 20:19:41 2008 Subject: Version control systems In-Reply-To: <48A05827.5020200@gmail.com> References: <48981C03.10908@gmail.com> <20080806051232.GD17673@scytale.galois.com> <1218016430.7661.189.camel@localhost> <9d4d38820808060331h4758c8a4y2bc6e79d14b8ae3d@mail.gmail.com> <18DB9581-AA5B-433C-9036-34EC2674C2CB@cse.unsw.edu.au> <20080808130329.GA15063@matrix.chaos.earth.li> <5FEA1F32-9C34-4888-A5BE-D0460D55C307@cse.unsw.edu.au> <48A05827.5020200@gmail.com> Message-ID: Simon Marlow: > Manuel M T Chakravarty wrote: > >> I think all *core* libraries must switch. Seriously, requiring GHC >> developer to use a mix of two vcs during development is a Very Bad >> Idea. Don was excited about getting more people to look at the >> source when it is in git (see the comments he posted from reddit). >> By requiring two vcs you will get *less* people to look at the >> source. >> This is not only to get the sources to hack them, but you >> effectively require developers to learn the commands for two vcs >> (when they are already reluctant to learn one). For example, often >> enough somebody who changes something in GHC will modify the base >> package, too. Then, to commit the overall work, you need to commit >> using both vcs. If you need to branch for your work, you need to >> create branches in two vcs (no idea whether the semantics of a >> branch in git and darcs is anywhere similar). When you merge your >> branch, you need to merge in both vcs. You can't seriously propose >> such a set up! > > I completely agree this is a problem. The main obstacle with just > switching the core libraries is that they are shared by other > implementations and other maintainers. So I see no alternative but > to create forks of those repositories for use by GHC, unless/until > the other projects/maintainers want to migrate to git. Some of the > repositories are not shared - for example ghc-prim, integer-gmp, > template-haskell, and these don't need to be forked. > > One way we could create the forks would be to create a git repo for > each package with two branches: the master branch that GHC builds, > and a separate branch that tracks the main darcs repository, and is > synced automatically whenever patches are pushed to the main darcs > repo. We'd have to explicitly merge the tracking branch into the > master branch from time to time. When we want to make changes > locally, we can just commit them to the GHC branch and push the > changes upstream in a batch later (and then we'd end up having to > merge them back in to the GHC branch... but hopefully git's merge is > clever enough to avoid manual intervention here). This is > complicated and ugly of course; better suggestions welcome. Yes, it's a pain. However, it is better than two vcs for one project. >> I *strongly* object to moving to git before this isn't sorted out. >> As Roman said before, GHC is heading into a dangerous direction. >> It gets progressively harder to contribute to the project at the >> moment. First, changing the build system to Cabal. Now, proposing >> to use two vcs. Somebody who is new to the project not only has to >> learn the internals of GHC, but they also have to learn two new >> vcs, and if they need to change the build system, they need to >> learn a new build tool. Raising the bar for developers to >> contribute to a project has been proven to be a very bad idea many >> times. Let's not take GHC down that path. > > I'm not completely convinced we need to have this all worked out > before GHC switches, although it would be nice of course. We > currently have infastructure in place for the build to work with a > mixture of darcs and git repositories, and existing developers > already have to learn git anyway. They just need to remember to use > darcs for libraries and git for the main GHC repo, and this is only > a temporary situation. As far as I am concerned, building GHC is turning into a big mess. We discussed ways to improve it again, BUT I'd rather not see it getting any messier before it gets better. Hence, please let's have a complete plan that we are convinced will work before making any more changes. > As for Cabal - we had a thread on cvs-ghc last week, and as I said > there we'd love to hear suggestions for how to improve things, > including wild and crazy ideas for throwing it all away and starting > again. However, as I explained, there are good reasons for the way > things are done now, the main one being that the build system for > packages is not written twice. Yes, we need cabal for packages because we don't want two build systems. However, this does not justify the use of Cabal outside of libraries/. Nobody explained to me why that was necessary. Why change all the rest of the build system. What is the benefit for the ghc project? To be honest, if you ask me, I'd go back to the old makefile based system and remove Cabal from everywhere except building of the library packages. Manuel PS: Just for some more collateral damage. Did anybody check whether the Mac OS installer support and the -unfortunately, only partially working- support to compile for older OS X versions that I added to the *makefiles* still works with the Cabal-based system? I doubt it. Took me quite a while to get all this going, and I am not very well motivated to spend a lot of time to figure out how it might work with Cabal. IMHO using Cabal for anything but the libraries was a step back for no good reason. From chak at cse.unsw.edu.au Mon Aug 11 20:35:57 2008 From: chak at cse.unsw.edu.au (Manuel M T Chakravarty) Date: Mon Aug 11 20:35:21 2008 Subject: Version control systems In-Reply-To: <20080811172735.GA13912@soi.city.ac.uk> References: <48981C03.10908@gmail.com> <20080806051232.GD17673@scytale.galois.com> <1218016430.7661.189.camel@localhost> <9d4d38820808060331h4758c8a4y2bc6e79d14b8ae3d@mail.gmail.com> <18DB9581-AA5B-433C-9036-34EC2674C2CB@cse.unsw.edu.au> <20080808130329.GA15063@matrix.chaos.earth.li> <5FEA1F32-9C34-4888-A5BE-D0460D55C307@cse.unsw.edu.au> <48A05827.5020200@gmail.com> <20080811172735.GA13912@soi.city.ac.uk> Message-ID: <99278BE4-C737-4349-91F1-78A74D83734E@cse.unsw.edu.au> Ross Paterson: > On Mon, Aug 11, 2008 at 04:17:59PM +0100, Simon Marlow wrote: >> The main obstacle with just switching the core libraries is that they >> are shared by other implementations and other maintainers. So I >> see no >> alternative but to create forks of those repositories for use by GHC, >> unless/until the other projects/maintainers want to migrate to git. > > Forking is much worse than using multiple vcs's, and if we don't fork, > anyone working on those libraries will have to use git at least to > get GHC > HEAD to check that they're not breaking it. And clearly GHC > developers > outnumber developers of other implementations. (I don't think a move > to git will lead to more GHC developers, but I buy the interns > argument.) Ah, good point! Changing ghc to git means *all* developers of boot libraries need to use git *regardless* of what repo format the boot libraries are in. After all, they need to validate against the current ghc head before pushing. In other words, the decision to move the ghc repo affects all core library developers anyway. No use pretenting that changing only the ghc repo (and leaving the rest in darcs) would make anything simpler for anybody. > My concern is that there are rather more developers of libraries and > assorted other packages, and this will place an arbitrary divide > across > those. Unless everyone moves to git, of course. There are surely more developers of libraries in general than there are GHC developers. However, I doubt that there are more developers of boot libraries, who are not also ghc developers, than there are ghc developers. The change doesn't have to affect anybody, but ghc developers and *core* library developers. Manuel From chak at cse.unsw.edu.au Mon Aug 11 20:46:30 2008 From: chak at cse.unsw.edu.au (Manuel M T Chakravarty) Date: Mon Aug 11 20:45:55 2008 Subject: Version control systems In-Reply-To: <20080811230042.GA7919@matrix.chaos.earth.li> References: <48981C03.10908@gmail.com> <20080806051232.GD17673@scytale.galois.com> <1218016430.7661.189.camel@localhost> <9d4d38820808060331h4758c8a4y2bc6e79d14b8ae3d@mail.gmail.com> <18DB9581-AA5B-433C-9036-34EC2674C2CB@cse.unsw.edu.au> <20080808130329.GA15063@matrix.chaos.earth.li> <5FEA1F32-9C34-4888-A5BE-D0460D55C307@cse.unsw.edu.au> <48A05827.5020200@gmail.com> <20080811230042.GA7919@matrix.chaos.earth.li> Message-ID: Ian Lynagh: > Even the current situation with Cabal is a bit of a pain, as it's easy > to forget to push patches upstream as well as GHC's repo, and that's > just with 2 repos of the same VCS. As I said before, IMHO it is a big mistake for ghc to depend on development versions of Cabal. GHC should only depend on stable Cabal versions. > I actually think the original plan, where only the ghc repo (plus > one or > two others) is in git is preferable. You may have to use a different > VCS > for different subprojects, but after that it's downhill all the way. > You don't have to worry about patches being converted from one VCS to > another, moved to another repo, converted back and merged back into > the > first repo. Having two vcs for one project is bad. One reason to switch to git (I am told) is that people had problems with darcs on some platforms (windows and Solaris, for example). How is that going to be any better if part of the project is still in darcs? So, can we please make up our mind? If darcs has problems on some platforms, then we should not use darcs at all for ghc. If darcs does not have problems on some platforms, then there is one less reason to switch. All core library developers need to use git anyway to validate their core library patches. So, let's just move the ghc repo and *all core libraries* over to git. If git is good enough for the ghc repo, it should be good enough for the core library repos as well, shouldn't it. Manuel From duncan.coutts at worc.ox.ac.uk Mon Aug 11 22:35:54 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Mon Aug 11 22:34:27 2008 Subject: Version control systems In-Reply-To: <48A0C80E.7010205@areta.org> References: <48981C03.10908@gmail.com> <20080806051232.GD17673@scytale.galois.com> <1218016430.7661.189.camel@localhost> <9d4d38820808060331h4758c8a4y2bc6e79d14b8ae3d@mail.gmail.com> <18DB9581-AA5B-433C-9036-34EC2674C2CB@cse.unsw.edu.au> <20080808130329.GA15063@matrix.chaos.earth.li> <5FEA1F32-9C34-4888-A5BE-D0460D55C307@cse.unsw.edu.au> <48A05827.5020200@gmail.com> <20080811212229.GA11669@petunia.outback.escape.de> <20080811214031.GH18593@scytale.galois.com> <48A0C80E.7010205@areta.org> Message-ID: <1218508554.7661.416.camel@localhost> On Tue, 2008-08-12 at 01:15 +0200, Johan Henriksson wrote: > I see an increasing problem in that every community comes up with > their own package system, instead of reusing existing frameworks. That's because there are no usable existing frameworks. It would be wonderful of course if there were some standard language neutral build and packaging system where each language just wrote some lib and could integrate nicely into multi-language systems. > dependencies to other non-haskell libraries has to be addressed for > every other coexisting package system (such as apt-get), if it is > addressed at all. likewise, other languages depending on haskell will > have trouble resolving dependencies. > > so my point is, if there will be any bigger reworking of cabal, I think > one should consider how it could work as a module in a bigger (maybe > future) meta-packaging framework, lifting up binaries to for example > .deb, .exe-installer, .dmg or whatever is the most native for the > platform. ?There are tools to convert Cabal packages to native packages for rpm, deb, ebuild and arch. The Cabal format was designed to allow this translation. This includes dependencies on C libs and external programs. ?Note that this is in contrast to ?existing frameworks like autoconf which do not allow the automatic extraction of dependencies to allow automatic conversion into native packages. > I see a point in language specific package systems as they > have more insight into the build process, but the current > implementations assume a very ideal world in which there are no other > dependencies involved. I don't think this is true. Duncan From donnie at darthik.com Mon Aug 11 23:45:51 2008 From: donnie at darthik.com (Donnie Jones) Date: Mon Aug 11 23:45:13 2008 Subject: Version control systems In-Reply-To: References: <48981C03.10908@gmail.com> <20080806051232.GD17673@scytale.galois.com> <1218016430.7661.189.camel@localhost> <9d4d38820808060331h4758c8a4y2bc6e79d14b8ae3d@mail.gmail.com> <18DB9581-AA5B-433C-9036-34EC2674C2CB@cse.unsw.edu.au> <20080808130329.GA15063@matrix.chaos.earth.li> <5FEA1F32-9C34-4888-A5BE-D0460D55C307@cse.unsw.edu.au> <48A05827.5020200@gmail.com> Message-ID: Hello, On Mon, Aug 11, 2008 at 8:20 PM, Manuel M T Chakravarty < chak@cse.unsw.edu.au> wrote: > Simon Marlow: > >> Manuel M T Chakravarty wrote: >> >> I think all *core* libraries must switch. Seriously, requiring GHC >>> developer to use a mix of two vcs during development is a Very Bad Idea. >>> Don was excited about getting more people to look at the source when it is >>> in git (see the comments he posted from reddit). By requiring two vcs you >>> will get *less* people to look at the source. >>> This is not only to get the sources to hack them, but you effectively >>> require developers to learn the commands for two vcs (when they are already >>> reluctant to learn one). For example, often enough somebody who changes >>> something in GHC will modify the base package, too. Then, to commit the >>> overall work, you need to commit using both vcs. If you need to branch for >>> your work, you need to create branches in two vcs (no idea whether the >>> semantics of a branch in git and darcs is anywhere similar). When you merge >>> your branch, you need to merge in both vcs. You can't seriously propose >>> such a set up! >>> >> >> I completely agree this is a problem. The main obstacle with just >> switching the core libraries is that they are shared by other >> implementations and other maintainers. So I see no alternative but to >> create forks of those repositories for use by GHC, unless/until the other >> projects/maintainers want to migrate to git. Some of the repositories are >> not shared - for example ghc-prim, integer-gmp, template-haskell, and these >> don't need to be forked. >> >> One way we could create the forks would be to create a git repo for each >> package with two branches: the master branch that GHC builds, and a separate >> branch that tracks the main darcs repository, and is synced automatically >> whenever patches are pushed to the main darcs repo. We'd have to explicitly >> merge the tracking branch into the master branch from time to time. When we >> want to make changes locally, we can just commit them to the GHC branch and >> push the changes upstream in a batch later (and then we'd end up having to >> merge them back in to the GHC branch... but hopefully git's merge is clever >> enough to avoid manual intervention here). This is complicated and ugly of >> course; better suggestions welcome. >> > > Yes, it's a pain. However, it is better than two vcs for one project. > > I *strongly* object to moving to git before this isn't sorted out. As >>> Roman said before, GHC is heading into a dangerous direction. It gets >>> progressively harder to contribute to the project at the moment. First, >>> changing the build system to Cabal. Now, proposing to use two vcs. >>> Somebody who is new to the project not only has to learn the internals of >>> GHC, but they also have to learn two new vcs, and if they need to change the >>> build system, they need to learn a new build tool. Raising the bar for >>> developers to contribute to a project has been proven to be a very bad idea >>> many times. Let's not take GHC down that path. >>> >> >> I'm not completely convinced we need to have this all worked out before >> GHC switches, although it would be nice of course. We currently have >> infastructure in place for the build to work with a mixture of darcs and git >> repositories, and existing developers already have to learn git anyway. >> They just need to remember to use darcs for libraries and git for the main >> GHC repo, and this is only a temporary situation. >> > > As far as I am concerned, building GHC is turning into a big mess. We > discussed ways to improve it again, BUT I'd rather not see it getting any > messier before it gets better. Hence, please let's have a complete plan > that we are convinced will work before making any more changes. > > As for Cabal - we had a thread on cvs-ghc last week, and as I said there >> we'd love to hear suggestions for how to improve things, including wild and >> crazy ideas for throwing it all away and starting again. However, as I >> explained, there are good reasons for the way things are done now, the main >> one being that the build system for packages is not written twice. >> > > Yes, we need cabal for packages because we don't want two build systems. > However, this does not justify the use of Cabal outside of libraries/. > Nobody explained to me why that was necessary. Why change all the rest of > the build system. What is the benefit for the ghc project? > > To be honest, if you ask me, I'd go back to the old makefile based system > and remove Cabal from everywhere except building of the library packages. > > Manuel > I am a new developer with GHC and most of my background is with C programming and Makefile based build systems, such as with the Linux Kernel. Thus, it was much easier for me to get started hacking on GHC to only need to modify Makefiles as compared to learning an entirely different build system; therefore, I think you lower the barrier to entry for gaining new GHC developers if you stick with the Makefile build system, which is far more common, stable, robust, and definitely taught/used in many university projects. (Some of these reasons may be the same reasons GHC repo is switching to git.) As I said, I am new to hacking on GHC, so I am not sure what reasons there are to switch to Cabal for the build system; but, I am not an expert in build systems and I was able to figure out the GHC Makefiles to add static and run-time flags to GHC, etc. I definitely think the current Makefile build system could be improved, but overall I did find it quite manageable for my needs. Disclaimer: I really have very little experience with Cabal other than using it for installing packages, so take everything I have said with a grain of salt. __ Donnie Jones -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20080811/522ee3cc/attachment.htm From gour at mail.inet.hr Tue Aug 12 01:12:52 2008 From: gour at mail.inet.hr (Gour) Date: Tue Aug 12 01:29:27 2008 Subject: Version control systems References: <48981C03.10908@gmail.com> <20080806051232.GD17673@scytale.galois.com> <1218016430.7661.189.camel@localhost> <9d4d38820808060331h4758c8a4y2bc6e79d14b8ae3d@mail.gmail.com> <18DB9581-AA5B-433C-9036-34EC2674C2CB@cse.unsw.edu.au> <20080808130329.GA15063@matrix.chaos.earth.li> <5FEA1F32-9C34-4888-A5BE-D0460D55C307@cse.unsw.edu.au> <48A05827.5020200@gmail.com> <20080811172735.GA13912@soi.city.ac.uk> <99278BE4-C737-4349-91F1-78A74D83734E@cse.unsw.edu.au> Message-ID: <874p5q95pn.fsf@gaura-nitai.no-ip.org> >>>>> "Manuel" == Manuel M T Chakravarty writes: Manuel> In other words, the decision to move the ghc repo affects all Manuel> core library developers anyway. No use pretenting that changing Manuel> only the ghc repo (and leaving the rest in darcs) would make Manuel> anything simpler for anybody. I'd say that moving GHC to git affects the WHOLE haskell community and we can already think about having all the HackageDB running git. I'm not at all pleased with it (personally I switched from darcs to bzr), bet better to face what the future brings instead of putting the head in the sand. :-) Sincerely, Gour -- Gour | Zagreb, Croatia | GPG key: C6E7162D ---------------------------------------------------------------- -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 196 bytes Desc: not available Url : http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20080812/ca444b67/attachment-0001.bin From marlowsd at gmail.com Tue Aug 12 04:19:11 2008 From: marlowsd at gmail.com (Simon Marlow) Date: Tue Aug 12 04:18:36 2008 Subject: Version control systems In-Reply-To: References: <48981C03.10908@gmail.com> <20080806051232.GD17673@scytale.galois.com> <1218016430.7661.189.camel@localhost> <9d4d38820808060331h4758c8a4y2bc6e79d14b8ae3d@mail.gmail.com> <18DB9581-AA5B-433C-9036-34EC2674C2CB@cse.unsw.edu.au> <20080808130329.GA15063@matrix.chaos.earth.li> <5FEA1F32-9C34-4888-A5BE-D0460D55C307@cse.unsw.edu.au> <48A05827.5020200@gmail.com> Message-ID: <48A1477F.4060003@gmail.com> Manuel M T Chakravarty wrote: > As far as I am concerned, building GHC is turning into a big mess. We > discussed ways to improve it again, BUT I'd rather not see it getting > any messier before it gets better. Hence, please let's have a complete > plan that we are convinced will work before making any more changes. > >> As for Cabal - we had a thread on cvs-ghc last week, and as I said >> there we'd love to hear suggestions for how to improve things, >> including wild and crazy ideas for throwing it all away and starting >> again. However, as I explained, there are good reasons for the way >> things are done now, the main one being that the build system for >> packages is not written twice. > > Yes, we need cabal for packages because we don't want two build > systems. However, this does not justify the use of Cabal outside of > libraries/. Nobody explained to me why that was necessary. Why change > all the rest of the build system. What is the benefit for the ghc project? GHC is a package, just like any other. The GHC package was the main reason we still had a lot of the old infrastructure for building packages still in the build system, so there was a compelling reason to switch the compiler itself to Cabal, at least. It's true that this change wasn't all win. We gained in some places and lost in others - the build system is more unfriendly to developers now, as opposed to people just building GHC, and that really is something we need to address. > To be honest, if you ask me, I'd go back to the old makefile based > system and remove Cabal from everywhere except building of the library > packages. I wouldn't object to dropping the use of Cabal for other tools in the build tree; the reasons for using it elsewhere are certainly not as compelling as for packages. Ian, I realise this means backing out a lot of the work you've been doing recently, and it would mean that we'd lose a lot of time in the runup to 6.10.1, but perhaps it's a step that we need to take to get us back on the right track again? Cheers, Simon From nominolo at googlemail.com Tue Aug 12 04:33:53 2008 From: nominolo at googlemail.com (Thomas Schilling) Date: Tue Aug 12 04:33:28 2008 Subject: Faster checkout times under Git In-Reply-To: <20080811211537.GG18593@scytale.galois.com> References: <20080811211537.GG18593@scytale.galois.com> Message-ID: <052E7D62-59B8-4300-AA7D-F432EEC1B216@googlemail.com> On 11 Aug 2008, at 23:15, Don Stewart wrote: > Eric Mertens kindly did some experiments on the various git repos, > and servers, and approaches to serving. > > * We're looking at >45 mins for a full history darcs get > of ghc, over http, from darcs.haskell.org. > > * git clone of full ghc over http, from darcs.haskell.org, > completes in > the range of 6-7 minutes (roughly 150KiB/s) > > * git clone over git protocol, using github's bandwidth, completes > in 2.1 minutes. (roughly 560KiB/s) > > So that indicates a significant improvment by switching to the git:// > server protocol. Can we get that on darcs.haskell.org? > > In general git is doing a good job here addressing slow 'darcs get ' > times, which are now way way down. This will make life easier for some > of us. > > Mirroring automatically to github could also address some of our > redundancy concerns. I'm working on both issues with Ian and Paul. The current setup also isn't friendly to incremental pulls over http. I'm working on it. / Thomas -- Push the envelope. Watch it bend. -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 194 bytes Desc: This is a digitally signed message part Url : http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20080812/f3079c32/PGP.bin From johan.tibell at gmail.com Tue Aug 12 04:54:32 2008 From: johan.tibell at gmail.com (Johan Tibell) Date: Tue Aug 12 04:53:52 2008 Subject: Version control systems In-Reply-To: References: <48981C03.10908@gmail.com> <20080806051232.GD17673@scytale.galois.com> <1218016430.7661.189.camel@localhost> <9d4d38820808060331h4758c8a4y2bc6e79d14b8ae3d@mail.gmail.com> <18DB9581-AA5B-433C-9036-34EC2674C2CB@cse.unsw.edu.au> <20080808130329.GA15063@matrix.chaos.earth.li> <5FEA1F32-9C34-4888-A5BE-D0460D55C307@cse.unsw.edu.au> <48A05827.5020200@gmail.com> <20080811230042.GA7919@matrix.chaos.earth.li> Message-ID: <90889fe70808120154h10491b06s645b3a1562794048@mail.gmail.com> On Tue, Aug 12, 2008 at 2:46 AM, Manuel M T Chakravarty wrote: > Ian Lynagh: > Having two vcs for one project is bad. One reason to switch to git (I am > told) is that people had problems with darcs on some platforms (windows and > Solaris, for example). How is that going to be any better if part of the > project is still in darcs? So, can we please make up our mind? If darcs > has problems on some platforms, then we should not use darcs at all for ghc. > If darcs does not have problems on some platforms, then there is one less > reason to switch. I switched all my Haskell projects over to Git, as a developer on Linux, is that I wasted way too much time fighting with Darcs that I should have spent programming. It's way too slow. I've run in to exponential merges with only two developers commiting to the same repository. It randomly freezes -- exponential merge, general sluggishness, who knows! -- or crashes. And merging, perhaps the most important operation in a DVCS, is a pain. I don't trust Darcs to keep my source code safe anymore. Cheers, Johan From malcolm.wallace at cs.york.ac.uk Tue Aug 12 05:10:31 2008 From: malcolm.wallace at cs.york.ac.uk (Malcolm Wallace) Date: Tue Aug 12 05:09:54 2008 Subject: Version control systems In-Reply-To: <99278BE4-C737-4349-91F1-78A74D83734E@cse.unsw.edu.au> References: <48981C03.10908@gmail.com> <20080806051232.GD17673@scytale.galois.com> <1218016430.7661.189.camel@localhost> <9d4d38820808060331h4758c8a4y2bc6e79d14b8ae3d@mail.gmail.com> <18DB9581-AA5B-433C-9036-34EC2674C2CB@cse.unsw.edu.au> <20080808130329.GA15063@matrix.chaos.earth.li> <5FEA1F32-9C34-4888-A5BE-D0460D55C307@cse.unsw.edu.au> <48A05827.5020200@gmail.com> <20080811172735.GA13912@soi.city.ac.uk> <99278BE4-C737-4349-91F1-78A74D83734E@cse.unsw.edu.au> Message-ID: On 12 Aug 2008, at 01:35, Manuel M T Chakravarty wrote: > Ah, good point! Changing ghc to git means *all* developers of boot > libraries need to use git *regardless* of what repo format the boot > libraries are in. After all, they need to validate against the > current ghc head before pushing. It is worth pointing out that I *never* validate against ghc head when I commit to the core libraries. (Actually, I don't even keep any checkout of ghc head.) Generally I'm fixing something that has unintentionally broken the nhc98 build of the libraries, *despite* the breaking-patch being validated against ghc. To be honest I don't particularly care if my fixing patch then breaks ghc again. Why not? Because the "chain of blame" effectively leads back past me to the earlier patch. (In practice, re-breaking ghc is very rare.) Now, there is only one person taking care of nhc98 (me), and probably I'm its only user as well, but I do still think it is worth the 30 secs or so every day it takes to check the nightly build logs and the 30mins it occasionally takes to fix breakage when necessary. Building a full Haskell'98 compiler is a significant undertaking, and it would be a great shame to simply discard it because the libraries are no longer available in a shared format. Who knows, maybe someone will find it easier to port to their iPhone than ghc. :-) What I'm not really prepared to do is to extend the fixing time by an extra 30mins just to validate against ghc. I might be prepared to learn a new VCS, but from what I've seen so far, git looks rather complex and difficult to use. It is also worth noting that where a larger community of developers has gathered around a core library (e.g. Cabal), ghc has found it necessary to branch off a ghc-only version of that library, so that commits to the library head do not need to be validated against ghc head. Igloo takes care of merging across a large bunch of patches every once in a while. This model seems to work well. In theory, the core library head could remain in darcs, with the ghc branch of it in git. All the pain of merging would be dumped on one person (sorry Igloo!) but everyone else gets the benefit. Regards, Malcolm From simonpj at microsoft.com Tue Aug 12 05:29:52 2008 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Tue Aug 12 05:29:14 2008 Subject: Version control systems In-Reply-To: References: <48981C03.10908@gmail.com> <20080806051232.GD17673@scytale.galois.com> <1218016430.7661.189.camel@localhost> <9d4d38820808060331h4758c8a4y2bc6e79d14b8ae3d@mail.gmail.com> <18DB9581-AA5B-433C-9036-34EC2674C2CB@cse.unsw.edu.au> <20080808130329.GA15063@matrix.chaos.earth.li> <5FEA1F32-9C34-4888-A5BE-D0460D55C307@cse.unsw.edu.au> <48A05827.5020200@gmail.com> <20080811172735.GA13912@soi.city.ac.uk> <99278BE4-C737-4349-91F1-78A74D83734E@cse.unsw.edu.au> Message-ID: <638ABD0A29C8884A91BC5FB5C349B1C32AE806640A@EA-EXMSG-C334.europe.corp.microsoft.com> | It is worth pointing out that I *never* validate against ghc head when | I commit to the core libraries. I think that's perfectly reasonable for the reasons you explain. Simon From marlowsd at gmail.com Tue Aug 12 06:11:38 2008 From: marlowsd at gmail.com (Simon Marlow) Date: Tue Aug 12 06:11:07 2008 Subject: Build system idea Message-ID: <48A161DA.3010106@gmail.com> Simon PJ and I had a talk about the build system earlier today, I thought I'd float the idea we discussed (I should admit that the idea was mine, lest Simon PJ think I'm attributing bad ideas to him :-). This is not completely thought through, but I'm pretty sure a solution exists along these lines that would improve things for us. Ok, the starting point is this: - Cabal has code to generate Makefiles. Almost nobody uses it except for the GHC build system. It essentially duplicates the build system for compiling Haskell source (but not for installation, haddocking, registration, configuration, etc.) - Cabal is a library I propose we do this: - Extract the code from Cabal that generates Makefiles, and treat it as part of the GHC build system. Rather than generating a Makefile complete with build rules, we generate a Makefile that just has the package-specific metadata (list of modules, etc.), and put the code to actually build the package in the GHC build system. This means we still get to use 'make', we still get to use the .cabal files as metadata, but the build system is more private to GHC, more extensible, and hopefully more understandable and modifiable. We can express dependencies that Cabal currently doesn't know about. It would let us avoid the current uncomfortable situation where we have to feed all kinds of configuration information from the GHC build system into Cabal - Cabal would be essentially just a mechanism for translating the .cabal file into Makefile bindings and package metadata for ghc-pkg. There will undoubtedly be some sticking points where we have to tradeoff duplicating things from Cabal against re-using parts of Cabal which might require modifying Cabal itself. For instance, we could use Cabal for installation, but that means that our build system has to leave everything in the places that Cabal's installation code expects, so it might be more feasible to do installation ourselves, but that means duplicating parts of Cabal. It will probably mean that we have a tighter dependency on Cabal, because we use it as a library rather than a black box; but hopefully we can keep our branch of Cabal more stable and not have to update it so often. Anyway, this is an idea that I think is interesting. Obviously it needs a lot more fleshing out to be a real proposal, but I'm interested in whether anyone thinks this idea is worth persuing, or whether there are better alternatives. Cheers, Simon From marlowsd at gmail.com Tue Aug 12 06:59:37 2008 From: marlowsd at gmail.com (Simon Marlow) Date: Tue Aug 12 06:59:02 2008 Subject: Version control systems In-Reply-To: <20080811212229.GA11669@petunia.outback.escape.de> References: <48981C03.10908@gmail.com> <20080806051232.GD17673@scytale.galois.com> <1218016430.7661.189.camel@localhost> <9d4d38820808060331h4758c8a4y2bc6e79d14b8ae3d@mail.gmail.com> <18DB9581-AA5B-433C-9036-34EC2674C2CB@cse.unsw.edu.au> <20080808130329.GA15063@matrix.chaos.earth.li> <5FEA1F32-9C34-4888-A5BE-D0460D55C307@cse.unsw.edu.au> <48A05827.5020200@gmail.com> <20080811212229.GA11669@petunia.outback.escape.de> Message-ID: <48A16D19.40800@gmail.com> Matthias Kilian wrote: > On Mon, Aug 11, 2008 at 04:17:59PM +0100, Simon Marlow wrote: > [...] >> As for Cabal - we had a thread on cvs-ghc last week, and as I said there >> we'd love to hear suggestions for how to improve things, including wild >> and crazy ideas for throwing it all away and starting again. However, as >> I explained, there are good reasons for the way things are done now, the >> main one being that the build system for packages is not written twice. > > Well, at least the Makefile creation was a step (the first step?) > into the wrong direction, IMHO. I'll run a GHC build to get some > of those generated Makefiles and followup on cvs-ghc, but for a > starter, Cabal shouldn't know anything about implementation-specific > internal build systems; instead it should rely only on it's own > metadata. I'm not completely sure, but I think you may have misunderstood how Cabal's makefile generation currently works. It has no specific knowledge of GHC's build system, and it does rely on its own metadata. (in my other message I'm suggesting moving the Makefile generation into GHC's build system so that it could be made specific to GHC, though). > Implementation-specific stuff (such as how to run the > compiler) should be supplied by the implementation, not by Cabal. This is what makes me unsure. Implementation of what? Are you suggesting a redesign of Cabal, or just changing the way something works? Cheers, Simon From duncan.coutts at worc.ox.ac.uk Tue Aug 12 07:09:13 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Tue Aug 12 07:07:44 2008 Subject: Build system idea In-Reply-To: <48A161DA.3010106@gmail.com> References: <48A161DA.3010106@gmail.com> Message-ID: <1218539353.7661.452.camel@localhost> On Tue, 2008-08-12 at 11:11 +0100, Simon Marlow wrote: > I propose we do this: > > - Extract the code from Cabal that generates Makefiles, and treat it as > part of the GHC build system. Rather than generating a Makefile > complete with build rules, we generate a Makefile that just > has the package-specific metadata (list of modules, etc.), and put > the code to actually build the package in the GHC build system. As you know, I've been trying to get rid of that code ever since it arrived :-) > It will probably mean that we have a tighter dependency on Cabal, because > we use it as a library rather than a black box; but hopefully we can keep > our branch of Cabal more stable and not have to update it so often. If you don't need to update so often it would make life easier for Cabal hackers and Manuel would be pleased :-) > Anyway, this is an idea that I think is interesting. Obviously it needs a > lot more fleshing out to be a real proposal, but I'm interested in whether > anyone thinks this idea is worth persuing, or whether there are better > alternatives. Right, so probably the crucial thing is how much you end up having to duplicate and of how much ?of said duplicated infrastructure has to be kept in sync. For example if the path layout is different does that make Cabal's haddocking support not work forcing that to be duplicated too? Duncan From Malcolm.Wallace at cs.york.ac.uk Tue Aug 12 07:09:54 2008 From: Malcolm.Wallace at cs.york.ac.uk (Malcolm Wallace) Date: Tue Aug 12 07:11:19 2008 Subject: Build system idea In-Reply-To: <48A161DA.3010106@gmail.com> References: <48A161DA.3010106@gmail.com> Message-ID: <20080812120954.670307b9.Malcolm.Wallace@cs.york.ac.uk> Simon Marlow wrote: > This means we still get to use 'make', we still get to use the .cabal > files as metadata, but the build system is more private to GHC, more > extensible, and hopefully more understandable and modifiable. This is essentially the same approach that nhc98 currently takes to building libraries. The Cabal file holds all the metadata, but the build system is Makefile-driven. There is a small separate tool (CabalParse) that extracts metadata from the cabal file. The Cabal *library* could be used to implement that extraction tool, but currently ours is hand-rolled. (One of the benefits of open specifications of file formats is that you can have multiple implementations for different purposes.) Here is an example of how it works: CABALFILE = $(shell ls *.cabal | head -n 1 ) READ = $(CABALPARSE) $(CABALFILE) -quiet MAP = $(LOCAL)map THISPKG = $(shell $(READ) name | cut -c2- ) VERSION = $(shell $(READ) version) SEARCH = $(shell $(READ) build-depends | $(MAP) "echo -package" ) \ $(shell $(READ) include-dirs | $(MAP) "echo -i" | cut -c1,2,4-) \ $(shell $(READ) hs-source-dir | $(MAP) "echo -I" | cut -c1,2,4-) \ $(shell $(READ) hs-source-dirs | $(MAP) "echo -I" | cut -c1,2,4-) CINCLUDES = $(shell $(READ) include-dirs | $(MAP) "echo -I" | cut -c1,2,4-) SRCS = $(shell $(READ) -slash exposed-modules) EXTRA_SRCS = $(shell $(READ) -slash other-modules) SRCS_C = $(shell $(READ) c-sources) DIRS = $(shell $(READ) -slash exposed-modules other-modules \ | $(MAP) dirname | sort | uniq ) EXTRA_C_FLAGS = $(shell $(READ) cc-options) EXTRA_H_FLAGS = $(shell $(READ) nhc98-options) Regards, Malcolm From igloo at earth.li Tue Aug 12 07:31:12 2008 From: igloo at earth.li (Ian Lynagh) Date: Tue Aug 12 07:30:33 2008 Subject: Version control systems In-Reply-To: <20080811001751.28DA31383C3@drdoom.eecs.harvard.edu> References: <18DB9581-AA5B-433C-9036-34EC2674C2CB@cse.unsw.edu.au> <20080808130329.GA15063@matrix.chaos.earth.li> <5FEA1F32-9C34-4888-A5BE-D0460D55C307@cse.unsw.edu.au> <20080809190651.GC3902@scytale.galois.com> <36A0EEA6-5E34-4A1A-A008-7F847D84A1E2@cs.york.ac.uk> <20080809225624.BDD6613833F@drdoom.eecs.harvard.edu> <20080810113200.GA16357@matrix.chaos.earth.li> <20080811001751.28DA31383C3@drdoom.eecs.harvard.edu> Message-ID: <20080812113112.GA17581@matrix.chaos.earth.li> On Sun, Aug 10, 2008 at 08:17:50PM -0400, Norman Ramsey wrote: > > On Sat, Aug 09, 2008 at 06:56:23PM -0400, Norman Ramsey wrote: > > > > > personally I would much prefer to see money spent on making darcs > > better, for reasons I won't repeat again. > > I missed them and wouldn't mind receiving a private note. OK, I'll send to the list so that I have somewhere convenient to point people if this comes up in the future: * A lot of darcs's functionality could be refactored into generally usable Haskell libraries, e.g. LCS-finding, downloading-with-libcurl. * darcs was once a flagship Haskell application, supporting the idea that Haskell can be used in the real world. That image has mostly faded away now due to the problems it has, but I think we can get it back if we can get a high quality darcs out there. That would be good for the community's image. * darcs has (in my opinion, at least) a much simpler, more intuitive interface than the other version control systems. I don't think I'm alone here, as I think this is where a lot of the resistance against moving to git is coming from. * I think darcs is the Obvious, Right way to do version control. Phil Wadler (at least, I think it was him; and probably many others too) has said that the lambda calculus is universal, in the sense that if we were to meet a sufficiently advanced alien culture, it is almost inconceivable that they would not have also discovered the lambda calculus. Darcs-style patch theory, before conflicting patches are introduced, falls into the same category in my opinion. (I'm not yet sure if it can be extended to include some definition of conflictors too). By contrast, the heuristics and multiple merge algorithms of other systems feels very ad-hoc. Thanks Ian From igloo at earth.li Tue Aug 12 07:53:44 2008 From: igloo at earth.li (Ian Lynagh) Date: Tue Aug 12 07:53:05 2008 Subject: Version control systems In-Reply-To: References: <20080806051232.GD17673@scytale.galois.com> <1218016430.7661.189.camel@localhost> <9d4d38820808060331h4758c8a4y2bc6e79d14b8ae3d@mail.gmail.com> <18DB9581-AA5B-433C-9036-34EC2674C2CB@cse.unsw.edu.au> <20080808130329.GA15063@matrix.chaos.earth.li> <5FEA1F32-9C34-4888-A5BE-D0460D55C307@cse.unsw.edu.au> <48A05827.5020200@gmail.com> <20080811172735.GA13912@soi.city.ac.uk> <99278BE4-C737-4349-91F1-78A74D83734E@cse.unsw.edu.au> Message-ID: <20080812115344.GB17581@matrix.chaos.earth.li> On Tue, Aug 12, 2008 at 10:10:31AM +0100, Malcolm Wallace wrote: > > On 12 Aug 2008, at 01:35, Manuel M T Chakravarty wrote: > >Ah, good point! Changing ghc to git means *all* developers of boot > >libraries need to use git *regardless* of what repo format the boot > >libraries are in. After all, they need to validate against the > >current ghc head before pushing. > > It is worth pointing out that I *never* validate against ghc head when > I commit to the core libraries. Also, all of the people who send us patches don't need to validate (and I suspect most of them don't), as we validate the patches before pushing them. Thanks Ian From duncan.coutts at worc.ox.ac.uk Tue Aug 12 08:17:25 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Tue Aug 12 08:15:53 2008 Subject: Version control systems In-Reply-To: References: <48981C03.10908@gmail.com> <20080806051232.GD17673@scytale.galois.com> <1218016430.7661.189.camel@localhost> <9d4d38820808060331h4758c8a4y2bc6e79d14b8ae3d@mail.gmail.com> <18DB9581-AA5B-433C-9036-34EC2674C2CB@cse.unsw.edu.au> <20080808130329.GA15063@matrix.chaos.earth.li> <5FEA1F32-9C34-4888-A5BE-D0460D55C307@cse.unsw.edu.au> <4BF2D191-FAC5-4285-8638-86D0A8366305@googlemail.com> <4E23A401-E5D4-4589-8334-D8B21BDDCA44@cse.unsw.edu.au> <55163A6F-9F46-450F-888D-BD52479B296E@googlemail.com> <1218452424.7661.366.camel@localhost> Message-ID: <1218543445.7661.457.camel@localhost> On Mon, 2008-08-11 at 14:29 +0200, Thomas Schilling wrote: > On 11 Aug 2008, at 13:00, Duncan Coutts wrote: > > It's not clear to me that we've really bothered to find out. The last > > evaluation in relation to ghc that I'm aware of was prior to the 2.0 > > release. My impression is that we've all complained about the darcs v1 > > problems (justly) but spent the most effort investigating things other > > than darcs v2 which would be the easiest to upgrade to and not have > > the > > problems of using two different systems for ghc vs other libs. > > I converted the ghc repo to darcs2 (locally): > > Getting file local history: > > * darcs changes --last 20 compiler/main/HscTypes.lhs > > very quick but prints only two patches > > * darcs changes compiler/hsSyn/HsTypes.lhs > > 1m22s (16s for the second time) Interesting that you get so much variance between runs. ?I get 32s user time first time and 30s the second. In this test darcs 2 is faster that darcs 1 on v1 format repos and darcs 2 is faster on v2 format repos than on v1 format, though only by a few seconds. At a guess, the issue here is that darcs is not indexing those changes per-file, which is why --last 20 doesn't give the last 20 for that file and why asking for all changes takes so long. Perhaps if it did cache this info per-file it'd help with annotate too. > Git <1s > > * darcs get ghc2 ghc-test (creating a *local* branch) > > real 13m25.365s > user 0m14.677s > sys 0m29.541s > > (at least it seems it actually worked, though) That's an order of magnitude different to what I see: $ time darcs2 get ghc2 ghc-test Copying patches, to get lazy repository hit ctrl-C... Finished getting. real 0m21.428s user 0m11.221s sys 0m1.380s Note that this is much faster in the darcs v2 format than darcs 2 using the darcs v1 format: $ time darcs2 get ghc ghc-test1 Finished getting. real 1m51.959s user 1m15.449s sys 0m11.877s However darcs v1 is faster still: $ time darcs1 get ghc ghc-test1_ Copying patch 19084 of 19084... done. Finished getting. real 0m8.851s user 0m3.668s sys 0m0.708s It doesn't seem to spend any time applying the patches, unlike what darcs 2 is doing for v1 or v2 formats. Though in any case, one doesn't need to darcs get locally since one can use cp -a right? > git clone ghc g2 (the slow method of creating a local branch) > > real 0m6.742s > user 0m0.335s > sys 0m0.652s > > * I haven't tested a remote pull yet. At 80 Kb/s, it should take > about 15min to clone via Git (70 MB). A test of darcs would be > interesting. We'll be testing this for the code.h.o conversion. We'll keep you posted. Duncan From igloo at earth.li Tue Aug 12 08:18:35 2008 From: igloo at earth.li (Ian Lynagh) Date: Tue Aug 12 08:17:55 2008 Subject: Version control systems In-Reply-To: References: <48981C03.10908@gmail.com> <20080806051232.GD17673@scytale.galois.com> <1218016430.7661.189.camel@localhost> <9d4d38820808060331h4758c8a4y2bc6e79d14b8ae3d@mail.gmail.com> <18DB9581-AA5B-433C-9036-34EC2674C2CB@cse.unsw.edu.au> <20080808130329.GA15063@matrix.chaos.earth.li> <5FEA1F32-9C34-4888-A5BE-D0460D55C307@cse.unsw.edu.au> <48A05827.5020200@gmail.com> Message-ID: <20080812121835.GA18185@matrix.chaos.earth.li> On Tue, Aug 12, 2008 at 10:20:14AM +1000, Manuel M T Chakravarty wrote: > > To be honest, if you ask me, I'd go back to the old makefile based > system and remove Cabal from everywhere except building of the library > packages. > > Manuel > > PS: Just for some more collateral damage. Did anybody check whether > the Mac OS installer support and the -unfortunately, only partially > working- support to compile for older OS X versions that I added to > the *makefiles* still works with the Cabal-based system? I doubt it. > Took me quite a while to get all this going, and I am not very well > motivated to spend a lot of time to figure out how it might work with > Cabal. IMHO using Cabal for anything but the libraries was a step > back for no good reason. Do you mean the "rebuilding the tools with stage2" stuff? If so, that's an interesting example to pick, as that was the impetus behind changing how the build system worked for all the non-libraries/ghc. Those changes made the build non-idempotent: we would build something with the bootstrapping compiler, build some other stuff, then come back, clean it, and build it again with the in-tree compiler. This was a little annoying at the best of times, as e.g. rerunning make at the top level would needlessly rebuild some stuff. However, when my local changes meant that programs built by GHC segfaulted, it was especially irritating to find that after (hopefully) fixing the bug I couldn't just run make in compiler/ or rts/, because ghc-pkg etc now just segfaulted! It was at that point that I half-reverted the changes, and later I reimplemented something similar using Cabal. Now we make, for example, ghc-pkg with the bootstrapping compiler in utils/ghc-pkg/dist-inplace, and then later on we make it with the stage1 compiler in utils/ghc-pkg/dist-install. To answer your actual question: No, not having OS X yet I haven't tested it, but I did make an effort to keep it working. In mk/cabal-flags.mk we say: USE_STAGE_CONFIGURE_FLAGS = \ ... $(addprefix --cc-option=,$(MACOSX_DEPLOYMENT_CC_OPTS)) \ $(addprefix --ld-option=,$(MACOSX_DEPLOYMENT_LD_OPTS)) which will hopefully do the trick, and (IMO) in a much cleaner, more maintainable way than would have been possible with the old build system. Thanks Ian From marlowsd at gmail.com Tue Aug 12 08:55:54 2008 From: marlowsd at gmail.com (Simon Marlow) Date: Tue Aug 12 08:55:25 2008 Subject: Build system idea In-Reply-To: <20080812120954.670307b9.Malcolm.Wallace@cs.york.ac.uk> References: <48A161DA.3010106@gmail.com> <20080812120954.670307b9.Malcolm.Wallace@cs.york.ac.uk> Message-ID: <48A1885A.9080306@gmail.com> Malcolm Wallace wrote: > Simon Marlow wrote: > >> This means we still get to use 'make', we still get to use the .cabal >> files as metadata, but the build system is more private to GHC, more >> extensible, and hopefully more understandable and modifiable. > > This is essentially the same approach that nhc98 currently takes to > building libraries. Right, I was aware that nhc98 uses this method but forgot to mention it. Thanks for pointing it out. I think it makes a lot more sense for us to re-use parts of Cabal than to re-implement the whole thing, although the balance is probably different for nhc98. Cabal generates the InstalledPackageInfo from the .cabal file, for example, and this is certainly something we don't want to re-implement. Cheers, Simon From simonpj at microsoft.com Tue Aug 12 09:46:59 2008 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Tue Aug 12 09:46:36 2008 Subject: Version control systems In-Reply-To: References: <48981C03.10908@gmail.com> <20080806051232.GD17673@scytale.galois.com> <1218016430.7661.189.camel@localhost> <9d4d38820808060331h4758c8a4y2bc6e79d14b8ae3d@mail.gmail.com> <18DB9581-AA5B-433C-9036-34EC2674C2CB@cse.unsw.edu.au> <20080808130329.GA15063@matrix.chaos.earth.li> <5FEA1F32-9C34-4888-A5BE-D0460D55C307@cse.unsw.edu.au> <48A05827.5020200@gmail.com> Message-ID: <638ABD0A29C8884A91BC5FB5C349B1C32AE8066602@EA-EXMSG-C334.europe.corp.microsoft.com> Friends | > I see more and more workarounds for workarounds for an unmaintainable | > (and unusable) build system, and after the latest discussions about | > git vs. darcs, maintaining GHC-specific branches of libraries etc., | > I think I'll just drop maintainership from all GHC-related OpenBSD | > ports until the GHC build system chaos settles down a little bit. | | Ian, please read this. | The inability to build GHC reliably is a problem. | | Can someone with a plan please describe what measures are in place | to ensure GHC emerges buildable, and the tree regains the status of a | tree that *does not break*? I don't think we should over-react here. There's been lots of email on this thread, some of which IMHO makes things sound rather worse than they really are. Let me say how it looks to me. There are two separate but loosely-related conversations going on. 1. Changes to GHC's build system. Cabal is used to build Haskell libraries. We started to use it to build the libraries that come with GHC; and we recently moved over to Cabal to build GHC itself (which is, these days, just another library). The old makefile-based system was essentially duplicating much of the functionality of Cabal, and that duplication was painful. In retrospect, we should have made this change in a branch, and tested it thoroughly before applying it to the HEAD. Build systems tend to be platform dependent, so testing on one platform isn't enough. Nor did we consult, or even communicate, enough before going ahead. And we need more Wiki documentation about how to drive the new system. The net effect of these omissions has been a lot of pain to our collaborators. I am very sorry about that. But I think it'd be a pity to confuse the pain of transition with the destination. The build system is settling down. For the moment, it probably makes sense not to aggressively pull patches from the GHC repo if you don't have to, but we absolutely do not expect that situation to persist. We'll make an announcement when we're ready for you to give it a try. The clear goal is: it simply builds flawlessly. There is an element of "dogfoooding" here. GHC is a stress test for what Cabal can do, and is itself not fully mature. But the pain we experience thereby leads to bug-fixes and significant features for Cabal that are useful for everyone. Perhaps we made the move too early though! The new design is not set in stone, and we are actively thinking about ways to improve it, *including* backing off from Cabal in places where it appears too inflexible. Of course, any such further changes would extend the period of upheaval, but (a) we'll publish a design before executing, and (b) we'll do it on a branch. 2. The version control system (VCS) At the same time, we had an extended conversation about changing the version control system we use for GHC. There was a lot of consultation here, as a result of which we chose git. I won't rehearse again the reasons we are unhappy with darcs, except to say that darcs is a thing of beauty, but the scale of GHC's repository seems to flush out many darcs bugs and performance problems that have proved difficult to fix. Unlike the build system, we have not yet executed this decision. In particular, the earlier discussions focused mainly on the relative merits of the various systems. But it's more complicated than that. GHC needs "core libraries" without which it cannot be built. It is obviously highly desirable that a developer can build GHC with just one VCS, which suggests that the core libraries should be in git too. But those same core libraries are used by nhc98 and Hugs (I think that's all), and the last thing we want to do is to impose new costs on other implementations. Diversity in implementation is a Good Thing. It's unclear exactly what to do about this. The most plausible possibility is to keep the core libraries that are shared with other implementations in darcs as now, and mirror them in git for GHC developers. That will impose pain on GHC developers to keep the git stuff in sync with the darcs master copies; but at least other developers would be unaffected. It's a hard judgement call to say which pain is greatest: the pain of staying with darcs, or the pain of managing the two-VCS problem. Regardless, though, if all you want to do is build GHC from scratch, it absolutely will be a question of getting the relevant VCS, installing support software (Happy, Alex, an earlier GHC), and typing 'make'. You won't have to know about funny branches. We (GHC HQ) are still learning the transition to wider participation in building and hacking on GHC, which we *very much* welcome. Bear with us if we don't get it right first time. We're trying! Simon From gale at sefer.org Tue Aug 12 11:47:58 2008 From: gale at sefer.org (Yitzchak Gale) Date: Tue Aug 12 11:47:18 2008 Subject: Orphan Instances In-Reply-To: <638ABD0A29C8884A91BC5FB5C349B1C32AE8066342@EA-EXMSG-C334.europe.corp.microsoft.com> References: <20080810200107.B5A303241BE@www.haskell.org> <638ABD0A29C8884A91BC5FB5C349B1C32AE8065EE6@EA-EXMSG-C334.europe.corp.microsoft.com> <48A117DD.8090108@semantic.org> <638ABD0A29C8884A91BC5FB5C349B1C32AE8066342@EA-EXMSG-C334.europe.corp.microsoft.com> Message-ID: <2608b8a80808120847s3b2ad8d5kdd062e490bc68b03@mail.gmail.com> Ashley Yakely wrote: >> What is an orphan instance, and why do we care about them? Simon Peyton-Jones wrote: > They are documented in the GHC manual > http://www.haskell.org/ghc/docs/latest/html/users_guide/separate-compilation.html#orphan-modules Thanks for the nice explanation there. Since you brought it up, though, the explanation might be made even clearer with two small changes: 1. The term "instance head" is used throughout the explanation, beginning already with the second paragraph ("the head of the instance..."). However, that term is only defined near the very end '(the part after the "=>")'. For those who do not already know the surprise ending, this makes the explanation read rather like a mystery story. 2. I believe that the text "by setting a = Int" was meant to be "by setting a = T". Thanks, Yitz From devnull1999 at yahoo.com Tue Aug 12 12:24:10 2008 From: devnull1999 at yahoo.com (Eric) Date: Tue Aug 12 12:23:29 2008 Subject: Version control systems Message-ID: <414912.80288.qm@web36508.mail.mud.yahoo.com> A metacomment: As a lurker, and a reader of other languages' mail groups, I just wanted to complement you GHC folks on the quality of your discussion. You're discussing an issue that people clearly have strong opinions about, yet you've all remained polite and respectful and kept the signal-to-noise ratio of the discussion high, unlike what I see on some the mail groups of some other languages. It's a pleasure reading even your disagreements. --Eric From bulat.ziganshin at gmail.com Tue Aug 12 13:42:07 2008 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Tue Aug 12 13:47:26 2008 Subject: Version control systems In-Reply-To: <638ABD0A29C8884A91BC5FB5C349B1C32AE8066602@EA-EXMSG-C334.europe.corp.microsoft.com> References: <48981C03.10908@gmail.com> <20080806051232.GD17673@scytale.galois.com> <1218016430.7661.189.camel@localhost> <9d4d38820808060331h4758c8a4y2bc6e79d14b8ae3d@mail.gmail.com> <18DB9581-AA5B-433C-9036-34EC2674C2CB@cse.unsw.edu.au> <20080808130329.GA15063@matrix.chaos.earth.li> <5FEA1F32-9C34-4888-A5BE-D0460D55C307@cse.unsw.edu.au> <48A05827.5020200@gmail.com> <638ABD0A29C8884A91BC5FB5C349B1C32AE8066602@EA-EXMSG-C334.europe.corp.microsoft.com> Message-ID: <1968109009.20080812214207@gmail.com> Hello Simon, Tuesday, August 12, 2008, 5:46:59 PM, you wrote: > GHC needs "core libraries" without which it cannot be built. It is > obviously highly desirable that a developer can build GHC with just > one VCS, which suggests that the core libraries should be in git too. > But those same core libraries are used by nhc98 and Hugs (I think > that's all), and the last thing we want to do is to impose new costs > on other implementations. Diversity in implementation is a Good Thing. why not ask hugs/nhc maintainers to switch to git too? it seems that darcs while being good solution for small/medium programs, hardly may be used for ghc. so, probably it should be divided to 2 parts: "large things" including compilers and corelibs should go into git and "small things" including all the 3rd-party libs should stay with darcs -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From simonpj at microsoft.com Tue Aug 12 14:25:59 2008 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Tue Aug 12 14:25:23 2008 Subject: Orphan Instances In-Reply-To: <2608b8a80808120847s3b2ad8d5kdd062e490bc68b03@mail.gmail.com> References: <20080810200107.B5A303241BE@www.haskell.org> <638ABD0A29C8884A91BC5FB5C349B1C32AE8065EE6@EA-EXMSG-C334.europe.corp.microsoft.com> <48A117DD.8090108@semantic.org> <638ABD0A29C8884A91BC5FB5C349B1C32AE8066342@EA-EXMSG-C334.europe.corp.microsoft.com> <2608b8a80808120847s3b2ad8d5kdd062e490bc68b03@mail.gmail.com> Message-ID: <638ABD0A29C8884A91BC5FB5C349B1C32AE8066717@EA-EXMSG-C334.europe.corp.microsoft.com> Suggestions like this are a great help for improving the user manual. Thank you. I will fix. Simon | -----Original Message----- | From: glasgow-haskell-users-bounces@haskell.org [mailto:glasgow-haskell- | users-bounces@haskell.org] On Behalf Of Yitzchak Gale | Sent: 12 August 2008 16:48 | To: Simon Peyton-Jones | Cc: GHC Users Mailing List; Ashley Yakeley | Subject: Re: Orphan Instances | | | | Ashley Yakely wrote: | >> What is an orphan instance, and why do we care about them? | | Simon Peyton-Jones wrote: | > They are documented in the GHC manual | > http://www.haskell.org/ghc/docs/latest/html/users_guide/separate- | compilation.html#orphan-modules | | Thanks for the nice explanation there. Since you brought it | up, though, the explanation might be made even clearer with | two small changes: | | 1. The term "instance head" is used throughout the explanation, | beginning already with the second paragraph ("the head of the | instance..."). However, that term is only defined near the very end | '(the part after the "=>")'. For those who do not already know the | surprise ending, this makes the explanation read rather like a | mystery story. | | 2. I believe that the text "by setting a = Int" was meant to be | "by setting a = T". | | Thanks, | Yitz | _______________________________________________ | Glasgow-haskell-users mailing list | Glasgow-haskell-users@haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users From nominolo at googlemail.com Tue Aug 12 14:53:26 2008 From: nominolo at googlemail.com (Thomas Schilling) Date: Tue Aug 12 14:53:02 2008 Subject: Version control systems In-Reply-To: <638ABD0A29C8884A91BC5FB5C349B1C32AE8066602@EA-EXMSG-C334.europe.corp.microsoft.com> References: <48981C03.10908@gmail.com> <20080806051232.GD17673@scytale.galois.com> <1218016430.7661.189.camel@localhost> <9d4d38820808060331h4758c8a4y2bc6e79d14b8ae3d@mail.gmail.com> <18DB9581-AA5B-433C-9036-34EC2674C2CB@cse.unsw.edu.au> <20080808130329.GA15063@matrix.chaos.earth.li> <5FEA1F32-9C34-4888-A5BE-D0460D55C307@cse.unsw.edu.au> <48A05827.5020200@gmail.com> <638ABD0A29C8884A91BC5FB5C349B1C32AE8066602@EA-EXMSG-C334.europe.corp.microsoft.com> Message-ID: <62845DD1-279E-4D68-BA9B-586266DF7A4A@googlemail.com> On 12 Aug 2008, at 15:46, Simon Peyton-Jones wrote: > > It's unclear exactly what to do about this. The most plausible > possibility is to keep the core libraries that are shared with other > implementations in darcs as now, and mirror them in git for GHC > developers. That will impose pain on GHC developers to keep the git > stuff in sync with the darcs master copies; but at least other > developers would be unaffected. > FWIW, I started a wiki page that tries a direct comparison between Darcs and Git: http://hackage.haskell.org/trac/ghc/wiki/GitForDarcsUsers Some mappings are simple, some are more complicated and will require adopting a different workflow. I still recommend reading a tutorial, but this cheat sheet should be a good start if you don't want to spend much time to learn Git just yet. Where no directly corresponding command exists or emulating it would be too messy, I try to hint towards other work flows. I encourage everyone to add useful tips and examples both from users who already use Git and later on, once we have gathered more experience. I believe that Git has some features which can improve our productivity and I'd like this page to also collect tips how to do so. / Thomas -- Push the envelope. Watch it bend. -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 194 bytes Desc: This is a digitally signed message part Url : http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20080812/4a85d9f8/PGP.bin From nr at eecs.harvard.edu Tue Aug 12 14:55:48 2008 From: nr at eecs.harvard.edu (Norman Ramsey) Date: Tue Aug 12 14:55:08 2008 Subject: Version control systems In-Reply-To: <1218508554.7661.416.camel@localhost> (sfid-H-20080811-224302-+76.47-1@multi.osbf.lua) References: <48981C03.10908@gmail.com> <20080806051232.GD17673@scytale.galois.com> <1218016430.7661.189.camel@localhost> <9d4d38820808060331h4758c8a4y2bc6e79d14b8ae3d@mail.gmail.com> <18DB9581-AA5B-433C-9036-34EC2674C2CB@cse.unsw.edu.au> <20080808130329.GA15063@matrix.chaos.earth.li> <5FEA1F32-9C34-4888-A5BE-D0460D55C307@cse.unsw.edu.au> <48A05827.5020200@gmail.com> <20080811212229.GA11669@petunia.outback.escape.de> <20080811214031.GH18593@scytale.galois.com> <48A0C80E.7010205@areta.org> <1218508554.7661.416.camel@localhost> (sfid-H-20080811-224302-+76.47-1@multi.osbf.lua) Message-ID: <20080812185548.E97CC1383C3@drdoom.eecs.harvard.edu> > > I see an increasing problem in that every community comes up with > > their own package system, instead of reusing existing frameworks. > > That's because there are no usable existing frameworks. I couldn't agree more. I have been working on this problem off and on since 1993, and the situation now is even worse than it was then. It's become a full-time job just to keep track of the frameworks. (For example, I'm not as informed about Omake as I'd like to be.) As someone who hangs out in a bunch of different language communities, I see two needs driving unnecessary diversity in build/package systems: 1. Language implementors see that they are serving multiple platforms (debian, red hat, bsd, windows, macos, ...), each of which has its own native packaging system, with its own way of expressing dependencies. The bad idea: invent a new system which works across all these platforms but serves only one language. This path was the genesis of 'Lua rocks', for example. And although I can't speak of Ruby and Java of my own knowledge, I suspect that Ruby gems and Java beans are similar. I don't really understand Cabal, but to the degree that I do, Cabal fills a similar role for Haskell. 2. The technique of 'smart recompilation', described in a 1986 journal article by Walter Tichy (who also invented RCS), has (again to my knowledge) has been reinvented again and again for one language after another---it has *never* been packaged as a reusable framework. I know of two valiant efforts: Clemm and Osterweil's "Odin" build tool and Blume and Appel's Compilation Manager. But the Odin people never really had a programming-language background, and Geoff Clemm was the only one who could extend the system. And the Compilation Manager, while really interesting, didn't make it obvious how to use with another compiler---in fact I'm not sure if the hooks to support smart recompilation were even exported. I also see repeatedly that the distinction between the build system and packaging system is blurry: both have to know about build targets, dependencies, and so on. At the time of the wonderful GHC Hackathon in Portland, where the GHC API was first introduced to the public, I urged Simon PJ to consider taking ghc --make and generalising it to support other languages. I still think this would be a good project. > There are tools to convert Cabal packages to native packages for rpm, > deb, ebuild and arch. The Cabal format was designed to allow this > translation. This includes dependencies on C libs and external programs. I think this is an essential property for any language-dependent packaging system to be successful. I think this is a very good path for Haskell, even though Cabal is a work in progress. What I like is that it overcomes an impedance mismatch: * The developer of a Haskell package is presented with *one* packaging interface (Cabal), which will create a package native to any widely used platform. * The client of a Haskell package treats it like any other native package: rpm, apt-get, emerge, or InstallShield just *work*---Haskell programs are not marginalized. Of course this model puts a heavy weight on the shoulders of the Cabal team, but given the current state of play, I don't see how it is possible to do better for developers and users. It's certainly better than the 'Lua rocks' model, which requires the end user to run both the platform-native packaging system *and* the Lua rocks packaging system. Such an outcome for Haskell is to be avoided at all costs. Norman From nr at eecs.harvard.edu Tue Aug 12 14:57:52 2008 From: nr at eecs.harvard.edu (Norman Ramsey) Date: Tue Aug 12 14:57:12 2008 Subject: Build system idea In-Reply-To: <48A161DA.3010106@gmail.com> (sfid-H-20080812-061316-+99.29-1@multi.osbf.lua) References: <48A161DA.3010106@gmail.com> (sfid-H-20080812-061316-+99.29-1@multi.osbf.lua) Message-ID: <20080812185753.9468C1383C3@drdoom.eecs.harvard.edu> > Simon PJ and I had a talk about the build system earlier today, I thought > I'd float the idea we discussed... > I propose we do this: > > - Extract the code from Cabal that generates Makefiles, and treat it as > part of the GHC build system. Rather than generating a Makefile > complete with build rules, we generate a Makefile that just > has the package-specific metadata (list of modules, etc.), and put > the code to actually build the package in the GHC build system. > > This means we still get to use 'make', we still get to use the .cabal files > as metadata, but the build system is more private to GHC, more extensible, > and hopefully more understandable and modifiable... > > ... I'm interested in whether anyone thinks this idea is worth > persuing, or whether there are better alternatives. Simon, This direction sounds very promising. I hope you will keep us posted. Norman From isaacdupree at charter.net Tue Aug 12 15:17:59 2008 From: isaacdupree at charter.net (Isaac Dupree) Date: Tue Aug 12 15:17:15 2008 Subject: Version control systems In-Reply-To: <62845DD1-279E-4D68-BA9B-586266DF7A4A@googlemail.com> References: <48981C03.10908@gmail.com> <20080806051232.GD17673@scytale.galois.com> <1218016430.7661.189.camel@localhost> <9d4d38820808060331h4758c8a4y2bc6e79d14b8ae3d@mail.gmail.com> <18DB9581-AA5B-433C-9036-34EC2674C2CB@cse.unsw.edu.au> <20080808130329.GA15063@matrix.chaos.earth.li> <5FEA1F32-9C34-4888-A5BE-D0460D55C307@cse.unsw.edu.au> <48A05827.5020200@gmail.com> <638ABD0A29C8884A91BC5FB5C349B1C32AE8066602@EA-EXMSG-C334.europe.corp.microsoft.com> <62845DD1-279E-4D68-BA9B-586266DF7A4A@googlemail.com> Message-ID: <48A1E1E7.1000203@charter.net> Thomas Schilling wrote: > I encourage everyone to add useful tips and examples both from users who > already use Git and later on, once we have gathered more experience. I > believe that Git has some features which can improve our productivity > and I'd like this page to also collect tips how to do so. what about `darcs send --dry-run`? It's not perfect, but I use it in my old repos in conjunction with `darcs wh [-l]` to find out what of value I'd lose by deleting an old checkout. (e.g., patches merged into HEAD aren't of value. But they still aren't of value even if they've been amend-recorded, rewritten, or equivalent by simon/ian/etc., but Darcs can't tell this, unfortunately.) -Isaac From tensor5 at gmail.com Tue Aug 12 15:36:12 2008 From: tensor5 at gmail.com (Nicola Squartini) Date: Tue Aug 12 15:35:31 2008 Subject: How to produce a statically linked binary with GHC? Message-ID: <2e981ed0808121236i25ce6209jf7894d2af3ac3422@mail.gmail.com> It seems that the -static flag serves a different purpose: according to the GHC manual it forces the compiler use the static Haskell libraries, but the resulting binary is still dynamically linked to the C libraries. What is the correct flag to create a static binary? Thanks Best Regards Nicola -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20080812/9daaee16/attachment.htm From leather at cs.uu.nl Tue Aug 12 15:43:47 2008 From: leather at cs.uu.nl (Sean Leather) Date: Tue Aug 12 15:43:07 2008 Subject: Version control systems In-Reply-To: <20080812185548.E97CC1383C3@drdoom.eecs.harvard.edu> References: <48981C03.10908@gmail.com> <20080808130329.GA15063@matrix.chaos.earth.li> <5FEA1F32-9C34-4888-A5BE-D0460D55C307@cse.unsw.edu.au> <48A05827.5020200@gmail.com> <20080811212229.GA11669@petunia.outback.escape.de> <20080811214031.GH18593@scytale.galois.com> <48A0C80E.7010205@areta.org> <1218508554.7661.416.camel@localhost> <20080812185548.E97CC1383C3@drdoom.eecs.harvard.edu> Message-ID: <3c6288ab0808121243x61a1c29bt8422b7bfd8e7527a@mail.gmail.com> Norman Ramsey wrote: > At the time of the wonderful GHC Hackathon in Portland, where the GHC > API was first introduced to the public, I urged Simon PJ to consider > taking ghc --make and generalising it to support other languages. > I still think this would be a good project. > As well as supporting any mix of languages (and platforms, since it's often difficult to separate the two). I would love to see such a tool! As flexible as make if necessary, but as easy as doing nothing if possible. Sean -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20080812/7e9f4ea3/attachment.htm From dons at galois.com Tue Aug 12 16:21:38 2008 From: dons at galois.com (Don Stewart) Date: Tue Aug 12 16:20:57 2008 Subject: How to produce a statically linked binary with GHC? In-Reply-To: <2e981ed0808121236i25ce6209jf7894d2af3ac3422@mail.gmail.com> References: <2e981ed0808121236i25ce6209jf7894d2af3ac3422@mail.gmail.com> Message-ID: <20080812202138.GE23698@scytale.galois.com> tensor5: > It seems that the -static flag serves a different purpose: according to > the GHC manual it forces the compiler use the static Haskell libraries, > but the resulting binary is still dynamically linked to the C libraries. > What is the correct flag to create a static binary? Thanks Pass -optl-static to GHC. -- Don From kili at outback.escape.de Tue Aug 12 16:29:03 2008 From: kili at outback.escape.de (Matthias Kilian) Date: Tue Aug 12 16:29:44 2008 Subject: Version control systems In-Reply-To: <48A16D19.40800@gmail.com> References: <48981C03.10908@gmail.com> <20080806051232.GD17673@scytale.galois.com> <1218016430.7661.189.camel@localhost> <9d4d38820808060331h4758c8a4y2bc6e79d14b8ae3d@mail.gmail.com> <18DB9581-AA5B-433C-9036-34EC2674C2CB@cse.unsw.edu.au> <20080808130329.GA15063@matrix.chaos.earth.li> <5FEA1F32-9C34-4888-A5BE-D0460D55C307@cse.unsw.edu.au> <48A05827.5020200@gmail.com> <20080811212229.GA11669@petunia.outback.escape.de> <48A16D19.40800@gmail.com> Message-ID: <20080812202903.GA10480@petunia.outback.escape.de> On Tue, Aug 12, 2008 at 11:59:37AM +0100, Simon Marlow wrote: > >Well, at least the Makefile creation was a step (the first step?) > >into the wrong direction, IMHO. I'll run a GHC build to get some > >of those generated Makefiles and followup on cvs-ghc, but for a > >starter, Cabal shouldn't know anything about implementation-specific > >internal build systems; instead it should rely only on it's own > >metadata. > > I'm not completely sure, but I think you may have misunderstood how > Cabal's makefile generation currently works. It has no specific knowledge > of GHC's build system, and it does rely on its own metadata. I mean the GHC-specific template used for building the Makefile (Distribution/Simple/GHC/Makefile.in) and the function `makefile` in Distribution/Simple/GHC.hs (this function even spills out some some make rules in addition to what's in Makefile.in, which looks very wrong to me). Yes, it relies only on the Cabal metadata, but the output is a Makefile only useful for building GHC. It'd be better to be able to run $ ./Setup mkmetadata -prefix foo- which just produces some simple variable declarations like foo-impl-ghc-build-depends = rts foo-impl-ghc-exposed-modules = Data.Generics Data.Generics.Aliases ... ... foo-exposed-modules = Control.Applicative Control.Arrow ... ... foo-c-sources = cbits/PrelIOUtils.c cbits/WCsubst.c ... ... foo-windows-extra-libaries = wsock32 msvcrt kernel32 user32 shell32 foo-extensions = CPP foo-ghc-options = -package-name base foo-nhc98-options = -H4M -K3M Basically, the .cabal file is just converted into some other format that may be included by another Makefile. And since it's a really simple output format, it could even be used by different implementations of make(1) or even other build tools. The `foo-' prefix just shields variables in the including Makefile. Take this output, write it to some cabalmetadata.mk, and then use a (GHC-specific) Makefile copied over into all library directories that does an include cabalmetadata.mk ... GHC_OPTS += $(foo-ghc-options) EXPOSED_MODULES = $(foo-exposed-modules) $(foo-impl-ghc-exposed-modules) EXTRA_LIBS = $(foo-extra-libraries) $(foo-$(HostOS_CPP)-extra-libraries) Thus, Cabal dumps the metadata, without knowing how it's used. All the remaining stuff are some (implementation specific) Makefiles relying on recursive variable expansion. I'll implement this for GHC when I've a little bit more spare time (in three or four weeks). > (in my other > message I'm suggesting moving the Makefile generation into GHC's build > system so that it could be made specific to GHC, though). Generated files should be as simple, primitive and portable as possible. Generating complete Makefiles make things more difficult. And it doesn't matter wether they're generated by Cabal or by GHC's build system. If you've to tweak the build system, you don't want to tweak generators but just an existing Makefile. > > Implementation-specific stuff (such as how to run the > >compiler) should be supplied by the implementation, not by Cabal. > > This is what makes me unsure. Implementation of what? The Haskell compiler. Or, to be more exact, the Cabal library shipped with the Haskell compiler (or some supplementary compiler-specific library -- I didn't think much about this part yet). However, my main concern is the usage of Cabal from within the GHC build system, so please just forget this part ;-) > Are you suggesting > a redesign of Cabal, or just changing the way something works? I don't think that a large redesign is necessary. It should just try to be as implementation-agnostic as possible. Ciao, Kili -- do yourself a favor and let the le(4)s rot on the junkpile of history... -- Henning Brauer From kili at outback.escape.de Tue Aug 12 16:37:16 2008 From: kili at outback.escape.de (Matthias Kilian) Date: Tue Aug 12 16:39:54 2008 Subject: Version control systems In-Reply-To: <20080812202903.GA10480@petunia.outback.escape.de> References: <20080806051232.GD17673@scytale.galois.com> <1218016430.7661.189.camel@localhost> <9d4d38820808060331h4758c8a4y2bc6e79d14b8ae3d@mail.gmail.com> <18DB9581-AA5B-433C-9036-34EC2674C2CB@cse.unsw.edu.au> <20080808130329.GA15063@matrix.chaos.earth.li> <5FEA1F32-9C34-4888-A5BE-D0460D55C307@cse.unsw.edu.au> <48A05827.5020200@gmail.com> <20080811212229.GA11669@petunia.outback.escape.de> <48A16D19.40800@gmail.com> <20080812202903.GA10480@petunia.outback.escape.de> Message-ID: <20080812203716.GA8944@petunia.outback.escape.de> On Tue, Aug 12, 2008 at 10:29:03PM +0200, Matthias Kilian wrote: > Basically, the .cabal file is just converted into some other format > that may be included by another Makefile. Oops! I again read your (SimonM's) proposal on changing Cabal and the GHC build system in exactly this way. Sorry for the noise. Ciao, Kili From chak at cse.unsw.edu.au Tue Aug 12 20:27:38 2008 From: chak at cse.unsw.edu.au (Manuel M T Chakravarty) Date: Tue Aug 12 20:27:03 2008 Subject: Build system idea In-Reply-To: <1218539353.7661.452.camel@localhost> References: <48A161DA.3010106@gmail.com> <1218539353.7661.452.camel@localhost> Message-ID: Duncan Coutts: > On Tue, 2008-08-12 at 11:11 +0100, Simon Marlow wrote: > >> I propose we do this: >> >> - Extract the code from Cabal that generates Makefiles, and treat >> it as >> part of the GHC build system. Rather than generating a Makefile >> complete with build rules, we generate a Makefile that just >> has the package-specific metadata (list of modules, etc.), and put >> the code to actually build the package in the GHC build system. > > As you know, I've been trying to get rid of that code ever since it > arrived :-) > >> It will probably mean that we have a tighter dependency on Cabal, >> because >> we use it as a library rather than a black box; but hopefully we >> can keep >> our branch of Cabal more stable and not have to update it so often. > > If you don't need to update so often it would make life easier for > Cabal > hackers and Manuel would be pleased :-) Yes! >> Anyway, this is an idea that I think is interesting. Obviously it >> needs a >> lot more fleshing out to be a real proposal, but I'm interested in >> whether >> anyone thinks this idea is worth persuing, or whether there are >> better >> alternatives. I think this is definitely an interesting idea. At the moment, it seems to me that all the metadata handling of Cabal is what's most useful to GHC, whereas the actual build procedure and its inflexibility causes a lot of grief, especially if you want to do something non-standard. The proposed idea would pick the best of both worlds (Cabal's metadata handling and make's build flexibility plus the fact that many more people know how to tweak makefiles even if it is a pain, but its pretty well understood pain). Manuel From chak at cse.unsw.edu.au Tue Aug 12 20:34:57 2008 From: chak at cse.unsw.edu.au (Manuel M T Chakravarty) Date: Tue Aug 12 20:34:37 2008 Subject: Version control systems In-Reply-To: <638ABD0A29C8884A91BC5FB5C349B1C32AE806640A@EA-EXMSG-C334.europe.corp.microsoft.com> References: <48981C03.10908@gmail.com> <20080806051232.GD17673@scytale.galois.com> <1218016430.7661.189.camel@localhost> <9d4d38820808060331h4758c8a4y2bc6e79d14b8ae3d@mail.gmail.com> <18DB9581-AA5B-433C-9036-34EC2674C2CB@cse.unsw.edu.au> <20080808130329.GA15063@matrix.chaos.earth.li> <5FEA1F32-9C34-4888-A5BE-D0460D55C307@cse.unsw.edu.au> <48A05827.5020200@gmail.com> <20080811172735.GA13912@soi.city.ac.uk> <99278BE4-C737-4349-91F1-78A74D83734E@cse.unsw.edu.au> <638ABD0A29C8884A91BC5FB5C349B1C32AE806640A@EA-EXMSG-C334.europe.corp.microsoft.com> Message-ID: <6AC4D8F1-D0BE-49A4-8E10-62945BB7639A@cse.unsw.edu.au> Simon Peyton-Jones: > | It is worth pointing out that I *never* validate against ghc head > when > | I commit to the core libraries. > > I think that's perfectly reasonable for the reasons you explain. Sorry, but I think the only reason its halfway acceptable is that Malcolm didn't break the GHC build yet. If he does, I'll be screaming as loudly as for anybody else. What Malcolm is basically saying is that he doesn't contribute to the functionality of the boot libraries, he simply makes sure they compile with nhc98. That's a valuable contribution, of course, but to be honest, I don't think its a valid reason for us to go to the trouble of having two vcs for ghc. Manuel From chak at cse.unsw.edu.au Tue Aug 12 20:39:25 2008 From: chak at cse.unsw.edu.au (Manuel M T Chakravarty) Date: Tue Aug 12 20:38:48 2008 Subject: Version control systems In-Reply-To: <20080812115344.GB17581@matrix.chaos.earth.li> References: <20080806051232.GD17673@scytale.galois.com> <1218016430.7661.189.camel@localhost> <9d4d38820808060331h4758c8a4y2bc6e79d14b8ae3d@mail.gmail.com> <18DB9581-AA5B-433C-9036-34EC2674C2CB@cse.unsw.edu.au> <20080808130329.GA15063@matrix.chaos.earth.li> <5FEA1F32-9C34-4888-A5BE-D0460D55C307@cse.unsw.edu.au> <48A05827.5020200@gmail.com> <20080811172735.GA13912@soi.city.ac.uk> <99278BE4-C737-4349-91F1-78A74D83734E@cse.unsw.edu.au> <20080812115344.GB17581@matrix.chaos.earth.li> Message-ID: Ian Lynagh: > On Tue, Aug 12, 2008 at 10:10:31AM +0100, Malcolm Wallace wrote: >> >> On 12 Aug 2008, at 01:35, Manuel M T Chakravarty wrote: >>> Ah, good point! Changing ghc to git means *all* developers of boot >>> libraries need to use git *regardless* of what repo format the boot >>> libraries are in. After all, they need to validate against the >>> current ghc head before pushing. >> >> It is worth pointing out that I *never* validate against ghc head >> when >> I commit to the core libraries. > > Also, all of the people who send us patches don't need to validate > (and > I suspect most of them don't), as we validate the patches before > pushing > them. Well, its up to you whether you want to validate for other people, but I don't think that is the right policy. Everybody (including Malcolm) should validate. If you contribute code to the linux kernel, comprehensive testing of the code is a requirement, too. It's not as if it were a strange requirement of GHC as an open source project to ask people to test their code properly. In fact, I even tell my first year students that they should test their code properly. Maybe we should hand books to introductory software engineering out to potential ghc and library contributors. (Sorry to get cynic, but I can't believe that we are even discussing that.) Manuel From chak at cse.unsw.edu.au Tue Aug 12 20:49:41 2008 From: chak at cse.unsw.edu.au (Manuel M T Chakravarty) Date: Tue Aug 12 20:49:06 2008 Subject: Version control systems In-Reply-To: <20080812113112.GA17581@matrix.chaos.earth.li> References: <18DB9581-AA5B-433C-9036-34EC2674C2CB@cse.unsw.edu.au> <20080808130329.GA15063@matrix.chaos.earth.li> <5FEA1F32-9C34-4888-A5BE-D0460D55C307@cse.unsw.edu.au> <20080809190651.GC3902@scytale.galois.com> <36A0EEA6-5E34-4A1A-A008-7F847D84A1E2@cs.york.ac.uk> <20080809225624.BDD6613833F@drdoom.eecs.harvard.edu> <20080810113200.GA16357@matrix.chaos.earth.li> <20080811001751.28DA31383C3@drdoom.eecs.harvard.edu> <20080812113112.GA17581@matrix.chaos.earth.li> Message-ID: <24AD8609-8644-4AEA-9A56-E5A603915A95@cse.unsw.edu.au> Ian, I completely agree with you. I love the darcs vcs model, too. However, we have three discussions here: (1) Do we want darcs vcs model? Except Thomas Schilling, who seems to be dead set to get rid of darcs, everybody who voiced their opinion seems to be in favour of the darcs model. (2) Is the current implementation of darcs up to a project the size of ghc? Due to problems in the past & performance regressions with darcs2, a serious number of (important) people believe that the current implementation is not good enough. (3) If we change the vcs for the ghc repo, do we change the vcs for the boot libs, too. This is just an open-source project maintenance question. It has nothing to do with which vcs is better. This is the only point I have been arguing: *if* GHC's repo changes, all boot lib repos must change, too. Manuel Ian Lynagh: > On Sun, Aug 10, 2008 at 08:17:50PM -0400, Norman Ramsey wrote: >>> On Sat, Aug 09, 2008 at 06:56:23PM -0400, Norman Ramsey wrote: >>>> >>> personally I would much prefer to see money spent on making darcs >>> better, for reasons I won't repeat again. >> >> I missed them and wouldn't mind receiving a private note. > > OK, I'll send to the list so that I have somewhere convenient to point > people if this comes up in the future: > > * A lot of darcs's functionality could be refactored into generally > usable Haskell libraries, e.g. LCS-finding, downloading-with-libcurl. > > * darcs was once a flagship Haskell application, supporting the idea > that Haskell can be used in the real world. That image has mostly > faded away now due to the problems it has, but I think we can get it > back if we can get a high quality darcs out there. That would be good > for the community's image. > > * darcs has (in my opinion, at least) a much simpler, more intuitive > interface than the other version control systems. I don't think I'm > alone here, as I think this is where a lot of the resistance against > moving to git is coming from. > > * I think darcs is the Obvious, Right way to do version control. > Phil Wadler (at least, I think it was him; and probably many others > too) has said that the lambda calculus is universal, in the sense > that > if we were to meet a sufficiently advanced alien culture, it is > almost > inconceivable that they would not have also discovered the lambda > calculus. Darcs-style patch theory, before conflicting patches are > introduced, falls into the same category in my opinion. (I'm not yet > sure if it can be extended to include some definition of conflictors > too). By contrast, the heuristics and multiple merge algorithms of > other systems feels very ad-hoc. > > > Thanks > Ian From rl at cse.unsw.edu.au Tue Aug 12 23:31:55 2008 From: rl at cse.unsw.edu.au (Roman Leshchinskiy) Date: Tue Aug 12 23:31:20 2008 Subject: Build system idea In-Reply-To: <48A161DA.3010106@gmail.com> References: <48A161DA.3010106@gmail.com> Message-ID: <061FA30C-4326-4B65-A80F-096593C81D6C@cse.unsw.edu.au> On 12/08/2008, at 20:11, Simon Marlow wrote: > - Extract the code from Cabal that generates Makefiles, and treat it > as > part of the GHC build system. Rather than generating a Makefile > complete with build rules, we generate a Makefile that just > has the package-specific metadata (list of modules, etc.), and put > the code to actually build the package in the GHC build system. Sounds good. It would be nice if the .cabal parser from Cabal could be made into a separate, stable library which ghc (and nhc?) could use. This makes me wonder, though. Wouldn't this model make more sense for Cabal in general than the current approach of duplicating the functionality of autoconf, make and other stuff? If it works ghc, it ought to work for other projects, too. Cabal as a preprocessor seems much more attractive to me than as a universal build system. Roman From iavor.diatchki at gmail.com Wed Aug 13 00:04:12 2008 From: iavor.diatchki at gmail.com (Iavor Diatchki) Date: Wed Aug 13 00:03:33 2008 Subject: Version control systems In-Reply-To: <24AD8609-8644-4AEA-9A56-E5A603915A95@cse.unsw.edu.au> References: <18DB9581-AA5B-433C-9036-34EC2674C2CB@cse.unsw.edu.au> <20080809190651.GC3902@scytale.galois.com> <36A0EEA6-5E34-4A1A-A008-7F847D84A1E2@cs.york.ac.uk> <20080809225624.BDD6613833F@drdoom.eecs.harvard.edu> <20080810113200.GA16357@matrix.chaos.earth.li> <20080811001751.28DA31383C3@drdoom.eecs.harvard.edu> <20080812113112.GA17581@matrix.chaos.earth.li> <24AD8609-8644-4AEA-9A56-E5A603915A95@cse.unsw.edu.au> Message-ID: <5ab17e790808122104l31613b54ka91861e7ab34047b@mail.gmail.com> Hello, On Tue, Aug 12, 2008 at 5:49 PM, Manuel M T Chakravarty wrote: > Ian, I completely agree with you. I love the darcs vcs model, too. > However, we have three discussions here: > > (1) Do we want darcs vcs model? > > Except Thomas Schilling, who seems to be dead set to get rid of darcs, > everybody who voiced their opinion seems to be in favour of the darcs model. I also don't think that the darcs model has much to offer over git, in fact I find that it lacks some useful features (not counting a reliable implementation). Examples include good support for branching, and being able to easily determine the version of the software that is in a repository (git uses a hash of the content to identify the current state, so it is easy to check if we two developers have the same version of the content). By the way, git's UI is really not as bad as people seem to think. For everyday development "git gui" works very well, and provides a nice GUI that lets you see what you have modified, choose what you want to record, and push/pull from other repos. -Iavor From bulat.ziganshin at gmail.com Wed Aug 13 02:06:10 2008 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Wed Aug 13 02:10:47 2008 Subject: Version control systems In-Reply-To: References: <20080806051232.GD17673@scytale.galois.com> <1218016430.7661.189.camel@localhost> <9d4d38820808060331h4758c8a4y2bc6e79d14b8ae3d@mail.gmail.com> <18DB9581-AA5B-433C-9036-34EC2674C2CB@cse.unsw.edu.au> <20080808130329.GA15063@matrix.chaos.earth.li> <5FEA1F32-9C34-4888-A5BE-D0460D55C307@cse.unsw.edu.au> <48A05827.5020200@gmail.com> <20080811172735.GA13912@soi.city.ac.uk> <99278BE4-C737-4349-91F1-78A74D83734E@cse.unsw.edu.au> <20080812115344.GB17581@matrix.chaos.earth.li> Message-ID: <1037054187.20080813100610@gmail.com> Hello Manuel, Wednesday, August 13, 2008, 4:39:25 AM, you wrote: > Well, its up to you whether you want to validate for other people, but > I don't think that is the right policy. Everybody (including Malcolm) > should validate. as far as we have people validating patches for their platforms (Igloo for GHC, Malcolm for nhc...) this reduces amount of time required to support things working. ideal solutions are too expensive for real world :) -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From chak at cse.unsw.edu.au Wed Aug 13 02:19:37 2008 From: chak at cse.unsw.edu.au (Manuel M T Chakravarty) Date: Wed Aug 13 02:18:57 2008 Subject: Version control systems In-Reply-To: <48A1477F.4060003@gmail.com> References: <48981C03.10908@gmail.com> <20080806051232.GD17673@scytale.galois.com> <1218016430.7661.189.camel@localhost> <9d4d38820808060331h4758c8a4y2bc6e79d14b8ae3d@mail.gmail.com> <18DB9581-AA5B-433C-9036-34EC2674C2CB@cse.unsw.edu.au> <20080808130329.GA15063@matrix.chaos.earth.li> <5FEA1F32-9C34-4888-A5BE-D0460D55C307@cse.unsw.edu.au> <48A05827.5020200@gmail.com> <48A1477F.4060003@gmail.com> Message-ID: <36972DFA-9091-4035-8E39-EE0F23F3D028@cse.unsw.edu.au> Simon Marlow: > Manuel M T Chakravarty wrote: >> To be honest, if you ask me, I'd go back to the old makefile based >> system and remove Cabal from everywhere except building of the >> library packages. > > I wouldn't object to dropping the use of Cabal for other tools in > the build tree; the reasons for using it elsewhere are certainly not > as compelling as for packages. > > Ian, I realise this means backing out a lot of the work you've been > doing recently, and it would mean that we'd lose a lot of time in > the runup to 6.10.1, but perhaps it's a step that we need to take to > get us back on the right track again? I do realise that this would mean backing out a lot of Ian recent work, and that's why I haven't proposed going back to the old system before you explicitly asked. However, I am increasingly getting the feeling that the move to Cabal was pre-mature, and the overall loss will be minimised by backing out now. In a sense, it was an interesting experiment and it should still be useful to the development of Cabal. In fact, I see no reason why the experiment cannot be continued on a branch. Who knows, maybe Cabal is sufficiently mature in a year to make a switch worthwhile? I just object to using the whole GHC developer community as guinea pigs. Manuel From chak at cse.unsw.edu.au Wed Aug 13 02:35:42 2008 From: chak at cse.unsw.edu.au (Manuel M T Chakravarty) Date: Wed Aug 13 02:35:02 2008 Subject: Version control systems In-Reply-To: <20080812121835.GA18185@matrix.chaos.earth.li> References: <48981C03.10908@gmail.com> <20080806051232.GD17673@scytale.galois.com> <1218016430.7661.189.camel@localhost> <9d4d38820808060331h4758c8a4y2bc6e79d14b8ae3d@mail.gmail.com> <18DB9581-AA5B-433C-9036-34EC2674C2CB@cse.unsw.edu.au> <20080808130329.GA15063@matrix.chaos.earth.li> <5FEA1F32-9C34-4888-A5BE-D0460D55C307@cse.unsw.edu.au> <48A05827.5020200@gmail.com> <20080812121835.GA18185@matrix.chaos.earth.li> Message-ID: <0E342A89-8750-49F6-AD6A-7EA64300134C@cse.unsw.edu.au> Ian Lynagh: > On Tue, Aug 12, 2008 at 10:20:14AM +1000, Manuel M T Chakravarty > wrote: >> >> To be honest, if you ask me, I'd go back to the old makefile based >> system and remove Cabal from everywhere except building of the >> library >> packages. >> >> Manuel >> >> PS: Just for some more collateral damage. Did anybody check whether >> the Mac OS installer support and the -unfortunately, only partially >> working- support to compile for older OS X versions that I added to >> the *makefiles* still works with the Cabal-based system? I doubt it. >> Took me quite a while to get all this going, and I am not very well >> motivated to spend a lot of time to figure out how it might work with >> Cabal. IMHO using Cabal for anything but the libraries was a step >> back for no good reason. > > Do you mean the "rebuilding the tools with stage2" stuff? If so, > that's > an interesting example to pick, as that was the impetus behind > changing > how the build system worked for all the non-libraries/ghc. Rebuilding with stage1 was already needed to build GHC with a builtin readline. In general, it is a bad idea to build distributed binaries of Haskell programs with the *bootstrap compiler*. It must be done with the stage1 compiler. (If you are unsure why, I'll happily elaborate.) What I was mainly refer to is the building of GHC.framework with xcodebuild and the accompanying packing with packagemaker. Building for older versions of Mac OS X requires the MACOSX_DEPLOYMENT_TARGET and related infrastructure. > Those changes made the build non-idempotent: we would build something > with the bootstrapping compiler, build some other stuff, then come > back, > clean it, and build it again with the in-tree compiler. This was a > little annoying at the best of times, as e.g. rerunning make at the > top > level would needlessly rebuild some stuff. > > However, when my local changes meant that programs built by GHC > segfaulted, it was especially irritating to find that after > (hopefully) > fixing the bug I couldn't just run make in compiler/ or rts/, because > ghc-pkg etc now just segfaulted! > > It was at that point that I half-reverted the changes, and later I > reimplemented something similar using Cabal. Now we make, for example, > ghc-pkg with the bootstrapping compiler in utils/ghc-pkg/dist-inplace, > and then later on we make it with the stage1 compiler in > utils/ghc-pkg/dist-install. It's of course much cleaner to build inplace versions of everything with the bootstrap compiler and separate distributeable versions with stage1. I think we briefly talked about that during the run up to 6.8.3. > To answer your actual question: No, not having OS X yet I haven't > tested > it, but I did make an effort to keep it working. In mk/cabal- > flags.mk we > say: > > USE_STAGE_CONFIGURE_FLAGS = \ > ... > $(addprefix --cc-option=,$(MACOSX_DEPLOYMENT_CC_OPTS)) \ > $(addprefix --ld-option=,$(MACOSX_DEPLOYMENT_LD_OPTS)) > > which will hopefully do the trick, and (IMO) in a much cleaner, more > maintainable way than would have been possible with the old build > system. I appreciate that you tried to preserve it, but things like those usually don't work until explicitly tested and debugged. I think this illustrates the issue I am having with the current process. I don't think large changes that have not been properly tested should be committed to the head. I appreciate that you cannot test everything for every patch and don't have all the platforms at hand. That's why major rejigging of the build system should be done on a branch. Then, you can ask other people to test it, once it is all working well for you. Ripping the guts out of the head and leaving some of them on the floor just means everybody else is going to trip over them. Manuel From chak at cse.unsw.edu.au Wed Aug 13 02:54:32 2008 From: chak at cse.unsw.edu.au (Manuel M T Chakravarty) Date: Wed Aug 13 02:54:17 2008 Subject: Version control systems In-Reply-To: <638ABD0A29C8884A91BC5FB5C349B1C32AE8066602@EA-EXMSG-C334.europe.corp.microsoft.com> References: <48981C03.10908@gmail.com> <20080806051232.GD17673@scytale.galois.com> <1218016430.7661.189.camel@localhost> <9d4d38820808060331h4758c8a4y2bc6e79d14b8ae3d@mail.gmail.com> <18DB9581-AA5B-433C-9036-34EC2674C2CB@cse.unsw.edu.au> <20080808130329.GA15063@matrix.chaos.earth.li> <5FEA1F32-9C34-4888-A5BE-D0460D55C307@cse.unsw.edu.au> <48A05827.5020200@gmail.com> <638ABD0A29C8884A91BC5FB5C349B1C32AE8066602@EA-EXMSG-C334.europe.corp.microsoft.com> Message-ID: <4492B45B-6699-4444-87A9-83F0595B4EB7@cse.unsw.edu.au> Simon Peyton-Jones: > 2. The version control system (VCS) > > GHC needs "core libraries" without which it cannot be built. It is > obviously highly desirable that a developer can build GHC with just > one VCS, which suggests that the core libraries should be in git too. > But those same core libraries are used by nhc98 and Hugs (I think > that's all), and the last thing we want to do is to impose new costs > on other implementations. What are these costs? I don't believe there are serious costs for those developers. Malcolm told us that all he contributes to the core libraries is fixing them for nhc when they break. He doesn't even validate, so I am sure he doesn't use branches or anything similar. The cost for him is to learn how to get, record & push with git. AFAIK, the only person who works on Hugs is Ross. He contributes to GHC, too, and hopefully validates his library patches before pushing. So, he'll have to learn to use git anyway. > It's unclear exactly what to do about this. The most plausible > possibility is to keep the core libraries that are shared with other > implementations in darcs as now, and mirror them in git for GHC > developers. That will impose pain on GHC developers to keep the git > stuff in sync with the darcs master copies; but at least other > developers would be unaffected. Everybody who contributes to the boot/core libraries needs to validate their patches. If the GHC version of the libraries is in git, then all library code needs to be validated against the git version of the libraries before it can enter the master repository. I don't see how that makes anything easier for anybody. As I said before, I believe there is exactly one sane solution: all boot libraries use the same vcs as ghc. Manuel From johan.tibell at gmail.com Wed Aug 13 03:09:00 2008 From: johan.tibell at gmail.com (Johan Tibell) Date: Wed Aug 13 03:08:18 2008 Subject: Version control systems In-Reply-To: <24AD8609-8644-4AEA-9A56-E5A603915A95@cse.unsw.edu.au> References: <18DB9581-AA5B-433C-9036-34EC2674C2CB@cse.unsw.edu.au> <20080809190651.GC3902@scytale.galois.com> <36A0EEA6-5E34-4A1A-A008-7F847D84A1E2@cs.york.ac.uk> <20080809225624.BDD6613833F@drdoom.eecs.harvard.edu> <20080810113200.GA16357@matrix.chaos.earth.li> <20080811001751.28DA31383C3@drdoom.eecs.harvard.edu> <20080812113112.GA17581@matrix.chaos.earth.li> <24AD8609-8644-4AEA-9A56-E5A603915A95@cse.unsw.edu.au> Message-ID: <90889fe70808130009r536f8a36sdf7d6b80f7a36d72@mail.gmail.com> On Wed, Aug 13, 2008 at 2:49 AM, Manuel M T Chakravarty wrote: > Ian, I completely agree with you. I love the darcs vcs model, too. > However, we have three discussions here: > > (1) Do we want darcs vcs model? > > Except Thomas Schilling, who seems to be dead set to get rid of darcs, > everybody who voiced their opinion seems to be in favour of the darcs model. I'm also in favor of the switch to Git. The Git model has proved to be both more productive and more reliable. And the interface, as far as I'm concerned, is *better*. Cheers, Johan From simonpj at microsoft.com Wed Aug 13 03:26:23 2008 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Wed Aug 13 03:25:43 2008 Subject: Version control systems In-Reply-To: <62845DD1-279E-4D68-BA9B-586266DF7A4A@googlemail.com> References: <48981C03.10908@gmail.com> <20080806051232.GD17673@scytale.galois.com> <1218016430.7661.189.camel@localhost> <9d4d38820808060331h4758c8a4y2bc6e79d14b8ae3d@mail.gmail.com> <18DB9581-AA5B-433C-9036-34EC2674C2CB@cse.unsw.edu.au> <20080808130329.GA15063@matrix.chaos.earth.li> <5FEA1F32-9C34-4888-A5BE-D0460D55C307@cse.unsw.edu.au> <48A05827.5020200@gmail.com> <638ABD0A29C8884A91BC5FB5C349B1C32AE8066602@EA-EXMSG-C334.europe.corp.microsoft.com> <62845DD1-279E-4D68-BA9B-586266DF7A4A@googlemail.com> Message-ID: <638ABD0A29C8884A91BC5FB5C349B1C32AE80667F2@EA-EXMSG-C334.europe.corp.microsoft.com> | FWIW, I started a wiki page that tries a direct comparison between | Darcs and Git: | | http://hackage.haskell.org/trac/ghc/wiki/GitForDarcsUsers Very helpful thank you! Simon From marlowsd at gmail.com Wed Aug 13 03:36:49 2008 From: marlowsd at gmail.com (Simon Marlow) Date: Wed Aug 13 03:36:12 2008 Subject: Version control systems In-Reply-To: <4492B45B-6699-4444-87A9-83F0595B4EB7@cse.unsw.edu.au> References: <48981C03.10908@gmail.com> <20080806051232.GD17673@scytale.galois.com> <1218016430.7661.189.camel@localhost> <9d4d38820808060331h4758c8a4y2bc6e79d14b8ae3d@mail.gmail.com> <18DB9581-AA5B-433C-9036-34EC2674C2CB@cse.unsw.edu.au> <20080808130329.GA15063@matrix.chaos.earth.li> <5FEA1F32-9C34-4888-A5BE-D0460D55C307@cse.unsw.edu.au> <48A05827.5020200@gmail.com> <638ABD0A29C8884A91BC5FB5C349B1C32AE8066602@EA-EXMSG-C334.europe.corp.microsoft.com> <4492B45B-6699-4444-87A9-83F0595B4EB7@cse.unsw.edu.au> Message-ID: <48A28F11.4090307@gmail.com> Manuel M T Chakravarty wrote: > Everybody who contributes to the boot/core libraries needs to validate > their patches. If the GHC version of the libraries is in git, then all > library code needs to be validated against the git version of the > libraries before it can enter the master repository. I don't see how > that makes anything easier for anybody. > > As I said before, I believe there is exactly one sane solution: all boot > libraries use the same vcs as ghc. I don't think this completely sane :-) It's not fair or reasonable for the GHC project to require everyone else contributing to the core libraries to validate their changes against GHC. We need to be branching the shared repositories, so that we can keep the GHC branches working and sync up with the shared repositories as necessary. Morally this is the right thing; technically its a lot more difficult than not forking. What would make it much easier is for both the original shared repository and GHC's branch to be git repositories (or branches of the same repo): git is really good at having two parallel lines of development that sync occasionally. Having one in darcs and one in git would be painful, but doable. So I suggest we propose moving all the core packages to git, and we translate all those for which nobody objects to the change. For the others, we'll keep them in darcs and live with the pain. Cheers, Simon From marlowsd at gmail.com Wed Aug 13 03:47:01 2008 From: marlowsd at gmail.com (Simon Marlow) Date: Wed Aug 13 03:46:20 2008 Subject: Build system idea In-Reply-To: <061FA30C-4326-4B65-A80F-096593C81D6C@cse.unsw.edu.au> References: <48A161DA.3010106@gmail.com> <061FA30C-4326-4B65-A80F-096593C81D6C@cse.unsw.edu.au> Message-ID: <48A29175.1030907@gmail.com> Roman Leshchinskiy wrote: > On 12/08/2008, at 20:11, Simon Marlow wrote: > >> - Extract the code from Cabal that generates Makefiles, and treat it as >> part of the GHC build system. Rather than generating a Makefile >> complete with build rules, we generate a Makefile that just >> has the package-specific metadata (list of modules, etc.), and put >> the code to actually build the package in the GHC build system. > > Sounds good. It would be nice if the .cabal parser from Cabal could be > made into a separate, stable library which ghc (and nhc?) could use. > > This makes me wonder, though. Wouldn't this model make more sense for > Cabal in general than the current approach of duplicating the > functionality of autoconf, make and other stuff? If it works ghc, it > ought to work for other projects, too. Cabal as a preprocessor seems > much more attractive to me than as a universal build system. So packages would be required to provide their own build system? That sounds like it would make it a lot harder for people to just create a package that others can use. The ease of making a Cabal package has I think a lot to do with the wealth of software available on Hackage. GHC is a special case: we already need a build system for other reasons. It was a design decision early on with Cabal that we didn't want to rely on the target system having a Unix-like build environment. You might disagree with this, but it certainly has some value: a Windows user can download GHC and immediately start building and installing external packages without having to install Cygwin. Cheers, Simon From marlowsd at gmail.com Wed Aug 13 03:51:30 2008 From: marlowsd at gmail.com (Simon Marlow) Date: Wed Aug 13 03:50:50 2008 Subject: Version control systems In-Reply-To: <20080812185548.E97CC1383C3@drdoom.eecs.harvard.edu> References: <48981C03.10908@gmail.com> <20080806051232.GD17673@scytale.galois.com> <1218016430.7661.189.camel@localhost> <9d4d38820808060331h4758c8a4y2bc6e79d14b8ae3d@mail.gmail.com> <18DB9581-AA5B-433C-9036-34EC2674C2CB@cse.unsw.edu.au> <20080808130329.GA15063@matrix.chaos.earth.li> <5FEA1F32-9C34-4888-A5BE-D0460D55C307@cse.unsw.edu.au> <48A05827.5020200@gmail.com> <20080811212229.GA11669@petunia.outback.escape.de> <20080811214031.GH18593@scytale.galois.com> <48A0C80E.7010205@areta.org> <1218508554.7661.416.camel@localhost> (sfid-H-20080811-224302-+76.47-1@multi.osbf.lua) <20080812185548.E97CC1383C3@drdoom.eecs.harvard.edu> Message-ID: <48A29282.1070504@gmail.com> Norman Ramsey wrote: > I also see repeatedly that the distinction between the build system > and packaging system is blurry: both have to know about build targets, > dependencies, and so on. > > At the time of the wonderful GHC Hackathon in Portland, where the GHC > API was first introduced to the public, I urged Simon PJ to consider > taking ghc --make and generalising it to support other languages. > I still think this would be a good project. I don't want to speak for those involved, but I believe this is what the "make-like dependency framework for Cabal" SoC project is doing: http://vezzosi.blogspot.com/2008/06/my-summer-of-code-project-dependency.html Cheers, Simon From marlowsd at gmail.com Wed Aug 13 04:03:34 2008 From: marlowsd at gmail.com (Simon Marlow) Date: Wed Aug 13 04:02:51 2008 Subject: Version control systems In-Reply-To: <20080812202903.GA10480@petunia.outback.escape.de> References: <48981C03.10908@gmail.com> <20080806051232.GD17673@scytale.galois.com> <1218016430.7661.189.camel@localhost> <9d4d38820808060331h4758c8a4y2bc6e79d14b8ae3d@mail.gmail.com> <18DB9581-AA5B-433C-9036-34EC2674C2CB@cse.unsw.edu.au> <20080808130329.GA15063@matrix.chaos.earth.li> <5FEA1F32-9C34-4888-A5BE-D0460D55C307@cse.unsw.edu.au> <48A05827.5020200@gmail.com> <20080811212229.GA11669@petunia.outback.escape.de> <48A16D19.40800@gmail.com> <20080812202903.GA10480@petunia.outback.escape.de> Message-ID: <48A29556.6030608@gmail.com> Matthias Kilian wrote: > I mean the GHC-specific template used for building the Makefile > (Distribution/Simple/GHC/Makefile.in) and the function `makefile` > in Distribution/Simple/GHC.hs (this function even spills out some > some make rules in addition to what's in Makefile.in, which looks > very wrong to me). > > Yes, it relies only on the Cabal metadata, but the output is a > Makefile only useful for building GHC. Ok, this statement is plainly not true, since I can use 'cabal makefile' to build any package outside of the GHC build tree. So perhaps I've misunderstood your point? > It'd be better to be able to run > > $ ./Setup mkmetadata -prefix foo- > > which just produces some simple variable declarations like > > foo-impl-ghc-build-depends = rts > foo-impl-ghc-exposed-modules = Data.Generics Data.Generics.Aliases ... > ... > foo-exposed-modules = Control.Applicative Control.Arrow ... > ... > foo-c-sources = cbits/PrelIOUtils.c cbits/WCsubst.c ... > ... > foo-windows-extra-libaries = wsock32 msvcrt kernel32 user32 shell32 > foo-extensions = CPP > foo-ghc-options = -package-name base > foo-nhc98-options = -H4M -K3M Yes, we could use this to implement GHC's build system. It's somewhat similar to the scheme I suggested in the other thread, but more generic. I'd be completely happy to do it this way if the functionality would be useful to others outside GHC too. Cheers, Simon From rl at cse.unsw.edu.au Wed Aug 13 04:51:30 2008 From: rl at cse.unsw.edu.au (Roman Leshchinskiy) Date: Wed Aug 13 04:51:01 2008 Subject: Build system idea In-Reply-To: <48A29175.1030907@gmail.com> References: <48A161DA.3010106@gmail.com> <061FA30C-4326-4B65-A80F-096593C81D6C@cse.unsw.edu.au> <48A29175.1030907@gmail.com> Message-ID: <4D6AF7CE-B789-4021-898D-876475DEABF2@cse.unsw.edu.au> On 13/08/2008, at 17:47, Simon Marlow wrote: > Roman Leshchinskiy wrote: >> On 12/08/2008, at 20:11, Simon Marlow wrote: >>> - Extract the code from Cabal that generates Makefiles, and treat >>> it as >>> part of the GHC build system. Rather than generating a Makefile >>> complete with build rules, we generate a Makefile that just >>> has the package-specific metadata (list of modules, etc.), and put >>> the code to actually build the package in the GHC build system. >> Sounds good. It would be nice if the .cabal parser from Cabal could >> be made into a separate, stable library which ghc (and nhc?) could >> use. >> This makes me wonder, though. Wouldn't this model make more sense >> for Cabal in general than the current approach of duplicating the >> functionality of autoconf, make and other stuff? If it works ghc, >> it ought to work for other projects, too. Cabal as a preprocessor >> seems much more attractive to me than as a universal build system. > > So packages would be required to provide their own build system? > That sounds like it would make it a lot harder for people to just > create a package that others can use. The ease of making a Cabal > package has I think a lot to do with the wealth of software > available on Hackage. Of course there should be a standard build system for simple packages. It could be part of Cabal or a separate tool (for which Cabal could, again, act as a preprocessor). > GHC is a special case: we already need a build system for other > reasons. I agree. I just don't think that adding a full-fledged build system to Cabal is the solution. In my experience, huge monolithic tools which try to do everything never work well. I much prefer small, modular tools. A Haskell-based build system is an interesting project but why does it have to be a part of Cabal? > It was a design decision early on with Cabal that we didn't want to > rely on the target system having a Unix-like build environment. You > might disagree with this, but it certainly has some value: a Windows > user can download GHC and immediately start building and installing > external packages without having to install Cygwin. I agree with this decision but IIUC, this only really works for simple (wrt building) packages which don't even use configure. Making Cabal into a modular preprocessor and providing a thin wrapper for ghc -- make which can act as a target for Cabal would achieve this just as well. Roman From malcolm.wallace at cs.york.ac.uk Wed Aug 13 04:54:14 2008 From: malcolm.wallace at cs.york.ac.uk (Malcolm Wallace) Date: Wed Aug 13 04:53:34 2008 Subject: Version control systems In-Reply-To: <6AC4D8F1-D0BE-49A4-8E10-62945BB7639A@cse.unsw.edu.au> References: <48981C03.10908@gmail.com> <20080806051232.GD17673@scytale.galois.com> <1218016430.7661.189.camel@localhost> <9d4d38820808060331h4758c8a4y2bc6e79d14b8ae3d@mail.gmail.com> <18DB9581-AA5B-433C-9036-34EC2674C2CB@cse.unsw.edu.au> <20080808130329.GA15063@matrix.chaos.earth.li> <5FEA1F32-9C34-4888-A5BE-D0460D55C307@cse.unsw.edu.au> <48A05827.5020200@gmail.com> <20080811172735.GA13912@soi.city.ac.uk> <99278BE4-C737-4349-91F1-78A74D83734E@cse.unsw.edu.au> <638ABD0A29C8884A91BC5FB5C349B1C32AE806640A@EA-EXMSG-C334.europe.corp.microsoft.com> <6AC4D8F1-D0BE-49A4-8E10-62945BB7639A@cse.unsw.edu.au> Message-ID: <16ABF72C-88B8-48C7-98C7-0AF011AAAA74@cs.york.ac.uk> Manuel wrote: >> | It is worth pointing out that I *never* validate against ghc head >> when >> | I commit to the core libraries. > Sorry, but I think the only reason its halfway acceptable is that > Malcolm didn't break the GHC build yet. If he does, I'll be > screaming as loudly as for anybody else. Whilst I'm in no way saying that a working nhc98 head is anything like as important as a working ghc head, are you saying that I should scream louder everytime someone breaks nhc98 too? It is happening several times a week at the moment. It can be jolly frustrating when I have other things I could be doing. But I accept that it is simply the price to pay for keeping up-to-date with the libraries everyone else is using. Ghc has no monopoly on the "core" libraries. They are a shared resource. > to be honest, I don't think its a valid reason for us to go to the > trouble of having two vcs for ghc. Well indeed, I don't want to stand in the way of ghc. There are far more people contributing to it, so their needs have greater weight. But I am raising the libraries question, because I think it has an impact much more widely than just ghc (or Hugs or nhc98, for that matter). Git may turn out to be sufficiently easy to use that this will all seem like a storm in a teacup once the dust has settled. (I'm not filled with confidence by blog postings that say "granted, git is a usability disaster zone", and "[you] may find git to be hostile, unfriendly and needlessly complex", but those seem to be minority opinions.) Regards, Malcolm Regards, Malcolm From claus.reinke at talk21.com Wed Aug 13 05:15:22 2008 From: claus.reinke at talk21.com (Claus Reinke) Date: Wed Aug 13 05:14:44 2008 Subject: GHC project blog? (Re: Version control systems) References: <48981C03.10908@gmail.com><20080806051232.GD17673@scytale.galois.com><1218016430.7661.189.camel@localhost><9d4d38820808060331h4758c8a4y2bc6e79d14b8ae3d@mail.gmail.com><18DB9581-AA5B-433C-9036-34EC2674C2CB@cse.unsw.edu.au><20080808130329.GA15063@matrix.chaos.earth.li><5FEA1F32-9C34-4888-A5BE-D0460D55C307@cse.unsw.edu.au><48A05827.5020200@gmail.com> <638ABD0A29C8884A91BC5FB5C349B1C32AE8066602@EA-EXMSG-C334.europe.corp.microsoft.com> Message-ID: <008e01c8fd25$1edebbf0$22438351@cr3lt> >We (GHC HQ) are still learning the transition to wider participation >in building and hacking on GHC, which we *very much* welcome. Bear >with us if we don't get it right first time. We're trying! And I very much like the steps I've seen recently in explaining what you're doing (sometimes even before you're doing it;-). However, there are so many lists to choose from, and many often opinionated discussions on many of them that will bury those informative messages of yours rather quickly. So if anyone joins the world of GHC in a few weeks, they will be just as lost as everyone was before you started outlining your plans and giving high-level summaries of on-going work in more detail. Perhaps it would be useful for GHC HQ to have a GHC project blog, like other non-trivial projects that like to talk about what they are doing/planning and how the pieces fit together (for examples, see: google, opera, ..)? The follow-on discussions should still be on cvs-ghc, or on cvs-libraries, or on libraries, or on glasgow-haskell-users, or on ghc wiki or trac, or whatever the topic requires. But the original information would be collected in a single place, on a blog with rss feed to which interested parties could be refered. Given the number of things going on, I'm sure such a blog would become required reading rather quickly, even for those not subscribed to cvs-ghc, etc. Just another suggestion;-) Claus From johan.tibell at gmail.com Wed Aug 13 05:26:30 2008 From: johan.tibell at gmail.com (Johan Tibell) Date: Wed Aug 13 05:25:47 2008 Subject: Version control systems In-Reply-To: <16ABF72C-88B8-48C7-98C7-0AF011AAAA74@cs.york.ac.uk> References: <48981C03.10908@gmail.com> <20080808130329.GA15063@matrix.chaos.earth.li> <5FEA1F32-9C34-4888-A5BE-D0460D55C307@cse.unsw.edu.au> <48A05827.5020200@gmail.com> <20080811172735.GA13912@soi.city.ac.uk> <99278BE4-C737-4349-91F1-78A74D83734E@cse.unsw.edu.au> <638ABD0A29C8884A91BC5FB5C349B1C32AE806640A@EA-EXMSG-C334.europe.corp.microsoft.com> <6AC4D8F1-D0BE-49A4-8E10-62945BB7639A@cse.unsw.edu.au> <16ABF72C-88B8-48C7-98C7-0AF011AAAA74@cs.york.ac.uk> Message-ID: <90889fe70808130226y672012c1q8c4b502105cedef5@mail.gmail.com> As someone who is not contributing to the core libraries I find a few things in this discussions a bit puzzlng. - Why does NHC98 break so often? Is it because people are checking in code that is not Haskell 98 compatible? - It seems to me that implementations "share" libraries using CPP. At least there are plenty of if-defs on symbols like __HUGS__ in the implementation. That seems like a bad approach to me. It doesn't factor out the specifics of an implementation to one place but instead litters the code with it making it hard to read and change without breaking it. I would imagine that this slows down library development. You could compare it to a scenario where Windows and Linux shared their libc implementation! If it's so difficult to share code without continuously breaking the build then we're better of keeping the code separate. I might have gotten this wrong so could someone please explain to me what exactly is the problem and why we are in this situation? Thank you, Johan From marlowsd at gmail.com Wed Aug 13 05:27:04 2008 From: marlowsd at gmail.com (Simon Marlow) Date: Wed Aug 13 05:26:27 2008 Subject: GHC project blog? (Re: Version control systems) In-Reply-To: <008e01c8fd25$1edebbf0$22438351@cr3lt> References: <48981C03.10908@gmail.com><20080806051232.GD17673@scytale.galois.com><1218016430.7661.189.camel@localhost><9d4d38820808060331h4758c8a4y2bc6e79d14b8ae3d@mail.gmail.com><18DB9581-AA5B-433C-9036-34EC2674C2CB@cse.unsw.edu.au><20080808130329.GA15063@matrix.chaos.earth.li><5FEA1F32-9C34-4888-A5BE-D0460D55C307@cse.unsw.edu.au><48A05827.5020200@gmail.com> <638ABD0A29C8884A91BC5FB5C349B1C32AE8066602@EA-EXMSG-C334.europe.corp.microsoft.com> <008e01c8fd25$1edebbf0$22438351@cr3lt> Message-ID: <48A2A8E8.1030605@gmail.com> Claus Reinke wrote: > Perhaps it would be useful for GHC HQ to have a GHC project > blog, Actually we have talked about doing that, and it's highly likely we'll set one up in due course. I think it's worth letting the current discussion(s) run their course and then we'll have a set of concrete decisions to act upon, one of which will probably be to set up a blog so that GHC devs can communicate what they're up to. Cheers, Simon From malcolm.wallace at cs.york.ac.uk Wed Aug 13 06:21:53 2008 From: malcolm.wallace at cs.york.ac.uk (Malcolm Wallace) Date: Wed Aug 13 06:21:19 2008 Subject: Version control systems In-Reply-To: <90889fe70808130226y672012c1q8c4b502105cedef5@mail.gmail.com> References: <48981C03.10908@gmail.com> <20080808130329.GA15063@matrix.chaos.earth.li> <5FEA1F32-9C34-4888-A5BE-D0460D55C307@cse.unsw.edu.au> <48A05827.5020200@gmail.com> <20080811172735.GA13912@soi.city.ac.uk> <99278BE4-C737-4349-91F1-78A74D83734E@cse.unsw.edu.au> <638ABD0A29C8884A91BC5FB5C349B1C32AE806640A@EA-EXMSG-C334.europe.corp.microsoft.com> <6AC4D8F1-D0BE-49A4-8E10-62945BB7639A@cse.unsw.edu.au> <16ABF72C-88B8-48C7-98C7-0AF011AAAA74@cs.york.ac.uk> <90889fe70808130226y672012c1q8c4b502105cedef5@mail.gmail.com> Message-ID: <829BBADD-7796-4555-8CDF-75F1505073F2@cs.york.ac.uk> > - Why does NHC98 break so often? Is it because people are checking in > code that is not Haskell 98 compatible? Yes, there is a bit of that. Also, as you point out, there is quite a lot of CPP conditionally compiled code in the libraries, and I would say that it is the major contributor to breakage. It is often unclear which parts of the code are shared and which separate, so a lot of breakage arises from e.g. exporting a name that is defined for ghc only. In addition, there are some (once obscure) bugs in nhc98 that are now triggered increasingly frequently. (We can't blame anyone except nhc98 for those of course.) These include complex import renaming resolution, and contexts on pattern variables. > - It seems to me that implementations "share" libraries using CPP. > That seems like a bad approach to me. Agreed. The CPP was always intended to be as temporary as possible, with the goal to share as much as possible. One of the problems is that the primitives provided by compilers are different. Really, there should be a package below 'base' in the dependency tree, specific to each compiler, and non-shared. Then everything from base upwards would be cleaner and more portable. > If it's so difficult to share code without continuously breaking the > build then we're better of keeping the code separate. I don't agree. The only way to achieve convergence is to start from some semi-merged point, and work to eliminate the differences. Igloo is doing a fantastic job of determining the dependencies and gradually moving stuff around to enable this to happen. Regards, Malcolm From marlowsd at gmail.com Wed Aug 13 06:34:00 2008 From: marlowsd at gmail.com (Simon Marlow) Date: Wed Aug 13 06:33:24 2008 Subject: Build system idea In-Reply-To: <4D6AF7CE-B789-4021-898D-876475DEABF2@cse.unsw.edu.au> References: <48A161DA.3010106@gmail.com> <061FA30C-4326-4B65-A80F-096593C81D6C@cse.unsw.edu.au> <48A29175.1030907@gmail.com> <4D6AF7CE-B789-4021-898D-876475DEABF2@cse.unsw.edu.au> Message-ID: <48A2B898.5080701@gmail.com> Roman Leshchinskiy wrote: > Of course there should be a standard build system for simple packages. > It could be part of Cabal or a separate tool (for which Cabal could, > again, act as a preprocessor). > >> GHC is a special case: we already need a build system for other reasons. > > I agree. I just don't think that adding a full-fledged build system to > Cabal is the solution. In my experience, huge monolithic tools which try > to do everything never work well. I much prefer small, modular tools. A > Haskell-based build system is an interesting project but why does it > have to be a part of Cabal? Hmm, but you said above "there should be a standard build system for simple packages. It could be part of Cabal...". Cabal has two parts: some generic infrastructure, and a "simple" build system (under Distribution.Simple) that suffices for most packages. We distribute them together only because it's convenient; you don't have to use the simple build system if you don't want to. I think perhaps you're objecting to the fact that the "simple" build system isn't so simple, and we keep adding more functionality to it. This is true, but the alternative - forcing some packages to provide their own build system - seems worse to me. Cheers, Simon From johan.tibell at gmail.com Wed Aug 13 07:43:15 2008 From: johan.tibell at gmail.com (Johan Tibell) Date: Wed Aug 13 07:42:31 2008 Subject: Version control systems In-Reply-To: <829BBADD-7796-4555-8CDF-75F1505073F2@cs.york.ac.uk> References: <48981C03.10908@gmail.com> <48A05827.5020200@gmail.com> <20080811172735.GA13912@soi.city.ac.uk> <99278BE4-C737-4349-91F1-78A74D83734E@cse.unsw.edu.au> <638ABD0A29C8884A91BC5FB5C349B1C32AE806640A@EA-EXMSG-C334.europe.corp.microsoft.com> <6AC4D8F1-D0BE-49A4-8E10-62945BB7639A@cse.unsw.edu.au> <16ABF72C-88B8-48C7-98C7-0AF011AAAA74@cs.york.ac.uk> <90889fe70808130226y672012c1q8c4b502105cedef5@mail.gmail.com> <829BBADD-7796-4555-8CDF-75F1505073F2@cs.york.ac.uk> Message-ID: <90889fe70808130443l6a578fffs4c23c409c62dd813@mail.gmail.com> On Wed, Aug 13, 2008 at 12:21 PM, Malcolm Wallace wrote: >> - Why does NHC98 break so often? Is it because people are checking in >> code that is not Haskell 98 compatible? > > Yes, there is a bit of that. Also, as you point out, there is quite a lot > of CPP conditionally compiled code in the libraries, and I would say that it > is the major contributor to breakage. It is often unclear which parts of > the code are shared and which separate, so a lot of breakage arises from > e.g. exporting a name that is defined for ghc only. > > In addition, there are some (once obscure) bugs in nhc98 that are now > triggered increasingly frequently. (We can't blame anyone except nhc98 for > those of course.) These include complex import renaming resolution, and > contexts on pattern variables. Can we make sure that these libraries are always built with some Haskell 98 compatibility flag by GHC so people find out when they add non Haskell 98 stuff? >> - It seems to me that implementations "share" libraries using CPP. >> That seems like a bad approach to me. > > Agreed. The CPP was always intended to be as temporary as possible, with > the goal to share as much as possible. One of the problems is that the > primitives provided by compilers are different. Really, there should be a > package below 'base' in the dependency tree, specific to each compiler, and > non-shared. Then everything from base upwards would be cleaner and more > portable. Some code rearrangement could go a long way to. We could put compiler specific implementations of certain functions in a separate module. We could then import the right compiler specific module with just one if-def and then reexport the functions from e.g. Data.Array. module Data.Array ( map, filter ) where #ifdef __GLASGOW_HASKELL__ import Ghc.Data.Array as Impl #endif #ifdef __HUGS__ import Hugs.Data.Array as Impl #endif -- | Documentation map = Impl.map -- | This implementation is shared. filter p xs = ... I don't know if this is the best way (I need to give the subject some more thought). >> If it's so difficult to share code without continuously breaking the >> build then we're better of keeping the code separate. > > I don't agree. The only way to achieve convergence is to start from some > semi-merged point, and work to eliminate the differences. Igloo is doing a > fantastic job of determining the dependencies and gradually moving stuff > around to enable this to happen. Trying to come up with a solution that allows us to share code in a sane way would of course be better. But if that doesn't work, maybe because the problem is inherent with the way we share code, and the build breakages continue I would argue strongly for always keeping HEAD buildable over sharing implementation. Cheers, Johan From duncan.coutts at worc.ox.ac.uk Wed Aug 13 07:09:53 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Wed Aug 13 07:43:56 2008 Subject: Build system idea In-Reply-To: <48A2B898.5080701@gmail.com> References: <48A161DA.3010106@gmail.com> <061FA30C-4326-4B65-A80F-096593C81D6C@cse.unsw.edu.au> <48A29175.1030907@gmail.com> <4D6AF7CE-B789-4021-898D-876475DEABF2@cse.unsw.edu.au> <48A2B898.5080701@gmail.com> Message-ID: <1218625793.7661.499.camel@localhost> On Wed, 2008-08-13 at 11:34 +0100, Simon Marlow wrote: > Cabal has two parts: some generic infrastructure, and a "simple" build > system (under Distribution.Simple) that suffices for most packages. We > distribute them together only because it's convenient; you don't have to > use the simple build system if you don't want to. The two parts also have different degrees of stability. In particular there are lots of tools that rely on the ?declarative parts, the types and parsers so we try not to break those so often. Roman asks for a "separate, stable library which ghc (and nhc?) could use" but since this part of Cabal is fairly stable I don't think it needs to be separate. I don't think it'd be more stable by being in a different package. The reasons to change it are usually to add new fields, and that usually does not affect clients that do not need to know about the new fields. > I think perhaps you're objecting to the fact that the "simple" build system > isn't so simple, and we keep adding more functionality to it. This is > true, but the alternative - forcing some packages to provide their own > build system - seems worse to me. As Isaac used to say, it's not the Simple build system because it's simple. It's because it does complex things to simple packages. The Make build type was supposed to let people wrap existing make-based build systems. Unfortunately it's not used much so is not well developed and for ghc is really the wrong way round. I think your approach of exporting the info in make syntax makes more sense for ghc, since it's not trying to pretend it's a cabal package anyway (which is what the Make build type was for, wrapping things up so people building packages didn't need to know what was used underneath). Duncan From duncan.coutts at worc.ox.ac.uk Wed Aug 13 07:45:31 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Wed Aug 13 07:44:03 2008 Subject: Version control systems In-Reply-To: <36972DFA-9091-4035-8E39-EE0F23F3D028@cse.unsw.edu.au> References: <48981C03.10908@gmail.com> <20080806051232.GD17673@scytale.galois.com> <1218016430.7661.189.camel@localhost> <9d4d38820808060331h4758c8a4y2bc6e79d14b8ae3d@mail.gmail.com> <18DB9581-AA5B-433C-9036-34EC2674C2CB@cse.unsw.edu.au> <20080808130329.GA15063@matrix.chaos.earth.li> <5FEA1F32-9C34-4888-A5BE-D0460D55C307@cse.unsw.edu.au> <48A05827.5020200@gmail.com> <48A1477F.4060003@gmail.com> <36972DFA-9091-4035-8E39-EE0F23F3D028@cse.unsw.edu.au> Message-ID: <1218627931.7661.523.camel@localhost> On Wed, 2008-08-13 at 16:19 +1000, Manuel M T Chakravarty wrote: > In a sense, it was an interesting experiment and it should still be > useful to the development of Cabal. In fact, I see no reason why the > experiment cannot be continued on a branch. Who knows, maybe Cabal is > sufficiently mature in a year to make a switch worthwhile? I just > object to using the whole GHC developer community as guinea pigs. Sadly, I'm not so sure we've really learnt much that helps Cabal itself. While there's been a lot of general pain I can't think of many specific issues we've discovered in Cabal. We added a couple of minor features, some of which we'd have needed anyway for building the libs for 6.10 (eg due to the base-3/4 thing). As far as I can see, most of the problems have been in the change itself and the makefile glue code. I may well me missing some things since I've not been intimately involved in the changes. I would most appreciate specific problems or missing features being filed as tickets in the Cabal trac so that we can learn things and not forget them. Roman filed #276 "Add support for convenience libraries" and I appreciate that. I know about the longer term need for dph for a more general 'ways' system in ghc's package system, which will need support in Cabal. I'll file a ticket for that one. Duncan From Malcolm.Wallace at cs.york.ac.uk Wed Aug 13 07:52:54 2008 From: Malcolm.Wallace at cs.york.ac.uk (Malcolm Wallace) Date: Wed Aug 13 07:56:40 2008 Subject: Version control systems In-Reply-To: References: <20080806051232.GD17673@scytale.galois.com> <1218016430.7661.189.camel@localhost> <9d4d38820808060331h4758c8a4y2bc6e79d14b8ae3d@mail.gmail.com> <18DB9581-AA5B-433C-9036-34EC2674C2CB@cse.unsw.edu.au> <20080808130329.GA15063@matrix.chaos.earth.li> <5FEA1F32-9C34-4888-A5BE-D0460D55C307@cse.unsw.edu.au> <48A05827.5020200@gmail.com> <20080811172735.GA13912@soi.city.ac.uk> <99278BE4-C737-4349-91F1-78A74D83734E@cse.unsw.edu.au> <20080812115344.GB17581@matrix.chaos.earth.li> Message-ID: <20080813125254.07009f79.Malcolm.Wallace@cs.york.ac.uk> > I don't think that is the right policy. Everybody (including Malcolm) > should validate. > > If you contribute code to the linux kernel, comprehensive testing of > the code is a requirement, too. The analogy is flawed. It is like asking the developers of _gcc_ to ensure that the Linux kernel still builds after every modification to the gcc project code base. The projects are different, so the suggested requirement would be an unreasonable burden. Regards, Malcolm From johan.tibell at gmail.com Wed Aug 13 08:18:17 2008 From: johan.tibell at gmail.com (Johan Tibell) Date: Wed Aug 13 08:17:34 2008 Subject: Version control systems In-Reply-To: <20080813125254.07009f79.Malcolm.Wallace@cs.york.ac.uk> References: <20080806051232.GD17673@scytale.galois.com> <20080808130329.GA15063@matrix.chaos.earth.li> <5FEA1F32-9C34-4888-A5BE-D0460D55C307@cse.unsw.edu.au> <48A05827.5020200@gmail.com> <20080811172735.GA13912@soi.city.ac.uk> <99278BE4-C737-4349-91F1-78A74D83734E@cse.unsw.edu.au> <20080812115344.GB17581@matrix.chaos.earth.li> <20080813125254.07009f79.Malcolm.Wallace@cs.york.ac.uk> Message-ID: <90889fe70808130518l448ed638k5bb3a4930a4c6844@mail.gmail.com> On Wed, Aug 13, 2008 at 1:52 PM, Malcolm Wallace wrote: >> I don't think that is the right policy. Everybody (including Malcolm) >> should validate. >> >> If you contribute code to the linux kernel, comprehensive testing of >> the code is a requirement, too. > > The analogy is flawed. It is like asking the developers of _gcc_ to > ensure that the Linux kernel still builds after every modification to > the gcc project code base. The projects are different, so the > suggested requirement would be an unreasonable burden. I think an even better analogy is probably comparing it to developer of GCC changing the libc implementation of another compiler or vice versa. -- Johan From rl at cse.unsw.edu.au Wed Aug 13 08:47:18 2008 From: rl at cse.unsw.edu.au (Roman Leshchinskiy) Date: Wed Aug 13 08:46:46 2008 Subject: Build system idea In-Reply-To: <48A2B898.5080701@gmail.com> References: <48A161DA.3010106@gmail.com> <061FA30C-4326-4B65-A80F-096593C81D6C@cse.unsw.edu.au> <48A29175.1030907@gmail.com> <4D6AF7CE-B789-4021-898D-876475DEABF2@cse.unsw.edu.au> <48A2B898.5080701@gmail.com> Message-ID: <48F76A30-31A2-434F-BA37-BFADBA42C3F5@cse.unsw.edu.au> On 13/08/2008, at 20:34, Simon Marlow wrote: > Roman Leshchinskiy wrote: > >> Of course there should be a standard build system for simple >> packages. It could be part of Cabal or a separate tool (for which >> Cabal could, again, act as a preprocessor). >>> GHC is a special case: we already need a build system for other >>> reasons. >> I agree. I just don't think that adding a full-fledged build system >> to Cabal is the solution. In my experience, huge monolithic tools >> which try to do everything never work well. I much prefer small, >> modular tools. A Haskell-based build system is an interesting >> project but why does it have to be a part of Cabal? > > Hmm, but you said above "there should be a standard build system for > simple packages. It could be part of Cabal...". On second thought, it shouldn't be part of Cabal :-) > Cabal has two parts: some generic infrastructure, and a "simple" > build system (under Distribution.Simple) that suffices for most > packages. We distribute them together only because it's convenient; > you don't have to use the simple build system if you don't want to. My impression of Cabal is that it is a build system with a bit of generic infrastructure. In particular, a large part of the .cabal syntax is specified in terms of this build system and some of it only really makes sense for this build system. > I think perhaps you're objecting to the fact that the "simple" build > system isn't so simple, and we keep adding more functionality to > it. This is true, but the alternative - forcing some packages to > provide their own build system - seems worse to me. Cabal packages do provide their own build system; it's just that they use Cabal syntax instead of, say, make. The advantage of doing this is, of course, that Cabal's syntax is simpler. Adding things to the "simple" build system erodes this advantage. Complex projects will still have complex build systems - the complexity will be in the .cabal files. If Cabal's goal is to be able to build any project it will basically have to duplicate the functionality of autoconf, automake, libtool, make and a couple of other tools *and* be just as flexible. I think this is neither realistic nor necessary. So where do we stop? And what about the packages that Cabal won't support when we stop? IMO, we should have stopped some time ago. A .cabal file should describe a package, not how to build it. Building should be handled by different tools with a clear interface between them and Cabal. If the build system of choice needs additional information, then that information should be provided in a separate file and not in the package description. Again, I'm not arguing against a build system written in Haskell. I'd just like it to be completely separated from Haskell's packaging system. In particular, "polluting" a package description with build information seems wrong to me. Roman From bulat.ziganshin at gmail.com Wed Aug 13 09:09:05 2008 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Wed Aug 13 09:11:18 2008 Subject: Version control systems In-Reply-To: <90889fe70808130443l6a578fffs4c23c409c62dd813@mail.gmail.com> References: <48981C03.10908@gmail.com> <48A05827.5020200@gmail.com> <20080811172735.GA13912@soi.city.ac.uk> <99278BE4-C737-4349-91F1-78A74D83734E@cse.unsw.edu.au> <638ABD0A29C8884A91BC5FB5C349B1C32AE806640A@EA-EXMSG-C334.europe.corp.microsoft.com> <6AC4D8F1-D0BE-49A4-8E10-62945BB7639A@cse.unsw.edu.au> <16ABF72C-88B8-48C7-98C7-0AF011AAAA74@cs.york.ac.uk> <90889fe70808130226y672012c1q8c4b502105cedef5@mail.gmail.com> <829BBADD-7796-4555-8CDF-75F1505073F2@cs.york.ac.uk> <90889fe70808130443l6a578fffs4c23c409c62dd813@mail.gmail.com> Message-ID: <772946044.20080813170905@gmail.com> Hello Johan, Wednesday, August 13, 2008, 3:43:15 PM, you wrote: >>> - Why does NHC98 break so often? Is it because people are checking in >>> code that is not Haskell 98 compatible? > Can we make sure that these libraries are always built with some > Haskell 98 compatibility flag by GHC so people find out when they add > non Haskell 98 stuff? on ghc, we use many non-h98 features. actually, there are even non-h98 features that are common to all 3 compilers (f.e. rank-2 types, afair) we need to check that non-nhc features are not used in *shared* code and the best tool to do such checks is nhc itself -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From Malcolm.Wallace at cs.york.ac.uk Wed Aug 13 09:13:44 2008 From: Malcolm.Wallace at cs.york.ac.uk (Malcolm Wallace) Date: Wed Aug 13 09:15:17 2008 Subject: Version control systems In-Reply-To: <90889fe70808130518l448ed638k5bb3a4930a4c6844@mail.gmail.com> References: <20080806051232.GD17673@scytale.galois.com> <20080808130329.GA15063@matrix.chaos.earth.li> <5FEA1F32-9C34-4888-A5BE-D0460D55C307@cse.unsw.edu.au> <48A05827.5020200@gmail.com> <20080811172735.GA13912@soi.city.ac.uk> <99278BE4-C737-4349-91F1-78A74D83734E@cse.unsw.edu.au> <20080812115344.GB17581@matrix.chaos.earth.li> <20080813125254.07009f79.Malcolm.Wallace@cs.york.ac.uk> <90889fe70808130518l448ed638k5bb3a4930a4c6844@mail.gmail.com> Message-ID: <20080813141344.390a81c3.Malcolm.Wallace@cs.york.ac.uk> > I think an even better analogy is probably comparing it to developer > of GCC changing the libc implementation of another compiler or vice > versa. Our shared libraries do not belong to any one compiler. They are joint creations, with a lot of community (non-compiler-hacker) involvement. Regards, Malcolm From johan.tibell at gmail.com Wed Aug 13 09:57:50 2008 From: johan.tibell at gmail.com (Johan Tibell) Date: Wed Aug 13 09:57:06 2008 Subject: Version control systems In-Reply-To: <20080813141344.390a81c3.Malcolm.Wallace@cs.york.ac.uk> References: <20080806051232.GD17673@scytale.galois.com> <48A05827.5020200@gmail.com> <20080811172735.GA13912@soi.city.ac.uk> <99278BE4-C737-4349-91F1-78A74D83734E@cse.unsw.edu.au> <20080812115344.GB17581@matrix.chaos.earth.li> <20080813125254.07009f79.Malcolm.Wallace@cs.york.ac.uk> <90889fe70808130518l448ed638k5bb3a4930a4c6844@mail.gmail.com> <20080813141344.390a81c3.Malcolm.Wallace@cs.york.ac.uk> Message-ID: <90889fe70808130657g2b973de1s70b1523e42564eb7@mail.gmail.com> On Wed, Aug 13, 2008 at 3:13 PM, Malcolm Wallace wrote: >> I think an even better analogy is probably comparing it to developer >> of GCC changing the libc implementation of another compiler or vice >> versa. > > Our shared libraries do not belong to any one compiler. They are joint > creations, with a lot of community (non-compiler-hacker) involvement. I'm very grateful these people took the time to write these libraries. However, how these modules were created is irrelevant when it comes to addressing the current problem. Parts of their implementation is compiler dependent and having compiler specific code live together is bound to lead to problems because the people hacking on those modules are likely to use and validate on only one compiler. It would be difficult to require them to do otherwise too. To avoid this problem either the compiler dependent code has to be abstracted out from these modules so people can ignore the differences or the implementations of these files need to be kept separate. Consider the following scenario. GHC hackers implement Data.Array in A.hs, Hugs and NHC98 hackers develop separate implementations in B.hs and C.hs respectively. We now run something like diff A.hs B.hs C.hs | sed > X.hs X.hs could be likened to what current implementation of these files look like. If the three groups don't validate their changes on all compilers they risk breaking someones build. Especially note the poor scaling properties of this approach were each new implementation adds one more compiler for everyone to verify on. I think the reason this works at all right now is that most work is happening on GHC and that's also were the most users are. Cheers, Johan From mad.one at gmail.com Wed Aug 13 11:04:41 2008 From: mad.one at gmail.com (Austin Seipp) Date: Wed Aug 13 11:04:01 2008 Subject: Version control systems In-Reply-To: <90889fe70808130009r536f8a36sdf7d6b80f7a36d72@mail.gmail.com> References: <18DB9581-AA5B-433C-9036-34EC2674C2CB@cse.unsw.edu.au> <20080809190651.GC3902@scytale.galois.com> <36A0EEA6-5E34-4A1A-A008-7F847D84A1E2@cs.york.ac.uk> <20080809225624.BDD6613833F@drdoom.eecs.harvard.edu> <20080810113200.GA16357@matrix.chaos.earth.li> <20080811001751.28DA31383C3@drdoom.eecs.harvard.edu> <20080812113112.GA17581@matrix.chaos.earth.li> <24AD8609-8644-4AEA-9A56-E5A603915A95@cse.unsw.edu.au> <90889fe70808130009r536f8a36sdf7d6b80f7a36d72@mail.gmail.com> Message-ID: <1218638920-sup-8518@existential.local> Excerpts from Johan Tibell's message of Wed Aug 13 02:09:00 -0500 2008: > I'm also in favor of the switch to Git. The Git model has proved to be > both more productive and more reliable. And the interface, as far as > I'm concerned, is *better*. > Seconded. The git documentation these days I find is excellent; many of the man pages have fairly lucid examples and explanations of their usage. The documentation on kernel.org is also very extensive. This software is used by a lot of people already and has proven to be reliable for projects the size of e.g. the linux kernel. While it may be true that in the past git was cumbersome and difficult to use, I can't agree with such an assessment these days. In many instances, you can probably get away with ignoring most of the more 'advanced' commands and simply using it like any other DVCS. "Everyday git" in fact, is surprisingly simple I think. I certainly don't think that the GHC devs will need anything under the porcelain commands either. You don't have to use super-advanced commands that might endanger your history (and commands like git-reflog are a safety net around that too.) You can get far with just a little. Also, this tutorial (and its sequel in particular) should do well for anybody new to git: http://www.kernel.org/pub/software/scm/git/docs/gittutorial.html It's really not that bad and should take you no more than a few minutes to read it and the second part. I encourage those who might be confused to read it. And besides familiarity, what does darcs give us that git doesn't? I find git's core model (objects, trees, blobs and tags are it) more simple and straightforward than the blackbox that is darcs. (And although it's already been elaborated upon before I'm sure, waiting on your tools is nothing but a waste of time. If I even want to get the latest HEAD, I find I can spend a lot of time waiting on darcs. I rarely wait on git for anything - it's fairly instant most of the time.) So I'm with Johan and Thomas for a switch to git. Austin From dagit at codersbase.com Wed Aug 13 13:11:32 2008 From: dagit at codersbase.com (Jason Dagit) Date: Wed Aug 13 13:10:49 2008 Subject: Version control systems In-Reply-To: <16ABF72C-88B8-48C7-98C7-0AF011AAAA74@cs.york.ac.uk> References: <48981C03.10908@gmail.com> <20080808130329.GA15063@matrix.chaos.earth.li> <5FEA1F32-9C34-4888-A5BE-D0460D55C307@cse.unsw.edu.au> <48A05827.5020200@gmail.com> <20080811172735.GA13912@soi.city.ac.uk> <99278BE4-C737-4349-91F1-78A74D83734E@cse.unsw.edu.au> <638ABD0A29C8884A91BC5FB5C349B1C32AE806640A@EA-EXMSG-C334.europe.corp.microsoft.com> <6AC4D8F1-D0BE-49A4-8E10-62945BB7639A@cse.unsw.edu.au> <16ABF72C-88B8-48C7-98C7-0AF011AAAA74@cs.york.ac.uk> Message-ID: On Wed, Aug 13, 2008 at 1:54 AM, Malcolm Wallace < malcolm.wallace@cs.york.ac.uk> wrote: > Manuel wrote: > > | It is worth pointing out that I *never* validate against ghc head when >>> | I commit to the core libraries. >>> >> > Sorry, but I think the only reason its halfway acceptable is that Malcolm >> didn't break the GHC build yet. If he does, I'll be screaming as loudly as >> for anybody else. >> > > Whilst I'm in no way saying that a working nhc98 head is anything like as > important as a working ghc head, are you saying that I should scream louder > everytime someone breaks nhc98 too? It is happening several times a week at > the moment. It can be jolly frustrating when I have other things I could be > doing. But I accept that it is simply the price to pay for keeping > up-to-date with the libraries everyone else is using. Ghc has no monopoly > on the "core" libraries. They are a shared resource. > > to be honest, I don't think its a valid reason for us to go to the trouble >> of having two vcs for ghc. >> > > Well indeed, I don't want to stand in the way of ghc. There are far more > people contributing to it, so their needs have greater weight. But I am > raising the libraries question, because I think it has an impact much more > widely than just ghc (or Hugs or nhc98, for that matter). > > Git may turn out to be sufficiently easy to use that this will all seem > like a storm in a teacup once the dust has settled. (I'm not filled with > confidence by blog postings that say "granted, git is a usability disaster > zone", and "[you] may find git to be hostile, unfriendly and needlessly > complex", but those seem to be minority opinions.) I'm not a contributor for hugs, nhc, jhc, ghc, or any other project that is affect here, but when I see this part of the discussion come up again and again I have to wonder if anyone has done the obvious thing of asking these other communities if they would mind switching to git? Of course each of them are free to say "No, we won't switch" for any reason they like and you'd have to then deal with the situation. But, it seems that it can't hurt to ask, and I get the impression no one has asked them formally. If everyone did happen to agree on using git for the shared libraries, wouldn't that end this part of the debate? Just my $0.02, Jason -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20080813/d4da1327/attachment.htm From kili at outback.escape.de Wed Aug 13 15:22:02 2008 From: kili at outback.escape.de (Matthias Kilian) Date: Wed Aug 13 15:26:35 2008 Subject: Version control systems In-Reply-To: <48A29556.6030608@gmail.com> References: <1218016430.7661.189.camel@localhost> <9d4d38820808060331h4758c8a4y2bc6e79d14b8ae3d@mail.gmail.com> <18DB9581-AA5B-433C-9036-34EC2674C2CB@cse.unsw.edu.au> <20080808130329.GA15063@matrix.chaos.earth.li> <5FEA1F32-9C34-4888-A5BE-D0460D55C307@cse.unsw.edu.au> <48A05827.5020200@gmail.com> <20080811212229.GA11669@petunia.outback.escape.de> <48A16D19.40800@gmail.com> <20080812202903.GA10480@petunia.outback.escape.de> <48A29556.6030608@gmail.com> Message-ID: <20080813192202.GC18477@petunia.outback.escape.de> On Wed, Aug 13, 2008 at 09:03:34AM +0100, Simon Marlow wrote: > >Yes, it relies only on the Cabal metadata, but the output is a > >Makefile only useful for building GHC. > > Ok, this statement is plainly not true, since I can use 'cabal makefile' > to build any package outside of the GHC build tree. So perhaps I've > misunderstood your point? No, I was confused (a little bit over-worked). > >$ ./Setup mkmetadata -prefix foo- > > > >which just produces some simple variable declarations like > > > > foo-impl-ghc-build-depends = rts > > foo-impl-ghc-exposed-modules = Data.Generics Data.Generics.Aliases [...] > Yes, we could use this to implement GHC's build system. It's somewhat > similar to the scheme I suggested in the other thread, but more generic. > I'd be completely happy to do it this way if the functionality would > be useful to others outside GHC too. I've a little bit spare time from august 25th to august 31th. This should be enough time for implementing it (in Cabal and in the GHC build system) to see how it feels. Ciao, Kili -- CRM114 isn't ugly like PERL. It's a whole different kind of ugly. -- John Bowker From duncan.coutts at worc.ox.ac.uk Wed Aug 13 16:32:39 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Wed Aug 13 16:35:12 2008 Subject: Build system idea In-Reply-To: <48F76A30-31A2-434F-BA37-BFADBA42C3F5@cse.unsw.edu.au> References: <48A161DA.3010106@gmail.com> <061FA30C-4326-4B65-A80F-096593C81D6C@cse.unsw.edu.au> <48A29175.1030907@gmail.com> <4D6AF7CE-B789-4021-898D-876475DEABF2@cse.unsw.edu.au> <48A2B898.5080701@gmail.com> <48F76A30-31A2-434F-BA37-BFADBA42C3F5@cse.unsw.edu.au> Message-ID: <1218659559.7661.553.camel@localhost> On Wed, 2008-08-13 at 22:47 +1000, Roman Leshchinskiy wrote: > Again, I'm not arguing against a build system written in Haskell. I'd > just like it to be completely separated from Haskell's packaging > system. In particular, "polluting" a package description with build > information seems wrong to me. There is a huge overlap of course. The things needed to build a package tend to be the dependencies. The ability to automatically extract the dependencies from a package description is crucial as it is what enables automatic package management either directly or by conversion to distro packages. Tools like automake + autoconf do not give us that. There is of course some separation possible, which in Cabal roughly corresponds to the stuff under Distribution.Simple vs everything else. We could split those two aspects into separate packages but it's not clear to me that we'd gain much by doing that. There is still the Make build type which we could improve if people want it. That allows the declarative stuff to be given in the .cabal file (so that package managers can do their thing) and all the building is delegated to make. People have not shown any interest in this so it's never been improved much. The obvious disadvantage of using it is that you have to do a lot of work to make your build system do all the things that users expect. Duncan From duncan.coutts at worc.ox.ac.uk Wed Aug 13 17:49:42 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Wed Aug 13 18:25:19 2008 Subject: Version control systems In-Reply-To: <48A0371D.1040407@gmail.com> References: <48981C03.10908@gmail.com> <20080806051232.GD17673@scytale.galois.com> <1218016430.7661.189.camel@localhost> <9d4d38820808060331h4758c8a4y2bc6e79d14b8ae3d@mail.gmail.com> <18DB9581-AA5B-433C-9036-34EC2674C2CB@cse.unsw.edu.au> <20080808130329.GA15063@matrix.chaos.earth.li> <5FEA1F32-9C34-4888-A5BE-D0460D55C307@cse.unsw.edu.au> <4BF2D191-FAC5-4285-8638-86D0A8366305@googlemail.com> <4E23A401-E5D4-4589-8334-D8B21BDDCA44@cse.unsw.edu.au> <55163A6F-9F46-450F-888D-BD52479B296E@googlemail.com> <1218452424.7661.366.camel@localhost> <48A0371D.1040407@gmail.com> Message-ID: <1218664182.7661.564.camel@localhost> On Mon, 2008-08-11 at 13:57 +0100, Simon Marlow wrote: > - Performance. darcs2 regressed in performance for many operations we > commonly use. I've submitted some measurements for some things, but > it's pretty easy to find your own test cases: things like "darcs add", > "darcs whatsnew", "darcs unrecord" are all slower than darcs 1. When > simple operations take multiple seconds to complete, it really slows > down your workflow. Turns out that the reason for slow darcs whatsnew is ghc bug #2093 http://hackage.haskell.org/trac/ghc/ticket/2093 because getSymbolicLinkStatus is broken on 32bit systems in 6.8.2 it means that the 'stat' optimisation does not work so darcs has to read the actual contents of many files. Obviously that's very slow, especially over nfs. That explains why it worked for me in 0.2 seconds but for you took several seconds user time and (even more real time due to nfs). If you were using ?http://darcs.haskell.org/ghc-hashedrepo/ then there's a further explanation. According to the darcs devs that repo is: "in some weird intermediate (not final) hashed format that doesn't keep (original) filesizes in filenames. So in effect, it's running like with --ignore-times still" So I suggest we get rid of that old repo so as not to further the confusion. Duncan From marlowsd at gmail.com Thu Aug 14 04:01:34 2008 From: marlowsd at gmail.com (Simon Marlow) Date: Thu Aug 14 09:03:22 2008 Subject: Build system idea In-Reply-To: References: <48A161DA.3010106@gmail.com> <061FA30C-4326-4B65-A80F-096593C81D6C@cse.unsw.edu.au> <48A29175.1030907@gmail.com> <4D6AF7CE-B789-4021-898D-876475DEABF2@cse.unsw.edu.au> <48A2B898.5080701@gmail.com> <48F76A30-31A2-434F-BA37-BFADBA42C3F5@cse.unsw.edu.au> <1218659559.7661.553.camel@localhost> Message-ID: <48A3E65E.7030609@gmail.com> Roman Leshchinskiy wrote: > But that is precisely my (other) point. A lot of that work is really > unnecessary and could be done by Cabal since it only or mostly depends > on the package information. Instead, it is implemented somewhere in > Distribution.Simple and not really usable from the outside. For > instance, a lot of the functionality of setup sdist, setup register and > so on could be implemented generically and used by a make-based build > system as well. That's exactly what I'm proposing we do in GHC: re-use Cabal's setup register and some of the other parts of the simple build system in a make-based build system for packages. It might require a bit of refactoring of Cabal, but I don't expect it to be a major upheaval at all. I think what you're proposing is mostly a matter of abstracting parts of Cabal with cleaner and more modular APIs, which is absolutely a good thing, but doesn't require a fundamental redesign. The tight coupling and lack of separation between Cabal's generic parts and the simple build system is somewhat accidental (lazy implementors :-), and is actually a lot better than it used to be thanks to the work Duncan has put in. I'm sure it'll improve further over time. The other part of your complaint is that the BuildInfo is in the .cabal file along with the PackageDescription (the types are pretty well separated internally). Again I don't think there's anything fundamental here, and in fact some packages have separate .buildinfo files. Cheers, Simon From igloo at earth.li Thu Aug 14 07:14:42 2008 From: igloo at earth.li (Ian Lynagh) Date: Thu Aug 14 09:19:25 2008 Subject: Version control systems In-Reply-To: <0E342A89-8750-49F6-AD6A-7EA64300134C@cse.unsw.edu.au> References: <20080806051232.GD17673@scytale.galois.com> <1218016430.7661.189.camel@localhost> <9d4d38820808060331h4758c8a4y2bc6e79d14b8ae3d@mail.gmail.com> <18DB9581-AA5B-433C-9036-34EC2674C2CB@cse.unsw.edu.au> <20080808130329.GA15063@matrix.chaos.earth.li> <5FEA1F32-9C34-4888-A5BE-D0460D55C307@cse.unsw.edu.au> <48A05827.5020200@gmail.com> <20080812121835.GA18185@matrix.chaos.earth.li> <0E342A89-8750-49F6-AD6A-7EA64300134C@cse.unsw.edu.au> Message-ID: <20080814111442.GB1813@matrix.chaos.earth.li> On Wed, Aug 13, 2008 at 04:35:42PM +1000, Manuel M T Chakravarty wrote: > > Rebuilding with stage1 was already needed to build GHC with a builtin > readline. In general, it is a bad idea to build distributed binaries > of Haskell programs with the *bootstrap compiler*. It must be done > with the stage1 compiler. (If you are unsure why, I'll happily > elaborate.) No, I understand why it was necessary, I just had problems with the way it was done. Of course, it would have been possible to extend the old build system to build the two versions in separate directories, but it would have meant adding more complexity to an already-complex system. I believe that using a Cabal-based build system instead has made things simpler. Thanks Ian From igloo at earth.li Thu Aug 14 07:07:30 2008 From: igloo at earth.li (Ian Lynagh) Date: Thu Aug 14 09:19:27 2008 Subject: Version control systems In-Reply-To: <36972DFA-9091-4035-8E39-EE0F23F3D028@cse.unsw.edu.au> References: <20080806051232.GD17673@scytale.galois.com> <1218016430.7661.189.camel@localhost> <9d4d38820808060331h4758c8a4y2bc6e79d14b8ae3d@mail.gmail.com> <18DB9581-AA5B-433C-9036-34EC2674C2CB@cse.unsw.edu.au> <20080808130329.GA15063@matrix.chaos.earth.li> <5FEA1F32-9C34-4888-A5BE-D0460D55C307@cse.unsw.edu.au> <48A05827.5020200@gmail.com> <48A1477F.4060003@gmail.com> <36972DFA-9091-4035-8E39-EE0F23F3D028@cse.unsw.edu.au> Message-ID: <20080814110730.GA1813@matrix.chaos.earth.li> On Wed, Aug 13, 2008 at 04:19:37PM +1000, Manuel M T Chakravarty wrote: > Simon Marlow: > >Manuel M T Chakravarty wrote: > >>To be honest, if you ask me, I'd go back to the old makefile based > >>system and remove Cabal from everywhere except building of the > >>library packages. > > > >I wouldn't object to dropping the use of Cabal for other tools in > >the build tree; the reasons for using it elsewhere are certainly not > >as compelling as for packages. > > > >Ian, I realise this means backing out a lot of the work you've been > >doing recently, and it would mean that we'd lose a lot of time in > >the runup to 6.10.1, but perhaps it's a step that we need to take to > >get us back on the right track again? > > I do realise that this would mean backing out a lot of Ian recent > work, and that's why I haven't proposed going back to the old system > before you explicitly asked. However, I am increasingly getting the > feeling that the move to Cabal was pre-mature, and the overall loss > will be minimised by backing out now. We're only talking about "other tools", not the libraries (including the GHC library), right? This seems like it would be a step backwards to me (after all, I wouldn't have spent the time moving to Cabal if I didn't think it was a step forwards), and I'm not really sure what benefit you see in it: how much time do you spend working in utils/? Thanks Ian From chak at cse.unsw.edu.au Wed Aug 13 22:26:47 2008 From: chak at cse.unsw.edu.au (Manuel M T Chakravarty) Date: Thu Aug 14 09:40:48 2008 Subject: Version control systems In-Reply-To: <1218664182.7661.564.camel@localhost> References: <48981C03.10908@gmail.com> <20080806051232.GD17673@scytale.galois.com> <1218016430.7661.189.camel@localhost> <9d4d38820808060331h4758c8a4y2bc6e79d14b8ae3d@mail.gmail.com> <18DB9581-AA5B-433C-9036-34EC2674C2CB@cse.unsw.edu.au> <20080808130329.GA15063@matrix.chaos.earth.li> <5FEA1F32-9C34-4888-A5BE-D0460D55C307@cse.unsw.edu.au> <4BF2D191-FAC5-4285-8638-86D0A8366305@googlemail.com> <4E23A401-E5D4-4589-8334-D8B21BDDCA44@cse.unsw.edu.au> <55163A6F-9F46-450F-888D-BD52479B296E@googlemail.com> <1218452424.7661.366.camel@localhost> <48A0371D.1040407@gmail.com> <1218664182.7661.564.camel@localhost> Message-ID: <7A005FB0-26EB-4FBC-9583-C619E580C6A0@cse.unsw.edu.au> Duncan Coutts: > On Mon, 2008-08-11 at 13:57 +0100, Simon Marlow wrote: >> - Performance. darcs2 regressed in performance for many >> operations we >> commonly use. I've submitted some measurements for some things, >> but >> it's pretty easy to find your own test cases: things like "darcs >> add", >> "darcs whatsnew", "darcs unrecord" are all slower than darcs 1. >> When >> simple operations take multiple seconds to complete, it really >> slows >> down your workflow. > > Turns out that the reason for slow darcs whatsnew is ghc bug #2093 > > http://hackage.haskell.org/trac/ghc/ticket/2093 > > because getSymbolicLinkStatus is broken on 32bit systems in 6.8.2 it > means that the 'stat' optimisation does not work so darcs has to read > the actual contents of many files. Obviously that's very slow, > especially over nfs. That explains why it worked for me in 0.2 seconds > but for you took several seconds user time and (even more real time > due > to nfs). LOL - that is funny. GHC devel slowed down by slow darcs due to GHC bug. The bug is fixed, isn't it? So, recompiling darcs with 6.8.3 should improve matters. Manuel From marlowsd at gmail.com Thu Aug 14 03:43:14 2008 From: marlowsd at gmail.com (Simon Marlow) Date: Thu Aug 14 10:15:33 2008 Subject: Version control systems In-Reply-To: <1218664182.7661.564.camel@localhost> References: <48981C03.10908@gmail.com> <20080806051232.GD17673@scytale.galois.com> <1218016430.7661.189.camel@localhost> <9d4d38820808060331h4758c8a4y2bc6e79d14b8ae3d@mail.gmail.com> <18DB9581-AA5B-433C-9036-34EC2674C2CB@cse.unsw.edu.au> <20080808130329.GA15063@matrix.chaos.earth.li> <5FEA1F32-9C34-4888-A5BE-D0460D55C307@cse.unsw.edu.au> <4BF2D191-FAC5-4285-8638-86D0A8366305@googlemail.com> <4E23A401-E5D4-4589-8334-D8B21BDDCA44@cse.unsw.edu.au> <55163A6F-9F46-450F-888D-BD52479B296E@googlemail.com> <1218452424.7661.366.camel@localhost> <48A0371D.1040407@gmail.com> <1218664182.7661.564.camel@localhost> Message-ID: <48A3E212.6020203@gmail.com> Duncan Coutts wrote: > Turns out that the reason for slow darcs whatsnew is ghc bug #2093 > > http://hackage.haskell.org/trac/ghc/ticket/2093 > > because getSymbolicLinkStatus is broken on 32bit systems in 6.8.2 it > means that the 'stat' optimisation does not work so darcs has to read > the actual contents of many files. Obviously that's very slow, > especially over nfs. That explains why it worked for me in 0.2 seconds > but for you took several seconds user time and (even more real time due > to nfs). Yes, I was aware of the #2093 problem (someone else pointed it out to me earlier), but it's not the cause of the slow whatsnew I'm seeing: my darcs is compiled with 6.8.3. ~/darcs/ghc-testing/testsuite-hashed > darcs +RTS --info [("GHC RTS", "Yes") ,("GHC version", "6.8.3") ,("RTS way", "rts_thr") ,("Host platform", "x86_64-unknown-linux") ,("Build platform", "x86_64-unknown-linux") ,("Target platform", "x86_64-unknown-linux") ,("Compiler unregisterised", "NO") ,("Tables next to code", "YES") ] ~/darcs/ghc-testing/testsuite-hashed > time darcs wh No changes! [2] 15793 exit 1 darcs wh 21.35s real 9.56s user 4.28s system 64% darcs wh ~/darcs/ghc-testing/testsuite-hashed > darcs --version 2.0.1rc2 (2.0.1rc2 (+ -1 patch)) ~/darcs/ghc-testing/testsuite-hashed > darcs query repo Type: darcs Format: hashed Root: /home/simonmar/darcs-all/work/ghc-testing/testsuite-hashed Pristine: HashedPristine Cache: thisrepo:/home/simonmar/darcs-all/work/ghc-testing/testsuite-hashed boringfile Pref: .darcs-boring Default Remote: /home/simonmar/darcs-all/work/ghc-testing/testsuite Num Patches: 2834 It's better on the darcs-2 version of the repo: ~/darcs/ghc-testing/testsuite-hashed2 > darcs query repo Type: darcs Format: hashed, darcs-2 Root: /home/simonmar/darcs-all/work/ghc-testing/testsuite-hashed2 Pristine: HashedPristine Cache: thisrepo:/home/simonmar/darcs-all/work/ghc-testing/testsuite-hashed2 Num Patches: 2834 ~/darcs/ghc-testing/testsuite-hashed2 > time darcs wh No changes! [2] 15824 exit 1 darcs wh 3.69s real 1.08s user 0.53s system 43% darcs wh Better, but still a factor of ~4 slower than on the darcs-1 repo. > If you were using ?http://darcs.haskell.org/ghc-hashedrepo/ then there's > a further explanation. According to the darcs devs that repo is: > "in some weird intermediate (not final) hashed format that > doesn't keep (original) filesizes in filenames. So in effect, > it's running like with --ignore-times still" Nope, I'm not using that repo, these were ones I created freshly yesterday. I will try building a fresh darcs to see if that helps. Cheers, Simon From rl at cse.unsw.edu.au Wed Aug 13 23:05:07 2008 From: rl at cse.unsw.edu.au (Roman Leshchinskiy) Date: Thu Aug 14 10:20:54 2008 Subject: Build system idea In-Reply-To: <1218659559.7661.553.camel@localhost> References: <48A161DA.3010106@gmail.com> <061FA30C-4326-4B65-A80F-096593C81D6C@cse.unsw.edu.au> <48A29175.1030907@gmail.com> <4D6AF7CE-B789-4021-898D-876475DEABF2@cse.unsw.edu.au> <48A2B898.5080701@gmail.com> <48F76A30-31A2-434F-BA37-BFADBA42C3F5@cse.unsw.edu.au> <1218659559.7661.553.camel@localhost> Message-ID: On 14/08/2008, at 06:32, Duncan Coutts wrote: > On Wed, 2008-08-13 at 22:47 +1000, Roman Leshchinskiy wrote: > >> Again, I'm not arguing against a build system written in Haskell. I'd >> just like it to be completely separated from Haskell's packaging >> system. In particular, "polluting" a package description with build >> information seems wrong to me. > > There is a huge overlap of course. The things needed to build a > package > tend to be the dependencies. The ability to automatically extract the > dependencies from a package description is crucial as it is what > enables > automatic package management either directly or by conversion to > distro > packages. Tools like automake + autoconf do not give us that. Right. Dependencies are part of a package description. That's what Cabal should do. It should provide a nice clean interface to the dependencies stuff for the build system to use. I don't think it does that at the moment; IIUC, it is all done by Distribution.Simple. > There is of course some separation possible, which in Cabal roughly > corresponds to the stuff under Distribution.Simple vs everything else. > We could split those two aspects into separate packages but it's not > clear to me that we'd gain much by doing that. My point isn't really about distribution, it's about coupling. My concern is that the syntax of .cabal files is increasingly based on what Distribution.Simple needs. This effectively makes all other build systems second class. It also loses us clean package descriptions which is what .cabal files should be. It's not too bad at the moment but will get worse as Distribution.Simple gets more complex since it will need more and more information. Just as an example, consider something like ld-options. This is obviously not a dependency and is basically only documented by how it is used by Distribution.Simple. It shouldn't be in .cabal, IMO. If a build system needs this information, it should be provided somewhere else. > There is still the Make build type which we could improve if people > want > it. That allows the declarative stuff to be given in the .cabal file > (so > that package managers can do their thing) and all the building is > delegated to make. People have not shown any interest in this so it's > never been improved much. The obvious disadvantage of using it is that > you have to do a lot of work to make your build system do all the > things > that users expect. But that is precisely my (other) point. A lot of that work is really unnecessary and could be done by Cabal since it only or mostly depends on the package information. Instead, it is implemented somewhere in Distribution.Simple and not really usable from the outside. For instance, a lot of the functionality of setup sdist, setup register and so on could be implemented generically and used by a make-based build system as well. Also, there is no easy way for build systems to work with the declarative stuff because a lot of that functionality is, again, part of Distribution.Simple. IMO, this is a direct result of the tight coupling between the package management and build system parts of Cabal. The other problem, of course, is that it isn't clear what exactly a build system should provide. IIUC, that's what "Building and installing a package" in the Cabal manual defines but there, we have things like this: setup test Run the test suite specified by the runTests field of Distribution.Simple.UserHooks. See Distribution.Simple for information about creating hooks and using defaultMainWithHooks. As a matter of fact, a lot of Cabal is documented in terms of what Distribution.Simple does. Again, this effectively shuts out other build systems. I'm sorry if this all sounds too negative, it shouldn't really. I think you guys have done a great job in implementing a system which is obviously very important to the community. I just somewhat disagree with the direction in which it is heading now. Roman From isaacdupree at charter.net Thu Aug 14 12:10:04 2008 From: isaacdupree at charter.net (Isaac Dupree) Date: Thu Aug 14 12:09:17 2008 Subject: Version control systems In-Reply-To: <5ab17e790808122104l31613b54ka91861e7ab34047b@mail.gmail.com> References: <18DB9581-AA5B-433C-9036-34EC2674C2CB@cse.unsw.edu.au> <20080809190651.GC3902@scytale.galois.com> <36A0EEA6-5E34-4A1A-A008-7F847D84A1E2@cs.york.ac.uk> <20080809225624.BDD6613833F@drdoom.eecs.harvard.edu> <20080810113200.GA16357@matrix.chaos.earth.li> <20080811001751.28DA31383C3@drdoom.eecs.harvard.edu> <20080812113112.GA17581@matrix.chaos.earth.li> <24AD8609-8644-4AEA-9A56-E5A603915A95@cse.unsw.edu.au> <5ab17e790808122104l31613b54ka91861e7ab34047b@mail.gmail.com> Message-ID: <48A458DC.4020205@charter.net> Iavor Diatchki wrote: > I also don't think that the darcs model has much to offer over git, in > fact I find that it lacks some useful features (not counting a > reliable implementation). Examples include good support for > branching, and being able to easily determine the version of the > software that is in a repository (git uses a hash of the content to > identify the current state, so it is easy to check if we two > developers have the same version of the content). I think these things are possible in darcs's model, just not its implementation. For example, under _darcs it could have enough info in various states to allow one to switch branches within the same physical directory tree (and if there aren't many changes between the two branches/patchsets, the switch can be quick). And if it weren't for the varying ways the same patch can be stored, hashes of history ought to work too (although that's certainly very built in to the current implementation of darcs; whether it's technically part of the model probably depends whether you can provide the exact same interface, semantics, and computational complexity with a different representation). And I wonder why (it sounds like) Git doesn't have tools to do some kind of smart cherrypicking, using a heuristic to decide which patches in a branch are definitely dependencies of the cherry-picked patch. In any case, I notice a few times with ghc/darcs/Trac tickets, more than one commit has to be listed explicitly to be merged into the stable branch. Maybe it's not very useful/reliable for these purposes anyway? Since I've only ever used Darcs (besides read-only CVS/SVN/etc.), I personally can't speak to what model is better for me! -Isaac From leather at cs.uu.nl Thu Aug 14 13:27:08 2008 From: leather at cs.uu.nl (Sean Leather) Date: Thu Aug 14 13:26:22 2008 Subject: How to disable warning for "export item 'module ...' exports nothing"? Message-ID: <3c6288ab0808141027p73b796edm87019afa58174a7a@mail.gmail.com> Hi, I have a module A that re-exports module B, and module B contains only class instances. Since I'm using -Wall, I get this warning about module B exporting nothing. Is there a way to disable this particular warning, since it is unnecessary in this case? No mailing list messages or GHC documentation has told me what to do. Thanks, Sean -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20080814/8fc95055/attachment.htm From isaacdupree at charter.net Thu Aug 14 13:31:34 2008 From: isaacdupree at charter.net (Isaac Dupree) Date: Thu Aug 14 13:30:46 2008 Subject: How to disable warning for "export item 'module ...' exports nothing"? In-Reply-To: <3c6288ab0808141027p73b796edm87019afa58174a7a@mail.gmail.com> References: <3c6288ab0808141027p73b796edm87019afa58174a7a@mail.gmail.com> Message-ID: <48A46BF6.9060003@charter.net> Sean Leather wrote: > Hi, > > I have a module A that re-exports module B, and module B contains only class > instances. Since I'm using -Wall, I get this warning about module B > exporting nothing. Is there a way to disable this particular warning, since > it is unnecessary in this case? No mailing list messages or GHC > documentation has told me what to do. Well, the warning is right that you don't need to re-export module B: instances are implicitly exported. So you could just remove the export of "module B", unless there's a reason to export it (such as, you might add some exported functions or data types to it later) -Isaac From leather at cs.uu.nl Thu Aug 14 13:47:55 2008 From: leather at cs.uu.nl (Sean Leather) Date: Thu Aug 14 13:47:08 2008 Subject: How to disable warning for "export item 'module ...' exports nothing"? In-Reply-To: <48A46BF6.9060003@charter.net> References: <3c6288ab0808141027p73b796edm87019afa58174a7a@mail.gmail.com> <48A46BF6.9060003@charter.net> Message-ID: <3c6288ab0808141047m58dbb27fsd21e0fa9231c8f89@mail.gmail.com> > I have a module A that re-exports module B, and module B contains only >> class >> instances. Since I'm using -Wall, I get this warning about module B >> exporting nothing. Is there a way to disable this particular warning, >> since >> it is unnecessary in this case? No mailing list messages or GHC >> documentation has told me what to do. >> > > Well, the warning is right that you don't need to re-export module B: > instances are implicitly exported. So you could just remove the export of > "module B", unless there's a reason to export it (such as, you might add > some exported functions or data types to it later) > Ah, got it. Thanks. I didn't realize instances of an imported module were also implicitly exported. I should have looked at the report, however. For the future reference of others: "Instance declarations cannot be explicitly named on import or export lists. All instances in scope within a module are *always *exported and any import brings *all* instances in from the imported module. Thus, an instance declaration is in scope if and only if a chain of import declarations leads to the module containing the instance declaration." -- 5.4 Importing and Exporting Instance Declarations at http://www.haskell.org/onlinereport/modules.html It would definitely be nice to have a bit more control over importing/exporting instances. I noticed this idea has been discussed a few times already. Sean -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20080814/8dc0965c/attachment-0001.htm From leather at cs.uu.nl Thu Aug 14 14:00:25 2008 From: leather at cs.uu.nl (Sean Leather) Date: Thu Aug 14 13:59:38 2008 Subject: How to disable warning for "export item 'module ...' exports nothing"? In-Reply-To: <48A46BF6.9060003@charter.net> References: <3c6288ab0808141027p73b796edm87019afa58174a7a@mail.gmail.com> <48A46BF6.9060003@charter.net> Message-ID: <3c6288ab0808141100k329052cerb1597cf45c9e4073@mail.gmail.com> > I have a module A that re-exports module B, and module B contains only >> class >> instances. Since I'm using -Wall, I get this warning about module B >> exporting nothing. Is there a way to disable this particular warning, >> since >> it is unnecessary in this case? No mailing list messages or GHC >> documentation has told me what to do. >> > > Well, the warning is right that you don't need to re-export module B: > instances are implicitly exported. So you could just remove the export of > "module B", unless there's a reason to export it (such as, you might add > some exported functions or data types to it later) Hmm, the disappointing result of removing module B from the export list is that now it doesn't show up in the Haddock-generated documentation for module A. Not that there was anything specific in B to document, because it's only instances. But I do want the user to know that importing A also imports B. Sigh... I suppose there's CPP if I really want it. Sean -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20080814/04005418/attachment.htm From ndmitchell at gmail.com Thu Aug 14 18:34:11 2008 From: ndmitchell at gmail.com (Neil Mitchell) Date: Thu Aug 14 18:33:23 2008 Subject: Version control systems In-Reply-To: <48A28F11.4090307@gmail.com> References: <48981C03.10908@gmail.com> <9d4d38820808060331h4758c8a4y2bc6e79d14b8ae3d@mail.gmail.com> <18DB9581-AA5B-433C-9036-34EC2674C2CB@cse.unsw.edu.au> <20080808130329.GA15063@matrix.chaos.earth.li> <5FEA1F32-9C34-4888-A5BE-D0460D55C307@cse.unsw.edu.au> <48A05827.5020200@gmail.com> <638ABD0A29C8884A91BC5FB5C349B1C32AE8066602@EA-EXMSG-C334.europe.corp.microsoft.com> <4492B45B-6699-4444-87A9-83F0595B4EB7@cse.unsw.edu.au> <48A28F11.4090307@gmail.com> Message-ID: <404396ef0808141534i65ceae28ud23186d3f845714@mail.gmail.com> Hi > So I suggest we propose moving all the core packages to git, and we > translate all those for which nobody objects to the change. For the others, > we'll keep them in darcs and live with the pain. Does this mean my (now the communities) FilePath library is going to get moved over to git? I personally don't know Git, and while I'm sure I'll be learning at some point, I'm always nervous about learning a VCS on something I care about, as mistakes can go quite wrong. In addition, things like the Yhc build scripts already check out the darcs version, so will have to be modified*. If it really makes the life easier for people who are having lots of VCS pain at the moment, then its hard to object. But many of the comments in this discussion, about how everyone is going to flock to GHC just as soon as it switches to Git, seem overly optimistic. I think GHC is a few years off becoming drive-by hacker friendly, for many other reasons. The halfway house of switching the compiler, and leaving the libraries in darcs, seems desirable. If Git turns out to be wonderful, as people claim, moving the whole way over is fairly easy and a simple choice. Thanks Neil * Modifying the Yhc build scripts is much harder than modifying the GHC build script, as they are 10,000 lines of Python (a language I don't know) in a very complex framework (which I also don't know)! Of course, this is something for the Yhc team to deal with... From chak at cse.unsw.edu.au Thu Aug 14 19:59:58 2008 From: chak at cse.unsw.edu.au (Manuel M T Chakravarty) Date: Thu Aug 14 19:59:22 2008 Subject: Version control systems In-Reply-To: <404396ef0808141534i65ceae28ud23186d3f845714@mail.gmail.com> References: <48981C03.10908@gmail.com> <9d4d38820808060331h4758c8a4y2bc6e79d14b8ae3d@mail.gmail.com> <18DB9581-AA5B-433C-9036-34EC2674C2CB@cse.unsw.edu.au> <20080808130329.GA15063@matrix.chaos.earth.li> <5FEA1F32-9C34-4888-A5BE-D0460D55C307@cse.unsw.edu.au> <48A05827.5020200@gmail.com> <638ABD0A29C8884A91BC5FB5C349B1C32AE8066602@EA-EXMSG-C334.europe.corp.microsoft.com> <4492B45B-6699-4444-87A9-83F0595B4EB7@cse.unsw.edu.au> <48A28F11.4090307@gmail.com> <404396ef0808141534i65ceae28ud23186d3f845714@mail.gmail.com> Message-ID: <83BF150C-20EA-48AA-8C1B-BFC8B6CA71EB@cse.unsw.edu.au> Neil Mitchell: > If it really makes the life easier for people who are having lots of > VCS pain at the moment, then its hard to object. But many of the > comments in this discussion, about how everyone is going to flock to > GHC just as soon as it switches to Git, seem overly optimistic. I > think GHC is a few years off becoming drive-by hacker friendly, for > many other reasons. It's not about becoming "drive-by hacker friendly". It is about not becoming even less friendly as it is right now. Manuel From nominolo at googlemail.com Thu Aug 14 20:12:50 2008 From: nominolo at googlemail.com (Thomas Schilling) Date: Thu Aug 14 20:12:03 2008 Subject: Version control systems In-Reply-To: <83BF150C-20EA-48AA-8C1B-BFC8B6CA71EB@cse.unsw.edu.au> References: <48981C03.10908@gmail.com> <20080808130329.GA15063@matrix.chaos.earth.li> <5FEA1F32-9C34-4888-A5BE-D0460D55C307@cse.unsw.edu.au> <48A05827.5020200@gmail.com> <638ABD0A29C8884A91BC5FB5C349B1C32AE8066602@EA-EXMSG-C334.europe.corp.microsoft.com> <4492B45B-6699-4444-87A9-83F0595B4EB7@cse.unsw.edu.au> <48A28F11.4090307@gmail.com> <404396ef0808141534i65ceae28ud23186d3f845714@mail.gmail.com> <83BF150C-20EA-48AA-8C1B-BFC8B6CA71EB@cse.unsw.edu.au> Message-ID: <916b84820808141712t18d87a07v47bf7be012cd7725@mail.gmail.com> Are you advocating for ease of use by new developers or for existing developers? Current GHC hackers have to learn Git anyways and know Darcs already. Library patches still have to be recorded separately, so it would be a bit weird, but not much harder, really. On Fri, Aug 15, 2008 at 1:59 AM, Manuel M T Chakravarty wrote: > Neil Mitchell: >> >> If it really makes the life easier for people who are having lots of >> VCS pain at the moment, then its hard to object. But many of the >> comments in this discussion, about how everyone is going to flock to >> GHC just as soon as it switches to Git, seem overly optimistic. I >> think GHC is a few years off becoming drive-by hacker friendly, for >> many other reasons. > > It's not about becoming "drive-by hacker friendly". It is about not > becoming even less friendly as it is right now. > > Manuel > > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users@haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > From chak at cse.unsw.edu.au Thu Aug 14 21:12:20 2008 From: chak at cse.unsw.edu.au (Manuel M T Chakravarty) Date: Thu Aug 14 21:11:35 2008 Subject: Version control systems In-Reply-To: <916b84820808141712t18d87a07v47bf7be012cd7725@mail.gmail.com> References: <48981C03.10908@gmail.com> <20080808130329.GA15063@matrix.chaos.earth.li> <5FEA1F32-9C34-4888-A5BE-D0460D55C307@cse.unsw.edu.au> <48A05827.5020200@gmail.com> <638ABD0A29C8884A91BC5FB5C349B1C32AE8066602@EA-EXMSG-C334.europe.corp.microsoft.com> <4492B45B-6699-4444-87A9-83F0595B4EB7@cse.unsw.edu.au> <48A28F11.4090307@gmail.com> <404396ef0808141534i65ceae28ud23186d3f845714@mail.gmail.com> <83BF150C-20EA-48AA-8C1B-BFC8B6CA71EB@cse.unsw.edu.au> <916b84820808141712t18d87a07v47bf7be012cd7725@mail.gmail.com> Message-ID: <26D36D0E-3A57-4DF2-8D9E-07A876B12DE5@cse.unsw.edu.au> Thomas Schilling: > Are you advocating for ease of use by new developers or for existing > developers? Current GHC hackers have to learn Git anyways and know > Darcs already. Library patches still have to be recorded separately, > so it would be a bit weird, but not much harder, really. I am arguing for both. It would be more than weird. For example, if you branch ghc, you usually need to branch the core libraries, too. Doing that in two different vcs sounds like a mess to me. Moreover, as I wrote a few times before, some reasons for switching in the first place are invalidated by not having the core libraries in git, too. For example, one complaint about darcs is that it either doesn't build (on the Sun Solaris T1 and T2 machines) or is buggy (on Mac OS with MacPorts), and hence people have trouble getting the sources out of darcs in the first place. How is that going to be addressed if some crucial code still needs to be obtained using darcs? Manuel > On Fri, Aug 15, 2008 at 1:59 AM, Manuel M T Chakravarty > wrote: >> Neil Mitchell: >>> >>> If it really makes the life easier for people who are having lots of >>> VCS pain at the moment, then its hard to object. But many of the >>> comments in this discussion, about how everyone is going to flock to >>> GHC just as soon as it switches to Git, seem overly optimistic. I >>> think GHC is a few years off becoming drive-by hacker friendly, for >>> many other reasons. >> >> It's not about becoming "drive-by hacker friendly". It is about not >> becoming even less friendly as it is right now. From rl at cse.unsw.edu.au Fri Aug 15 00:06:17 2008 From: rl at cse.unsw.edu.au (Roman Leshchinskiy) Date: Fri Aug 15 00:05:39 2008 Subject: Build system idea In-Reply-To: <48A3E65E.7030609@gmail.com> References: <48A161DA.3010106@gmail.com> <061FA30C-4326-4B65-A80F-096593C81D6C@cse.unsw.edu.au> <48A29175.1030907@gmail.com> <4D6AF7CE-B789-4021-898D-876475DEABF2@cse.unsw.edu.au> <48A2B898.5080701@gmail.com> <48F76A30-31A2-434F-BA37-BFADBA42C3F5@cse.unsw.edu.au> <1218659559.7661.553.camel@localhost> <48A3E65E.7030609@gmail.com> Message-ID: <5C2823E3-6E57-4F26-9EA7-38A7F51BEF6F@cse.unsw.edu.au> On 14/08/2008, at 18:01, Simon Marlow wrote: > Roman Leshchinskiy wrote: > >> But that is precisely my (other) point. A lot of that work is >> really unnecessary and could be done by Cabal since it only or >> mostly depends on the package information. Instead, it is >> implemented somewhere in Distribution.Simple and not really usable >> from the outside. For instance, a lot of the functionality of setup >> sdist, setup register and so on could be implemented generically >> and used by a make-based build system as well. > > That's exactly what I'm proposing we do in GHC: re-use Cabal's setup > register and some of the other parts of the simple build system in a > make-based build system for packages. It might require a bit of > refactoring of Cabal, but I don't expect it to be a major upheaval > at all. Ah! I hadn't realised that you are going to reuse Cabal functionality. You wrote "Extract the code from Cabal that generates Makefiles" so I thought you won't be really using anything from Cabal. > I think what you're proposing is mostly a matter of abstracting > parts of Cabal with cleaner and more modular APIs, which is > absolutely a good thing, but doesn't require a fundamental > redesign. The tight coupling and lack of separation between Cabal's > generic parts and the simple build system is somewhat accidental > (lazy implementors :-), and is actually a lot better than it used to > be thanks to the work Duncan has put in. I'm sure it'll improve > further over time. IMO, getting this right is absolutely crucial for Cabal's usability and should be the primary short-term goal. Then again, I guess I should contribute code instead of opinions already :-) > The other part of your complaint is that the BuildInfo is in > the .cabal file along with the PackageDescription (the types are > pretty well separated internally). Again I don't think there's > anything fundamental here, and in fact some packages have > separate .buildinfo files. Well, it is fundamental in the sense that this is how Cabal is used (and is supposed to be used) at the moment. It is good that Cabal separates these things internally but the separation should be enforced in the external interface, as well. Roman From tensor5 at gmail.com Fri Aug 15 01:02:31 2008 From: tensor5 at gmail.com (Nicola Squartini) Date: Fri Aug 15 01:01:49 2008 Subject: How to produce a statically linked binary with GHC? In-Reply-To: <20080812202138.GE23698@scytale.galois.com> References: <2e981ed0808121236i25ce6209jf7894d2af3ac3422@mail.gmail.com> <20080812202138.GE23698@scytale.galois.com> Message-ID: <1218776551.2664.11.camel@eukleidis> I did the following in my project and this is what I get: $> runhaskell Setup configure --user --ghc-option="-optl -static" $> runhaskell Setup build ... ... /usr/lib/gcc/x86_64-pc-linux-gnu/4.2.1/../../../../lib/librt.a(timer_create.o): In function `timer_create': (.text+0x124): undefined reference to `pthread_once' /usr/lib/gcc/x86_64-pc-linux-gnu/4.2.1/../../../../lib/librt.a(timer_create.o): In function `timer_create': (.text+0x171): undefined reference to `pthread_attr_init' /usr/lib/gcc/x86_64-pc-linux-gnu/4.2.1/../../../../lib/librt.a(timer_create.o): In function `timer_create': (.text+0x1b8): undefined reference to `pthread_attr_setdetachstate' /usr/lib/gcc/x86_64-pc-linux-gnu/4.2.1/../../../../lib/librt.a(timer_routines.o): In function `__start_helper_thread': (.text+0x3f): undefined reference to `pthread_attr_init' /usr/lib/gcc/x86_64-pc-linux-gnu/4.2.1/../../../../lib/librt.a(timer_routines.o): In function `__start_helper_thread': (.text+0x4c): undefined reference to `pthread_attr_setstacksize' /usr/lib/gcc/x86_64-pc-linux-gnu/4.2.1/../../../../lib/librt.a(timer_routines.o): In function `__start_helper_thread': (.text+0x92): undefined reference to `pthread_create' /usr/lib/gcc/x86_64-pc-linux-gnu/4.2.1/../../../../lib/librt.a(timer_routines.o): In function `__start_helper_thread': (.text+0xc6): undefined reference to `pthread_attr_destroy' /usr/lib/gcc/x86_64-pc-linux-gnu/4.2.1/../../../../lib/librt.a(timer_routines.o): In function `__start_helper_thread': (.text+0xd4): undefined reference to `pthread_atfork' /usr/lib/gcc/x86_64-pc-linux-gnu/4.2.1/../../../../lib/librt.a(timer_routines.o): In function `timer_helper_thread': (.text+0x1e1): undefined reference to `pthread_exit' /usr/lib/gcc/x86_64-pc-linux-gnu/4.2.1/../../../../lib/librt.a(timer_routines.o): In function `timer_helper_thread': (.text+0x21b): undefined reference to `pthread_create' /usr/lib/gcc/x86_64-pc-linux-gnu/4.2.1/libgcc_eh.a(unwind-dw2.o): In function `uw_init_context_1': (.text+0x1b65): undefined reference to `pthread_once' collect2: ld returned 1 exit status Basically when GHC calls GCC it forgets to add -lpthread. By the way without --ghc-option="-optl -static" everything works and it produces a nice dynamic binary. Regards Nicola On Tue, 2008-08-12 at 13:21 -0700, Don Stewart wrote: > tensor5: > > It seems that the -static flag serves a different purpose: according to > > the GHC manual it forces the compiler use the static Haskell libraries, > > but the resulting binary is still dynamically linked to the C libraries. > > What is the correct flag to create a static binary? Thanks > > Pass -optl-static to GHC. > > -- Don -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20080814/535513d3/attachment-0001.htm From allbery at ece.cmu.edu Fri Aug 15 01:06:08 2008 From: allbery at ece.cmu.edu (Brandon S. Allbery KF8NH) Date: Fri Aug 15 01:05:23 2008 Subject: How to produce a statically linked binary with GHC? In-Reply-To: <1218776551.2664.11.camel@eukleidis> References: <2e981ed0808121236i25ce6209jf7894d2af3ac3422@mail.gmail.com> <20080812202138.GE23698@scytale.galois.com> <1218776551.2664.11.camel@eukleidis> Message-ID: <28100FE1-257A-4125-9F17-853E02DEF861@ece.cmu.edu> On 2008 Aug 15, at 1:02, Nicola Squartini wrote: > I did the following in my project and this is what I get: > > $> runhaskell Setup configure --user --ghc-option="-optl -static" No space between "-optl" and "-static". The "-pthread" is probably being misrecognized as a result of the generated command. -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20080815/51b7a545/attachment.htm From tensor5 at gmail.com Fri Aug 15 01:40:33 2008 From: tensor5 at gmail.com (Nicola Squartini) Date: Fri Aug 15 01:39:45 2008 Subject: How to produce a statically linked binary with GHC? In-Reply-To: <28100FE1-257A-4125-9F17-853E02DEF861@ece.cmu.edu> References: <2e981ed0808121236i25ce6209jf7894d2af3ac3422@mail.gmail.com> <20080812202138.GE23698@scytale.galois.com> <1218776551.2664.11.camel@eukleidis> <28100FE1-257A-4125-9F17-853E02DEF861@ece.cmu.edu> Message-ID: <2e981ed0808142240wc335f2g2ddec1b16cfa62ea@mail.gmail.com> Same result. When I type $> runhaskell Setup build --verbose=3 I see this ... gcc -v -o dist/build/lambdaInit/lambdaInit dist/build/lambdaInit/lambdaInit-tmp/Main.o -static -L/usr/lib/ghc-6.8.2/lib/hinotify-0.2 -L/usr/lib/ghc-6.8.2/lib/containers-0.1.0.1 -L/home/nicola/ghc//lib/VolumeID-0.1/ghc-6.8.2 -L/home/nicola/ghc/lib/Mount-0.1/ghc-6.8.2 -L/usr/lib/ghc-6.8.2/lib/regex-compat-0.71.0.1 -L/usr/lib/ghc-6.8.2/lib/regex-posix-0.72.0.2 -L/usr/lib/ghc-6.8.2/lib/regex-base-0.72.0.1 -L/usr/lib/ghc-6.8.2/lib/bytestring-0.9.0.1 -L/usr/lib/ghc-6.8.2/lib/array-0.1.0.0 -L/usr/lib/ghc-6.8.2/lib/process-1.0.0.0 -L/usr/lib/ghc-6.8.2/lib/unix-2.3.0.0 -L/usr/lib/ghc-6.8.2/lib/directory-1.0.0.0 -L/usr/lib/ghc-6.8.2/lib/filepath-1.1.0.0 -L/usr/lib/ghc-6.8.2/lib/old-time-1.0.0.0 -L/usr/lib/ghc-6.8.2/lib/old-locale-1.0.0.0 -L/usr/lib/ghc-6.8.2/lib/base-3.0.1.0 -L/usr/lib/ghc-6.8.2 -lHShinotify-0.2 -lHScontainers-0.1.0.1 -lHSVolumeID-0.1 -lvolume_id -lHSMount-0.1 -lHSregex-compat-0.71.0.1 -lHSregex-posix-0.72.0.2 -lHSregex-base-0.72.0.1 -lHSbytestring-0.9.0.1 -lHSarray-0.1.0.0 -lHSprocess-1.0.0.0 -lHSunix-2.3.0.0 -lutil -ldl -lHSdirectory-1.0.0.0 -lHSfilepath-1.1.0.0 -lHSold-time-1.0.0.0 -lHSold-locale-1.0.0.0 -lHSbase-3.0.1.0 -lHSrts -lm -lgmp -ldl -lrt -u base_GHCziBase_Izh_static_info -u base_GHCziBase_Czh_static_info -u base_GHCziFloat_Fzh_static_info -u base_GHCziFloat_Dzh_static_info -u base_GHCziPtr_Ptr_static_info -u base_GHCziWord_Wzh_static_info -u base_GHCziInt_I8zh_static_info -u base_GHCziInt_I16zh_static_info -u base_GHCziInt_I32zh_static_info -u base_GHCziInt_I64zh_static_info -u base_GHCziWord_W8zh_static_info -u base_GHCziWord_W16zh_static_info -u base_GHCziWord_W32zh_static_info -u base_GHCziWord_W64zh_static_info -u base_GHCziStable_StablePtr_static_info -u base_GHCziBase_Izh_con_info -u base_GHCziBase_Czh_con_info -u base_GHCziFloat_Fzh_con_info -u base_GHCziFloat_Dzh_con_info -u base_GHCziPtr_Ptr_con_info -u base_GHCziPtr_FunPtr_con_info -u base_GHCziStable_StablePtr_con_info -u base_GHCziBase_False_closure -u base_GHCziBase_True_closure -u base_GHCziPack_unpackCString_closure -u base_GHCziIOBase_stackOverflow_closure -u base_GHCziIOBase_heapOverflow_closure -u base_GHCziIOBase_NonTermination_closure -u base_GHCziIOBase_BlockedOnDeadMVar_closure -u base_GHCziIOBase_BlockedIndefinitely_closure -u base_GHCziIOBase_Deadlock_closure -u base_GHCziIOBase_NestedAtomically_closure -u base_GHCziWeak_runFinalizzerBatch_closure -u base_GHCziConc_ensureIOManagerIsRunning_closure ... So I run that gcc command manually adding -lpthread at the end of it end it works, I get the static binary. Isn't it strange? It could be a gcc problem. On Thu, Aug 14, 2008 at 10:06 PM, Brandon S. Allbery KF8NH < allbery@ece.cmu.edu> wrote: > > On 2008 Aug 15, at 1:02, Nicola Squartini wrote: > > I did the following in my project and this is what I get: > > $> runhaskell Setup configure --user --ghc-option="-optl -static" > > > No space between "-optl" and "-static". The "-pthread" is probably being > misrecognized as a result of the generated command. > > -- > brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com > system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu > electrical and computer engineering, carnegie mellon university KF8NH > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20080814/9e015dd1/attachment.htm From agentzh at gmail.com Fri Aug 15 02:30:56 2008 From: agentzh at gmail.com (Agent Zhang) Date: Fri Aug 15 02:30:08 2008 Subject: How to produce a statically linked binary with GHC? In-Reply-To: <2e981ed0808142240wc335f2g2ddec1b16cfa62ea@mail.gmail.com> References: <2e981ed0808121236i25ce6209jf7894d2af3ac3422@mail.gmail.com> <20080812202138.GE23698@scytale.galois.com> <1218776551.2664.11.camel@eukleidis> <28100FE1-257A-4125-9F17-853E02DEF861@ece.cmu.edu> <2e981ed0808142240wc335f2g2ddec1b16cfa62ea@mail.gmail.com> Message-ID: 2008/8/15 Nicola Squartini > > So I run that gcc command manually adding -lpthread at the end of it end it works, > I get the static binary. Isn't it strange? It could be a gcc problem. Well, it needn't be that hacky ;) The following command works for me and it does essentially the same thing: ghc -i -static -optl-static -optl-pthread -funbox-strict-fields -fwarn-incomplete-patterns -isrc --make Main -o bin/restyscript Please note that without -optl-pthread option, I'll get exactly the same errors: Linking bin/restyscript ... /usr/lib/gcc/i486-linux-gnu/4.2.3/../../../../lib/librt.a(timer_create.o): In function `timer_create': (.text+0x117): undefined reference to `pthread_once' /usr/lib/gcc/i486-linux-gnu/4.2.3/../../../../lib/librt.a(timer_create.o): In function `timer_create': ... -lpthread needs to be put to the end of the argument list to help gcc or ld solve the symbols properly. Hope this helps ;) -agentzh From gwright at comcast.net Fri Aug 15 02:48:17 2008 From: gwright at comcast.net (Gregory Wright) Date: Fri Aug 15 02:48:01 2008 Subject: Version control systems In-Reply-To: <26D36D0E-3A57-4DF2-8D9E-07A876B12DE5@cse.unsw.edu.au> References: <48981C03.10908@gmail.com> <20080808130329.GA15063@matrix.chaos.earth.li> <5FEA1F32-9C34-4888-A5BE-D0460D55C307@cse.unsw.edu.au> <48A05827.5020200@gmail.com> <638ABD0A29C8884A91BC5FB5C349B1C32AE8066602@EA-EXMSG-C334.europe.corp.microsoft.com> <4492B45B-6699-4444-87A9-83F0595B4EB7@cse.unsw.edu.au> <48A28F11.4090307@gmail.com> <404396ef0808141534i65ceae28ud23186d3f845714@mail.gmail.com> <83BF150C-20EA-48AA-8C1B-BFC8B6CA71EB@cse.unsw.edu.au> <916b84820808141712t18d87a07v47bf7be012cd7725@mail.gmail.com> <26D36D0E-3A57-4DF2-8D9E-07A876B12DE5@cse.unsw.edu.au> Message-ID: Hi Manuel, On Aug 14, 2008, at 9:12 PM, Manuel M T Chakravarty wrote: > Moreover, as I wrote a few times before, some reasons for switching > in the first place are invalidated by not having the core libraries > in git, too. For example, one complaint about darcs is that it > either doesn't build (on the Sun Solaris T1 and T2 machines) or is > buggy (on Mac OS with MacPorts), and hence people have trouble > getting the sources out of darcs in the first place. How is that > going to be addressed if some crucial code still needs to be > obtained using darcs? > Regarding darcs on OS X from MacPorts, I am not aware (or have been sent any bug reports) that there are problems with the latest darcs-2.0.0 port. Is there something that I should know (and try to fix)? The latest port defaults to wget instead of libcurl since I have noticed darcs spinning endlessly when using libcurl. I haven't had time to dtrace what is going on but I'm guessing the underlying problem is likely some misunderstanding of the signal handling API or some corner case of blocking/nonblocking IO. -Greg From tensor5 at gmail.com Fri Aug 15 02:55:48 2008 From: tensor5 at gmail.com (Nicola Squartini) Date: Fri Aug 15 02:55:01 2008 Subject: How to produce a statically linked binary with GHC? In-Reply-To: References: <2e981ed0808121236i25ce6209jf7894d2af3ac3422@mail.gmail.com> <20080812202138.GE23698@scytale.galois.com> <1218776551.2664.11.camel@eukleidis> <28100FE1-257A-4125-9F17-853E02DEF861@ece.cmu.edu> <2e981ed0808142240wc335f2g2ddec1b16cfa62ea@mail.gmail.com> Message-ID: <2e981ed0808142355p4003a85bp9bac4690f1c4576a@mail.gmail.com> It works! This is much easier, thank you Nicola On Thu, Aug 14, 2008 at 11:30 PM, Agent Zhang wrote: > 2008/8/15 Nicola Squartini > > > > So I run that gcc command manually adding -lpthread at the end of it end > it works, > > I get the static binary. Isn't it strange? It could be a gcc problem. > > Well, it needn't be that hacky ;) The following command works for me > and it does essentially the same thing: > > ghc -i -static -optl-static -optl-pthread -funbox-strict-fields > -fwarn-incomplete-patterns -isrc --make Main -o bin/restyscript > > Please note that without -optl-pthread option, I'll get exactly the same > errors: > > Linking bin/restyscript ... > /usr/lib/gcc/i486-linux-gnu/4.2.3/../../../../lib/librt.a(timer_create.o): > In function `timer_create': > (.text+0x117): undefined reference to `pthread_once' > /usr/lib/gcc/i486-linux-gnu/4.2.3/../../../../lib/librt.a(timer_create.o): > In function `timer_create': > ... > > -lpthread needs to be put to the end of the argument list to help gcc > or ld solve the symbols properly. > > Hope this helps ;) > > -agentzh > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20080814/36d59615/attachment-0001.htm From peteg42 at gmail.com Fri Aug 15 04:20:54 2008 From: peteg42 at gmail.com (Peter Gammie) Date: Fri Aug 15 04:20:05 2008 Subject: How to produce a statically linked binary with GHC? In-Reply-To: <2e981ed0808142355p4003a85bp9bac4690f1c4576a@mail.gmail.com> References: <2e981ed0808121236i25ce6209jf7894d2af3ac3422@mail.gmail.com> <20080812202138.GE23698@scytale.galois.com> <1218776551.2664.11.camel@eukleidis> <28100FE1-257A-4125-9F17-853E02DEF861@ece.cmu.edu> <2e981ed0808142240wc335f2g2ddec1b16cfa62ea@mail.gmail.com> <2e981ed0808142355p4003a85bp9bac4690f1c4576a@mail.gmail.com> Message-ID: <717927700808150120i4bbc0548l47e2bb9449e82350@mail.gmail.com> Nicola: I had the same problem using the GHC 6.8.2 Debian package. Igloo promises me that GHC 6.8.3 fixes this problem, but I haven't seen that in the Debian repository yet. cheers peter 2008/8/15 Nicola Squartini : > It works! This is much easier, thank you > > Nicola From agentzh at gmail.com Fri Aug 15 04:47:26 2008 From: agentzh at gmail.com (Agent Zhang) Date: Fri Aug 15 04:46:38 2008 Subject: How to produce a statically linked binary with GHC? In-Reply-To: <717927700808150120i4bbc0548l47e2bb9449e82350@mail.gmail.com> References: <2e981ed0808121236i25ce6209jf7894d2af3ac3422@mail.gmail.com> <20080812202138.GE23698@scytale.galois.com> <1218776551.2664.11.camel@eukleidis> <28100FE1-257A-4125-9F17-853E02DEF861@ece.cmu.edu> <2e981ed0808142240wc335f2g2ddec1b16cfa62ea@mail.gmail.com> <2e981ed0808142355p4003a85bp9bac4690f1c4576a@mail.gmail.com> <717927700808150120i4bbc0548l47e2bb9449e82350@mail.gmail.com> Message-ID: On Fri, Aug 15, 2008 at 4:20 PM, Peter Gammie wrote: > Nicola: I had the same problem using the GHC 6.8.2 Debian package. > Igloo promises me that GHC 6.8.3 fixes this problem, but I haven't > seen that in the Debian repository yet. > GHC 6.8.3 does not have this problem at least on my machine ;) Regards, -agentzh From isaacdupree at charter.net Fri Aug 15 07:04:43 2008 From: isaacdupree at charter.net (Isaac Dupree) Date: Fri Aug 15 07:03:59 2008 Subject: Haddocking exported instances [was Re: How to disable warning for "export item 'module ...' exports nothing"?] In-Reply-To: <3c6288ab0808141100k329052cerb1597cf45c9e4073@mail.gmail.com> References: <3c6288ab0808141027p73b796edm87019afa58174a7a@mail.gmail.com> <48A46BF6.9060003@charter.net> <3c6288ab0808141100k329052cerb1597cf45c9e4073@mail.gmail.com> Message-ID: <48A562CB.9090409@charter.net> Sean Leather wrote: >> I have a module A that re-exports module B, and module B contains only >>> class >>> instances. Since I'm using -Wall, I get this warning about module B >>> exporting nothing. Is there a way to disable this particular warning, >>> since >>> it is unnecessary in this case? No mailing list messages or GHC >>> documentation has told me what to do. >>> >> Well, the warning is right that you don't need to re-export module B: >> instances are implicitly exported. So you could just remove the export of >> "module B", unless there's a reason to export it (such as, you might add >> some exported functions or data types to it later) > > > Hmm, the disappointing result of removing module B from the export list is > that now it doesn't show up in the Haddock-generated documentation for > module A. Not that there was anything specific in B to document, because > it's only instances. But I do want the user to know that importing A also > imports B. Sigh... I suppose there's CPP if I really want it. You could put a link to the module in the intro-documentation that comes before the export list, possibly in a sentence saying e.g. "deliberately exports instances from @module B@" (except I've forgotten Haddock syntax and might have used it wrong there :-) It's an interesting use-case though. I wonder if Haddock should automatically provide links to all instances exported from the module that are either (1) instances for datatypes or classes exported by the module, or (2) orphan (i.e. not defined in the same module as either the class or the datatype). (It would be too tedious to list *all* exported instances, but luckily it's not necessary for completeness.) -Isaac From isaacdupree at charter.net Fri Aug 15 07:13:24 2008 From: isaacdupree at charter.net (Isaac Dupree) Date: Fri Aug 15 07:12:40 2008 Subject: Version control systems In-Reply-To: <26D36D0E-3A57-4DF2-8D9E-07A876B12DE5@cse.unsw.edu.au> References: <48981C03.10908@gmail.com> <20080808130329.GA15063@matrix.chaos.earth.li> <5FEA1F32-9C34-4888-A5BE-D0460D55C307@cse.unsw.edu.au> <48A05827.5020200@gmail.com> <638ABD0A29C8884A91BC5FB5C349B1C32AE8066602@EA-EXMSG-C334.europe.corp.microsoft.com> <4492B45B-6699-4444-87A9-83F0595B4EB7@cse.unsw.edu.au> <48A28F11.4090307@gmail.com> <404396ef0808141534i65ceae28ud23186d3f845714@mail.gmail.com> <83BF150C-20EA-48AA-8C1B-BFC8B6CA71EB@cse.unsw.edu.au> <916b84820808141712t18d87a07v47bf7be012cd7725@mail.gmail.com> <26D36D0E-3A57-4DF2-8D9E-07A876B12DE5@cse.unsw.edu.au> Message-ID: <48A564D4.3000806@charter.net> Manuel M T Chakravarty wrote: > Thomas Schilling: >> Are you advocating for ease of use by new developers or for existing >> developers? Current GHC hackers have to learn Git anyways and know >> Darcs already. Library patches still have to be recorded separately, >> so it would be a bit weird, but not much harder, really. > > I am arguing for both. It would be more than weird. For example, if > you branch ghc, you usually need to branch the core libraries, too. > Doing that in two different vcs sounds like a mess to me. So let's figure out how it would work (I have doubts too!) So, within the directory that's a git repo (ghc), we have some other repos, git (testsuite) and darcs (some libraries). Does anyone know how git handles nested repos even natively? Then, adding complexity, git branches are normally done by switching in-place. So how does this interact with VCS like darcs that doesn't have a concept of in-place switching of branches? (Now, I wouldn't be surprised if git, the monstrosity that it is, has already invented answers for these sort of questions :-) But we need to figure out the answers for whatever situation we choose for the 6.11 development cycle, and probably document them somewhere on the wiki (that I lazily didn't bother to check again before writing this message). -Isaac From ross at soi.city.ac.uk Fri Aug 15 07:36:41 2008 From: ross at soi.city.ac.uk (Ross Paterson) Date: Fri Aug 15 07:35:54 2008 Subject: How to disable warning for "export item 'module ...' exports nothing"? In-Reply-To: <3c6288ab0808141100k329052cerb1597cf45c9e4073@mail.gmail.com> References: <3c6288ab0808141027p73b796edm87019afa58174a7a@mail.gmail.com> <48A46BF6.9060003@charter.net> <3c6288ab0808141100k329052cerb1597cf45c9e4073@mail.gmail.com> Message-ID: <20080815113640.GA4130@soi.city.ac.uk> On Thu, Aug 14, 2008 at 08:00:25PM +0200, Sean Leather wrote: > Well, the warning is right that you don't need to re-export module B: > instances are implicitly exported. So you could just remove the export of > "module B", unless there's a reason to export it (such as, you might add > some exported functions or data types to it later) > > Hmm, the disappointing result of removing module B from the export list > is that now it doesn't show up in the Haddock-generated documentation > for module A. Not that there was anything specific in B to document, > because it's only instances. But I do want the user to know that > importing A also imports B. Sigh... I suppose there's CPP if I really > want it. That shouldn't be necessary. Because instances are implicitly exported and imported, you'll really want to avoid orphan instances, so that the user can be sure that if both the class and the data type are in scope, so is the instance. But then the instance will be listed under both the class and the type in the Haddock documentation. It won't matter where the instance was defined, just as it doesn't matter where other stuff is defined, just where it is in scope. Unfortunately Haddock does not allow doc comments to be attached to instances, but that's independent of whether the defining module is shown. From batterseapower at hotmail.com Fri Aug 15 08:01:08 2008 From: batterseapower at hotmail.com (Max Bolingbroke) Date: Fri Aug 15 08:00:20 2008 Subject: Version control systems In-Reply-To: <48A564D4.3000806@charter.net> References: <48981C03.10908@gmail.com> <638ABD0A29C8884A91BC5FB5C349B1C32AE8066602@EA-EXMSG-C334.europe.corp.microsoft.com> <4492B45B-6699-4444-87A9-83F0595B4EB7@cse.unsw.edu.au> <48A28F11.4090307@gmail.com> <404396ef0808141534i65ceae28ud23186d3f845714@mail.gmail.com> <83BF150C-20EA-48AA-8C1B-BFC8B6CA71EB@cse.unsw.edu.au> <916b84820808141712t18d87a07v47bf7be012cd7725@mail.gmail.com> <26D36D0E-3A57-4DF2-8D9E-07A876B12DE5@cse.unsw.edu.au> <48A564D4.3000806@charter.net> Message-ID: <9d4d38820808150501n17c8d56g730dc2b5d4e99126@mail.gmail.com> 2008/8/15 Isaac Dupree : > So let's figure out how it would work (I have doubts too!) So, within the > directory that's a git repo (ghc), we have some other repos, git (testsuite) > and darcs (some libraries). Does anyone know how git handles nested repos > even natively? You can explicitly tell Git about nested Git repos using http://www.kernel.org/pub/software/scm/git/docs/git-submodule.html. This essentially associates a particular version of each subrepo with every version of the repo that contains them, so e.g. checking out GHC from 2 weeks ago could check out the libraries from the same point in time. AFAIK, nothing in Git caters for subrepos of a different VCS. > Then, adding complexity, git branches are normally done by > switching in-place. So how does this interact with VCS like darcs that > doesn't have a concept of in-place switching of branches? Since we will set up Git to ignore the contents of the Darcs repos, it will simply leave them unmodified. This is exactly like the current situation, where rolling back / patching the GHC repo does not affect the others. If you want Darcs-like behaviour (one branch per repo) you are free to do this in Git as well, in which case since you never switch branches the nested Darcs repos should never be inappropriate for your branch. Personally, since I only ever hack GHC and tend to leave the libraries alone, I could still use the in-place branching without difficulty. > (Now, I wouldn't > be surprised if git, the monstrosity that it is, has already invented > answers for these sort of questions :-) But we need to figure out the > answers for whatever situation we choose for the 6.11 development cycle, and > probably document them somewhere on the wiki (that I lazily didn't bother to > check again before writing this message). The situation above is pretty much the whole story, if we are taking the route where we just convert the GHC+testsuite repo to Git. I don't think it's particularly confusing, but maybe that's because I've spent too long thinking about VCSs :-). This thread has got quite large, and doesn't appear to have made much progress towards a resolution. Let me try and sum up the discussion so far. There seem to be four stakeholders in this switch: a) Current GHC developers b) Future GHC developers c) People who just contribute to the libaries d) Maintainers of other compilers GHC shares repos with And there are at least 5 options for how to proceed: 1) Convert just GHC and Testsuite to Git, leave everything else in Darcs Pros: - No change in habits required for stakeholders c, d - Resolves all Darcs issues discussed at length before, pleasing stakeholders a, b Cons: - Requires two VCSs to be installed and learnt (more points of failure, makes source tree less accessible, doesn't solve any Darcs' build+install problems), affecting stakeholders a and b - Difficult to check out a consistent version of the source tree (no submodules), affecting stakeholders a and b 2) Wait for Darcs2 to get better Pros: - No change in habits required for any stakeholders (though we still have one-off switching cost) - Potentially resolves all Darcs issues, pleasing stakeholders a, b - Only option that will not require a workflow change for GHC developers (more topic branches rather than "spontaneous branches" and cherry-picking), pleasing stakeholders a Cons: - Darcs will probably continue to be less popular and well supported than Git (see Debian popcon graphs for the trend difference). Reduced popularity will affect the ability of stakeholders b to contribute (learning barrier), and less support/real world use may potentially lead to a higher incidence of bugs encountered, affecting stakeholders a-d. This point is certainly debatable. - Apparently somewhat vaporware at the moment 3) Convert all repos to Git Pros: - Native Git submodule integration, makes life easier for stakeholders a-b - Single (popular) command set to learn, single thing to install: makes life better for stakeholder b at least Cons: - Significant inconvenience for stakeholders c-d as they have to change their own projects 4) Branch all repos into Git but leave the Darcs repos alone and push Darcs patches into the Git repos automatically. Never push to these Git repos in any other way, similar to Cabal repo currently Pros: - As option 3 - Stakeholders c-d do not need to do anything Cons: - Makes it harder to hack on the libraries within a GHC checkout, affecting a, b - Automatic synchronisation will require occasional maintenance by someone 5) Branch all repos into Git and then set up a manual merging / sync process that tries to turn Git commits into Darcs patches and vice-versa Pros: - As option 3 - Hack on the libraries in a GHC checkout with ease, pleasing a, b - Stakeholders c-d do not need to do anything Cons: - Synchronisation much more fragile than 4), will likely require constant maintenance This summary is probably incomplete and inaccurate. However, if people find it useful for organising the various lines of discussion on this issue, perhaps someone could Wikify it so we can get a complete, clear picture? My personal preference is for 3), but that's because I'm a stakeholder "a" who isn't a great fan of spontaneous branches! Anyway, there are good arguments on every side, so I don't want to advocate a particular position (and indeed, my opinions quite rightly do not carry any weight! :-). However I'd really like for us to work out what is going on so we have a clear plan for moving away from Darcs 1, which is an inadequate VCS for GHC for reasons that have been discussed to death. I hope (perhaps naively) that this email can provide a framework for reaching a consensus agreeable to all parties. All the best, Max From leather at cs.uu.nl Fri Aug 15 08:05:17 2008 From: leather at cs.uu.nl (Sean Leather) Date: Fri Aug 15 08:04:29 2008 Subject: Haddocking exported instances [was Re: How to disable warning for "export item 'module ...' exports nothing"?] In-Reply-To: <48A562CB.9090409@charter.net> References: <3c6288ab0808141027p73b796edm87019afa58174a7a@mail.gmail.com> <48A46BF6.9060003@charter.net> <3c6288ab0808141100k329052cerb1597cf45c9e4073@mail.gmail.com> <48A562CB.9090409@charter.net> Message-ID: <3c6288ab0808150505t2fc2bbc7u1d6866dd200f9b9a@mail.gmail.com> Isaac Dupree wrote: > Sean Leather wrote: > >> I have a module A that re-exports module B, and module B contains only >>> >>>> class >>>> instances. Since I'm using -Wall, I get this warning about module B >>>> exporting nothing. Is there a way to disable this particular warning, >>>> since >>>> it is unnecessary in this case? No mailing list messages or GHC >>>> documentation has told me what to do. >>>> >>>> Well, the warning is right that you don't need to re-export module B: >>> instances are implicitly exported. So you could just remove the export >>> of >>> "module B", unless there's a reason to export it (such as, you might add >>> some exported functions or data types to it later) >>> >> >> >> Hmm, the disappointing result of removing module B from the export list is >> that now it doesn't show up in the Haddock-generated documentation for >> module A. Not that there was anything specific in B to document, because >> it's only instances. But I do want the user to know that importing A also >> imports B. Sigh... I suppose there's CPP if I really want it. >> > So, I tried to do the above with CPP, and I can't get Haddock to recognize that it should list this. Here's what it looks like: module A ( module Z, #ifdef __HADDOCK__ module B #endif ) where ... I added "extensions: CPP" to the .cabal file as I saw instructed in some Cabal thread from long ago. Building works such that I don't get the warning, but "cabal haddock" just acts as if it doesn't recognize __HADDOCK__. Assuming I'm not doing anything wrong, this might be a Cabal problem. You could put a link to the module in the intro-documentation that comes > before the export list, possibly in a sentence saying e.g. "deliberately > exports instances from @module B@" (except I've forgotten Haddock syntax > and might have used it wrong there :-) > Yep, that is an option. I noticed it in the documentation for another package, the name of which escapes me right now. It's an interesting use-case though. I wonder if Haddock should > automatically provide links to all instances exported from the module that > are either (1) instances for datatypes or classes exported by the module, or > (2) orphan (i.e. not defined in the same module as either the class or the > datatype). (It would be too tedious to list *all* exported instances, but > luckily it's not necessary for completeness.) > Yeah, I think instances should be documented in general. But, I agree with Ross in the previous thread, that's a different story. Sean -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20080815/a19c6996/attachment-0001.htm From leather at cs.uu.nl Fri Aug 15 08:21:33 2008 From: leather at cs.uu.nl (Sean Leather) Date: Fri Aug 15 08:20:43 2008 Subject: How to disable warning for "export item 'module ...' exports nothing"? In-Reply-To: <20080815113640.GA4130@soi.city.ac.uk> References: <3c6288ab0808141027p73b796edm87019afa58174a7a@mail.gmail.com> <48A46BF6.9060003@charter.net> <3c6288ab0808141100k329052cerb1597cf45c9e4073@mail.gmail.com> <20080815113640.GA4130@soi.city.ac.uk> Message-ID: <3c6288ab0808150521t2534191dwa98513c1e462cc15@mail.gmail.com> Ross Paterson wrote: > On Thu, Aug 14, 2008 at 08:00:25PM +0200, Sean Leather wrote: > > Well, the warning is right that you don't need to re-export module B: > > instances are implicitly exported. So you could just remove the > export of > > "module B", unless there's a reason to export it (such as, you might > add > > some exported functions or data types to it later) > > > > Hmm, the disappointing result of removing module B from the export list > > is that now it doesn't show up in the Haddock-generated documentation > > for module A. Not that there was anything specific in B to document, > > because it's only instances. But I do want the user to know that > > importing A also imports B. Sigh... I suppose there's CPP if I really > > want it. > > That shouldn't be necessary. Because instances are implicitly exported > and imported, you'll really want to avoid orphan instances, so that the > user can be sure that if both the class and the data type are in scope, > so is the instance. But then the instance will be listed under both > the class and the type in the Haddock documentation. It won't matter > where the instance was defined, just as it doesn't matter where other > stuff is defined, just where it is in scope. > In my case, it does matter where instances are in scope. My library requires orphan instances by design. If the programmer imports the top-level module, then s/he gets a default set of instances. But the programmer has the option to import select modules and get a different set of classes and instances. My goal was to put the default set of instances into a separate module and re-export that from a higher-level module. That way, it is more clearly documented where things are located. Unfortunately Haddock does not allow doc comments to be attached to > instances, but that's independent of whether the defining module is shown. > Agreed. I am getting the impression that it would be nice if there were a lot of things that were more explicit about instances, both in Haskell and in Haddock. Sean -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20080815/d78fc430/attachment.htm From ross at soi.city.ac.uk Fri Aug 15 08:51:12 2008 From: ross at soi.city.ac.uk (Ross Paterson) Date: Fri Aug 15 08:50:24 2008 Subject: How to disable warning for "export item 'module ...' exports nothing"? In-Reply-To: <3c6288ab0808150521t2534191dwa98513c1e462cc15@mail.gmail.com> References: <3c6288ab0808141027p73b796edm87019afa58174a7a@mail.gmail.com> <48A46BF6.9060003@charter.net> <3c6288ab0808141100k329052cerb1597cf45c9e4073@mail.gmail.com> <20080815113640.GA4130@soi.city.ac.uk> <3c6288ab0808150521t2534191dwa98513c1e462cc15@mail.gmail.com> Message-ID: <20080815125112.GB4130@soi.city.ac.uk> On Fri, Aug 15, 2008 at 02:21:33PM +0200, Sean Leather wrote: > In my case, it does matter where instances are in scope. My library > requires orphan instances by design. If the programmer imports the > top-level module, then s/he gets a default set of instances. But the > programmer has the option to import select modules and get a different > set of classes and instances. With implicit import, it just doesn't work to have different instances in different places. Suppose two modules use your library in the different ways you envisage. Then those modules cannot be used together in the same program. Your library will not be re-usable. I'd recommend seeking alternate forms of parameterization. From daniil.elovkov at googlemail.com Fri Aug 15 08:54:46 2008 From: daniil.elovkov at googlemail.com (Daniil Elovkov) Date: Fri Aug 15 08:53:58 2008 Subject: problems running ghc-6.8.2 on solaris 10, sparc Message-ID: Hello folks, Christian I'm trying to get ghc 6.8.2 running on Solaris 10 and having problems. To be precise, I'm trying to compile a 'hello world' program by ghc 6.8.2 which I got in binary form haskell.org. gcc is 2.95, it uses sun linker. I remember there were problems with that in the past. Is ghc supposed to work only with gnu ld or sun ld as well? So, how it went first I got compiler errors in many places of Reg.hs: global register variable follows a function definition Googling showed that Don Stewart used to fix it by swapping 2 includes in Stg.h - putting MachRegs.h after Regs.h instead of before. It helped Then there was assembler error: cannot use v8plus instructions in a non-v8plus target binary It was caused by -mcpu=v9, which ghc passes to gcc. I blindly added -optc -mcpu=v8 and it helped :) Then the linker complained that it could not resolve aio_fork and __aio_suspend64, referenced from librt.so. -lrt is passed by ghc to the linker. On this machine there is /lib/libaio.so. Linking with it didn't help. It doesn't really contain exactly those functions, only with slightly different names, like _aio_forkinit, _libaio_fork. Also, librt which was linked in was the one lying close to where gcc is installed. Apart from that, there is also librt.so in /lib. I thought, maybe the wrong librt was used and said -optl -L/lib to link against the one in /lib. No complaints, but the resulting binary segfaults. Does anybody have any ideas? -- Daniil Elovkov From leather at cs.uu.nl Fri Aug 15 09:09:16 2008 From: leather at cs.uu.nl (Sean Leather) Date: Fri Aug 15 09:08:26 2008 Subject: How to disable warning for "export item 'module ...' exports nothing"? In-Reply-To: <20080815125112.GB4130@soi.city.ac.uk> References: <3c6288ab0808141027p73b796edm87019afa58174a7a@mail.gmail.com> <48A46BF6.9060003@charter.net> <3c6288ab0808141100k329052cerb1597cf45c9e4073@mail.gmail.com> <20080815113640.GA4130@soi.city.ac.uk> <3c6288ab0808150521t2534191dwa98513c1e462cc15@mail.gmail.com> <20080815125112.GB4130@soi.city.ac.uk> Message-ID: <3c6288ab0808150609w33e4f182m7d997fea5df8b1d8@mail.gmail.com> Ross Paterson wrote: > On Fri, Aug 15, 2008 at 02:21:33PM +0200, Sean Leather wrote: > > In my case, it does matter where instances are in scope. My library > > requires orphan instances by design. If the programmer imports the > > top-level module, then s/he gets a default set of instances. But the > > programmer has the option to import select modules and get a different > > set of classes and instances. > > With implicit import, it just doesn't work to have different instances in > different places. Suppose two modules use your library in the different > ways you envisage. Then those modules cannot be used together in the > same program. Your library will not be re-usable. > It is not true that those modules cannot be used in the same program. It is possibly true that they cannot both be imported by another module. (It depends on how the instances are used.) The issue is not that the library is not re-usable. It's simply a trade-off. One use of the library (the default) allows for simplicity. The second use allows for extensibility and specialization. The latter requires more work, but it is possible. Sean -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20080815/d982de63/attachment.htm From Christian.Maeder at dfki.de Fri Aug 15 09:23:51 2008 From: Christian.Maeder at dfki.de (Christian Maeder) Date: Fri Aug 15 09:22:56 2008 Subject: problems running ghc-6.8.2 on solaris 10, sparc In-Reply-To: References: Message-ID: <48A58367.3040500@dfki.de> Hi Daniil I have a binary dist here: http://www.dfki.de/sks/hets/solaris/ghcs/ghc-6.8.3-sparc-sun-solaris2.tar.bz2 that runs and was built with gcc-4.0.3 on Solaris 8 sparc. It runs under Solaris 10 with gcc-4.2.2, too. (It also runs with gcc-3.4, but building fails as in #951). I've not tried gcc-2.95. my ldd output of ghc-6.8.3 is: librt.so.1 => /usr/lib/librt.so.1 libreadline.so.5 => /usr/local/lib/libreadline.so.5 libncurses.so.5 => /usr/local/lib/libncurses.so.5 libdl.so.1 => /usr/lib/libdl.so.1 libm.so.2 => /usr/local/lib/libm.so.2 libgmp.so.3 => /usr/local/lib/libgmp.so.3 libpthread.so.1 => /usr/lib/libpthread.so.1 libc.so.1 => /usr/lib/libc.so.1 libaio.so.1 => /usr/lib/libaio.so.1 libthread.so.1 => /usr/lib/libthread.so.1 /usr/platform/SUNW,Ultra-4/lib/libc_psr.so.1 My "ld" is a Solaris Link Editors: 5.8-1.302 (resp. 5.10-1.489), but a gnu-linker should work, too. In fact gcc uses a gnu linker, i.e. my gcc was configured: --with-gnu-as --with-as=/usr/local/bin/gnu-as --with-gnu-ld --with-ld=/usr/local/bin/gnu-ld My build.mk file for building ghc contains: SRC_HC_OPTS += -optc-mcpu=ultrasparc -opta-mcpu=ultrasparc I've no idea what goes wrong for you, but maybe my above information helps you to figure this out yourself. Cheers Christian Daniil Elovkov wrote: > Hello folks, Christian > > I'm trying to get ghc 6.8.2 running on Solaris 10 and having problems. > To be precise, I'm trying to compile a 'hello world' program by ghc > 6.8.2 which I got in binary form haskell.org. > > gcc is 2.95, it uses sun linker. I remember there were problems with > that in the past. Is ghc supposed to work only with gnu ld or sun ld > as well? > > So, how it went > > first I got compiler errors in many places of Reg.hs: > global register variable follows a function definition > > Googling showed that Don Stewart used to fix it by swapping 2 includes > in Stg.h - putting MachRegs.h after Regs.h instead of before. It > helped > > Then there was assembler error: > cannot use v8plus instructions in a non-v8plus target binary > > It was caused by -mcpu=v9, which ghc passes to gcc. I blindly added > -optc -mcpu=v8 and it helped :) > > Then the linker complained that it could not resolve aio_fork and > __aio_suspend64, referenced from librt.so. > > -lrt is passed by ghc to the linker. On this machine there is > /lib/libaio.so. Linking with it didn't help. It doesn't really contain > exactly those functions, only with slightly different names, like > _aio_forkinit, _libaio_fork. > > Also, librt which was linked in was the one lying close to where gcc > is installed. Apart from that, there is also librt.so in /lib. I > thought, maybe the wrong librt was used and said -optl -L/lib to link > against the one in /lib. > > No complaints, but the resulting binary segfaults. > > Does anybody have any ideas? > > From ross at soi.city.ac.uk Fri Aug 15 09:39:28 2008 From: ross at soi.city.ac.uk (Ross Paterson) Date: Fri Aug 15 09:38:59 2008 Subject: How to disable warning for "export item 'module ...' exports nothing"? In-Reply-To: <3c6288ab0808150609w33e4f182m7d997fea5df8b1d8@mail.gmail.com> References: <3c6288ab0808141027p73b796edm87019afa58174a7a@mail.gmail.com> <48A46BF6.9060003@charter.net> <3c6288ab0808141100k329052cerb1597cf45c9e4073@mail.gmail.com> <20080815113640.GA4130@soi.city.ac.uk> <3c6288ab0808150521t2534191dwa98513c1e462cc15@mail.gmail.com> <20080815125112.GB4130@soi.city.ac.uk> <3c6288ab0808150609w33e4f182m7d997fea5df8b1d8@mail.gmail.com> Message-ID: <20080815133928.GA7850@soi.city.ac.uk> On Fri, Aug 15, 2008 at 03:09:16PM +0200, Sean Leather wrote: > Ross Paterson wrote: > With implicit import, it just doesn't work to have different instances in > different places. Suppose two modules use your library in the different > ways you envisage. Then those modules cannot be used together in the > same program. Your library will not be re-usable. > > It is not true that those modules cannot be used in the same program. It is > possibly true that they cannot both be imported by another module. (It depends > on how the instances are used.) If they're in the same program, there will be chains of imports from Main to each of them, so Main will implicitly import conflicting instances and will be rejected by the compiler. From igloo at earth.li Fri Aug 15 10:12:23 2008 From: igloo at earth.li (Ian Lynagh) Date: Fri Aug 15 10:11:34 2008 Subject: Version control systems In-Reply-To: <26D36D0E-3A57-4DF2-8D9E-07A876B12DE5@cse.unsw.edu.au> References: <5FEA1F32-9C34-4888-A5BE-D0460D55C307@cse.unsw.edu.au> <48A05827.5020200@gmail.com> <638ABD0A29C8884A91BC5FB5C349B1C32AE8066602@EA-EXMSG-C334.europe.corp.microsoft.com> <4492B45B-6699-4444-87A9-83F0595B4EB7@cse.unsw.edu.au> <48A28F11.4090307@gmail.com> <404396ef0808141534i65ceae28ud23186d3f845714@mail.gmail.com> <83BF150C-20EA-48AA-8C1B-BFC8B6CA71EB@cse.unsw.edu.au> <916b84820808141712t18d87a07v47bf7be012cd7725@mail.gmail.com> <26D36D0E-3A57-4DF2-8D9E-07A876B12DE5@cse.unsw.edu.au> Message-ID: <20080815141223.GA9938@matrix.chaos.earth.li> On Fri, Aug 15, 2008 at 11:12:20AM +1000, Manuel M T Chakravarty wrote: > > Moreover, as I wrote a few times before, some reasons for switching in > the first place are invalidated by not having the core libraries in > git, too. For example, one complaint about darcs is that it either > doesn't build (on the Sun Solaris T1 and T2 machines) I don't remember seeing this mentioned before, and googling for "Solaris T1" darcs doesn't find anything. What goes wrong? I'd expect darcs to build anywhere GHC does. Thanks Ian From leather at cs.uu.nl Fri Aug 15 10:17:44 2008 From: leather at cs.uu.nl (Sean Leather) Date: Fri Aug 15 10:16:57 2008 Subject: How to disable warning for "export item 'module ...' exports nothing"? In-Reply-To: <20080815133928.GA7850@soi.city.ac.uk> References: <3c6288ab0808141027p73b796edm87019afa58174a7a@mail.gmail.com> <48A46BF6.9060003@charter.net> <3c6288ab0808141100k329052cerb1597cf45c9e4073@mail.gmail.com> <20080815113640.GA4130@soi.city.ac.uk> <3c6288ab0808150521t2534191dwa98513c1e462cc15@mail.gmail.com> <20080815125112.GB4130@soi.city.ac.uk> <3c6288ab0808150609w33e4f182m7d997fea5df8b1d8@mail.gmail.com> <20080815133928.GA7850@soi.city.ac.uk> Message-ID: <3c6288ab0808150717i39c66444h812bb7bc2a68ceef@mail.gmail.com> Ross Paterson wrote: > On Fri, Aug 15, 2008 at 03:09:16PM +0200, Sean Leather wrote: > > Ross Paterson wrote: > > With implicit import, it just doesn't work to have different > instances in > > different places. Suppose two modules use your library in the > different > > ways you envisage. Then those modules cannot be used together in the > > same program. Your library will not be re-usable. > > > > It is not true that those modules cannot be used in the same program. It > is > > possibly true that they cannot both be imported by another module. (It > depends > > on how the instances are used.) > > If they're in the same program, there will be chains of imports from Main > to each of them, so Main will implicitly import conflicting instances and > will be rejected by the compiler. > module A where class A t where a :: t module B where import A instance A Int where a = 0 a0 :: Int a0 = a module C where import A instance A Int where a = 1 a1 :: Int a1 = a module Main where import A import B import C main = do putStrLn $ "a0=" ++ show a0 putStrLn $ "a1=" ++ show a1 This works, because of the way the instances are used. While overlapping instances are imported into Main, they are not used in Main. Sean -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20080815/7d017325/attachment.htm From ross at soi.city.ac.uk Fri Aug 15 10:34:01 2008 From: ross at soi.city.ac.uk (Ross Paterson) Date: Fri Aug 15 10:33:14 2008 Subject: How to disable warning for "export item 'module ...' exports nothing"? In-Reply-To: <3c6288ab0808150717i39c66444h812bb7bc2a68ceef@mail.gmail.com> References: <3c6288ab0808141027p73b796edm87019afa58174a7a@mail.gmail.com> <48A46BF6.9060003@charter.net> <3c6288ab0808141100k329052cerb1597cf45c9e4073@mail.gmail.com> <20080815113640.GA4130@soi.city.ac.uk> <3c6288ab0808150521t2534191dwa98513c1e462cc15@mail.gmail.com> <20080815125112.GB4130@soi.city.ac.uk> <3c6288ab0808150609w33e4f182m7d997fea5df8b1d8@mail.gmail.com> <20080815133928.GA7850@soi.city.ac.uk> <3c6288ab0808150717i39c66444h812bb7bc2a68ceef@mail.gmail.com> Message-ID: <20080815143359.GB7850@soi.city.ac.uk> On Fri, Aug 15, 2008 at 04:17:44PM +0200, Sean Leather wrote: > module A where > class A t where > a :: t > > module B where > import A > instance A Int where > a = 0 > a0 :: Int > a0 = a > > module C where > import A > instance A Int where > a = 1 > a1 :: Int > a1 = a > > module Main where > import A > import B > import C > main = do putStrLn $ "a0=" ++ show a0 > putStrLn $ "a1=" ++ show a1 > > This works, because of the way the instances are used. While overlapping > instances are imported into Main, they are not used in Main. Then that is a GHC bug. Haskell 98 Report 4.3.2: "A type may not be declared as an instance of a particular class more than once in the program." From igloo at earth.li Fri Aug 15 10:38:40 2008 From: igloo at earth.li (Ian Lynagh) Date: Fri Aug 15 10:37:53 2008 Subject: Version control systems In-Reply-To: <9d4d38820808150501n17c8d56g730dc2b5d4e99126@mail.gmail.com> References: <638ABD0A29C8884A91BC5FB5C349B1C32AE8066602@EA-EXMSG-C334.europe.corp.microsoft.com> <4492B45B-6699-4444-87A9-83F0595B4EB7@cse.unsw.edu.au> <48A28F11.4090307@gmail.com> <404396ef0808141534i65ceae28ud23186d3f845714@mail.gmail.com> <83BF150C-20EA-48AA-8C1B-BFC8B6CA71EB@cse.unsw.edu.au> <916b84820808141712t18d87a07v47bf7be012cd7725@mail.gmail.com> <26D36D0E-3A57-4DF2-8D9E-07A876B12DE5@cse.unsw.edu.au> <48A564D4.3000806@charter.net> <9d4d38820808150501n17c8d56g730dc2b5d4e99126@mail.gmail.com> Message-ID: <20080815143840.GB9938@matrix.chaos.earth.li> On Fri, Aug 15, 2008 at 01:01:08PM +0100, Max Bolingbroke wrote: > 2008/8/15 Isaac Dupree : > > So let's figure out how it would work (I have doubts too!) So, within the > > directory that's a git repo (ghc), we have some other repos, git (testsuite) > > and darcs (some libraries). Does anyone know how git handles nested repos > > even natively? > > You can explicitly tell Git about nested Git repos using > http://www.kernel.org/pub/software/scm/git/docs/git-submodule.html. > This essentially associates a particular version of each subrepo with > every version of the repo that contains them, so e.g. checking out GHC > from 2 weeks ago could check out the libraries from the same point in > time. We were talking about this last night on #ghc, and AIUI this doesn't play well with the in-tree branching style that is advocated, e.g. if you want to branch ghc and base then as you change between ghc branch X and Y, git won't automatically change base between branches X' and Y'. > > Then, adding complexity, git branches are normally done by > > switching in-place. So how does this interact with VCS like darcs that > > doesn't have a concept of in-place switching of branches? The in-tree branching style also sounds like it won't work well with trees you are working in: If you have a tree built with branch X, and then you swap to branch Y for a minute and then back to branch X, then the timestamps on any source files that differ between the branches will have changed, so the build won't think it is up-to-date any more and you will get needless recompilation. Working only in the "master" branch, and using different repos for branches (i.e. doing what we do with darcs), is an option, although git users seem to think it is a worse way to work; I'm not really clear on the main reasons why. One way that it is worse is that you will get a lot more "automatic merge" commits when you pull changes from the central repo into a repo in which you have local commits. I don't think that there is anything bad about these, as such; they're just noise in the history. (I'm not sure if it's possible to automatically rebase these away, or something?). Hopefully a git person will correct me if I've got something wrong! Thanks Ian From leather at cs.uu.nl Fri Aug 15 11:06:19 2008 From: leather at cs.uu.nl (Sean Leather) Date: Fri Aug 15 11:05:32 2008 Subject: Overlapping instances vs. Haskell98 Report [was: How to disable warning for "export item 'module ...' exports nothing"?] Message-ID: <3c6288ab0808150806j344329c8s764346a55dec3d41@mail.gmail.com> Ross Paterson wrote: > On Fri, Aug 15, 2008 at 04:17:44PM +0200, Sean Leather wrote: > > module A where > > class A t where > > a :: t > > > > module B where > > import A > > instance A Int where > > a = 0 > > a0 :: Int > > a0 = a > > > > module C where > > import A > > instance A Int where > > a = 1 > > a1 :: Int > > a1 = a > > > > module Main where > > import A > > import B > > import C > > main = do putStrLn $ "a0=" ++ show a0 > > putStrLn $ "a1=" ++ show a1 > > > > This works, because of the way the instances are used. While overlapping > > instances are imported into Main, they are not used in Main. > > Then that is a GHC bug. Haskell 98 Report 4.3.2: "A type may not be > declared as an instance of a particular class more than once in the > program." > That's interesting. So, maybe there should be some language extension or warning (with associated -fno-warn) for this in GHC. Personally, I prefer the way it's done now. (I guess that's obvious, considering I'm developing a library that will take advantage of it. ;) ) But it makes sense that instances are only looked up when needed, instead of globally tracked. Sean -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20080815/fcd50c1b/attachment.htm From nominolo at googlemail.com Fri Aug 15 11:09:55 2008 From: nominolo at googlemail.com (Thomas Schilling) Date: Fri Aug 15 11:09:15 2008 Subject: Version control systems In-Reply-To: <20080815143840.GB9938@matrix.chaos.earth.li> References: <4492B45B-6699-4444-87A9-83F0595B4EB7@cse.unsw.edu.au> <48A28F11.4090307@gmail.com> <404396ef0808141534i65ceae28ud23186d3f845714@mail.gmail.com> <83BF150C-20EA-48AA-8C1B-BFC8B6CA71EB@cse.unsw.edu.au> <916b84820808141712t18d87a07v47bf7be012cd7725@mail.gmail.com> <26D36D0E-3A57-4DF2-8D9E-07A876B12DE5@cse.unsw.edu.au> <48A564D4.3000806@charter.net> <9d4d38820808150501n17c8d56g730dc2b5d4e99126@mail.gmail.com> <20080815143840.GB9938@matrix.chaos.earth.li> Message-ID: <916b84820808150809w3bf7c83dk8734f679c5c34654@mail.gmail.com> On Fri, Aug 15, 2008 at 4:38 PM, Ian Lynagh wrote: > One way that it is worse is that you will get a lot more "automatic > merge" commits when you pull changes from the central repo into a repo > in which you have local commits. I don't think that there is anything > bad about these, as such; they're just noise in the history. (I'm not > sure if it's possible to automatically rebase these away, or > something?). This is the use case for "git pull --rebase". Instead of creating an automatic merge commit, it rebases your local changes on top of the newly pulled changes (ignoring patches already present, which could happen if you had sent one change as a patch via mail.) The timestamp issue seems tricky, though. From daniil.elovkov at googlemail.com Fri Aug 15 11:23:41 2008 From: daniil.elovkov at googlemail.com (Daniil Elovkov) Date: Fri Aug 15 11:22:54 2008 Subject: problems running ghc-6.8.2 on solaris 10, sparc In-Reply-To: <48A58367.3040500@dfki.de> References: <48A58367.3040500@dfki.de> Message-ID: Thank you Christian It seems that an old gcc was the problem. I downloaded gcc 3.4.6 from sunfreeware and it works ok. Also, their precompiled gcc's at sunfreeware are configured to use sun linker. It caused no problems at hello world Haskell program. I yet have to check how it will behave with a quite big project. There were serious problems with performance in the past, as we know. Btw, the link you gave me is not on haskell.org/ghc. For 6.8.3 only solaris-x86 is downloadable. That's why I grabbed 6.8.2 in the first place. Thanks for your ports! 2008/8/15 Christian Maeder : > Hi Daniil > > I have a binary dist here: > http://www.dfki.de/sks/hets/solaris/ghcs/ghc-6.8.3-sparc-sun-solaris2.tar.bz2 > > that runs and was built with gcc-4.0.3 on Solaris 8 sparc. It runs under > Solaris 10 with gcc-4.2.2, too. (It also runs with gcc-3.4, but building > fails as in #951). I've not tried gcc-2.95. > > my ldd output of ghc-6.8.3 is: > librt.so.1 => /usr/lib/librt.so.1 > libreadline.so.5 => /usr/local/lib/libreadline.so.5 > libncurses.so.5 => /usr/local/lib/libncurses.so.5 > libdl.so.1 => /usr/lib/libdl.so.1 > libm.so.2 => /usr/local/lib/libm.so.2 > libgmp.so.3 => /usr/local/lib/libgmp.so.3 > libpthread.so.1 => /usr/lib/libpthread.so.1 > libc.so.1 => /usr/lib/libc.so.1 > libaio.so.1 => /usr/lib/libaio.so.1 > libthread.so.1 => /usr/lib/libthread.so.1 > /usr/platform/SUNW,Ultra-4/lib/libc_psr.so.1 > > My "ld" is a Solaris Link Editors: 5.8-1.302 (resp. 5.10-1.489), but a > gnu-linker should work, too. In fact gcc uses a gnu linker, i.e. my gcc was > configured: > --with-gnu-as --with-as=/usr/local/bin/gnu-as > --with-gnu-ld --with-ld=/usr/local/bin/gnu-ld > > My build.mk file for building ghc contains: > > SRC_HC_OPTS += -optc-mcpu=ultrasparc -opta-mcpu=ultrasparc > > I've no idea what goes wrong for you, but maybe my above information helps > you to figure this out yourself. > > Cheers Christian > > Daniil Elovkov wrote: >> >> Hello folks, Christian >> >> I'm trying to get ghc 6.8.2 running on Solaris 10 and having problems. >> To be precise, I'm trying to compile a 'hello world' program by ghc >> 6.8.2 which I got in binary form haskell.org. >> >> gcc is 2.95, it uses sun linker. I remember there were problems with >> that in the past. Is ghc supposed to work only with gnu ld or sun ld >> as well? >> >> So, how it went >> >> first I got compiler errors in many places of Reg.hs: >> global register variable follows a function definition >> >> Googling showed that Don Stewart used to fix it by swapping 2 includes >> in Stg.h - putting MachRegs.h after Regs.h instead of before. It >> helped >> >> Then there was assembler error: >> cannot use v8plus instructions in a non-v8plus target binary >> >> It was caused by -mcpu=v9, which ghc passes to gcc. I blindly added >> -optc -mcpu=v8 and it helped :) >> >> Then the linker complained that it could not resolve aio_fork and >> __aio_suspend64, referenced from librt.so. >> >> -lrt is passed by ghc to the linker. On this machine there is >> /lib/libaio.so. Linking with it didn't help. It doesn't really contain >> exactly those functions, only with slightly different names, like >> _aio_forkinit, _libaio_fork. >> >> Also, librt which was linked in was the one lying close to where gcc >> is installed. Apart from that, there is also librt.so in /lib. I >> thought, maybe the wrong librt was used and said -optl -L/lib to link >> against the one in /lib. >> >> No complaints, but the resulting binary segfaults. >> >> Does anybody have any ideas? >> >> > -- Daniil Elovkov From igloo at earth.li Fri Aug 15 11:24:12 2008 From: igloo at earth.li (Ian Lynagh) Date: Fri Aug 15 11:23:23 2008 Subject: Version control systems In-Reply-To: <916b84820808150809w3bf7c83dk8734f679c5c34654@mail.gmail.com> References: <4492B45B-6699-4444-87A9-83F0595B4EB7@cse.unsw.edu.au> <48A28F11.4090307@gmail.com> <404396ef0808141534i65ceae28ud23186d3f845714@mail.gmail.com> <83BF150C-20EA-48AA-8C1B-BFC8B6CA71EB@cse.unsw.edu.au> <916b84820808141712t18d87a07v47bf7be012cd7725@mail.gmail.com> <26D36D0E-3A57-4DF2-8D9E-07A876B12DE5@cse.unsw.edu.au> <48A564D4.3000806@charter.net> <9d4d38820808150501n17c8d56g730dc2b5d4e99126@mail.gmail.com> <20080815143840.GB9938@matrix.chaos.earth.li> <916b84820808150809w3bf7c83dk8734f679c5c34654@mail.gmail.com> Message-ID: <20080815152412.GA11627@matrix.chaos.earth.li> On Fri, Aug 15, 2008 at 05:09:55PM +0200, Thomas Schilling wrote: > On Fri, Aug 15, 2008 at 4:38 PM, Ian Lynagh wrote: > > One way that it is worse is that you will get a lot more "automatic > > merge" commits when you pull changes from the central repo into a repo > > in which you have local commits. I don't think that there is anything > > bad about these, as such; they're just noise in the history. (I'm not > > sure if it's possible to automatically rebase these away, or > > something?). > > This is the use case for "git pull --rebase". Instead of creating an > automatic merge commit, it rebases your local changes on top of the > newly pulled changes Hmm, last night the conversation went: < nominolo> malcolmw: so i'm advocating "git pull --rebase" for that use case < glguy_> rebasing can be less successful than merging when dealing with big changes < glguy_> since the rebase happens one commit at a time so I'm confused as to what the best practice is. Thanks Ian From rl at cse.unsw.edu.au Fri Aug 15 11:28:40 2008 From: rl at cse.unsw.edu.au (Roman Leshchinskiy) Date: Fri Aug 15 11:28:03 2008 Subject: Version control systems In-Reply-To: <20080815141223.GA9938@matrix.chaos.earth.li> References: <5FEA1F32-9C34-4888-A5BE-D0460D55C307@cse.unsw.edu.au> <48A05827.5020200@gmail.com> <638ABD0A29C8884A91BC5FB5C349B1C32AE8066602@EA-EXMSG-C334.europe.corp.microsoft.com> <4492B45B-6699-4444-87A9-83F0595B4EB7@cse.unsw.edu.au> <48A28F11.4090307@gmail.com> <404396ef0808141534i65ceae28ud23186d3f845714@mail.gmail.com> <83BF150C-20EA-48AA-8C1B-BFC8B6CA71EB@cse.unsw.edu.au> <916b84820808141712t18d87a07v47bf7be012cd7725@mail.gmail.com> <26D36D0E-3A57-4DF2-8D9E-07A876B12DE5@cse.unsw.edu.au> <20080815141223.GA9938@matrix.chaos.earth.li> Message-ID: On 16/08/2008, at 00:12, Ian Lynagh wrote: > On Fri, Aug 15, 2008 at 11:12:20AM +1000, Manuel M T Chakravarty > wrote: >> >> Moreover, as I wrote a few times before, some reasons for switching >> in >> the first place are invalidated by not having the core libraries in >> git, too. For example, one complaint about darcs is that it either >> doesn't build (on the Sun Solaris T1 and T2 machines) > > I don't remember seeing this mentioned before, and googling for > "Solaris T1" darcs > doesn't find anything. What goes wrong? I'd expect darcs to build > anywhere GHC does. I only vaguely remember what was wrong but IIRC, the problem was that darcs 1.0.? didn't build with GHC 6.8.? because of some incompatibility in the libs and darcs 2 built ok but didn't work, probably because of libcurl issues. At that point I gave up. Roman From Christian.Maeder at dfki.de Fri Aug 15 11:31:00 2008 From: Christian.Maeder at dfki.de (Christian Maeder) Date: Fri Aug 15 11:30:11 2008 Subject: problems running ghc-6.8.2 on solaris 10, sparc In-Reply-To: References: <48A58367.3040500@dfki.de> Message-ID: <48A5A134.8000502@dfki.de> Daniil Elovkov wrote: [...] > Btw, the link you gave me is not on haskell.org/ghc. For 6.8.3 only > solaris-x86 is downloadable. That's why I grabbed 6.8.2 in the first > place. [..] >> I have a binary dist here: >> http://www.dfki.de/sks/hets/solaris/ghcs/ghc-6.8.3-sparc-sun-solaris2.tar.bz2 Ian, you may copy it to http://www.haskell.org/ghc/download_ghc_683.html Thanks, Christian >> >> that runs and was built with gcc-4.0.3 on Solaris 8 sparc. It runs under >> Solaris 10 with gcc-4.2.2, too. (It also runs with gcc-3.4, but building >> fails as in #951). I've not tried gcc-2.95. >> >> my ldd output of ghc-6.8.3 is: >> librt.so.1 => /usr/lib/librt.so.1 >> libreadline.so.5 => /usr/local/lib/libreadline.so.5 >> libncurses.so.5 => /usr/local/lib/libncurses.so.5 >> libdl.so.1 => /usr/lib/libdl.so.1 >> libm.so.2 => /usr/local/lib/libm.so.2 >> libgmp.so.3 => /usr/local/lib/libgmp.so.3 >> libpthread.so.1 => /usr/lib/libpthread.so.1 >> libc.so.1 => /usr/lib/libc.so.1 >> libaio.so.1 => /usr/lib/libaio.so.1 >> libthread.so.1 => /usr/lib/libthread.so.1 >> /usr/platform/SUNW,Ultra-4/lib/libc_psr.so.1 >> >> My "ld" is a Solaris Link Editors: 5.8-1.302 (resp. 5.10-1.489), but a >> gnu-linker should work, too. In fact gcc uses a gnu linker, i.e. my gcc was >> configured: >> --with-gnu-as --with-as=/usr/local/bin/gnu-as >> --with-gnu-ld --with-ld=/usr/local/bin/gnu-ld >> >> My build.mk file for building ghc contains: >> >> SRC_HC_OPTS += -optc-mcpu=ultrasparc -opta-mcpu=ultrasparc From isaacdupree at charter.net Fri Aug 15 11:39:33 2008 From: isaacdupree at charter.net (Isaac Dupree) Date: Fri Aug 15 11:38:36 2008 Subject: Overlapping instances vs. Haskell98 Report [was: How to disable warning for "export item 'module ...' exports nothing"?] In-Reply-To: <3c6288ab0808150806j344329c8s764346a55dec3d41@mail.gmail.com> References: <3c6288ab0808150806j344329c8s764346a55dec3d41@mail.gmail.com> Message-ID: <48A5A335.8010605@charter.net> Sean Leather wrote: > That's interesting. So, maybe there should be some language extension or > warning (with associated -fno-warn) for this in GHC. > > Personally, I prefer the way it's done now. (I guess that's obvious, > considering I'm developing a library that will take advantage of it. ;) ) > But it makes sense that instances are only looked up when needed, instead of > globally tracked. see: http://hackage.haskell.org/trac/ghc/ticket/2356 From igloo at earth.li Fri Aug 15 14:19:14 2008 From: igloo at earth.li (Ian Lynagh) Date: Fri Aug 15 14:18:24 2008 Subject: Version control systems In-Reply-To: <20080815152412.GA11627@matrix.chaos.earth.li> References: <48A28F11.4090307@gmail.com> <404396ef0808141534i65ceae28ud23186d3f845714@mail.gmail.com> <83BF150C-20EA-48AA-8C1B-BFC8B6CA71EB@cse.unsw.edu.au> <916b84820808141712t18d87a07v47bf7be012cd7725@mail.gmail.com> <26D36D0E-3A57-4DF2-8D9E-07A876B12DE5@cse.unsw.edu.au> <48A564D4.3000806@charter.net> <9d4d38820808150501n17c8d56g730dc2b5d4e99126@mail.gmail.com> <20080815143840.GB9938@matrix.chaos.earth.li> <916b84820808150809w3bf7c83dk8734f679c5c34654@mail.gmail.com> <20080815152412.GA11627@matrix.chaos.earth.li> Message-ID: <20080815181914.GA17041@matrix.chaos.earth.li> On Fri, Aug 15, 2008 at 04:24:12PM +0100, Ian Lynagh wrote: > On Fri, Aug 15, 2008 at 05:09:55PM +0200, Thomas Schilling wrote: > > On Fri, Aug 15, 2008 at 4:38 PM, Ian Lynagh wrote: > > > One way that it is worse is that you will get a lot more "automatic > > > merge" commits when you pull changes from the central repo into a repo > > > in which you have local commits. I don't think that there is anything > > > bad about these, as such; they're just noise in the history. (I'm not > > > sure if it's possible to automatically rebase these away, or > > > something?). > > > > This is the use case for "git pull --rebase". Instead of creating an > > automatic merge commit, it rebases your local changes on top of the > > newly pulled changes > > Hmm, last night the conversation went: > > < nominolo> malcolmw: so i'm advocating "git pull --rebase" for > that use case > < glguy_> rebasing can be less successful than merging when > dealing with big changes > < glguy_> since the rebase happens one commit > at a time > > so I'm confused as to what the best practice is. We discussed this in #ghc, and the conclusion seems to be: If you have lots of local changes (e.g. the sorts of long-running branch that gives darcs 1 problems), then you need to use merge. If you use rebase then you might end up with lots of conflicts to manually resolve. Using merge gives you automatic merge commits, If you think these are ugly (opinion is divided on that amongst git people; I guess for GHC we'd want to make a global decision about that) then you can use rebase when you have few local changes, and thus you are unlikely to get many conflicts. Using merge you also get a more accurate reflection of the project history, i.e. you can see that the two branches were being developed independently. Thanks Ian From nominolo at googlemail.com Fri Aug 15 15:53:12 2008 From: nominolo at googlemail.com (Thomas Schilling) Date: Fri Aug 15 15:52:22 2008 Subject: Version control systems In-Reply-To: <20080815181914.GA17041@matrix.chaos.earth.li> References: <48A28F11.4090307@gmail.com> <83BF150C-20EA-48AA-8C1B-BFC8B6CA71EB@cse.unsw.edu.au> <916b84820808141712t18d87a07v47bf7be012cd7725@mail.gmail.com> <26D36D0E-3A57-4DF2-8D9E-07A876B12DE5@cse.unsw.edu.au> <48A564D4.3000806@charter.net> <9d4d38820808150501n17c8d56g730dc2b5d4e99126@mail.gmail.com> <20080815143840.GB9938@matrix.chaos.earth.li> <916b84820808150809w3bf7c83dk8734f679c5c34654@mail.gmail.com> <20080815152412.GA11627@matrix.chaos.earth.li> <20080815181914.GA17041@matrix.chaos.earth.li> Message-ID: <916b84820808151253t11d44133qafb9f99292f3b356@mail.gmail.com> > If you have lots of local changes (e.g. the sorts of long-running branch > that gives darcs 1 problems), then you need to use merge. If you use > rebase then you might end up with lots of conflicts to manually resolve. > > Using merge gives you automatic merge commits, If you think these are > ugly (opinion is divided on that amongst git people; I guess for GHC > we'd want to make a global decision about that) then you can use rebase > when you have few local changes, and thus you are unlikely to get many > conflicts. > > Using merge you also get a more accurate reflection of the project > history, i.e. you can see that the two branches were being developed > independently. That's not quite accurate: If you have conflicts, you have conflicts and have to resolve them manually. In case of a branch, however, you only have to resolve them once you do the merge, so when _you_ decide, not whenever some upstream change breaks things. Some projects encourage to have one development branch and periodically update the master branch and rebase the development branch on top of it. I think it's a matter of taste and we should probably advocate one usage. I think rebase should only be used for smaller changes. The automatic usefulness of the automatic merge message is varying. I think it makes sense if it contains public repos, like, e.g. "Merge 'master' from git://github.com/chak/ghc", but less useful for pulls from local repos like, e.g. "Merge 'master' from '/home/igloo/tmp/trash/ghc/fix-stupid-osx-bug/'". However, if we prefer merges we get those pretty git history graphs: http://www.flickr.com/photos/malcolmtredinnick/1516857444/ From bdonlan at gmail.com Fri Aug 15 16:00:46 2008 From: bdonlan at gmail.com (Bryan Donlan) Date: Fri Aug 15 15:59:55 2008 Subject: Version control systems In-Reply-To: <48A458DC.4020205@charter.net> References: <18DB9581-AA5B-433C-9036-34EC2674C2CB@cse.unsw.edu.au> <36A0EEA6-5E34-4A1A-A008-7F847D84A1E2@cs.york.ac.uk> <20080809225624.BDD6613833F@drdoom.eecs.harvard.edu> <20080810113200.GA16357@matrix.chaos.earth.li> <20080811001751.28DA31383C3@drdoom.eecs.harvard.edu> <20080812113112.GA17581@matrix.chaos.earth.li> <24AD8609-8644-4AEA-9A56-E5A603915A95@cse.unsw.edu.au> <5ab17e790808122104l31613b54ka91861e7ab34047b@mail.gmail.com> <48A458DC.4020205@charter.net> Message-ID: <3e8340490808151300m3e4fd3b1w2ac7bacfb645a67f@mail.gmail.com> On Thu, Aug 14, 2008 at 12:10 PM, Isaac Dupree wrote: > And I wonder why (it sounds like) Git doesn't have tools to do some kind of > smart cherrypicking, using a heuristic to decide which patches in a branch > are definitely dependencies of the cherry-picked patch. In any case, I > notice a few times with ghc/darcs/Trac tickets, more than one commit has to > be listed explicitly to be merged into the stable branch. Maybe it's not > very useful/reliable for these purposes anyway? The intent with git is that you would do such cherrypicks at the branch level, not at the individual commit level - ie, if you have dependent patches that also need to be backported or whatever, you really ought to have developed the feature as a branch in the first place. You could then rebase such a branch to a prior version, and merge it into both old and new; or you could just rebase it on top of wherever you're backporting to, if you don't intend to do big merges much between the two (as the commit IDs would be different in this case). You can of course just use git cherry-pick, but this doesn't have any intelligence at all when it comes to avoiding duplicate patches - it basically just diffs from the old commit and applies it somewhere else. The git merging logic does have some heuristics to detect duplicate patches and do the right thing, however. The limitations come from git's relatively simple history model, in which commits have parent commits but no 'sideways' relationships. In practice I don't think it will be a problem - how often will there be branches which will receive cherry picks and then later have a merge from or to the same source? From batterseapower at hotmail.com Fri Aug 15 17:17:44 2008 From: batterseapower at hotmail.com (Max Bolingbroke) Date: Fri Aug 15 17:16:54 2008 Subject: Version control systems In-Reply-To: <20080815143840.GB9938@matrix.chaos.earth.li> References: <4492B45B-6699-4444-87A9-83F0595B4EB7@cse.unsw.edu.au> <48A28F11.4090307@gmail.com> <404396ef0808141534i65ceae28ud23186d3f845714@mail.gmail.com> <83BF150C-20EA-48AA-8C1B-BFC8B6CA71EB@cse.unsw.edu.au> <916b84820808141712t18d87a07v47bf7be012cd7725@mail.gmail.com> <26D36D0E-3A57-4DF2-8D9E-07A876B12DE5@cse.unsw.edu.au> <48A564D4.3000806@charter.net> <9d4d38820808150501n17c8d56g730dc2b5d4e99126@mail.gmail.com> <20080815143840.GB9938@matrix.chaos.earth.li> Message-ID: <9d4d38820808151417u77d19ea9ufec040d994d5406a@mail.gmail.com> 2008/8/15 Ian Lynagh : >> You can explicitly tell Git about nested Git repos using >> http://www.kernel.org/pub/software/scm/git/docs/git-submodule.html. >> This essentially associates a particular version of each subrepo with >> every version of the repo that contains them, so e.g. checking out GHC >> from 2 weeks ago could check out the libraries from the same point in >> time. > > We were talking about this last night on #ghc, and AIUI this doesn't > play well with the in-tree branching style that is advocated, e.g. if > you want to branch ghc and base then as you change between ghc branch X > and Y, git won't automatically change base between branches X' and Y'. If you change the submodules in branch X to point to the X' commit in base, and do the corresponding thing for Y and Y', I believe you /would/ get this behaviour (though you might have to remember to do "git submodule update" when switching.. this can probably be automated). Provisio: I'm also not a Git expert, but this is my understanding of how it works. Cheers, Max From johan.tibell at gmail.com Fri Aug 15 18:04:26 2008 From: johan.tibell at gmail.com (Johan Tibell) Date: Fri Aug 15 18:03:38 2008 Subject: Version control systems In-Reply-To: <20080815143840.GB9938@matrix.chaos.earth.li> References: <4492B45B-6699-4444-87A9-83F0595B4EB7@cse.unsw.edu.au> <48A28F11.4090307@gmail.com> <404396ef0808141534i65ceae28ud23186d3f845714@mail.gmail.com> <83BF150C-20EA-48AA-8C1B-BFC8B6CA71EB@cse.unsw.edu.au> <916b84820808141712t18d87a07v47bf7be012cd7725@mail.gmail.com> <26D36D0E-3A57-4DF2-8D9E-07A876B12DE5@cse.unsw.edu.au> <48A564D4.3000806@charter.net> <9d4d38820808150501n17c8d56g730dc2b5d4e99126@mail.gmail.com> <20080815143840.GB9938@matrix.chaos.earth.li> Message-ID: <90889fe70808151504r422686bbu9e4784803e7ba784@mail.gmail.com> On Fri, Aug 15, 2008 at 4:38 PM, Ian Lynagh wrote: > One way that it is worse is that you will get a lot more "automatic > merge" commits when you pull changes from the central repo into a repo > in which you have local commits. I don't think that there is anything > bad about these, as such; they're just noise in the history. (I'm not > sure if it's possible to automatically rebase these away, or > something?). I'm not sure if this is what you want but I always use git pull --rebase when I'm pulling to have my local commits lie on top of the one in the published repo. -- Johan From igloo at earth.li Fri Aug 15 18:07:12 2008 From: igloo at earth.li (Ian Lynagh) Date: Fri Aug 15 18:06:21 2008 Subject: problems running ghc-6.8.2 on solaris 10, sparc In-Reply-To: <48A5A134.8000502@dfki.de> References: <48A58367.3040500@dfki.de> <48A5A134.8000502@dfki.de> Message-ID: <20080815220712.GA22788@matrix.chaos.earth.li> On Fri, Aug 15, 2008 at 05:31:00PM +0200, Christian Maeder wrote: > > >>I have a binary dist here: > >>http://www.dfki.de/sks/hets/solaris/ghcs/ghc-6.8.3-sparc-sun-solaris2.tar.bz2 > > Ian, you may copy it to http://www.haskell.org/ghc/download_ghc_683.html Done! Thanks Ian From nominolo at googlemail.com Fri Aug 15 18:21:45 2008 From: nominolo at googlemail.com (Thomas Schilling) Date: Fri Aug 15 18:20:54 2008 Subject: Version control systems In-Reply-To: <90889fe70808151504r422686bbu9e4784803e7ba784@mail.gmail.com> References: <48A28F11.4090307@gmail.com> <404396ef0808141534i65ceae28ud23186d3f845714@mail.gmail.com> <83BF150C-20EA-48AA-8C1B-BFC8B6CA71EB@cse.unsw.edu.au> <916b84820808141712t18d87a07v47bf7be012cd7725@mail.gmail.com> <26D36D0E-3A57-4DF2-8D9E-07A876B12DE5@cse.unsw.edu.au> <48A564D4.3000806@charter.net> <9d4d38820808150501n17c8d56g730dc2b5d4e99126@mail.gmail.com> <20080815143840.GB9938@matrix.chaos.earth.li> <90889fe70808151504r422686bbu9e4784803e7ba784@mail.gmail.com> Message-ID: <916b84820808151521j568ceeeew43546879c835f1ba@mail.gmail.com> you don't use local branches? On Sat, Aug 16, 2008 at 12:04 AM, Johan Tibell wrote: > On Fri, Aug 15, 2008 at 4:38 PM, Ian Lynagh wrote: >> One way that it is worse is that you will get a lot more "automatic >> merge" commits when you pull changes from the central repo into a repo >> in which you have local commits. I don't think that there is anything >> bad about these, as such; they're just noise in the history. (I'm not >> sure if it's possible to automatically rebase these away, or >> something?). > > I'm not sure if this is what you want but I always use git pull > --rebase when I'm pulling to have my local commits lie on top of the > one in the published repo. > > -- Johan > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users@haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > From chak at cse.unsw.edu.au Sat Aug 16 01:52:04 2008 From: chak at cse.unsw.edu.au (Manuel M T Chakravarty) Date: Sat Aug 16 01:51:19 2008 Subject: Version control systems In-Reply-To: <9d4d38820808150501n17c8d56g730dc2b5d4e99126@mail.gmail.com> References: <48981C03.10908@gmail.com> <638ABD0A29C8884A91BC5FB5C349B1C32AE8066602@EA-EXMSG-C334.europe.corp.microsoft.com> <4492B45B-6699-4444-87A9-83F0595B4EB7@cse.unsw.edu.au> <48A28F11.4090307@gmail.com> <404396ef0808141534i65ceae28ud23186d3f845714@mail.gmail.com> <83BF150C-20EA-48AA-8C1B-BFC8B6CA71EB@cse.unsw.edu.au> <916b84820808141712t18d87a07v47bf7be012cd7725@mail.gmail.com> <26D36D0E-3A57-4DF2-8D9E-07A876B12DE5@cse.unsw.edu.au> <48A564D4.3000806@charter.net> <9d4d38820808150501n17c8d56g730dc2b5d4e99126@mail.gmail.com> Message-ID: Max Bolingbroke: >> Then, adding complexity, git branches are normally done by >> switching in-place. So how does this interact with VCS like darcs >> that >> doesn't have a concept of in-place switching of branches? > > Since we will set up Git to ignore the contents of the Darcs repos, it > will simply leave them unmodified. This is exactly like the current > situation, where rolling back / patching the GHC repo does not affect > the others. If you want Darcs-like behaviour (one branch per repo) you > are free to do this in Git as well, in which case since you never > switch branches the nested Darcs repos should never be inappropriate > for your branch. This ignores that the ability to have branches, switch between them, and merge has been cited as one of the reasons for switching to git. Embedded darcs library repos would hence nullify, or at least reduce, one of the advantages. Manuel From johan.tibell at gmail.com Sat Aug 16 02:23:00 2008 From: johan.tibell at gmail.com (Johan Tibell) Date: Sat Aug 16 02:22:08 2008 Subject: Version control systems In-Reply-To: <916b84820808151521j568ceeeew43546879c835f1ba@mail.gmail.com> References: <404396ef0808141534i65ceae28ud23186d3f845714@mail.gmail.com> <83BF150C-20EA-48AA-8C1B-BFC8B6CA71EB@cse.unsw.edu.au> <916b84820808141712t18d87a07v47bf7be012cd7725@mail.gmail.com> <26D36D0E-3A57-4DF2-8D9E-07A876B12DE5@cse.unsw.edu.au> <48A564D4.3000806@charter.net> <9d4d38820808150501n17c8d56g730dc2b5d4e99126@mail.gmail.com> <20080815143840.GB9938@matrix.chaos.earth.li> <90889fe70808151504r422686bbu9e4784803e7ba784@mail.gmail.com> <916b84820808151521j568ceeeew43546879c835f1ba@mail.gmail.com> Message-ID: <90889fe70808152323o1acab31s412d0b0c69218b04@mail.gmail.com> On Sat, Aug 16, 2008 at 12:21 AM, Thomas Schilling wrote: > you don't use local branches? I do. I like to keep a clean linear history on top of the upstream repo. So I might do work in a topic branch, rebase it on my master branch which is synced with upstream and then push. -- Johan From duncan.coutts at worc.ox.ac.uk Sat Aug 16 07:55:36 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Sat Aug 16 07:55:00 2008 Subject: problems running ghc-6.8.2 on solaris 10, sparc In-Reply-To: References: Message-ID: <1218887736.13639.76.camel@localhost> On Fri, 2008-08-15 at 16:54 +0400, Daniil Elovkov wrote: > Then there was assembler error: > cannot use v8plus instructions in a non-v8plus target binary > > It was caused by -mcpu=v9, which ghc passes to gcc. I blindly added > -optc -mcpu=v8 and it helped :) The better solution is to pass -optl-mcpu=v9. The reason you get the problem is that you're using v9 for code gen (probably in your CFLAGS env var or something) but not for the assembly phase, so tell it to use v9 as the assembly phase too and it works. From duncan.coutts at worc.ox.ac.uk Sat Aug 16 08:01:15 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Sat Aug 16 08:00:52 2008 Subject: Version control systems In-Reply-To: <20080815141223.GA9938@matrix.chaos.earth.li> References: <5FEA1F32-9C34-4888-A5BE-D0460D55C307@cse.unsw.edu.au> <48A05827.5020200@gmail.com> <638ABD0A29C8884A91BC5FB5C349B1C32AE8066602@EA-EXMSG-C334.europe.corp.microsoft.com> <4492B45B-6699-4444-87A9-83F0595B4EB7@cse.unsw.edu.au> <48A28F11.4090307@gmail.com> <404396ef0808141534i65ceae28ud23186d3f845714@mail.gmail.com> <83BF150C-20EA-48AA-8C1B-BFC8B6CA71EB@cse.unsw.edu.au> <916b84820808141712t18d87a07v47bf7be012cd7725@mail.gmail.com> <26D36D0E-3A57-4DF2-8D9E-07A876B12DE5@cse.unsw.edu.au> <20080815141223.GA9938@matrix.chaos.earth.li> Message-ID: <1218888075.13639.81.camel@localhost> On Fri, 2008-08-15 at 15:12 +0100, Ian Lynagh wrote: > On Fri, Aug 15, 2008 at 11:12:20AM +1000, Manuel M T Chakravarty wrote: > > > > Moreover, as I wrote a few times before, some reasons for switching in > > the first place are invalidated by not having the core libraries in > > git, too. For example, one complaint about darcs is that it either > > doesn't build (on the Sun Solaris T1 and T2 machines) > > I don't remember seeing this mentioned before, and googling for > "Solaris T1" darcs > doesn't find anything. That's probably because there ?entire world are probably only two T1/T2 machines that people are using to run ghc. :-) One of them is at UNSW and the other was recently donated by Sun to the community and is just about to go online at Chalmers. > What goes wrong? I'd expect darcs to build anywhere GHC does. So would I usually, though I've had to turn down cc flags to get darcs to build on ia64 before (SHA1.hs generates enormous register pressure). Duncan From chak at cse.unsw.edu.au Sun Aug 17 22:00:47 2008 From: chak at cse.unsw.edu.au (Manuel M T Chakravarty) Date: Sun Aug 17 22:46:49 2008 Subject: Version control systems In-Reply-To: References: <48981C03.10908@gmail.com> <20080808130329.GA15063@matrix.chaos.earth.li> <5FEA1F32-9C34-4888-A5BE-D0460D55C307@cse.unsw.edu.au> <48A05827.5020200@gmail.com> <638ABD0A29C8884A91BC5FB5C349B1C32AE8066602@EA-EXMSG-C334.europe.corp.microsoft.com> <4492B45B-6699-4444-87A9-83F0595B4EB7@cse.unsw.edu.au> <48A28F11.4090307@gmail.com> <404396ef0808141534i65ceae28ud23186d3f845714@mail.gmail.com> <83BF150C-20EA-48AA-8C1B-BFC8B6CA71EB@cse.unsw.edu.au> <916b84820808141712t18d87a07v47bf7be012cd7725@mail.gmail.com> <26D36D0E-3A57-4DF2-8D9E-07A876B12DE5@cse.unsw.edu.au> Message-ID: Gregory Wright: > On Aug 14, 2008, at 9:12 PM, Manuel M T Chakravarty wrote: > >> Moreover, as I wrote a few times before, some reasons for switching >> in the first place are invalidated by not having the core libraries >> in git, too. For example, one complaint about darcs is that it >> either doesn't build (on the Sun Solaris T1 and T2 machines) or is >> buggy (on Mac OS with MacPorts), and hence people have trouble >> getting the sources out of darcs in the first place. How is that >> going to be addressed if some crucial code still needs to be >> obtained using darcs? >> > > Regarding darcs on OS X from MacPorts, I am not aware (or have been > sent any bug reports) that there > are problems with the latest darcs-2.0.0 port. Is there something > that I should know (and try to fix)? > > The latest port defaults to wget instead of libcurl since I have > noticed darcs spinning endlessly when > using libcurl. I haven't had time to dtrace what is going on but > I'm guessing the underlying problem is likely > some misunderstanding of the signal handling API or some corner case > of blocking/nonblocking IO. Well, that "spinning endlessly" is the bug I am referring to. I re- checked my MacPorts darcs2 installation and, you are right, there was an update that removes the use of libcurl. It seems to work *much* better now. Thanks for the fix! You may want to publicise this a bit further. When I asked on #darcs about the problem a few days ago, nobody knew about this update to the port. Manuel From chak at cse.unsw.edu.au Sun Aug 17 22:21:47 2008 From: chak at cse.unsw.edu.au (Manuel M T Chakravarty) Date: Sun Aug 17 23:01:01 2008 Subject: Version control systems In-Reply-To: <20080815143840.GB9938@matrix.chaos.earth.li> References: <638ABD0A29C8884A91BC5FB5C349B1C32AE8066602@EA-EXMSG-C334.europe.corp.microsoft.com> <4492B45B-6699-4444-87A9-83F0595B4EB7@cse.unsw.edu.au> <48A28F11.4090307@gmail.com> <404396ef0808141534i65ceae28ud23186d3f845714@mail.gmail.com> <83BF150C-20EA-48AA-8C1B-BFC8B6CA71EB@cse.unsw.edu.au> <916b84820808141712t18d87a07v47bf7be012cd7725@mail.gmail.com> <26D36D0E-3A57-4DF2-8D9E-07A876B12DE5@cse.unsw.edu.au> <48A564D4.3000806@charter.net> <9d4d38820808150501n17c8d56g730dc2b5d4e99126@mail.gmail.com> <20080815143840.GB9938@matrix.chaos.earth.li> Message-ID: From what you are saying, it seems that one "advantage" of git (in- place branch switching) is not going to be useful to GHC in any case (because we use nested repositories). Manuel Ian Lynagh: > On Fri, Aug 15, 2008 at 01:01:08PM +0100, Max Bolingbroke wrote: >> 2008/8/15 Isaac Dupree : >>> So let's figure out how it would work (I have doubts too!) So, >>> within the >>> directory that's a git repo (ghc), we have some other repos, git >>> (testsuite) >>> and darcs (some libraries). Does anyone know how git handles >>> nested repos >>> even natively? >> >> You can explicitly tell Git about nested Git repos using >> http://www.kernel.org/pub/software/scm/git/docs/git-submodule.html. >> This essentially associates a particular version of each subrepo with >> every version of the repo that contains them, so e.g. checking out >> GHC >> from 2 weeks ago could check out the libraries from the same point in >> time. > > We were talking about this last night on #ghc, and AIUI this doesn't > play well with the in-tree branching style that is advocated, e.g. if > you want to branch ghc and base then as you change between ghc > branch X > and Y, git won't automatically change base between branches X' and Y'. > >>> Then, adding complexity, git branches are normally done by >>> switching in-place. So how does this interact with VCS like darcs >>> that >>> doesn't have a concept of in-place switching of branches? > > The in-tree branching style also sounds like it won't work well with > trees you are working in: If you have a tree built with branch X, and > then you swap to branch Y for a minute and then back to branch X, then > the timestamps on any source files that differ between the branches > will > have changed, so the build won't think it is up-to-date any more and > you > will get needless recompilation. > > Working only in the "master" branch, and using different repos for > branches (i.e. doing what we do with darcs), is an option, although > git > users seem to think it is a worse way to work; I'm not really clear on > the main reasons why. > > One way that it is worse is that you will get a lot more "automatic > merge" commits when you pull changes from the central repo into a repo > in which you have local commits. I don't think that there is anything > bad about these, as such; they're just noise in the history. (I'm not > sure if it's possible to automatically rebase these away, or > something?). > > Hopefully a git person will correct me if I've got something wrong! > > > Thanks > Ian > > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users@haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users From chak at cse.unsw.edu.au Sun Aug 17 22:28:03 2008 From: chak at cse.unsw.edu.au (Manuel M T Chakravarty) Date: Sun Aug 17 23:03:23 2008 Subject: Version control systems In-Reply-To: <20080815181914.GA17041@matrix.chaos.earth.li> References: <48A28F11.4090307@gmail.com> <404396ef0808141534i65ceae28ud23186d3f845714@mail.gmail.com> <83BF150C-20EA-48AA-8C1B-BFC8B6CA71EB@cse.unsw.edu.au> <916b84820808141712t18d87a07v47bf7be012cd7725@mail.gmail.com> <26D36D0E-3A57-4DF2-8D9E-07A876B12DE5@cse.unsw.edu.au> <48A564D4.3000806@charter.net> <9d4d38820808150501n17c8d56g730dc2b5d4e99126@mail.gmail.com> <20080815143840.GB9938@matrix.chaos.earth.li> <916b84820808150809w3bf7c83dk8734f679c5c34654@mail.gmail.com> <20080815152412.GA11627@matrix.chaos.earth.li> <20080815181914.GA17041@matrix.chaos.earth.li> Message-ID: <848BCA1E-DF91-4C0F-9DD8-B3BCD7EFF562@cse.unsw.edu.au> Ian Lynagh: > On Fri, Aug 15, 2008 at 04:24:12PM +0100, Ian Lynagh wrote: >> On Fri, Aug 15, 2008 at 05:09:55PM +0200, Thomas Schilling wrote: >>> On Fri, Aug 15, 2008 at 4:38 PM, Ian Lynagh wrote: >>>> One way that it is worse is that you will get a lot more "automatic >>>> merge" commits when you pull changes from the central repo into a >>>> repo >>>> in which you have local commits. I don't think that there is >>>> anything >>>> bad about these, as such; they're just noise in the history. (I'm >>>> not >>>> sure if it's possible to automatically rebase these away, or >>>> something?). >>> >>> This is the use case for "git pull --rebase". Instead of creating >>> an >>> automatic merge commit, it rebases your local changes on top of the >>> newly pulled changes >> >> Hmm, last night the conversation went: >> >> < nominolo> malcolmw: so i'm advocating "git pull --rebase" for >> that use case >> < glguy_> rebasing can be less successful than merging when >> dealing with big changes >> < glguy_> since the rebase happens one commit >> at a time >> >> so I'm confused as to what the best practice is. > > We discussed this in #ghc, and the conclusion seems to be: > > If you have lots of local changes (e.g. the sorts of long-running > branch > that gives darcs 1 problems), then you need to use merge. If you use > rebase then you might end up with lots of conflicts to manually > resolve. > > Using merge gives you automatic merge commits, If you think these are > ugly (opinion is divided on that amongst git people; I guess for GHC > we'd want to make a global decision about that) then you can use > rebase > when you have few local changes, and thus you are unlikely to get many > conflicts. > > Using merge you also get a more accurate reflection of the project > history, i.e. you can see that the two branches were being developed > independently. Sorry for being a git n00b, but does using merge mean that we need to use in-place branch switching (which you earlier said won't work well for ghc anyways)? Manuel From prj at po.cwru.edu Sun Aug 17 23:45:30 2008 From: prj at po.cwru.edu (Paul Jarc) Date: Sun Aug 17 23:44:42 2008 Subject: invoking a Haskell script without a .hs extension Message-ID: I have a Haskell script called "notify", without a .hs extension, which causes some problems. (I'm using ghc 6.8.3.) First attempt: runhaskell notify Without the .hs extension, ghc doesn't know it's a Haskell script, and so I get "Could not find module `notify'". Maybe runhaskell should automatically add "-x hs" to the ghc command? Second attempt: runhaskell -x hs notify This get me "Not in scope: `main'". runhaskell is invoking ghc with these arguments: -ignore-dot-ghci -x -e ':set prog "hs"' -e ':main ["notify"]' hs So it looks like runhaskell it treating "-x" as an argument to be relayed to ghc, "hs" as the name of the script, and "notify" as an argument to the script. I guess I need to use "--" to make it clear where the ghc arguments end and where the script and its arguments begin. Third attempt: runhaskell -- -x hs -- notify This gets me "Not in scope: `main'" again. runhaskell is invoking ghc with these arguments: -ignore-dot-ghci -x -e ':set prog "hs"' -e ':main ["--","notify"]' hs This looks like a bug in the "--" handling, unless I'm misinterpreting the usage message I get from running plain "runhaskell". Fourth attempt: ghc -ignore-dot-ghci -e ':set prog "notify"' \ -e ':main []' -x hs notify This works, but passing arguments becomes rather cumbersome. If there's a way to get runhaskell to pass "-x hs" in the right place, that would be much better. A somewhat related issue: I'd like to avoid hard-coding the path to runhaskell or ghc in the #! line. Instead, I'd like to use #!/bin/sh, and have the shell find runhaskell or ghc in $PATH. This means the first few lines of the script would have to be executed by sh, but ignored by ghc. Most scripting langauges have some way of doing this, although it's often by accident. The best way I've seen is in Guile, where "#!" starts a multi-line comment, and "!#" ends it. For Haskell, this is the best I could come up with: #!/bin/sh {- > /dev/null 2>&1 exec ghc -ignore-dot-ghci \ -e ":set prog \"$0\"" \ -e ':main []' -x hs "$0" -} But this depends on "{-" not existing as an executable command, or at least not doing anything harmful when invoked like this. I'd like to avoid depending on anything like that. Does anyone have any better ideas? paul From philip.weaver at gmail.com Mon Aug 18 00:32:01 2008 From: philip.weaver at gmail.com (Philip Weaver) Date: Mon Aug 18 00:31:10 2008 Subject: invoking a Haskell script without a .hs extension In-Reply-To: References: Message-ID: On Sun, Aug 17, 2008 at 8:45 PM, Paul Jarc wrote: > I have a Haskell script called "notify", without a .hs extension, > which causes some problems. (I'm using ghc 6.8.3.) > > First attempt: runhaskell notify > Without the .hs extension, ghc doesn't know it's a Haskell script, and > so I get "Could not find module `notify'". Maybe runhaskell should > automatically add "-x hs" to the ghc command? > > Second attempt: runhaskell -x hs notify > This get me "Not in scope: `main'". runhaskell is invoking ghc with > these arguments: > -ignore-dot-ghci -x -e ':set prog "hs"' -e ':main ["notify"]' hs > So it looks like runhaskell it treating "-x" as an argument to be > relayed to ghc, "hs" as the name of the script, and "notify" as an > argument to the script. I guess I need to use "--" to make it clear > where the ghc arguments end and where the script and its arguments > begin. > > Third attempt: runhaskell -- -x hs -- notify > This gets me "Not in scope: `main'" again. runhaskell is invoking ghc > with these arguments: > -ignore-dot-ghci -x -e ':set prog "hs"' -e ':main ["--","notify"]' hs > This looks like a bug in the "--" handling, unless I'm misinterpreting > the usage message I get from running plain "runhaskell". > > Fourth attempt: ghc -ignore-dot-ghci -e ':set prog "notify"' \ > -e ':main []' -x hs notify > This works, but passing arguments becomes rather cumbersome. If > there's a way to get runhaskell to pass "-x hs" in the right place, > that would be much better. > > A somewhat related issue: I'd like to avoid hard-coding the path to > runhaskell or ghc in the #! line. Instead, I'd like to use #!/bin/sh, > and have the shell find runhaskell or ghc in $PATH. I'll let someone more knowledgeable address the other issues, but as for the argument to #!, I believe you could/should use "#!/usr/bin/env runhaskell". > This means the > first few lines of the script would have to be executed by sh, but > ignored by ghc. Most scripting langauges have some way of doing this, > although it's often by accident. The best way I've seen is in Guile, > where "#!" starts a multi-line comment, and "!#" ends it. For > Haskell, this is the best I could come up with: > > #!/bin/sh > {- > /dev/null 2>&1 > exec ghc -ignore-dot-ghci \ > -e ":set prog \"$0\"" \ > -e ':main []' -x hs "$0" > -} > > But this depends on "{-" not existing as an executable command, or at > least not doing anything harmful when invoked like this. I'd like to > avoid depending on anything like that. Does anyone have any better > ideas? > > > paul > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users@haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20080817/de83821f/attachment.htm From prj at po.cwru.edu Mon Aug 18 01:53:06 2008 From: prj at po.cwru.edu (Paul Jarc) Date: Mon Aug 18 01:52:09 2008 Subject: invoking a Haskell script without a .hs extension In-Reply-To: (Philip Weaver's message of "Sun\, 17 Aug 2008 21\:32\:01 -0700") References: Message-ID: "Philip Weaver" wrote: > I'll let someone more knowledgeable address the other issues, but as for the > argument to #!, I believe you could/should use "#!/usr/bin/env runhaskell". That would work if runhaskell automatically supplied -x hs (passing multiple arguments on the #! line doesn't work portably), and if no other arguments to runhaskell are needed, and if there's no need/want to do anything else in sh before re-executing with runhaskell. Using #!/bin/sh gives more flexibility, so I'd like to find a better way to do that. paul From Christian.Maeder at dfki.de Mon Aug 18 04:46:44 2008 From: Christian.Maeder at dfki.de (Christian Maeder) Date: Mon Aug 18 04:45:46 2008 Subject: Any release date for GHC 6.8.3 for Mac OS X 10.5 (Leopard) on PowerPC G4 machines? In-Reply-To: <1s4g94ltjp7goe83lsgehgp204odhl0da2@4ax.com> References: <7e9d94d3c5vb7na7k02d6rn5i5hqbqsoba@4ax.com> <489732B7.9020203@dfki.de> <4897FD1D.8000308@dfki.de> <1s4g94ltjp7goe83lsgehgp204odhl0da2@4ax.com> Message-ID: <48A936F4.8080507@dfki.de> Meanwhile Ian has updated the download page. Although it was built on a G5 with Tiger it should also run on a G4 with Leopard. (and was reported to run on G4 with Tiger) Christian Benjamin L.Russell wrote: > On Tue, 05 Aug 2008 09:11:25 +0200, Christian Maeder > wrote: > >> I've rebuild the binary without statically linked gmp. [...] >> >> So in addition to readline (and ncurses) you need gmp from MacPorts. >> (Otherwise even installation will fail, because pwd needs gmp.) >> >> If you want ghc to produce static binaries then move the static library >> libgmp.a into your installed ghc's libdir. > > Thank you very much for the update. I'll be sure to fetch gmp from > MaPorts when I install GHC 6.8.3 on Mac OS X 10.5 (Leopard), and to > move libgmp.a into my installed GHC's libdir. > > If I run into problems, I'll post them in this thread. > > -- Benjamin L. Russell From bertram.felgenhauer at googlemail.com Mon Aug 18 04:47:51 2008 From: bertram.felgenhauer at googlemail.com (Bertram Felgenhauer) Date: Mon Aug 18 04:47:05 2008 Subject: invoking a Haskell script without a .hs extension In-Reply-To: References: Message-ID: <20080818084751.GA4202@zombie.inf.tu-dresden.de> Paul Jarc wrote: > I have a Haskell script called "notify", without a .hs extension, > which causes some problems. (I'm using ghc 6.8.3.) > > First attempt: runhaskell notify > Without the .hs extension, ghc doesn't know it's a Haskell script, and > so I get "Could not find module `notify'". Maybe runhaskell should > automatically add "-x hs" to the ghc command? The 6.9 branch version of runghc does that, actually. (runhaskell is probably a symlink to runghc.) > Second attempt: runhaskell -x hs notify There's an undocumented runghc flag which I found by looking at the source code, --ghc-arg, that can be used for this. runghc -x --ghc-arg=hs notify should work. runghc's handling of "--" is a little odd; it does stop parsing ghc args when "--" is encountered, but it also stops at the first option that doesn't start with a hyphen, even if a "--" follows later. HTH, Bertram From igloo at earth.li Mon Aug 18 05:28:40 2008 From: igloo at earth.li (Ian Lynagh) Date: Mon Aug 18 05:27:42 2008 Subject: Version control systems In-Reply-To: References: <4492B45B-6699-4444-87A9-83F0595B4EB7@cse.unsw.edu.au> <48A28F11.4090307@gmail.com> <404396ef0808141534i65ceae28ud23186d3f845714@mail.gmail.com> <83BF150C-20EA-48AA-8C1B-BFC8B6CA71EB@cse.unsw.edu.au> <916b84820808141712t18d87a07v47bf7be012cd7725@mail.gmail.com> <26D36D0E-3A57-4DF2-8D9E-07A876B12DE5@cse.unsw.edu.au> <48A564D4.3000806@charter.net> <9d4d38820808150501n17c8d56g730dc2b5d4e99126@mail.gmail.com> <20080815143840.GB9938@matrix.chaos.earth.li> Message-ID: <20080818092840.GA25432@matrix.chaos.earth.li> On Mon, Aug 18, 2008 at 12:21:47PM +1000, Manuel M T Chakravarty wrote: > From what you are saying, it seems that one "advantage" of git (in- > place branch switching) is not going to be useful to GHC in any case Yes. > (because we use nested repositories). That does make it harder, but the main problem is that switching between branches changes the timestamp of files that differ, meaning the build system thinks that recompilation needs to be done. Also, if you have 2 in-place branches of GHC then only one of them can be built at any one time, as they share a working directory. Thanks Ian From igloo at earth.li Mon Aug 18 05:31:41 2008 From: igloo at earth.li (Ian Lynagh) Date: Mon Aug 18 05:30:43 2008 Subject: Version control systems In-Reply-To: <848BCA1E-DF91-4C0F-9DD8-B3BCD7EFF562@cse.unsw.edu.au> References: <83BF150C-20EA-48AA-8C1B-BFC8B6CA71EB@cse.unsw.edu.au> <916b84820808141712t18d87a07v47bf7be012cd7725@mail.gmail.com> <26D36D0E-3A57-4DF2-8D9E-07A876B12DE5@cse.unsw.edu.au> <48A564D4.3000806@charter.net> <9d4d38820808150501n17c8d56g730dc2b5d4e99126@mail.gmail.com> <20080815143840.GB9938@matrix.chaos.earth.li> <916b84820808150809w3bf7c83dk8734f679c5c34654@mail.gmail.com> <20080815152412.GA11627@matrix.chaos.earth.li> <20080815181914.GA17041@matrix.chaos.earth.li> <848BCA1E-DF91-4C0F-9DD8-B3BCD7EFF562@cse.unsw.edu.au> Message-ID: <20080818093141.GB25432@matrix.chaos.earth.li> On Mon, Aug 18, 2008 at 12:28:03PM +1000, Manuel M T Chakravarty wrote: > > does using merge mean that we need to use in-place branch switching No; when you "git pull" (the equivalent of darcs pull -a) it will pull and merge the changes (unless you ask it to rebase them instead of merging them). Thanks Ian From marlowsd at gmail.com Mon Aug 18 05:55:20 2008 From: marlowsd at gmail.com (Simon Marlow) Date: Mon Aug 18 05:54:25 2008 Subject: Version control systems In-Reply-To: References: <638ABD0A29C8884A91BC5FB5C349B1C32AE8066602@EA-EXMSG-C334.europe.corp.microsoft.com> <4492B45B-6699-4444-87A9-83F0595B4EB7@cse.unsw.edu.au> <48A28F11.4090307@gmail.com> <404396ef0808141534i65ceae28ud23186d3f845714@mail.gmail.com> <83BF150C-20EA-48AA-8C1B-BFC8B6CA71EB@cse.unsw.edu.au> <916b84820808141712t18d87a07v47bf7be012cd7725@mail.gmail.com> <26D36D0E-3A57-4DF2-8D9E-07A876B12DE5@cse.unsw.edu.au> <48A564D4.3000806@charter.net> <9d4d38820808150501n17c8d56g730dc2b5d4e99126@mail.gmail.com> <20080815143840.GB9938@matrix.chaos.earth.li> Message-ID: <48A94708.70202@gmail.com> Manuel M T Chakravarty wrote: > From what you are saying, it seems that one "advantage" of git > (in-place branch switching) is not going to be useful to GHC in any case > (because we use nested repositories). As far as I can tell, in-place branches are not a lot of use to us compared to just having separate checkouts for each local branch. For one thing, having separate source trees lets you keep multiple builds, whereas with in-place branches you can only have one build at a time, and switching branches probably requires a complete rebuild. However, I think I am convinced that using in-place branches for the master repo makes sense. That way we don't need to publish the names of new branches when we make them, and everyone can easily see which branches of GHC are available from the main repo. Cheers, Simon From marlowsd at gmail.com Mon Aug 18 06:13:28 2008 From: marlowsd at gmail.com (Simon Marlow) Date: Mon Aug 18 06:12:37 2008 Subject: Version control systems In-Reply-To: <1218888075.13639.81.camel@localhost> References: <5FEA1F32-9C34-4888-A5BE-D0460D55C307@cse.unsw.edu.au> <48A05827.5020200@gmail.com> <638ABD0A29C8884A91BC5FB5C349B1C32AE8066602@EA-EXMSG-C334.europe.corp.microsoft.com> <4492B45B-6699-4444-87A9-83F0595B4EB7@cse.unsw.edu.au> <48A28F11.4090307@gmail.com> <404396ef0808141534i65ceae28ud23186d3f845714@mail.gmail.com> <83BF150C-20EA-48AA-8C1B-BFC8B6CA71EB@cse.unsw.edu.au> <916b84820808141712t18d87a07v47bf7be012cd7725@mail.gmail.com> <26D36D0E-3A57-4DF2-8D9E-07A876B12DE5@cse.unsw.edu.au> <20080815141223.GA9938@matrix.chaos.earth.li> <1218888075.13639.81.camel@localhost> Message-ID: <48A94B48.5030402@gmail.com> Duncan Coutts wrote: > On Fri, 2008-08-15 at 15:12 +0100, Ian Lynagh wrote: >> On Fri, Aug 15, 2008 at 11:12:20AM +1000, Manuel M T Chakravarty wrote: >>> Moreover, as I wrote a few times before, some reasons for switching in >>> the first place are invalidated by not having the core libraries in >>> git, too. For example, one complaint about darcs is that it either >>> doesn't build (on the Sun Solaris T1 and T2 machines) >> I don't remember seeing this mentioned before, and googling for >> "Solaris T1" darcs >> doesn't find anything. > > That's probably because there ?entire world are probably only two T1/T2 > machines that people are using to run ghc. :-) > > One of them is at UNSW and the other was recently donated by Sun to the > community and is just about to go online at Chalmers. > >> What goes wrong? I'd expect darcs to build anywhere GHC does. > > So would I usually, though I've had to turn down cc flags to get darcs > to build on ia64 before (SHA1.hs generates enormous register pressure). We should really use a C implementation of SHA1, the Haskell version isn't buying us anything beyond being a stress test of the register allocator. Cheers, Simon From Ben.Lippmeier at anu.edu.au Mon Aug 18 07:20:54 2008 From: Ben.Lippmeier at anu.edu.au (Ben Lippmeier) Date: Mon Aug 18 07:20:00 2008 Subject: Version control systems In-Reply-To: <48A94B48.5030402@gmail.com> References: <5FEA1F32-9C34-4888-A5BE-D0460D55C307@cse.unsw.edu.au> <48A05827.5020200@gmail.com> <638ABD0A29C8884A91BC5FB5C349B1C32AE8066602@EA-EXMSG-C334.europe.corp.microsoft.com> <4492B45B-6699-4444-87A9-83F0595B4EB7@cse.unsw.edu.au> <48A28F11.4090307@gmail.com> <404396ef0808141534i65ceae28ud23186d3f845714@mail.gmail.com> <83BF150C-20EA-48AA-8C1B-BFC8B6CA71EB@cse.unsw.edu.au> <916b84820808141712t18d87a07v47bf7be012cd7725@mail.gmail.com> <26D36D0E-3A57-4DF2-8D9E-07A876B12DE5@cse.unsw.edu.au> <20080815141223.GA9938@matrix.chaos.earth.li> <1218888075.13639.81.camel@localhost> <48A94B48.5030402@gmail.com> Message-ID: On 18/08/2008, at 8:13 PM, Simon Marlow wrote: >> So would I usually, though I've had to turn down cc flags to get >> darcs >> to build on ia64 before (SHA1.hs generates enormous register >> pressure). > > We should really use a C implementation of SHA1, the Haskell version > isn't buying us anything beyond being a stress test of the register > allocator. > .. and perhaps a test case for too much code unfolding in GHC? Sounds like bugs to me. :) If you turn down GHC flags the pressure also goes away. Ian: Did this problem result in Intel CC / GCC register allocator freakouts? Ben. From prj at po.cwru.edu Mon Aug 18 10:32:27 2008 From: prj at po.cwru.edu (Paul Jarc) Date: Mon Aug 18 10:31:33 2008 Subject: invoking a Haskell script without a .hs extension In-Reply-To: <20080818084751.GA4202@zombie.inf.tu-dresden.de> (Bertram Felgenhauer's message of "Mon\, 18 Aug 2008 10\:47\:51 +0200") References: <20080818084751.GA4202@zombie.inf.tu-dresden.de> Message-ID: Bertram Felgenhauer wrote: > Paul Jarc wrote: >> Maybe runhaskell should automatically add "-x hs" to the ghc >> command? > > The 6.9 branch version of runghc does that, actually. Ah, that's good news. > There's an undocumented runghc flag which I found by looking at the > source code, --ghc-arg, that can be used for this. > > runghc -x --ghc-arg=hs notify That works, thanks! paul From allbery at ece.cmu.edu Mon Aug 18 14:11:41 2008 From: allbery at ece.cmu.edu (Brandon S. Allbery KF8NH) Date: Mon Aug 18 14:10:50 2008 Subject: invoking a Haskell script without a .hs extension In-Reply-To: References: Message-ID: <7C3E0470-4600-49A6-8975-B93C9940E6CF@ece.cmu.edu> On 2008 Aug 17, at 23:45, Paul Jarc wrote: > A somewhat related issue: I'd like to avoid hard-coding the path to > runhaskell or ghc in the #! line. Instead, I'd like to use #!/bin/sh, > and have the shell find runhaskell or ghc in $PATH. This means the #! /usr/bin/env runhaskell ... -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH From johan.tibell at gmail.com Tue Aug 19 05:45:04 2008 From: johan.tibell at gmail.com (Johan Tibell) Date: Tue Aug 19 05:44:03 2008 Subject: Version control systems In-Reply-To: References: <5FEA1F32-9C34-4888-A5BE-D0460D55C307@cse.unsw.edu.au> <48A28F11.4090307@gmail.com> <404396ef0808141534i65ceae28ud23186d3f845714@mail.gmail.com> <83BF150C-20EA-48AA-8C1B-BFC8B6CA71EB@cse.unsw.edu.au> <916b84820808141712t18d87a07v47bf7be012cd7725@mail.gmail.com> <26D36D0E-3A57-4DF2-8D9E-07A876B12DE5@cse.unsw.edu.au> <20080815141223.GA9938@matrix.chaos.earth.li> <1218888075.13639.81.camel@localhost> <48A94B48.5030402@gmail.com> Message-ID: <90889fe70808190245i645cd72fuf08eb27cfef53525@mail.gmail.com> Git 1.6.0 was just released [1]. Might be of interest given the current discussion. I cherry picked some highlights that might matter to us: * Source changes needed for porting to MinGW environment are now all in the main git.git codebase. * even more documentation pages are now accessible via "man" and "git help". * "git-add -i" has a new action 'e/dit' to allow you edit the patch hunk manually. 1. http://lkml.org/lkml/2008/8/17/174 Cheers, Johan From igloo at earth.li Tue Aug 19 06:57:05 2008 From: igloo at earth.li (Ian Lynagh) Date: Tue Aug 19 06:56:03 2008 Subject: Version control systems In-Reply-To: References: <4492B45B-6699-4444-87A9-83F0595B4EB7@cse.unsw.edu.au> <48A28F11.4090307@gmail.com> <404396ef0808141534i65ceae28ud23186d3f845714@mail.gmail.com> <83BF150C-20EA-48AA-8C1B-BFC8B6CA71EB@cse.unsw.edu.au> <916b84820808141712t18d87a07v47bf7be012cd7725@mail.gmail.com> <26D36D0E-3A57-4DF2-8D9E-07A876B12DE5@cse.unsw.edu.au> <20080815141223.GA9938@matrix.chaos.earth.li> <1218888075.13639.81.camel@localhost> <48A94B48.5030402@gmail.com> Message-ID: <20080819105705.GA13921@matrix.chaos.earth.li> On Mon, Aug 18, 2008 at 09:20:54PM +1000, Ben Lippmeier wrote: > > Ian: Did this problem result in Intel CC / GCC register allocator > freakouts? Have you got me confused with someone else? I don't think I've ever used Intel CC. Thanks Ian From Ben.Lippmeier at anu.edu.au Tue Aug 19 09:55:23 2008 From: Ben.Lippmeier at anu.edu.au (Ben Lippmeier) Date: Tue Aug 19 09:54:29 2008 Subject: SHA1.hs woes, was Version control systems In-Reply-To: <20080819105705.GA13921@matrix.chaos.earth.li> References: <4492B45B-6699-4444-87A9-83F0595B4EB7@cse.unsw.edu.au> <48A28F11.4090307@gmail.com> <404396ef0808141534i65ceae28ud23186d3f845714@mail.gmail.com> <83BF150C-20EA-48AA-8C1B-BFC8B6CA71EB@cse.unsw.edu.au> <916b84820808141712t18d87a07v47bf7be012cd7725@mail.gmail.com> <26D36D0E-3A57-4DF2-8D9E-07A876B12DE5@cse.unsw.edu.au> <20080815141223.GA9938@matrix.chaos.earth.li> <1218888075.13639.81.camel@localhost> <48A94B48.5030402@gmail.com> <20080819105705.GA13921@matrix.chaos.earth.li> Message-ID: <4A856484-91B7-4178-BEA4-6EBDBD885140@anu.edu.au> On 19/08/2008, at 8:57 PM, Ian Lynagh wrote: > On Mon, Aug 18, 2008 at 09:20:54PM +1000, Ben Lippmeier wrote: >> >> Ian: Did this problem result in Intel CC / GCC register allocator >> freakouts? > > Have you got me confused with someone else? I don't think I've ever > used > Intel CC. > Sorry, I couldn't find the rest of the preceding message. Someone wrote that they had to turn down cc flags to get SHA1.hs to compile on IA64. What C compiler was being used, and what were the symptoms? SHA1.hs creates vastly more register pressure than any other code I know of (or could find), but only when -O or -O2 is enabled in GHC. If -O and -prof are enabled then the linear allocator runs out of stack slots (last time I checked). I'm wondering three things: 1) If the C compiler could not compile the C code emitted by GHC then maybe we should file a bug report with the CC people. 2) If the register pressure in SHA1.hs is more due to excessive code unfolding than the actual SHA algorithm, then maybe this should be treated as a bug in the simplifier(?) (sorry, I'm not familiar with the core level stuff) 3) Ticket #1993 says that the linear allocator runs out of stack slots, and the graph coloring allocator stack overflows when trying to compile SHA1.hs with -funfolding-use-threshold20. I'm a bit worried about the stack over-flow part. The graph size is O(n^2) in the number of vreg conflicts, which isn't a problem for most code. However, if register pressure in SHA1.hs is proportional to the unfolding threshold (especially if more than linearly) then you could always blow up the graph allocator by setting the threshold arbitrarily high. In this case maybe the allocator should give a warning when the pressure is high and suggest turning the threshold down. Then we could close this issue and prevent it from being re-opened. Cheers, Ben. From duncan.coutts at worc.ox.ac.uk Tue Aug 19 15:43:27 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Tue Aug 19 15:43:08 2008 Subject: SHA1.hs woes, was Version control systems In-Reply-To: <4A856484-91B7-4178-BEA4-6EBDBD885140@anu.edu.au> References: <4492B45B-6699-4444-87A9-83F0595B4EB7@cse.unsw.edu.au> <48A28F11.4090307@gmail.com> <404396ef0808141534i65ceae28ud23186d3f845714@mail.gmail.com> <83BF150C-20EA-48AA-8C1B-BFC8B6CA71EB@cse.unsw.edu.au> <916b84820808141712t18d87a07v47bf7be012cd7725@mail.gmail.com> <26D36D0E-3A57-4DF2-8D9E-07A876B12DE5@cse.unsw.edu.au> <20080815141223.GA9938@matrix.chaos.earth.li> <1218888075.13639.81.camel@localhost> <48A94B48.5030402@gmail.com> <20080819105705.GA13921@matrix.chaos.earth.li> <4A856484-91B7-4178-BEA4-6EBDBD885140@anu.edu.au> Message-ID: <1219175007.13639.275.camel@localhost> On Tue, 2008-08-19 at 23:55 +1000, Ben Lippmeier wrote: > On 19/08/2008, at 8:57 PM, Ian Lynagh wrote: > > > On Mon, Aug 18, 2008 at 09:20:54PM +1000, Ben Lippmeier wrote: > >> > >> Ian: Did this problem result in Intel CC / GCC register allocator > >> freakouts? > > > > Have you got me confused with someone else? I don't think I've ever > > used > > Intel CC. > > > > Sorry, I couldn't find the rest of the preceding message. Someone > wrote that they had to turn down cc flags to get SHA1.hs to compile on > IA64. Yep. > What C compiler was being used, and what were the symptoms? GCC. As I recall the symptoms were that gcc used more than 32 registers and then the mangler balked. The reason is that a registerised ia64 build expects to only use the first 32 registers but does not take any precautions to make sure that this is the case. It just relies on the fact that most code coming out of the ghc backend cannot make use of more than a handful of registers. If gcc does actually use more then the mangler catches this. We tried some flags to make gcc restrict itself to a subset of the registers but could not get it to obey. Duncan From claus.reinke at talk21.com Wed Aug 20 10:52:13 2008 From: claus.reinke at talk21.com (Claus Reinke) Date: Wed Aug 20 10:51:10 2008 Subject: #ghc connection issue Message-ID: <00fc01c902d4$55d2a400$2c408351@cr3lt> I seem to be unable to join the ghc chatroom at irc.freenode.net at the moment (using Opera). Is that an issue with my irc client or a general problem? 15:47 Joining chat room... Disconnected from chat Claus From flippa at flippac.org Wed Aug 20 10:54:22 2008 From: flippa at flippac.org (Philippa Cowderoy) Date: Wed Aug 20 10:57:42 2008 Subject: #ghc connection issue In-Reply-To: <00fc01c902d4$55d2a400$2c408351@cr3lt> References: <00fc01c902d4$55d2a400$2c408351@cr3lt> Message-ID: On Wed, 20 Aug 2008, Claus Reinke wrote: > I seem to be unable to join the ghc chatroom at irc.freenode.net > at the moment (using Opera). Is that an issue with my irc client or a general > problem? > > 15:47 Joining chat room... > Disconnected from chat > It's probably on your end one way or another - I just /joined fine. Are you having problems with other freenode chans such as #haskell? -- flippa@flippac.org A problem that's all in your head is still a problem. Brain damage is but one form of mind damage. From ndmitchell at gmail.com Wed Aug 20 11:20:12 2008 From: ndmitchell at gmail.com (Neil Mitchell) Date: Wed Aug 20 11:19:05 2008 Subject: #ghc connection issue In-Reply-To: <00fc01c902d4$55d2a400$2c408351@cr3lt> References: <00fc01c902d4$55d2a400$2c408351@cr3lt> Message-ID: <404396ef0808200820u6569c657td895f82ee8944d15@mail.gmail.com> Hi Claus, > I seem to be unable to join the ghc chatroom at irc.freenode.net > at the moment (using Opera). Is that an issue with my irc client or a > general problem? I have joined just fine, using mibbit.com (from in Opera) Thanks Neil From claus.reinke at talk21.com Wed Aug 20 11:55:03 2008 From: claus.reinke at talk21.com (Claus Reinke) Date: Wed Aug 20 11:54:16 2008 Subject: #ghc connection issue References: <00fc01c902d4$55d2a400$2c408351@cr3lt> <404396ef0808200820u6569c657td895f82ee8944d15@mail.gmail.com> Message-ID: <013901c902dd$24df1f00$2c408351@cr3lt> Thanks everyone. Yes, the problem seems independent of channel, and yes, the disconnections come so quickly that I assume the attempts aren't even recorded in the rooms. mibbit.com 's javascript client was the third client I tried today, and that one finally worked. Looking forward to the log;-) Thanks, Claus >> I seem to be unable to join the ghc chatroom at irc.freenode.net >> at the moment (using Opera). Is that an issue with my irc client or a >> general problem? > > I have joined just fine, using mibbit.com (from in Opera) > > Thanks > > Neil > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users@haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users From allbery at ece.cmu.edu Wed Aug 20 12:40:01 2008 From: allbery at ece.cmu.edu (Brandon S. Allbery KF8NH) Date: Wed Aug 20 12:38:57 2008 Subject: #ghc connection issue In-Reply-To: <00fc01c902d4$55d2a400$2c408351@cr3lt> References: <00fc01c902d4$55d2a400$2c408351@cr3lt> Message-ID: On 2008 Aug 20, at 10:52, Claus Reinke wrote: > I seem to be unable to join the ghc chatroom at irc.freenode.net > at the moment (using Opera). Is that an issue with my irc client or > a general problem? > > 15:47 Joining chat room... > Disconnected from chat For a while some home routers/APs were a bit overzealous about trying to block certain kinds of evil DCC, and could do things like that. -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH From venkatr2004 at gmail.com Thu Aug 21 16:19:00 2008 From: venkatr2004 at gmail.com (Venkat Ramanan) Date: Thu Aug 21 16:17:52 2008 Subject: ghci history. Message-ID: Hi all, I've just started learning haskell. I encountered a strange behaviour in ghci. 1. ghci doesn't seem to do pruning of duplicate expressions. If the same expression is entered twice, both of them are stored in the history instead of just one. Bash uses environmental variables (HISTCONTROL and HISTIGNORE ) to modify this behavior. Is there a way to get the same behaviour in ghci? 2. Does the history of ghci get stored somewhere in a file? That would be useful. I'm using ghc-6.8.2 (ubuntu 8.04). Also, is there an updated ghc package (6.8.3) for ubuntu? If not, I'll try to install the binary. Thanks, Venkat. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20080821/797411de/attachment.htm From judah.jacobson at gmail.com Thu Aug 21 17:13:12 2008 From: judah.jacobson at gmail.com (Judah Jacobson) Date: Thu Aug 21 17:12:02 2008 Subject: ghci history. In-Reply-To: References: Message-ID: <6d74b0d20808211413s7a211c4fgba6bd92e0ab413c8@mail.gmail.com> 2008/8/21 Venkat Ramanan : > Hi all, > > I've just started learning haskell. > > I encountered a strange behaviour in ghci. > > 1. ghci doesn't seem to do pruning of duplicate expressions. If the same > expression is entered twice, both of them are stored in the history instead > of just one. Bash uses environmental variables (HISTCONTROL and HISTIGNORE ) > to modify this behavior. > > Is there a way to get the same behaviour in ghci? > I don't think there currently is; but you should feel free to submit a feature request with the desired behavior at: http://hackage.haskell.org/trac/ghc/ > 2. Does the history of ghci get stored somewhere in a file? That would be > useful. Currently (ghc-6.8) it does not store a history file, but it will in version 6.10 (due out around late September, I believe). Best, -Judah From venkatr2004 at gmail.com Thu Aug 21 18:26:00 2008 From: venkatr2004 at gmail.com (Venkat Ramanan) Date: Thu Aug 21 18:24:51 2008 Subject: ghci history. In-Reply-To: <6d74b0d20808211413s7a211c4fgba6bd92e0ab413c8@mail.gmail.com> References: <6d74b0d20808211413s7a211c4fgba6bd92e0ab413c8@mail.gmail.com> Message-ID: On Thu, Aug 21, 2008 at 5:13 PM, Judah Jacobson wrote: > I don't think there currently is; but you should feel free to submit a > feature request with the desired behavior at: > http://hackage.haskell.org/trac/ghc/ > OK. I just submitted a feature request there. (#2531) Is this easy enough for a haskell-newbie to do? I can try to take a swipe at it. Thanks, Venkat. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20080821/6d7345db/attachment.htm From marco-oweber at gmx.de Thu Aug 21 22:48:42 2008 From: marco-oweber at gmx.de (Marc Weber) Date: Thu Aug 21 22:47:34 2008 Subject: Version control systems - git example find changes which could be lost In-Reply-To: <48A1E1E7.1000203@charter.net> References: <1218016430.7661.189.camel@localhost> <9d4d38820808060331h4758c8a4y2bc6e79d14b8ae3d@mail.gmail.com> <18DB9581-AA5B-433C-9036-34EC2674C2CB@cse.unsw.edu.au> <20080808130329.GA15063@matrix.chaos.earth.li> <5FEA1F32-9C34-4888-A5BE-D0460D55C307@cse.unsw.edu.au> <48A05827.5020200@gmail.com> <638ABD0A29C8884A91BC5FB5C349B1C32AE8066602@EA-EXMSG-C334.europe.corp.microsoft.com> <62845DD1-279E-4D68-BA9B-586266DF7A4A@googlemail.com> <48A1E1E7.1000203@charter.net> Message-ID: <20080822024842.GA26519@gmx.de> On Tue, Aug 12, 2008 at 03:17:59PM -0400, Isaac Dupree wrote: > Thomas Schilling wrote: > > I encourage everyone to add useful tips and examples both from users who > > already use Git and later on, once we have gathered more experience. I > > believe that Git has some features which can improve our productivity and > > I'd like this page to also collect tips how to do so. > > what about `darcs send --dry-run`? It's not perfect, but I use it in my old > repos in conjunction with `darcs wh [-l]` to find out what of value I'd lose > by deleting an old checkout. (e.g., patches merged into HEAD aren't of > value. But they still aren't of value even if they've been amend-recorded, > rewritten, or equivalent by simon/ian/etc., but Darcs can't tell this, > unfortunately.) > > -Isaac Hi Isaac, git rebase can do this partially. See this example that's what I know about (make sure you don't have important data in /tmp/xx) How intelligent git behaves on partially applied / cherry picked commits I don't know. #!/bin/sh echO(){ echo; echo " >>>> $@"; echo 'return to continue'; read; } evaL(){ echo; echo "cmd: $@"; eval "$@"; } cd /tmp/xx || exit 1 rm -fr * .* set -e git init addfile(){ echo $1 > $1 git add $1 git commit -m $1 -a } evaL 'addfile a' evaL 'addfile b' evaL 'addfile c' evaL 'addfile d' echO 'a,b,c,d recorded succesfully' evaL 'git checkout HEAD~2' echO 'gone back two commits' evaL 'git checkout -b mutate' echO 'branch mutate created' evaL 'addfile new' echO 'new file new added which would be lost' evaL 'git cherry-pick master' evaL 'git cherry-pick master^' echO 'cherry picked d c in reverse order, look at popping up gitk now (you may want to keep it open)' evaL 'gitk --all &' echO 'continue after gitk has popped up, you should see one branch' evaL 'git checkout -b rebased' evaL 'git rebase master rebased' echO 'tried rebasing, data which would be lost should be ahead of master now' echO 'opening second gitk showing current repo state' evaL 'gitk --all' echO 'if this is not enough, you can always use git-diff:' evaL 'git diff mutate master' From marco-oweber at gmx.de Thu Aug 21 23:34:07 2008 From: marco-oweber at gmx.de (Marc Weber) Date: Thu Aug 21 23:32:58 2008 Subject: Version control systems In-Reply-To: <62845DD1-279E-4D68-BA9B-586266DF7A4A@googlemail.com> References: <20080806051232.GD17673@scytale.galois.com> <1218016430.7661.189.camel@localhost> <9d4d38820808060331h4758c8a4y2bc6e79d14b8ae3d@mail.gmail.com> <18DB9581-AA5B-433C-9036-34EC2674C2CB@cse.unsw.edu.au> <20080808130329.GA15063@matrix.chaos.earth.li> <5FEA1F32-9C34-4888-A5BE-D0460D55C307@cse.unsw.edu.au> <48A05827.5020200@gmail.com> <638ABD0A29C8884A91BC5FB5C349B1C32AE8066602@EA-EXMSG-C334.europe.corp.microsoft.com> <62845DD1-279E-4D68-BA9B-586266DF7A4A@googlemail.com> Message-ID: <20080822033407.GB26519@gmx.de> Isaac see third > FWIW, I started a wiki page that tries a direct comparison between Darcs and > Git: > > http://hackage.haskell.org/trac/ghc/wiki/GitForDarcsUsers > > Some mappings are simple, some are more complicated and will require > adopting a different workflow. I still recommend reading a tutorial, but > this cheat sheet should be a good start if you don't want to spend much time > to learn Git just yet. Where no directly corresponding command exists or > emulating it would be too messy, I try to hint towards other work flows. > > I encourage everyone to add useful tips and examples both from users who > already use Git and later on, once we have gathered more experience. I > believe that Git has some features which can improve our productivity and > I'd like this page to also collect tips how to do so. Hi Thomas: Great work! There is not much I could add (although I've used git during the last weeks quite often..) However I'm missing four small tips: first man git-rev-parse (or git rev-parse help) HEAD HEAD^ HEAD^^ .. is equal to HEAD HEAD~1 HEAD~2 ..> So to drop one of the last ten commits (don't remember which one) git rebase -i HEAD~10 ... second : you forgot to mention gitk. It helps you getting an overview about when which branches have been created You can use google pictures search to see how it looks like or just play around (try the script in my other post).. You can have a look at the history and branches easily.. You can even highlight commits by changes made to filepath (must be relative to repo path!) or by adding/ removing strings etc.. And it's a nice tool to just keep all hashes in memory in case you mess up your repo by accident :-) But recent gitk can do more. When getting some conflicts on git merge or git rebase gitk --merge will show you all commits causing this conflict. third: #git on freenode.. I bet you'll get help there as well.. I got the last tip there as well < doener> MarcWeber: you could, for example, do "git log or git rev-list or gitk --left-right --cherry-pick A...B" lists all commits beeing present on the one or the other branch, but not in both 4th: You should know one thing about git history There used to be no difference between git-log (now depreceated, does no longer work in the git git version) and git log Thus git log --help = git-log --help = man git-log (more convinient to type) The only execption: git-clone doesn't work in all cases, git clone does (?) (Don't ask me why) maybe git show commit-id:file is of interest as well (you told about git show) Sincerly Marc Weber From marco-oweber at gmx.de Thu Aug 21 23:52:27 2008 From: marco-oweber at gmx.de (Marc Weber) Date: Thu Aug 21 23:51:19 2008 Subject: Version control systems - no need to fear git In-Reply-To: <404396ef0808141534i65ceae28ud23186d3f845714@mail.gmail.com> References: <9d4d38820808060331h4758c8a4y2bc6e79d14b8ae3d@mail.gmail.com> <18DB9581-AA5B-433C-9036-34EC2674C2CB@cse.unsw.edu.au> <20080808130329.GA15063@matrix.chaos.earth.li> <5FEA1F32-9C34-4888-A5BE-D0460D55C307@cse.unsw.edu.au> <48A05827.5020200@gmail.com> <638ABD0A29C8884A91BC5FB5C349B1C32AE8066602@EA-EXMSG-C334.europe.corp.microsoft.com> <4492B45B-6699-4444-87A9-83F0595B4EB7@cse.unsw.edu.au> <48A28F11.4090307@gmail.com> <404396ef0808141534i65ceae28ud23186d3f845714@mail.gmail.com> Message-ID: <20080822035227.GC26519@gmx.de> > I personally don't know Git, and while I'm sure I'll be learning at > some point, I'm always nervous about learning a VCS on something I > care about, as mistakes can go quite wrong. If I can lend you (or someone else) a hand don't hesitate to contact me. (I'm not a git guru though..) With git you can't get too much wrong because it's very cheap to create additional pointerns / branches.. So if you clone a branch before taking any action you can always reset the messed up branch to the "backup" by git reset --{soft or hard} backupbranchname Or you could write a two line sh script writing all hashes to a temp file etc.. If you just start gitk it will keep all hashes in memory.. so you can recover from those as well (unless using the update menu item or running the garbage collector) Sincerly Marc Weber From marco-oweber at gmx.de Fri Aug 22 00:15:55 2008 From: marco-oweber at gmx.de (Marc Weber) Date: Fri Aug 22 00:14:49 2008 Subject: Version control systems In-Reply-To: <20080815181914.GA17041@matrix.chaos.earth.li> References: <404396ef0808141534i65ceae28ud23186d3f845714@mail.gmail.com> <83BF150C-20EA-48AA-8C1B-BFC8B6CA71EB@cse.unsw.edu.au> <916b84820808141712t18d87a07v47bf7be012cd7725@mail.gmail.com> <26D36D0E-3A57-4DF2-8D9E-07A876B12DE5@cse.unsw.edu.au> <48A564D4.3000806@charter.net> <9d4d38820808150501n17c8d56g730dc2b5d4e99126@mail.gmail.com> <20080815143840.GB9938@matrix.chaos.earth.li> <916b84820808150809w3bf7c83dk8734f679c5c34654@mail.gmail.com> <20080815152412.GA11627@matrix.chaos.earth.li> <20080815181914.GA17041@matrix.chaos.earth.li> Message-ID: <20080822041555.GD26519@gmx.de> > Using merge you also get a more accurate reflection of the project > history, i.e. you can see that the two branches were being developed > independently. Timestamps will be preserved so not all information is lost.. Marc From marco-oweber at gmx.de Fri Aug 22 00:26:28 2008 From: marco-oweber at gmx.de (Marc Weber) Date: Fri Aug 22 00:25:19 2008 Subject: Version control systems In-Reply-To: <848BCA1E-DF91-4C0F-9DD8-B3BCD7EFF562@cse.unsw.edu.au> References: <83BF150C-20EA-48AA-8C1B-BFC8B6CA71EB@cse.unsw.edu.au> <916b84820808141712t18d87a07v47bf7be012cd7725@mail.gmail.com> <26D36D0E-3A57-4DF2-8D9E-07A876B12DE5@cse.unsw.edu.au> <48A564D4.3000806@charter.net> <9d4d38820808150501n17c8d56g730dc2b5d4e99126@mail.gmail.com> <20080815143840.GB9938@matrix.chaos.earth.li> <916b84820808150809w3bf7c83dk8734f679c5c34654@mail.gmail.com> <20080815152412.GA11627@matrix.chaos.earth.li> <20080815181914.GA17041@matrix.chaos.earth.li> <848BCA1E-DF91-4C0F-9DD8-B3BCD7EFF562@cse.unsw.edu.au> Message-ID: <20080822042628.GE26519@gmx.de> > Sorry for being a git n00b, but does using merge mean that we need to use > in-place branch switching (which you earlier said won't work well for ghc > anyways)? You have to kind of "branches" : local ones and remote ones. remote ones represent the state of remote ones. The only way I know of to change them is by using git-fetch (which is called by git pull as well) or by editing the files manually On the other hand you normally push your local ones. So if you have /tmp/a/.git (heads master and mybranch) than do cd /tmp git clone a b git will setup .git/refs/remotes/{master,mybranch} .git/refs/heads/master Now you can make mybranch local as well by git branch mybranch remotes/mybranch (indeed you have 4 branches, 2 tracking the remote repo and two you are working with) Now you can do git checktout master; git merge mybranch # merge in place within the same repo or git merge remotes/mybranch # merge with remote branch which is what you'll do when using darcs branch style etc.. After comitting to mybrach git push will change the head of the remote repository. You can setup each local head branch to "track" a remote oone automaticaly so that git pull will rebase or merge depending on your settings (AFAIK) So if you have an active project you end up having dozens of remote branches but only some "heads" you are working on or you want to backup (in case someone else rewrits history or such) HTH Marc Weber From marco-oweber at gmx.de Fri Aug 22 00:42:10 2008 From: marco-oweber at gmx.de (Marc Weber) Date: Fri Aug 22 00:41:02 2008 Subject: Version control systems In-Reply-To: References: <4492B45B-6699-4444-87A9-83F0595B4EB7@cse.unsw.edu.au> <48A28F11.4090307@gmail.com> <404396ef0808141534i65ceae28ud23186d3f845714@mail.gmail.com> <83BF150C-20EA-48AA-8C1B-BFC8B6CA71EB@cse.unsw.edu.au> <916b84820808141712t18d87a07v47bf7be012cd7725@mail.gmail.com> <26D36D0E-3A57-4DF2-8D9E-07A876B12DE5@cse.unsw.edu.au> <48A564D4.3000806@charter.net> <9d4d38820808150501n17c8d56g730dc2b5d4e99126@mail.gmail.com> <20080815143840.GB9938@matrix.chaos.earth.li> Message-ID: <20080822044210.GF26519@gmx.de> On Mon, Aug 18, 2008 at 12:21:47PM +1000, Manuel M T Chakravarty wrote: > From what you are saying, it seems that one "advantage" of git (in-place > branch switching) is not going to be useful to GHC in any case (because we > use nested repositories). > Manuel I don't agree. I feel it's convinient. But I make full copies as well because switching the shell with my window manager is faster than checking out another branch.. But this depends on what I want to do. > > Ian Lynagh: > > The in-tree branching style also sounds like it won't work well with > > trees you are working in: If you have a tree built with branch X, and > > then you swap to branch Y for a minute and then back to branch X, then > > the timestamps on any source files that differ between the branches will > > have changed, so the build won't think it is up-to-date any more and you > > will get needless recompilation. Which is the fault of make not of git.. Why can't we configure make to use checksum based recompilations (that's possile using scons) Maybe it's possible to hack this in some way? I'd recommend having one working clone and one for browsing. Than you need two clones, but not n (you would have to mantain with darcs..) Why do you want to switch for a minute? There are tools such as gitk/ qgit letting you browse the repository (and all file contents) without switching. I don't think that recompilation is a real issue. Marc Weber From red5_2 at hotmail.com Fri Aug 22 10:05:04 2008 From: red5_2 at hotmail.com (C Rodrigues) Date: Fri Aug 22 10:03:53 2008 Subject: SHA1.hs woes, was Version control systems In-Reply-To: <20080822024742.1F6A73244B9@www.haskell.org> References: <20080822024742.1F6A73244B9@www.haskell.org> Message-ID: I've "fixed" this problem by increasing the number of registers used on ia64 to 34. The problem will show up again if anyone finds a way to make GCC use even more registers. -heatsink >> >> Sorry, I couldn't find the rest of the preceding message. Someone >> wrote that they had to turn down cc flags to get SHA1.hs to compile on >> IA64. > > Yep. > >> What C compiler was being used, and what were the symptoms? > > GCC. > > As I recall the symptoms were that gcc used more than 32 registers and > then the mangler balked. The reason is that a registerised ia64 build > expects to only use the first 32 registers but does not take any > precautions to make sure that this is the case. It just relies on the > fact that most code coming out of the ghc backend cannot make use of > more than a handful of registers. If gcc does actually use more then the > mangler catches this. We tried some flags to make gcc restrict itself to > a subset of the registers but could not get it to obey. > > Duncan _________________________________________________________________ Talk to your Yahoo! Friends via Windows Live Messenger. Find out how. http://www.windowslive.com/explore/messenger?ocid=TXT_TAGLM_WL_messenger_yahoo_082008 From chad.scherrer at gmail.com Fri Aug 22 17:20:32 2008 From: chad.scherrer at gmail.com (Chad Scherrer) Date: Fri Aug 22 17:19:19 2008 Subject: "dataflow rewriting engine" Message-ID: Hello GHC, This page http://hackage.haskell.org/trac/ghc/wiki/Commentary/Compiler/IntegratedCodeGen mentions a to-be-developed "dataflow rewriting engine". Can someone please send a description of what this will do? Thanks! -- Chad Scherrer "Time flies like an arrow; fruit flies like a banana" -- Groucho Marx From simonpj at microsoft.com Tue Aug 26 08:31:32 2008 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Tue Aug 26 08:30:09 2008 Subject: "dataflow rewriting engine" In-Reply-To: References: Message-ID: <638ABD0A29C8884A91BC5FB5C349B1C32AE85E0C2F@EA-EXMSG-C334.europe.corp.microsoft.com> Norman, John Would you care to respond to this? (Perhaps by amplifying the wiki page?) A good starting point is perhaps Craig's paper. Simon | -----Original Message----- | From: glasgow-haskell-users-bounces@haskell.org [mailto:glasgow-haskell-users-bounces@haskell.org] On | Behalf Of Chad Scherrer | Sent: 22 August 2008 22:21 | To: GHC Users | Subject: "dataflow rewriting engine" | | Hello GHC, | | This page | http://hackage.haskell.org/trac/ghc/wiki/Commentary/Compiler/IntegratedCodeGen | mentions a to-be-developed "dataflow rewriting engine". Can someone | please send a description of what this will do? | | Thanks! | -- | | Chad Scherrer | | "Time flies like an arrow; fruit flies like a banana" -- Groucho Marx | _______________________________________________ | Glasgow-haskell-users mailing list | Glasgow-haskell-users@haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users From t-jodias at microsoft.com Tue Aug 26 09:04:07 2008 From: t-jodias at microsoft.com (John Dias) Date: Tue Aug 26 09:02:45 2008 Subject: "dataflow rewriting engine" In-Reply-To: <638ABD0A29C8884A91BC5FB5C349B1C32AE85E0C2F@EA-EXMSG-C334.europe.corp.microsoft.com> References: <638ABD0A29C8884A91BC5FB5C349B1C32AE85E0C2F@EA-EXMSG-C334.europe.corp.microsoft.com> Message-ID: <6F495814B44AB642B84261441AD9155E2540AB297B@EA-EXMSG-C331.europe.corp.microsoft.com> I've added some text and links to point the reader in the right direction. Here's the new text, cribbed from the Wiki: Dataflow optimization: We can define a new optimization simply by defining a lattice of dataflow facts (akin to a specialized logic) and then writing the dataflow-transfer functions found in compiler textbooks. Handing these functions to the dataflow engine produces a new optimization that is not only useful on its own, but that can easily be composed with other optimizations to create an integrated "superoptimization" that is strictly more powerful than any sequence of individual optimizations, no matter how many times they are re-run. The dataflow engine is based on (Lerner, Grove, and Chambers 2002 http://citeseer.ist.psu.edu/old/lerner01composing.html); you can find a functional implementation of the dataflow engine presented in (Ramsey and Dias 2005 http://www.cs.tufts.edu/~nr/pubs/zipcfg-abstract.html). Let me know how I can further clarify the text, -j > -----Original Message----- > From: Simon Peyton-Jones > Sent: Tuesday, August 26, 2008 1:32 PM > To: Norman Ramsey; John Dias > Cc: Chad Scherrer; GHC Users > Subject: RE: "dataflow rewriting engine" > > Norman, John > > Would you care to respond to this? (Perhaps by amplifying the wiki > page?) A good starting point is perhaps Craig's paper. > > Simon > > | -----Original Message----- > | From: glasgow-haskell-users-bounces@haskell.org [mailto:glasgow- > haskell-users-bounces@haskell.org] On > | Behalf Of Chad Scherrer > | Sent: 22 August 2008 22:21 > | To: GHC Users > | Subject: "dataflow rewriting engine" > | > | Hello GHC, > | > | This page > | > http://hackage.haskell.org/trac/ghc/wiki/Commentary/Compiler/Integrated > CodeGen > | mentions a to-be-developed "dataflow rewriting engine". Can someone > | please send a description of what this will do? > | > | Thanks! > | -- > | > | Chad Scherrer > | > | "Time flies like an arrow; fruit flies like a banana" -- Groucho Marx > | _______________________________________________ > | Glasgow-haskell-users mailing list > | Glasgow-haskell-users@haskell.org > | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users From simonpj at microsoft.com Tue Aug 26 11:50:51 2008 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Tue Aug 26 11:49:27 2008 Subject: GHC's build system Message-ID: <638ABD0A29C8884A91BC5FB5C349B1C32AE86974D6@EA-EXMSG-C334.europe.corp.microsoft.com> Friends There's been quite a bit of discussion about GHC's build system recently, and in particular about the use of Cabal. Responding to that discussion we now have a new plan, described here: http://hackage.haskell.org/trac/ghc/wiki/Design/BuildSystem If you've taken an interest in the earlier thread, now would be a good time to look at our plan and help us improve it. In concrete terms, we propose to develop the changes (which should not be a radical upheaval) on a branch, and merge them into the head *after* the 6.10 code fork. So the new build system won't be on the 6.10 branch. It'll take a while to make the new system stabilise, and we want to get 6.10 out! Some comments and suggestions are best done by email, but please feel free to clarify or amplify wording on the Wiki itself, or add lists of questions and open issues. The two media are suitable for different things. But we do want to end up with a *comprehensible* description, with long-term value, of how the new system works, so where things are obscure please help us to clarify it. All this is somewhat separate to the question of what version control system to use for what. We're still working on that question! Simon From dons at galois.com Tue Aug 26 13:57:22 2008 From: dons at galois.com (Don Stewart) Date: Tue Aug 26 13:56:52 2008 Subject: "dataflow rewriting engine" In-Reply-To: <6F495814B44AB642B84261441AD9155E2540AB297B@EA-EXMSG-C331.europe.corp.microsoft.com> References: <638ABD0A29C8884A91BC5FB5C349B1C32AE85E0C2F@EA-EXMSG-C334.europe.corp.microsoft.com> <6F495814B44AB642B84261441AD9155E2540AB297B@EA-EXMSG-C331.europe.corp.microsoft.com> Message-ID: <20080826175722.GC3200@scytale.galois.com> I think we're all rather excited about seeing this stuff land. What's the expected timeline, wrt. ghc 6.10's release? -- Don t-jodias: > I've added some text and links to point the reader in the right > direction. Here's the new text, cribbed from the Wiki: > > Dataflow optimization: We can define a new optimization simply by > defining a lattice of dataflow facts (akin to a specialized logic) and > then writing the dataflow-transfer functions found in compiler > textbooks. Handing these functions to the dataflow engine produces a > new optimization that is not only useful on its own, but that can > easily be composed with other optimizations to create an integrated > "superoptimization" that is strictly more powerful than any sequence > of individual optimizations, no matter how many times they are re-run. > The dataflow engine is based on (Lerner, Grove, and Chambers 2002 > http://citeseer.ist.psu.edu/old/lerner01composing.html); you can find > a functional implementation of the dataflow engine presented in > (Ramsey and Dias 2005 > http://www.cs.tufts.edu/~nr/pubs/zipcfg-abstract.html). > > Let me know how I can further clarify the text, > -j > > > -----Original Message----- > > From: Simon Peyton-Jones > > Sent: Tuesday, August 26, 2008 1:32 PM > > To: Norman Ramsey; John Dias > > Cc: Chad Scherrer; GHC Users > > Subject: RE: "dataflow rewriting engine" > > > > Norman, John > > > > Would you care to respond to this? (Perhaps by amplifying the wiki > > page?) A good starting point is perhaps Craig's paper. > > > > Simon > > > > | -----Original Message----- > > | From: glasgow-haskell-users-bounces@haskell.org [mailto:glasgow- > > haskell-users-bounces@haskell.org] On > > | Behalf Of Chad Scherrer > > | Sent: 22 August 2008 22:21 > > | To: GHC Users > > | Subject: "dataflow rewriting engine" > > | > > | Hello GHC, > > | > > | This page > > | > > http://hackage.haskell.org/trac/ghc/wiki/Commentary/Compiler/Integrated > > CodeGen > > | mentions a to-be-developed "dataflow rewriting engine". Can someone > > | please send a description of what this will do? > > | > > | Thanks! > > | -- > > | > > | Chad Scherrer > > | > > | "Time flies like an arrow; fruit flies like a banana" -- Groucho Marx > > | _______________________________________________ > > | Glasgow-haskell-users mailing list > > | Glasgow-haskell-users@haskell.org > > | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users@haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > From dgoldsmith at mac.com Tue Aug 26 15:26:33 2008 From: dgoldsmith at mac.com (Deborah Goldsmith) Date: Tue Aug 26 15:26:01 2008 Subject: "dataflow rewriting engine" In-Reply-To: <20080826175722.GC3200@scytale.galois.com> References: <638ABD0A29C8884A91BC5FB5C349B1C32AE85E0C2F@EA-EXMSG-C334.europe.corp.microsoft.com> <6F495814B44AB642B84261441AD9155E2540AB297B@EA-EXMSG-C331.europe.corp.microsoft.com> <20080826175722.GC3200@scytale.galois.com> Message-ID: Has there been any thought about working with the LLVM project? I didn't find anything on the wiki along those lines. Thanks, Deborah On Aug 26, 2008, at 10:57 AM, Don Stewart wrote: > I think we're all rather excited about seeing this stuff land. > What's the expected timeline, wrt. ghc 6.10's release? > > -- Don > > t-jodias: >> I've added some text and links to point the reader in the right >> direction. Here's the new text, cribbed from the Wiki: >> >> Dataflow optimization: We can define a new optimization simply by >> defining a lattice of dataflow facts (akin to a specialized logic) >> and >> then writing the dataflow-transfer functions found in compiler >> textbooks. Handing these functions to the dataflow engine produces a >> new optimization that is not only useful on its own, but that can >> easily be composed with other optimizations to create an integrated >> "superoptimization" that is strictly more powerful than any sequence >> of individual optimizations, no matter how many times they are re- >> run. >> The dataflow engine is based on (Lerner, Grove, and Chambers 2002 >> http://citeseer.ist.psu.edu/old/lerner01composing.html); you can find >> a functional implementation of the dataflow engine presented in >> (Ramsey and Dias 2005 >> http://www.cs.tufts.edu/~nr/pubs/zipcfg-abstract.html). >> >> Let me know how I can further clarify the text, >> -j >> >>> -----Original Message----- >>> From: Simon Peyton-Jones >>> Sent: Tuesday, August 26, 2008 1:32 PM >>> To: Norman Ramsey; John Dias >>> Cc: Chad Scherrer; GHC Users >>> Subject: RE: "dataflow rewriting engine" >>> >>> Norman, John >>> >>> Would you care to respond to this? (Perhaps by amplifying the wiki >>> page?) A good starting point is perhaps Craig's paper. >>> >>> Simon >>> >>> | -----Original Message----- >>> | From: glasgow-haskell-users-bounces@haskell.org [mailto:glasgow- >>> haskell-users-bounces@haskell.org] On >>> | Behalf Of Chad Scherrer >>> | Sent: 22 August 2008 22:21 >>> | To: GHC Users >>> | Subject: "dataflow rewriting engine" >>> | >>> | Hello GHC, >>> | >>> | This page >>> | >>> http://hackage.haskell.org/trac/ghc/wiki/Commentary/Compiler/Integrated >>> CodeGen >>> | mentions a to-be-developed "dataflow rewriting engine". Can >>> someone >>> | please send a description of what this will do? >>> | >>> | Thanks! >>> | -- >>> | >>> | Chad Scherrer >>> | >>> | "Time flies like an arrow; fruit flies like a banana" -- Groucho >>> Marx >>> | _______________________________________________ >>> | Glasgow-haskell-users mailing list >>> | Glasgow-haskell-users@haskell.org >>> | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users >> >> _______________________________________________ >> Glasgow-haskell-users mailing list >> Glasgow-haskell-users@haskell.org >> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users >> > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users@haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users From mad.one at gmail.com Tue Aug 26 17:11:42 2008 From: mad.one at gmail.com (Austin Seipp) Date: Tue Aug 26 17:10:23 2008 Subject: "dataflow rewriting engine" In-Reply-To: References: <638ABD0A29C8884A91BC5FB5C349B1C32AE85E0C2F@EA-EXMSG-C334.europe.corp.microsoft.com> <6F495814B44AB642B84261441AD9155E2540AB297B@EA-EXMSG-C331.europe.corp.microsoft.com> <20080826175722.GC3200@scytale.galois.com> Message-ID: <1219785020-sup-3681@existential.local> Excerpts from Deborah Goldsmith's message of Tue Aug 26 14:26:33 -0500 2008: > Has there been any thought about working with the LLVM project? I > didn't find anything on the wiki along those lines. I imagine if tried, haskell as a language on LLVM would quickly end up a second-class citizen, due to non-strict semantics? Austin From chak at cse.unsw.edu.au Tue Aug 26 20:25:56 2008 From: chak at cse.unsw.edu.au (Manuel M T Chakravarty) Date: Tue Aug 26 20:24:37 2008 Subject: "dataflow rewriting engine" In-Reply-To: References: <638ABD0A29C8884A91BC5FB5C349B1C32AE85E0C2F@EA-EXMSG-C334.europe.corp.microsoft.com> <6F495814B44AB642B84261441AD9155E2540AB297B@EA-EXMSG-C331.europe.corp.microsoft.com> <20080826175722.GC3200@scytale.galois.com> Message-ID: <3B2D86AD-CE33-4AEB-8CBB-21A43DA7B6F1@cse.unsw.edu.au> Deborah Goldsmith: > Has there been any thought about working with the LLVM project? I > didn't find anything on the wiki along those lines. I have only had a rather brief look at LLVM, but my understanding at the moment is that LLVM would not be able to support one of GHC's current code layout optimisations. More precisely, with LLVM, it would not be possible to enforce that the meta data for a closure is placed right before (in terms of layout in the address space) the code executing the "eval" method of that same closure. GHC uses that to have the closure code pointer point directly to the "eval" code (and hence also by an appropriate offset) to the various fields of the meta data. If that layout cannot be ensured, GHC needs to take one more indirection to execute "evals" (which is a very frequent operation) - this is what an unregistered build does btw. However, I am not convinced that this layout optimisation is really gaining that much extra performance these days. In particular, since dynamic pointer tagging, very short running "evals" (for which the extra indirection incurs the largest overhead) have become less frequent. Even if there is a slight performance regression, I think, it would be worthwhile to consider giving up on the described layout constraint. It is the Last Quirk that keeps GHC from using standard compiler back-ends (such as LLVM), and I suspect, it is not worth it anymore. When we discussed this last, Simon Marlow planned to run benchmarks to determine how much performance the layout optimisation gains us these days. Simon, did you ever get around to that? Manuel > On Aug 26, 2008, at 10:57 AM, Don Stewart wrote: > >> I think we're all rather excited about seeing this stuff land. >> What's the expected timeline, wrt. ghc 6.10's release? >> >> -- Don >> >> t-jodias: >>> I've added some text and links to point the reader in the right >>> direction. Here's the new text, cribbed from the Wiki: >>> >>> Dataflow optimization: We can define a new optimization simply by >>> defining a lattice of dataflow facts (akin to a specialized logic) >>> and >>> then writing the dataflow-transfer functions found in compiler >>> textbooks. Handing these functions to the dataflow engine produces a >>> new optimization that is not only useful on its own, but that can >>> easily be composed with other optimizations to create an integrated >>> "superoptimization" that is strictly more powerful than any sequence >>> of individual optimizations, no matter how many times they are re- >>> run. >>> The dataflow engine is based on (Lerner, Grove, and Chambers 2002 >>> http://citeseer.ist.psu.edu/old/lerner01composing.html); you can >>> find >>> a functional implementation of the dataflow engine presented in >>> (Ramsey and Dias 2005 >>> http://www.cs.tufts.edu/~nr/pubs/zipcfg-abstract.html). >>> >>> Let me know how I can further clarify the text, >>> -j >>> >>>> -----Original Message----- >>>> From: Simon Peyton-Jones >>>> Sent: Tuesday, August 26, 2008 1:32 PM >>>> To: Norman Ramsey; John Dias >>>> Cc: Chad Scherrer; GHC Users >>>> Subject: RE: "dataflow rewriting engine" >>>> >>>> Norman, John >>>> >>>> Would you care to respond to this? (Perhaps by amplifying the wiki >>>> page?) A good starting point is perhaps Craig's paper. >>>> >>>> Simon >>>> >>>> | -----Original Message----- >>>> | From: glasgow-haskell-users-bounces@haskell.org [mailto:glasgow- >>>> haskell-users-bounces@haskell.org] On >>>> | Behalf Of Chad Scherrer >>>> | Sent: 22 August 2008 22:21 >>>> | To: GHC Users >>>> | Subject: "dataflow rewriting engine" >>>> | >>>> | Hello GHC, >>>> | >>>> | This page >>>> | >>>> http://hackage.haskell.org/trac/ghc/wiki/Commentary/Compiler/Integrated >>>> CodeGen >>>> | mentions a to-be-developed "dataflow rewriting engine". Can >>>> someone >>>> | please send a description of what this will do? >>>> | >>>> | Thanks! >>>> | -- >>>> | >>>> | Chad Scherrer >>>> | >>>> | "Time flies like an arrow; fruit flies like a banana" -- >>>> Groucho Marx >>>> | _______________________________________________ >>>> | Glasgow-haskell-users mailing list >>>> | Glasgow-haskell-users@haskell.org >>>> | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users >>> >>> _______________________________________________ >>> Glasgow-haskell-users mailing list >>> Glasgow-haskell-users@haskell.org >>> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users >>> >> _______________________________________________ >> Glasgow-haskell-users mailing list >> Glasgow-haskell-users@haskell.org >> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users@haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users From duncan.coutts at worc.ox.ac.uk Tue Aug 26 22:17:04 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Tue Aug 26 22:15:02 2008 Subject: "dataflow rewriting engine" In-Reply-To: <3B2D86AD-CE33-4AEB-8CBB-21A43DA7B6F1@cse.unsw.edu.au> References: <638ABD0A29C8884A91BC5FB5C349B1C32AE85E0C2F@EA-EXMSG-C334.europe.corp.microsoft.com> <6F495814B44AB642B84261441AD9155E2540AB297B@EA-EXMSG-C331.europe.corp.microsoft.com> <20080826175722.GC3200@scytale.galois.com> <3B2D86AD-CE33-4AEB-8CBB-21A43DA7B6F1@cse.unsw.edu.au> Message-ID: <1219803424.24846.103.camel@localhost> On Wed, 2008-08-27 at 10:25 +1000, Manuel M T Chakravarty wrote: > However, I am not convinced that this layout optimisation is really > gaining that much extra performance these days. In particular, since > dynamic pointer tagging, very short running "evals" (for which the > extra indirection incurs the largest overhead) have become less > frequent. Even if there is a slight performance regression, I think, > it would be worthwhile to consider giving up on the described layout > constraint. It is the Last Quirk that keeps GHC from using standard > compiler back-ends (such as LLVM), and I suspect, it is not worth it > anymore. There's also a potential benefit on the other side, that the cpu's instruction cache is not wasted on non-instruction data. Apparently some cpus also do instruction read-ahead and suffer slowdown if they encounter data that does not decode as valid op codes. Obviously it's not allowed to fault since the instructions are not actually executed but it can impact on performance according to Intel manuals (presumably because it ends up flushing some instruction decoding caches or something). Of course, as you've discussed, the only way to find out is to benchmark. Duncan From simonpj at microsoft.com Wed Aug 27 04:10:14 2008 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Wed Aug 27 04:08:57 2008 Subject: "dataflow rewriting engine" In-Reply-To: <3B2D86AD-CE33-4AEB-8CBB-21A43DA7B6F1@cse.unsw.edu.au> References: <638ABD0A29C8884A91BC5FB5C349B1C32AE85E0C2F@EA-EXMSG-C334.europe.corp.microsoft.com> <6F495814B44AB642B84261441AD9155E2540AB297B@EA-EXMSG-C331.europe.corp.microsoft.com> <20080826175722.GC3200@scytale.galois.com> <3B2D86AD-CE33-4AEB-8CBB-21A43DA7B6F1@cse.unsw.edu.au> Message-ID: <638ABD0A29C8884A91BC5FB5C349B1C32AE86976D0@EA-EXMSG-C334.europe.corp.microsoft.com> | > Has there been any thought about working with the LLVM project? I | > didn't find anything on the wiki along those lines. | | I have only had a rather brief look at LLVM, but my understanding at | the moment is that LLVM would not be able to support one of GHC's | current code layout optimisations. With the new, modular code generation framework, described here http://hackage.haskell.org/trac/ghc/wiki/Commentary/Compiler/NewCodeGen I think it'll be much easier [for someone else] to consider using LLVM. I don't see the "data next to code" thing as a show-stopper; it used to be a performance win of a handful of percent, but I don't think we have recent data. And an LLVM back end might be willing to give up that few percent. There may well be other difficulties, of course. If anyone is interested, the best thing is to wait for the new stuff to be committed to the HEAD (which will happen in Sept), and look at the new Cmm data types (which define the language you'd have to convert to LLVM). Simon From marlowsd at gmail.com Wed Aug 27 05:35:17 2008 From: marlowsd at gmail.com (Simon Marlow) Date: Wed Aug 27 05:34:02 2008 Subject: "dataflow rewriting engine" In-Reply-To: <3B2D86AD-CE33-4AEB-8CBB-21A43DA7B6F1@cse.unsw.edu.au> References: <638ABD0A29C8884A91BC5FB5C349B1C32AE85E0C2F@EA-EXMSG-C334.europe.corp.microsoft.com> <6F495814B44AB642B84261441AD9155E2540AB297B@EA-EXMSG-C331.europe.corp.microsoft.com> <20080826175722.GC3200@scytale.galois.com> <3B2D86AD-CE33-4AEB-8CBB-21A43DA7B6F1@cse.unsw.edu.au> Message-ID: <48B51FD5.3050502@gmail.com> Manuel M T Chakravarty wrote: > Deborah Goldsmith: >> Has there been any thought about working with the LLVM project? I >> didn't find anything on the wiki along those lines. > > I have only had a rather brief look at LLVM, but my understanding at the > moment is that LLVM would not be able to support one of GHC's current > code layout optimisations. More precisely, with LLVM, it would not be > possible to enforce that the meta data for a closure is placed right > before (in terms of layout in the address space) the code executing the > "eval" method of that same closure. GHC uses that to have the closure > code pointer point directly to the "eval" code (and hence also by an > appropriate offset) to the various fields of the meta data. If that > layout cannot be ensured, GHC needs to take one more indirection to > execute "evals" (which is a very frequent operation) - this is what an > unregistered build does btw. > > However, I am not convinced that this layout optimisation is really > gaining that much extra performance these days. In particular, since > dynamic pointer tagging, very short running "evals" (for which the extra > indirection incurs the largest overhead) have become less frequent. > Even if there is a slight performance regression, I think, it would be > worthwhile to consider giving up on the described layout constraint. It > is the Last Quirk that keeps GHC from using standard compiler back-ends > (such as LLVM), and I suspect, it is not worth it anymore. > > When we discussed this last, Simon Marlow planned to run benchmarks to > determine how much performance the layout optimisation gains us these > days. Simon, did you ever get around to that? I didn't get around to benchmarking it, but since the layout optimisation is easily switched off (it's called tablesNextToCode inside GHC) there's really nothing stopping someone from building a backend that doesn't rely on it. Everything works without this optimisation, including GHCi, the debugger, and the FFI. My guess is you'd pay a few percent on average for not doing it. You're quite right that pointer tagging makes it less attractive, but like most optimisations there are programs that fall outside the common case. Programs that do a lot of thunk evals will suffer the most. Cheers, Simon From john at repetae.net Wed Aug 27 06:04:58 2008 From: john at repetae.net (John Meacham) Date: Wed Aug 27 06:03:32 2008 Subject: Build system idea In-Reply-To: <061FA30C-4326-4B65-A80F-096593C81D6C@cse.unsw.edu.au> References: <48A161DA.3010106@gmail.com> <061FA30C-4326-4B65-A80F-096593C81D6C@cse.unsw.edu.au> Message-ID: <20080827100458.GQ15616@sliver.repetae.net> On Wed, Aug 13, 2008 at 01:31:55PM +1000, Roman Leshchinskiy wrote: > This makes me wonder, though. Wouldn't this model make more sense for > Cabal in general than the current approach of duplicating the > functionality of autoconf, make and other stuff? If it works ghc, it > ought to work for other projects, too. Cabal as a preprocessor seems > much more attractive to me than as a universal build system. I can't tell you how much I agree with this. the fact that cabal wants to be my build system as well as my configuration system means it is pretty much unusable to me in my projects. Features are something that _hurts_ a system such as this. between a build system, a configuration manager, a packaging system, etc, it is rare for any large project that at least one isn't imposed on you by some external constrant or just a better choice for the job. I would much rather see cabals functionality split among a variety of different programs so the pieces can be used when appropriate, not as an all or nothing thing. (bring back hmake! :) ). John -- John Meacham - ?repetae.net?john? From Malcolm.Wallace at cs.york.ac.uk Wed Aug 27 06:32:11 2008 From: Malcolm.Wallace at cs.york.ac.uk (Malcolm Wallace) Date: Wed Aug 27 06:34:32 2008 Subject: Build system idea In-Reply-To: <20080827100458.GQ15616@sliver.repetae.net> References: <48A161DA.3010106@gmail.com> <061FA30C-4326-4B65-A80F-096593C81D6C@cse.unsw.edu.au> <20080827100458.GQ15616@sliver.repetae.net> Message-ID: <20080827113211.398b564f.Malcolm.Wallace@cs.york.ac.uk> John Meacham wrote: > (bring back hmake! :) ). It never went away... http://www.cs.york.ac.uk/fp/hmake I even have the idea to allow hmake to read the .cabal file format for configuration data (although that is waiting for a delivery of round tuits). Regards, Malcolm From duncan.coutts at worc.ox.ac.uk Wed Aug 27 06:45:10 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Wed Aug 27 06:43:04 2008 Subject: Build system idea In-Reply-To: <20080827100458.GQ15616@sliver.repetae.net> References: <48A161DA.3010106@gmail.com> <061FA30C-4326-4B65-A80F-096593C81D6C@cse.unsw.edu.au> <20080827100458.GQ15616@sliver.repetae.net> Message-ID: <1219833910.24846.138.camel@localhost> On Wed, 2008-08-27 at 03:04 -0700, John Meacham wrote: > On Wed, Aug 13, 2008 at 01:31:55PM +1000, Roman Leshchinskiy wrote: > > This makes me wonder, though. Wouldn't this model make more sense for > > Cabal in general than the current approach of duplicating the > > functionality of autoconf, make and other stuff? If it works ghc, it > > ought to work for other projects, too. Cabal as a preprocessor seems > > much more attractive to me than as a universal build system. > > I can't tell you how much I agree with this. the fact that cabal wants > to be my build system as well as my configuration system means it is > pretty much unusable to me in my projects. > > Features are something that _hurts_ a system such as this. between a > build system, a configuration manager, a packaging system, etc, it is > rare for any large project that at least one isn't imposed on you by > some external constrant or just a better choice for the job. I would > much rather see cabals functionality split among a variety of different > programs so the pieces can be used when appropriate, not as an all or > nothing thing. (bring back hmake! :) ). People are of course still free to use autoconf and make to implement their own build system and have it still be a Cabal package (which has the advantage of presenting the same meta-data and command interface to packaging tools). It's been that way since the original design. Quite a few packages to use autoconf though the use seems to be slightly on the decline as people try and make their packages portable to Windows. Very few packages use make as it involves re-implementing their own build system which is a lot of work. That's partly a self-fulfilling prophecy of course because nobody uses that interface so it does not get improved so nobody uses it etc. Also, as far as I'm aware hmake still works, at least for nhc, I've not used it recently for building with ghc. So there's nothing stopping people from using that (except hard work), even as part of a cabal package. The different parts of the system are relatively separated. The declarative bits that deal with package meta-data (.cabal files) are available through the Cabal library (Distribution.*) and many tools make use of this. Then the 'Simple' build system is in the same library but fairly cleanly separated ?(Distribution.Simple.*). As I mentioned, you do not have to use the ?'Simple' build system, but the vast majority of packages do. Then there are the packaging tools like the tools for converting to native packages and cabal-install which use the Cabal library and the command line interface that Cabal packages present. I'm not saying it's perfect, but it's not as monolithic as some would suggest. Duncan From simonpj at microsoft.com Wed Aug 27 08:08:59 2008 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Wed Aug 27 08:07:31 2008 Subject: "dataflow rewriting engine" In-Reply-To: <20080826175722.GC3200@scytale.galois.com> References: <638ABD0A29C8884A91BC5FB5C349B1C32AE85E0C2F@EA-EXMSG-C334.europe.corp.microsoft.com> <6F495814B44AB642B84261441AD9155E2540AB297B@EA-EXMSG-C331.europe.corp.microsoft.com> <20080826175722.GC3200@scytale.galois.com> Message-ID: <638ABD0A29C8884A91BC5FB5C349B1C32AE86978E1@EA-EXMSG-C334.europe.corp.microsoft.com> | I think we're all rather excited about seeing this stuff land. | What's the expected timeline, wrt. ghc 6.10's release? Good question. I've updated the overview here http://hackage.haskell.org/trac/ghc/wiki/Commentary/Compiler/NewCodeGen to say what we plan. Simon From john at repetae.net Wed Aug 27 09:13:24 2008 From: john at repetae.net (John Meacham) Date: Wed Aug 27 09:11:56 2008 Subject: Build system idea In-Reply-To: <1219833910.24846.138.camel@localhost> References: <48A161DA.3010106@gmail.com> <061FA30C-4326-4B65-A80F-096593C81D6C@cse.unsw.edu.au> <20080827100458.GQ15616@sliver.repetae.net> <1219833910.24846.138.camel@localhost> Message-ID: <20080827131324.GR15616@sliver.repetae.net> The problem with the way cabal wants to mix with make/autoconf is that it is the wrong way round. make is very good at managing pre-processors, dependency tracking and calling external programs in the right order, in parallel, and as needed. cabal is generally good at building a single library or executable given relatively straightforward haskell source. (I know it _can_ do more, but this is mainly what it is good at). The way this should work is that make determines what haskell libraries need to be built, and what haskell files need to be generated to allow cabal to run and calls cabal to build just the ones needed. cabal as a build tool that make calls is much more flexible and in tune with each tools capabilities. The other issue is with cabal files themselves which are somewhat conflicted in purpose. on one hand, you have declarative stuff about a package. name, version, etc... information you want before you start to build something. but then you have build-depends, which is something that you cannot know until after your configuration manager (whatever it may be, autoconf being a popular one) is run. What packages you depend on are going to depend on things like what compiler you have installed, your configuration options, which packages are installed, what operating system you are running on, which kernel version you are running, which c libraries you have installed. etc. things that cannot be predicted before the configuration is actually run. Then you have cabal as a packaging system (or perhaps hackage/cabal considered together). Which has its own warts, if it is meant to live in the niche of package managers such as rpm or deb, where are the 'release' version numbers that rpms and debs have for one example? If it is meant to be a tarball like format, where is the distinction between 'distribution' and 'source' tarballs? For instance, jhc from darcs for developers requires perl,ghc,DrIFT,pandoc,autotools, and happy. however the jhc tarball requires _only_ ghc. nothing else. This is because the make dist target is more interesting than just taring up the source. (and posthooks/prehooks don't really help. they are sort of equivalent to saying 'write your own build system'.) One of the biggest sources of conflict arise from using cabal as a configuration manager. A configuration managers entire purpose is to examine the system and figure out how to adapt your programs build to the system. this is completely 100% at odds with the idea of users having to 'upgrade' cabal. Figuring out how to adapt your build to whatever cabal is installed or failing gracefully if you can't is exactly the job of the configuration manager. something like autoconf. This is why _users_ need not install autoconf, just developers. since autoconf generates a portable script is so that users are never told to upgrade their autoconf. if a developer wants to use new features, he gets the new autoconf and reruns 'autoreconf'. The user is never asked to update anything that isn't actually needed for the project itself. This distinction is key fora configuration manager and really conflicts with cabal wanting to also be a build system and package manager. It is also what is needed for forwards and backwards compatibility. All in all, I think these conflicting goals of cabal make it hard to use in projects and have led to very odd design choices. I think external tools should not be the exception but rather the rule. Not that cabal shouldn't come with a full set of said tools. But as long as they are integrated I don't see cabal's design problems being fixed, meerly augmented with various work-arounds. John -- John Meacham - ?repetae.net?john? From chad.scherrer at gmail.com Wed Aug 27 15:42:38 2008 From: chad.scherrer at gmail.com (Chad Scherrer) Date: Wed Aug 27 15:48:36 2008 Subject: "dataflow rewriting engine" References: <638ABD0A29C8884A91BC5FB5C349B1C32AE85E0C2F@EA-EXMSG-C334.europe.corp.microsoft.com> <6F495814B44AB642B84261441AD9155E2540AB297B@EA-EXMSG-C331.europe.corp.microsoft.com> <20080826175722.GC3200@scytale.galois.com> <638ABD0A29C8884A91BC5FB5C349B1C32AE86978E1@EA-EXMSG-C334.europe.corp.microsoft.com> Message-ID: Wow, lots of great information. We'll take a look at the papers and get back if there's any remaining confusion. Thanks! Chad From duncan.coutts at worc.ox.ac.uk Wed Aug 27 17:18:59 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Wed Aug 27 17:48:38 2008 Subject: Build system idea In-Reply-To: <20080827131324.GR15616@sliver.repetae.net> References: <48A161DA.3010106@gmail.com> <061FA30C-4326-4B65-A80F-096593C81D6C@cse.unsw.edu.au> <20080827100458.GQ15616@sliver.repetae.net> <1219833910.24846.138.camel@localhost> <20080827131324.GR15616@sliver.repetae.net> Message-ID: <1219871939.24846.206.camel@localhost> On Wed, 2008-08-27 at 06:13 -0700, John Meacham wrote: > The problem with the way cabal wants to mix with make/autoconf is that > it is the wrong way round. make is very good at managing pre-processors, > dependency tracking and calling external programs in the right order, in > parallel, and as needed. cabal is generally good at building a single > library or executable given relatively straightforward haskell source. > (I know it _can_ do more, but this is mainly what it is good at). > > The way this should work is that make determines what haskell libraries > need to be built, and what haskell files need to be generated to allow > cabal to run and calls cabal to build just the ones needed. cabal as a > build tool that make calls is much more flexible and in tune with each > tools capabilities. I'd say if you're using make for all that, then use it to build the haskell modules too. That gives the advantage of incremental and parallel builds, which Cabal does not do yet (though we've got a GSoC project just coming to an end which does this). > The other issue is with cabal files themselves which are somewhat > conflicted in purpose. on one hand, you have declarative stuff about a > package. name, version, etc... information you want before you start to > build something. but then you have build-depends, which is something > that you cannot know until after your configuration manager (whatever it > may be, autoconf being a popular one) is run. Ah, but that's where the autoconf and Cabal models part ways. > What packages you depend on are going to depend on things like what > compiler you have installed, your configuration options, which > packages are installed, what operating system you are running on, > which kernel version you are running, which c libraries you have > installed. etc. things that cannot be predicted before the > configuration is actually run. So Cabal takes the view that the relationship between features and dependencies should be declarative. autoconf is essentially a function from a platform environment to maybe a configuration. That's a very flexible approach, the function is opaque and can do whatever feature tests it likes. The downside is that it is not possible to work out what the dependencies are. It might be able to if autoconf explained the result of its decisions, but even then, it's not possible to work out what dependencies are required to get a particular feature enabled. With the Cabal approach these things are explicit. The conditionals in a .cabal file can be read in either direction so it is possible for a package manager to automatically work out what deps would be needed for that optional libcurl feature, or GUI. The other principle is that the packager, the environment is in control over what things the package 'sees'. With autoconf, the script can take into account anything it likes, even if you'd rather it did not. Eg it's important to be able to build a package that does not have that optional dependency, even though the C lib is indeed installed on the build machine, because I may be configuring it for a machine without the C lib. Sure, some good packages allow those automagic decisions to be overridden, but many don't and of course there is no easy way to tell if it's picking up deps it should not. So one of the principles in Cabal configuration is that all decisions about how to configure the package are transparent to the packager and can be overridden. Now currently, Cabal only has a partial implementation of the concept because when it tries to find a configuration that works in the current environment (which it only does if the configuration is not already fully specified by the packager) it only considers dependencies on haskell packages. Obviously there are a range of other dependencies specified in the .cabal file and it should use them all, in particular external C libs. So I accept that we do not yet cover the range of configuration choices that are needed by the more complex packages (cf darcs), but I think that we can and that the approach is basically sound. The fact that we can automatically generate distro packages for hundreds of packages is not insignificant. This is just not possible with the autoconf approach. > Then you have cabal as a packaging system (or perhaps hackage/cabal > considered together). Which has its own warts, if it is meant to live in > the niche of package managers such as rpm or deb, where are the > 'release' version numbers that rpms and debs have for one example? If it is > meant to be a tarball like format, where is the distinction between > 'distribution' and 'source' tarballs? Right, it's supposed to be the upstream release format, tarballs. Distro packages obviously have their additional revision numbers. > For instance, jhc from darcs for developers requires > perl,ghc,DrIFT,pandoc,autotools, and happy. however the jhc > tarball requires _only_ ghc. nothing else. This is because the make > dist target is more interesting than just taring up the source. (and > posthooks/prehooks don't really help. they are sort of equivalent to > saying 'write your own build system'.) Right. Cabal does that too (or strictly speaking, the Simple build system can do this). For pre-processors that are platform independent (like alex, happy etc) it puts the pre-processed source into the release tarball. It's also possible to make tarballs without the pre-generated files if it's important. > One of the biggest sources of conflict arise from using cabal as a > configuration manager. A configuration managers entire purpose is to > examine the system and figure out how to adapt your programs build to > the system. Well, that's the autoconf view. It's not the only way of looking at it as I explained above (perhaps not very clearly). I'd say a configuration manager should negotiate between the package and the packager/user/environment to find a configuration that is satisfactory to all (which requires information flow in both directions). > this is completely 100% at odds with the idea of users > having to 'upgrade' cabal. Figuring out how to adapt your build to > whatever cabal is installed or failing gracefully if you can't is > exactly the job of the configuration manager. something like autoconf. > This is why _users_ need not install autoconf, just developers. since > autoconf generates a portable script is so that users are never told to > upgrade their autoconf. if a developer wants to use new features, he > gets the new autoconf and reruns 'autoreconf'. The user is never > asked to update anything that isn't actually needed for the project > itself. This distinction is key fora configuration manager and really > conflicts with cabal wanting to also be a build system and package > manager. It is also what is needed for forwards and backwards > compatibility. I suppose in principle it'd be possible to ship the build system in every package like autoconf/automake does. Perhaps we should allow that as an option. It's doable since the Setup.hs can import local modules. > All in all, I think these conflicting goals of cabal make it hard to use > in projects and have led to very odd design choices. I think external > tools should not be the exception but rather the rule. Not that cabal > shouldn't come with a full set of said tools. But as long as they are > integrated I don't see cabal's design problems being fixed, meerly > augmented with various work-arounds. One issue, with a pick and mix approach is what is the top level interface that users/package managers use? The current choice (which I'm not at all sure is the right one) is a Setup.hs file that imports its build system from a library that's already on the system (or a custom one implemented locally). So a system that uses make underneath still has to present the ?Setup.hs interface so that package managers can use it in a uniform way. You mention at the top that you think the make/cabal relationship is the wrong way round, but the Cabal/Setup.hs interface has to be the top level one (at least at the moment) so you'd have Setup.hs call make and make call it back again to build various bits like libs etc? Do you think that separating the Simple build system from the declarative part of Cabal would help? It'd make it more obvious that the build system part really is replaceable which currently is not so obvious since they're in the same package. I'm not averse to splitting them if it'd help. They're already completely partitioned internally. Duncan From john at repetae.net Wed Aug 27 22:26:38 2008 From: john at repetae.net (John Meacham) Date: Wed Aug 27 22:25:08 2008 Subject: Build system idea In-Reply-To: <1219871939.24846.206.camel@localhost> References: <48A161DA.3010106@gmail.com> <061FA30C-4326-4B65-A80F-096593C81D6C@cse.unsw.edu.au> <20080827100458.GQ15616@sliver.repetae.net> <1219833910.24846.138.camel@localhost> <20080827131324.GR15616@sliver.repetae.net> <1219871939.24846.206.camel@localhost> Message-ID: <20080828022638.GY15616@sliver.repetae.net> On Wed, Aug 27, 2008 at 10:18:59PM +0100, Duncan Coutts wrote: > On Wed, 2008-08-27 at 06:13 -0700, John Meacham wrote: > > The problem with the way cabal wants to mix with make/autoconf is that > > it is the wrong way round. make is very good at managing pre-processors, > > dependency tracking and calling external programs in the right order, in > > parallel, and as needed. cabal is generally good at building a single > > library or executable given relatively straightforward haskell source. > > (I know it _can_ do more, but this is mainly what it is good at). > > > > The way this should work is that make determines what haskell libraries > > need to be built, and what haskell files need to be generated to allow > > cabal to run and calls cabal to build just the ones needed. cabal as a > > build tool that make calls is much more flexible and in tune with each > > tools capabilities. > > I'd say if you're using make for all that, then use it to build the > haskell modules too. That gives the advantage of incremental and > parallel builds, which Cabal does not do yet (though we've got a GSoC > project just coming to an end which does this). So, don't use cabal at all? that is the solution I have been going with so far and am trying to remedy. > > The other issue is with cabal files themselves which are somewhat > > conflicted in purpose. on one hand, you have declarative stuff about a > > package. name, version, etc... information you want before you start to > > build something. but then you have build-depends, which is something > > that you cannot know until after your configuration manager (whatever it > > may be, autoconf being a popular one) is run. > > Ah, but that's where the autoconf and Cabal models part ways. > > > What packages you depend on are going to depend on things like what > > compiler you have installed, your configuration options, which > > packages are installed, what operating system you are running on, > > which kernel version you are running, which c libraries you have > > installed. etc. things that cannot be predicted before the > > configuration is actually run. > > So Cabal takes the view that the relationship between features and > dependencies should be declarative. autoconf is essentially a function > from a platform environment to maybe a configuration. That's a very > flexible approach, the function is opaque and can do whatever feature > tests it likes. The downside is that it is not possible to work out what > the dependencies are. It might be able to if autoconf explained the > result of its decisions, but even then, it's not possible to work out > what dependencies are required to get a particular feature enabled. With > the Cabal approach these things are explicit. unfortunately the cabal approach doesn't work. note, I am not saying a declarative configuration manager won't work. in fact, I have sketched a design for one on occasion. but cabal's particular choices are broken. It is treading the same waters that made 'imake' fail. the ideas of forwards and backwards compatability are _the_ defining features of a configuration manager. Think about this, I can take my old sunsite CD, burned _ten years_ ago and take the unchanged tarballs off that CD and ./configure && make and in general most will work. many were written before linux even existed, many were written with non gcc compilers, yet they work today. The cabal way wasn't able to handle a single release of ghc and keep forwards or backwards compatability. That any project ever had to be changed to use the flag 'split-base' is a travesty. What about all the projects on burnt cds or that don't have someone to update them? 20 years from now when we are all using 'fhc' (Fred's Haskell Compiler) will we still have this reference to 'split-base' in our cabal files? how many more flags will have accumulated by then? Sure it's declarative, but in a language that doesn't make sense without the rule-book. autoconf tests things like 'does a library named foo exist and export bar'. 'is char signed or unsigned on the target system'. those are declarative statement and have a defined meaning through all time. (though, implemented in a pretty ugly imperative way) That is what allows autoconfed packages to be compiled by compilers on systems that were never dreamed of when the packages were written. > The conditionals in a .cabal file can be read in either direction so it > is possible for a package manager to automatically work out what deps > would be needed for that optional libcurl feature, or GUI. In the cabal framework Will cabal be able to do things like cross compile a c file to an object file, and deconstruct the generated ELF file to determine parameters needed for an unknown embedded platform _and_ do so without me requiring the user to upgrade their cabal? This is an example of the type of autoconf test that comes up in the real world. You can never come up with a language that will have every needed primitive, any restricted set will ultimately not be enough for someone. and the only alternative is pretty much to not use cabal at all or hack around it in odd ways. > The other principle is that the packager, the environment is in control > over what things the package 'sees'. With autoconf, the script can take > into account anything it likes, even if you'd rather it did not. Eg it's > important to be able to build a package that does not have that optional > dependency, even though the C lib is indeed installed on the build > machine, because I may be configuring it for a machine without the C > lib. Sure, some good packages allow those automagic decisions to be > overridden, but many don't and of course there is no easy way to tell if > it's picking up deps it should not. So one of the principles in Cabal > configuration is that all decisions about how to configure the package > are transparent to the packager and can be overridden. I am not sure what you mean by this. autoconf's flexibility in this regard is pretty exceptional when written properly. Native cross-compilation is one of autoconfs strengths and a big motivating factor in its design. > Now currently, Cabal only has a partial implementation of the concept > because when it tries to find a configuration that works in the current > environment (which it only does if the configuration is not already > fully specified by the packager) it only considers dependencies on > haskell packages. Obviously there are a range of other dependencies > specified in the .cabal file and it should use them all, in particular > external C libs. And there are many other possible implementations of configuration managers. I fully believe that the next big one will come out of the haskell community, we are a good bunch of people. But it won't if innovation is stifled by cabal _insisting_ on using its own configuration manager and cabal being promoted as 'the way' to do things. This is completely independent of my opinions of cabal as a configuration manager, I would just hate to see such an enticing area of research be cut off prematurely. If cabal is going to be the way to do things with haskell, that means it cannot be the place to try out ones own pet projects about how one thinks things should be. A declarative configuration manager is an intruiging project. one I want to see people work on in different directions, but it is new research. > So I accept that we do not yet cover the range of configuration choices > that are needed by the more complex packages (cf darcs), but I think > that we can and that the approach is basically sound. The fact that we > can automatically generate distro packages for hundreds of packages is > not insignificant. This is just not possible with the autoconf approach. This is just utterly untrue. autoconfed packages that generate rpms, debs, etc are quite common. The only reason cabal can autogenerate distro packages for so many is that many interesting or hard ones just _arn't possible with cabal at all_. Cabal's inflexibility puts a huge selection bias on the population of cabalized programs. > > Then you have cabal as a packaging system (or perhaps hackage/cabal > > considered together). Which has its own warts, if it is meant to live in > > the niche of package managers such as rpm or deb, where are the > > 'release' version numbers that rpms and debs have for one example? If it is > > meant to be a tarball like format, where is the distinction between > > 'distribution' and 'source' tarballs? > > Right, it's supposed to be the upstream release format, tarballs. Distro > packages obviously have their additional revision numbers. one might say hackage is a distro in and of itself, so should have similar numbers. reusing the same file directly for the packager and the build system makes things like this trickier than they need to be. > > For instance, jhc from darcs for developers requires > > perl,ghc,DrIFT,pandoc,autotools, and happy. however the jhc > > tarball requires _only_ ghc. nothing else. This is because the make > > dist target is more interesting than just taring up the source. (and > > posthooks/prehooks don't really help. they are sort of equivalent to > > saying 'write your own build system'.) > > Right. Cabal does that too (or strictly speaking, the Simple build > system can do this). For pre-processors that are platform independent > (like alex, happy etc) it puts the pre-processed source into the release > tarball. It's also possible to make tarballs without the pre-generated > files if it's important. Sort of. but cabal can only do these things because they are _built in_ to cabal. make will happily use DrIFT, figure out dependencies for ghc, gcc, and jhc, and build my rpms without having to be modified itself. Because it was designed that way. > > One of the biggest sources of conflict arise from using cabal as a > > configuration manager. A configuration managers entire purpose is to > > examine the system and figure out how to adapt your programs build to > > the system. > > Well, that's the autoconf view. It's not the only way of looking at it > as I explained above (perhaps not very clearly). I'd say a configuration > manager should negotiate between the package and the > packager/user/environment to find a configuration that is satisfactory > to all (which requires information flow in both directions). > > > this is completely 100% at odds with the idea of users > > having to 'upgrade' cabal. Figuring out how to adapt your build to > > whatever cabal is installed or failing gracefully if you can't is > > exactly the job of the configuration manager. something like autoconf. > > This is why _users_ need not install autoconf, just developers. since > > autoconf generates a portable script is so that users are never told to > > upgrade their autoconf. if a developer wants to use new features, he > > gets the new autoconf and reruns 'autoreconf'. The user is never > > asked to update anything that isn't actually needed for the project > > itself. This distinction is key fora configuration manager and really > > conflicts with cabal wanting to also be a build system and package > > manager. It is also what is needed for forwards and backwards > > compatibility. > > I suppose in principle it'd be possible to ship the build system in > every package like autoconf/automake does. Perhaps we should allow that > as an option. It's doable since the Setup.hs can import local modules. I don't see what you mean, autoconf doesn't "ship the build system" with the package any more than ghc ships ghc with every binary it produces. autoconf is a _compiler_ of a domain specific language to a portable intermediate language by design. This means that autoconf need not be upgraded or installed by users, yet developers are free to take advantage of autoconf's newest features without troubling their users because what is distributed is autoconfs compiled output. If a user has to upgrade their cabal to install a package, then cabal is broken as a configuration manager by design. If I were willing to make a user upgrade their system, there would be _no need_ for a configuration manager at all. The problem of building the most recent and updated library with the most recent and updated compiler on a fully up to date system is a _non problem_. > > All in all, I think these conflicting goals of cabal make it hard to use > > in projects and have led to very odd design choices. I think external > > tools should not be the exception but rather the rule. Not that cabal > > shouldn't come with a full set of said tools. But as long as they are > > integrated I don't see cabal's design problems being fixed, meerly > > augmented with various work-arounds. > > One issue, with a pick and mix approach is what is the top level > interface that users/package managers use? The current choice (which I'm > not at all sure is the right one) is a Setup.hs file that imports its > build system from a library that's already on the system (or a custom > one implemented locally). So a system that uses make underneath still > has to present the ?Setup.hs interface so that package managers can use > it in a uniform way. You mention at the top that you think the > make/cabal relationship is the wrong way round, but the Cabal/Setup.hs > interface has to be the top level one (at least at the moment) so you'd > have Setup.hs call make and make call it back again to build various > bits like libs etc? Right now I just have ./configure && make be the way to build things, and the ./configure generates an appropriate cabal file when needed. But the 'cabal proxy' stub cabal file similar to what you are saying is also something I have considered (only for haskell libraries I want to put on hackage) but it is far from ideal. As for programs written in haskell, I don't want people's first impression of haskell being "oh crap, I gotta learn a new way to build things just because this program is written in some odd language called 'haskell'" I don't care how awesome a language is, I am going to be annoyed by having to deal with it when I just want to compile/install a program. It will leave a bad taste in my mouth. I would much rather peoples first impression be "oh wow, this program is pretty sweet. I wonder what it is written in?" hence they all use ./configure && make by design rather than necessity. > Do you think that separating the Simple build system from the > declarative part of Cabal would help? It'd make it more obvious that the > build system part really is replaceable which currently is not so > obvious since they're in the same package. I'm not averse to splitting > them if it'd help. They're already completely partitioned internally. Yes it would help signifigantly if it were its own program, invoked by cabal just like hmake or make or mk or cook or bake would be. It would be a step in the right direction. But what I'd really like to see is a split of the configuration management from the parts that meerly describe the package. I sometimes hear that I just shouldn't use cabal for some projects but, when it comes down to it. If cabal is a limited build/configuration system in any way, why would I ever choose it when starting a project when I know it is either putting a limit on my projects ability to innovate or knowing that at some point in the future I am going to have to switch build systems? If cabal isn't suitable or convinient for some projects (which we all admit) and cabal is the haskell way of doing things then the perception will be that _haskell_ is not suitable for said projects. And that is what I fear. John -- John Meacham - ?repetae.net?john? From chak at cse.unsw.edu.au Thu Aug 28 02:31:16 2008 From: chak at cse.unsw.edu.au (Manuel M T Chakravarty) Date: Thu Aug 28 02:29:48 2008 Subject: Version control systems In-Reply-To: <20080818092840.GA25432@matrix.chaos.earth.li> References: <4492B45B-6699-4444-87A9-83F0595B4EB7@cse.unsw.edu.au> <48A28F11.4090307@gmail.com> <404396ef0808141534i65ceae28ud23186d3f845714@mail.gmail.com> <83BF150C-20EA-48AA-8C1B-BFC8B6CA71EB@cse.unsw.edu.au> <916b84820808141712t18d87a07v47bf7be012cd7725@mail.gmail.com> <26D36D0E-3A57-4DF2-8D9E-07A876B12DE5@cse.unsw.edu.au> <48A564D4.3000806@charter.net> <9d4d38820808150501n17c8d56g730dc2b5d4e99126@mail.gmail.com> <20080815143840.GB9938@matrix.chaos.earth.li> <20080818092840.GA25432@matrix.chaos.earth.li> Message-ID: <5F93330D-CE2C-4304-A39F-7C67C3B9A271@cse.unsw.edu.au> Ian Lynagh: > On Mon, Aug 18, 2008 at 12:21:47PM +1000, Manuel M T Chakravarty > wrote: >> From what you are saying, it seems that one "advantage" of git (in- >> place branch switching) is not going to be useful to GHC in any case > > Yes. > >> (because we use nested repositories). > > That does make it harder, but the main problem is that switching > between > branches changes the timestamp of files that differ, meaning the build > system thinks that recompilation needs to be done. > > Also, if you have 2 in-place branches of GHC then only one of them can > be built at any one time, as they share a working directory. That doesn't sound like GHC-specific issues. So, if inplace branches are useful for other projects -such as the Linux kernel- why shouldn't it be useful for us? Manuel From ganesh.sittampalam at credit-suisse.com Thu Aug 28 03:29:49 2008 From: ganesh.sittampalam at credit-suisse.com (Sittampalam, Ganesh) Date: Thu Aug 28 03:28:29 2008 Subject: Build system idea In-Reply-To: <20080828022638.GY15616@sliver.repetae.net> References: <48A161DA.3010106@gmail.com> <061FA30C-4326-4B65-A80F-096593C81D6C@cse.unsw.edu.au> <20080827100458.GQ15616@sliver.repetae.net> <1219833910.24846.138.camel@localhost> <20080827131324.GR15616@sliver.repetae.net> <1219871939.24846.206.camel@localhost> <20080828022638.GY15616@sliver.repetae.net> Message-ID: <78A3C5650E28124399107F21A1FA419401D3B81C@ELON17P32002A.csfb.cs-group.com> John Meacham wrote: > On Wed, Aug 27, 2008 at 10:18:59PM +0100, Duncan Coutts wrote: > > So I accept that we do not yet cover the range of configuration > > choices that are needed by the more complex packages (cf darcs), but I > > think that we can and that the approach is basically sound. The fact > > that we can automatically generate distro packages for hundreds of > > packages is not insignificant. This is just not possible with the > > autoconf approach. > This is just utterly untrue. autoconfed packages that generate rpms, > debs, etc are quite common. Can you give an example of how this works? I would expect autoconf scripts to be completely missing the necessary metadata to do this. > As for programs written in haskell, I don't want people's first > impression of haskell being "oh crap, I gotta learn a new way to > build things just because this program is written in some odd language > called 'haskell'" I don't care how awesome a language is, I am going > to be annoyed by having to deal with it when I just want to > compile/install a program. It will leave a bad taste in my mouth. > I would much rather peoples first impression be "oh wow, this > program is pretty sweet. I wonder what it is written in?" hence > they all use ./configure && make by design rather than necessity. On the flip side, ./configure && make is completely useless on native windows (i.e. without cygwin, mingw or the like) platforms, whereas cabal works everywhere GHC does. Cheers, Ganesh ============================================================================== Please access the attached hyperlink for an important electronic communications disclaimer: http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html ============================================================================== From simonpj at microsoft.com Thu Aug 28 05:27:22 2008 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Thu Aug 28 05:25:51 2008 Subject: Build system idea In-Reply-To: <1219871939.24846.206.camel@localhost> References: <48A161DA.3010106@gmail.com> <061FA30C-4326-4B65-A80F-096593C81D6C@cse.unsw.edu.au> <20080827100458.GQ15616@sliver.repetae.net> <1219833910.24846.138.camel@localhost> <20080827131324.GR15616@sliver.repetae.net> <1219871939.24846.206.camel@localhost> Message-ID: <638ABD0A29C8884A91BC5FB5C349B1C32AE8697D91@EA-EXMSG-C334.europe.corp.microsoft.com> | So Cabal takes the view that the relationship between features and | dependencies should be declarative. ... | The other principle is that the packager, the environment is in control | over what things the package 'sees'. ... | that we can and that the approach is basically sound. The fact that we | can automatically generate distro packages for hundreds of packages is | not insignificant. This is just not possible with the autoconf approach. ... | Do you think that separating the Simple build system from the | declarative part of Cabal would help? It'd make it more obvious that the | build system part really is replaceable which currently is not so | obvious since they're in the same package. I'm not averse to splitting | them if it'd help. They're already completely partitioned internally. Duncan, I'm not following every detail here, but it's clear that you have some clear mental infrastructure in your head that informs and underpins the way Cabal is. Cabal "takes the view that...", has "principles", and "is clearly partitioned internally". These things are clear to you, but my sense it that they are *not* clear even to other well-informed people. (I exclude myself from this group.) It's like the Loch Ness monster: the bits above the waves make sense only when you get an underwater picture that shows you the monster underneath that explains why the humps surface in the way they do. This isn't a criticism: one of the hardest thing to do is to accurately convey this underwater stuff. But I wonder whether there might be a useful paper hiding here? Something that establishes terminology, writes down principles, explains the Cabal viewpoint, contrasts with alternatives, and thereby allows discussion about Cabal to be better informed. Simon PS: concerning your last point, about "separating the Simple build system", that might indeed be good. Indeed, the GHC plan described here http://hackage.haskell.org/trac/ghc/wiki/Design/BuildSystem is (I think) precisely using the declarative part but not the build-system part. From igloo at earth.li Thu Aug 28 07:10:38 2008 From: igloo at earth.li (Ian Lynagh) Date: Thu Aug 28 07:09:07 2008 Subject: Build system idea In-Reply-To: <638ABD0A29C8884A91BC5FB5C349B1C32AE8697D91@EA-EXMSG-C334.europe.corp.microsoft.com> References: <48A161DA.3010106@gmail.com> <061FA30C-4326-4B65-A80F-096593C81D6C@cse.unsw.edu.au> <20080827100458.GQ15616@sliver.repetae.net> <1219833910.24846.138.camel@localhost> <20080827131324.GR15616@sliver.repetae.net> <1219871939.24846.206.camel@localhost> <638ABD0A29C8884A91BC5FB5C349B1C32AE8697D91@EA-EXMSG-C334.europe.corp.microsoft.com> Message-ID: <20080828111038.GA15591@matrix.chaos.earth.li> On Thu, Aug 28, 2008 at 10:27:22AM +0100, Simon Peyton-Jones wrote: > > PS: concerning your last point, about "separating the Simple build system", that might indeed be good. Indeed, the GHC plan described here http://hackage.haskell.org/trac/ghc/wiki/Design/BuildSystem is (I think) precisely using the declarative part but not the build-system part. The * Use Cabal for Haddocking, installing, and anything else we need to do. bullet point uses the build system part. Thanks Ian From marlowsd at gmail.com Thu Aug 28 09:59:16 2008 From: marlowsd at gmail.com (Simon Marlow) Date: Thu Aug 28 09:57:49 2008 Subject: Build system idea In-Reply-To: <20080828022638.GY15616@sliver.repetae.net> References: <48A161DA.3010106@gmail.com> <061FA30C-4326-4B65-A80F-096593C81D6C@cse.unsw.edu.au> <20080827100458.GQ15616@sliver.repetae.net> <1219833910.24846.138.camel@localhost> <20080827131324.GR15616@sliver.repetae.net> <1219871939.24846.206.camel@localhost> <20080828022638.GY15616@sliver.repetae.net> Message-ID: <48B6AF34.2010601@gmail.com> John Meacham wrote: > unfortunately the cabal approach doesn't work. note, I am not saying a > declarative configuration manager won't work. in fact, I have sketched a > design for one on occasion. but cabal's particular choices are broken. > It is treading the same waters that made 'imake' fail. > > the ideas of forwards and backwards compatability are _the_ defining > features of a configuration manager. Think about this, I can take my old > sunsite CD, burned _ten years_ ago and take the unchanged tarballs off > that CD and ./configure && make and in general most will work. many were > written before linux even existed, many were written with non gcc > compilers, yet they work today. The cabal way wasn't able to handle a > single release of ghc and keep forwards or backwards compatability. > > That any project ever had to be changed to use the flag 'split-base' is > a travesty. What about all the projects on burnt cds or that don't have > someone to update them? 20 years from now when we are all using 'fhc' > (Fred's Haskell Compiler) will we still have this reference to > 'split-base' in our cabal files? how many more flags will have > accumulated by then? Sure it's declarative, but in a language that > doesn't make sense without the rule-book. autoconf tests things like > 'does a library named foo exist and export bar'. 'is char signed or > unsigned on the target system'. those are declarative statement and > have a defined meaning through all time. (though, implemented in a > pretty ugly imperative way) That is what allows autoconfed packages to > be compiled by compilers on systems that were never dreamed of when the > packages were written. The important thing about Cabal's way of specifying dependencies is that they can be made sound with not much difficulty. If I say that my package depends on base==3.0 and network==1.0, then I can guarantee that as long as those dependencies are present then my package will build. ("but but but..." I hear you say - don't touch that keyboard yet!) Suppose you used autoconf tests instead. You might happen to know that Network.Socket.blah was added at some point and write a test for that, but alas if you didn't also write a test for Network.Socket.foo (which your code uses but ends up getting removed in network-1.1) then your code breaks. Autoconf doesn't help you make your configuration sound, and you get no prior guarantee that your code will build. Now, Cabal's dependencies have the well-known problem that they're exceptionally brittle, because they either overspecify or underspecify, and it's not possible to get it "just right". On the other hand, autoconf configurations tend to underspecify dependencies, because you typically only write an autoconf test for something that you know has changed in the past - you don't know what's going to change in the future, so you usually just hope for the best. For Cabal I can ask the question "if I modify the API of package P, which other packages might be broken as a result?", but I can't do that with autoconf. Both systems are flawed, but neither fundamentally. For Cabal I think it would be interesting to look into using more precise dependencies (module.identifier::type, rather than package-version) and have them auto-generated. But this has difficult implications: implementing cabal-install's installation plans becomes much harder, for example. >> So I accept that we do not yet cover the range of configuration choices >> that are needed by the more complex packages (cf darcs), but I think >> that we can and that the approach is basically sound. The fact that we >> can automatically generate distro packages for hundreds of packages is >> not insignificant. This is just not possible with the autoconf approach. > > This is just utterly untrue. autoconfed packages that generate rpms, > debs, etc are quite common. The only reason cabal can autogenerate > distro packages for so many is that many interesting or hard ones just > _arn't possible with cabal at all_. Exactly! Cabal is designed so that a distro packager can write a program that takes a Cabal package and generates a distro package for their distro. It has to do distro-specific stuff, but it doesn't typically need to do package-specific stuff. To generate a distro package from an autoconf package either the package author has to include support for that distro, or a distro packager has to write specific support for that package. There's no way to do generic autoconf->distro package generation, like there is with Cabal. Yes this means that Cabal is less general than autoconf. It was quite a revelation when we discovered this during the design of Cabal - originally we were going to have everything done programmatically in the Setup.hs file, but then we realised that having the package configuration available *as data* gave us a lot more scope for automation, albeit at the expense of some generality. That's the tradeoff - but there's still nothing stopping you from using autoconf and your own build system instead if you need to! > As for programs written in haskell, I don't want people's first > impression of haskell being "oh crap, I gotta learn a new way to build > things just because this program is written in some odd language called > 'haskell'" I don't care how awesome a language is, I am going to be > annoyed by having to deal with it when I just want to compile/install a > program. It will leave a bad taste in my mouth. I would much rather > peoples first impression be "oh wow, this program is pretty sweet. I > wonder what it is written in?" hence they all use ./configure && make by > design rather than necessity. Python packages don't have ./configure or make... > I sometimes hear that I just shouldn't use cabal for some projects but, > when it comes down to it. If cabal is a limited build/configuration > system in any way, why would I ever choose it when starting a project > when I know it is either putting a limit on my projects ability to > innovate or knowing that at some point in the future I am going to have > to switch build systems? Because if you *can* use Cabal, you get a lot of value-adds for free (distro packages, cabal-install, Haddock, source distributions, Hackage). What's more, it's really cheap to use Cabal: a .cabal file is typically less than a screenful, so it's no big deal to switch to something else later if you need to. Cheers, Simon From allbery at ece.cmu.edu Thu Aug 28 10:02:19 2008 From: allbery at ece.cmu.edu (Brandon S. Allbery KF8NH) Date: Thu Aug 28 10:01:07 2008 Subject: Build system idea In-Reply-To: <638ABD0A29C8884A91BC5FB5C349B1C32AE8697D91@EA-EXMSG-C334.europe.corp.microsoft.com> References: <48A161DA.3010106@gmail.com> <061FA30C-4326-4B65-A80F-096593C81D6C@cse.unsw.edu.au> <20080827100458.GQ15616@sliver.repetae.net> <1219833910.24846.138.camel@localhost> <20080827131324.GR15616@sliver.repetae.net> <1219871939.24846.206.camel@localhost> <638ABD0A29C8884A91BC5FB5C349B1C32AE8697D91@EA-EXMSG-C334.europe.corp.microsoft.com> Message-ID: On 2008 Aug 28, at 5:27, Simon Peyton-Jones wrote: > This isn't a criticism: one of the hardest thing to do is to > accurately convey this underwater stuff. But I wonder whether there > might be a useful paper hiding here? Something that establishes > terminology, writes down principles, explains the Cabal viewpoint, > contrasts with alternatives, and thereby allows discussion about > Cabal to be better informed. I think we're at the point where such a document is necessary if we're going to have a coherent discussion. (And as an aside, I think the same is true of darcs.) -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH From simonpj at microsoft.com Thu Aug 28 10:02:52 2008 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Thu Aug 28 10:01:19 2008 Subject: Build system idea In-Reply-To: <48B6AF34.2010601@gmail.com> References: <48A161DA.3010106@gmail.com> <061FA30C-4326-4B65-A80F-096593C81D6C@cse.unsw.edu.au> <20080827100458.GQ15616@sliver.repetae.net> <1219833910.24846.138.camel@localhost> <20080827131324.GR15616@sliver.repetae.net> <1219871939.24846.206.camel@localhost> <20080828022638.GY15616@sliver.repetae.net> <48B6AF34.2010601@gmail.com> Message-ID: <638ABD0A29C8884A91BC5FB5C349B1C32AE8697FFD@EA-EXMSG-C334.europe.corp.microsoft.com> | Yes this means that Cabal is less general than autoconf. It was quite a | revelation when we discovered this during the design of Cabal - originally | we were going to have everything done programmatically in the Setup.hs | file, but then we realised that having the package configuration available | *as data* gave us a lot more scope for automation, albeit at the expense of | some generality. Now there's a useful insight for the paper I hope Duncan (or someone) is going to write configuration as code [autoconf] vs configuration as data [cabal] Simon From rl at cse.unsw.edu.au Thu Aug 28 10:55:56 2008 From: rl at cse.unsw.edu.au (Roman Leshchinskiy) Date: Thu Aug 28 10:54:44 2008 Subject: Build system idea In-Reply-To: <638ABD0A29C8884A91BC5FB5C349B1C32AE8697D91@EA-EXMSG-C334.europe.corp.microsoft.com> References: <48A161DA.3010106@gmail.com> <061FA30C-4326-4B65-A80F-096593C81D6C@cse.unsw.edu.au> <20080827100458.GQ15616@sliver.repetae.net> <1219833910.24846.138.camel@localhost> <20080827131324.GR15616@sliver.repetae.net> <1219871939.24846.206.camel@localhost> <638ABD0A29C8884A91BC5FB5C349B1C32AE8697D91@EA-EXMSG-C334.europe.corp.microsoft.com> Message-ID: On 28/08/2008, at 19:27, Simon Peyton-Jones wrote: > Duncan, I'm not following every detail here, but it's clear that you > have some clear mental infrastructure in your head that informs and > underpins the way Cabal is. Cabal "takes the view that...", has > "principles", and "is clearly partitioned internally". > > These things are clear to you, but my sense it that they are *not* > clear even to other well-informed people. (I exclude myself from > this group.) It's like the Loch Ness monster: the bits above the > waves make sense only when you get an underwater picture that shows > you the monster underneath that explains why the humps surface in > the way they do. FWIW, I fully agree with this (although I'm not especially well- informed in this particular area). It would be immensely helpful if Cabal's "philosophy" was described somewhere. Roman From rl at cse.unsw.edu.au Thu Aug 28 10:57:59 2008 From: rl at cse.unsw.edu.au (Roman Leshchinskiy) Date: Thu Aug 28 10:56:42 2008 Subject: Build system idea In-Reply-To: <20080828111038.GA15591@matrix.chaos.earth.li> References: <48A161DA.3010106@gmail.com> <061FA30C-4326-4B65-A80F-096593C81D6C@cse.unsw.edu.au> <20080827100458.GQ15616@sliver.repetae.net> <1219833910.24846.138.camel@localhost> <20080827131324.GR15616@sliver.repetae.net> <1219871939.24846.206.camel@localhost> <638ABD0A29C8884A91BC5FB5C349B1C32AE8697D91@EA-EXMSG-C334.europe.corp.microsoft.com> <20080828111038.GA15591@matrix.chaos.earth.li> Message-ID: <821873D9-9768-4418-985A-A1DDD2858F08@cse.unsw.edu.au> On 28/08/2008, at 21:10, Ian Lynagh wrote: > On Thu, Aug 28, 2008 at 10:27:22AM +0100, Simon Peyton-Jones wrote: >> >> PS: concerning your last point, about "separating the Simple build >> system", that might indeed be good. Indeed, the GHC plan described >> here http://hackage.haskell.org/trac/ghc/wiki/Design/BuildSystem is >> (I think) precisely using the declarative part but not the build- >> system part. > > The > * Use Cabal for Haddocking, installing, and anything else we need > to do. > bullet point uses the build system part. Hmm, from the previous discussion I got the impression that (large parts of) this functionality would be extracted from Simple and could then be used by other build systems. Is this wrong? Roman From rl at cse.unsw.edu.au Thu Aug 28 11:19:53 2008 From: rl at cse.unsw.edu.au (Roman Leshchinskiy) Date: Thu Aug 28 11:18:33 2008 Subject: Build system idea In-Reply-To: <48B6AF34.2010601@gmail.com> References: <48A161DA.3010106@gmail.com> <061FA30C-4326-4B65-A80F-096593C81D6C@cse.unsw.edu.au> <20080827100458.GQ15616@sliver.repetae.net> <1219833910.24846.138.camel@localhost> <20080827131324.GR15616@sliver.repetae.net> <1219871939.24846.206.camel@localhost> <20080828022638.GY15616@sliver.repetae.net> <48B6AF34.2010601@gmail.com> Message-ID: On 28/08/2008, at 23:59, Simon Marlow wrote: > The important thing about Cabal's way of specifying dependencies is > that they can be made sound with not much difficulty. If I say that > my package depends on base==3.0 and network==1.0, then I can > guarantee that as long as those dependencies are present then my > package will build. ("but but but..." I hear you say - don't touch > that keyboard yet!) > > Suppose you used autoconf tests instead. You might happen to know > that Network.Socket.blah was added at some point and write a test > for that, but alas if you didn't also write a test for > Network.Socket.foo (which your code uses but ends up getting removed > in network-1.1) then your code breaks. Autoconf doesn't help you > make your configuration sound, and you get no prior guarantee that > your code will build. Cabal doesn't give this guarantee, either, since it allows you to depend on just network or on network>x. To be perfectly honest, I think neither autoconf's approach (free-form feature tests) nor Cabal's (version-based dependencies) really work for all important use cases. And I have to disagree with what you write below - I think both systems are fundamentally flawed. As I said before, what does (mostly) work IMO is depending on interfaces which are independent of packages. Being required to specify the exact interface you depend on solves the problem you describe above. It also solves the problem of name clashes with functions defined in later versions of a package. And it is still nicely declarative. > Both systems are flawed, but neither fundamentally. For Cabal I > think it would be interesting to look into using more precise > dependencies (module.identifier::type, rather than package-version) > and have them auto-generated. But this has difficult implications: > implementing cabal-install's installation plans becomes much harder, > for example. Interesting. From our previous discussion I got the impression that you wouldn't like something like this. :-) Roman From marlowsd at gmail.com Thu Aug 28 11:31:22 2008 From: marlowsd at gmail.com (Simon Marlow) Date: Thu Aug 28 11:29:56 2008 Subject: Build system idea In-Reply-To: References: <48A161DA.3010106@gmail.com> <061FA30C-4326-4B65-A80F-096593C81D6C@cse.unsw.edu.au> <20080827100458.GQ15616@sliver.repetae.net> <1219833910.24846.138.camel@localhost> <20080827131324.GR15616@sliver.repetae.net> <1219871939.24846.206.camel@localhost> <20080828022638.GY15616@sliver.repetae.net> <48B6AF34.2010601@gmail.com> Message-ID: <48B6C4CA.7080808@gmail.com> Roman Leshchinskiy wrote: > On 28/08/2008, at 23:59, Simon Marlow wrote: > >> The important thing about Cabal's way of specifying dependencies is >> that they can be made sound with not much difficulty. If I say that >> my package depends on base==3.0 and network==1.0, then I can guarantee >> that as long as those dependencies are present then my package will >> build. ("but but but..." I hear you say - don't touch that keyboard >> yet!) >> >> Suppose you used autoconf tests instead. You might happen to know >> that Network.Socket.blah was added at some point and write a test for >> that, but alas if you didn't also write a test for Network.Socket.foo >> (which your code uses but ends up getting removed in network-1.1) then >> your code breaks. Autoconf doesn't help you make your configuration >> sound, and you get no prior guarantee that your code will build. > > Cabal doesn't give this guarantee, either, since it allows you to depend > on just network or on network>x. Indeed. That's why I was careful not to say that Cabal gives you the guarantee, only that it's easy to achieve it. >> Both systems are flawed, but neither fundamentally. For Cabal I think >> it would be interesting to look into using more precise dependencies >> (module.identifier::type, rather than package-version) and have them >> auto-generated. But this has difficult implications: implementing >> cabal-install's installation plans becomes much harder, for example. > > Interesting. From our previous discussion I got the impression that you > wouldn't like something like this. :-) Sorry for giving that impression. Yes I'd like to solve the problems that Cabal dependencies have, but I don't want the solution to be too costly - first-class interfaces seem too heavyweight to me. But I do agree with most of the arguments you gave in their favour. Cheers, Simon From igloo at earth.li Thu Aug 28 13:11:52 2008 From: igloo at earth.li (Ian Lynagh) Date: Thu Aug 28 13:10:21 2008 Subject: Build system idea In-Reply-To: <821873D9-9768-4418-985A-A1DDD2858F08@cse.unsw.edu.au> References: <48A161DA.3010106@gmail.com> <061FA30C-4326-4B65-A80F-096593C81D6C@cse.unsw.edu.au> <20080827100458.GQ15616@sliver.repetae.net> <1219833910.24846.138.camel@localhost> <20080827131324.GR15616@sliver.repetae.net> <1219871939.24846.206.camel@localhost> <638ABD0A29C8884A91BC5FB5C349B1C32AE8697D91@EA-EXMSG-C334.europe.corp.microsoft.com> <20080828111038.GA15591@matrix.chaos.earth.li> <821873D9-9768-4418-985A-A1DDD2858F08@cse.unsw.edu.au> Message-ID: <20080828171152.GA27108@matrix.chaos.earth.li> On Fri, Aug 29, 2008 at 12:57:59AM +1000, Roman Leshchinskiy wrote: > On 28/08/2008, at 21:10, Ian Lynagh wrote: > > >On Thu, Aug 28, 2008 at 10:27:22AM +0100, Simon Peyton-Jones wrote: > >> > >>PS: concerning your last point, about "separating the Simple build > >>system", that might indeed be good. Indeed, the GHC plan described > >>here http://hackage.haskell.org/trac/ghc/wiki/Design/BuildSystem is > >>(I think) precisely using the declarative part but not the build- > >>system part. > > > >The > > * Use Cabal for Haddocking, installing, and anything else we need > >to do. > >bullet point uses the build system part. > > Hmm, from the previous discussion I got the impression that (large > parts of) this functionality would be extracted from Simple and could > then be used by other build systems. Is this wrong? I thought that the proposal was to split Cabal into the "declarative package specification part", and the "how to build the package" part? If so, then surely "how to run haddock on the sources" belongs in the "how to build the package" part? Of course, you can call the haddocking code from another build system, provided your build system is compatible with the way the haddocking code works. That's more-or-less what "Setup makefile" does: It builds the package itself, but puts things in the same places as the simple build system, so the simple build system can be used for configuring, haddocking, installing, etc. I guess in principle you could split the "how to build the package" part up into multiple packages (Cabal-configure, Cabal-haddock, Cabal-install, etc), but I don't see what benefit that would provide. It would still be the same modules containing the same code inside. Thanks Ian From john at repetae.net Thu Aug 28 18:16:16 2008 From: john at repetae.net (John Meacham) Date: Thu Aug 28 18:14:43 2008 Subject: Build system idea In-Reply-To: <48B6AF34.2010601@gmail.com> References: <48A161DA.3010106@gmail.com> <061FA30C-4326-4B65-A80F-096593C81D6C@cse.unsw.edu.au> <20080827100458.GQ15616@sliver.repetae.net> <1219833910.24846.138.camel@localhost> <20080827131324.GR15616@sliver.repetae.net> <1219871939.24846.206.camel@localhost> <20080828022638.GY15616@sliver.repetae.net> <48B6AF34.2010601@gmail.com> Message-ID: <20080828221615.GB15616@sliver.repetae.net> On Thu, Aug 28, 2008 at 02:59:16PM +0100, Simon Marlow wrote: > The important thing about Cabal's way of specifying dependencies is that > they can be made sound with not much difficulty. If I say that my > package depends on base==3.0 and network==1.0, then I can guarantee that > as long as those dependencies are present then my package will build. > ("but but but..." I hear you say - don't touch that keyboard yet!) I can easily achieve this with autoconf or even nothing, I can simply do a test to see if a system is running fedora core 9 using ghc 6.8.2 and be assured that my package will build properly. But this misses the entire point, I want my package to build not on my exact system, I want it to build on _other_ peoples systems. People running with compilers and libraries and on operating systems I never heard of. However, this has the huge flaw of requiring a closed universe. A complete and universal definition of what 'network == 1.0' means for all time that all future compilers must agree on. It places a huge burden on implementors to provide a 'network=1.0' compatible interface, simply so cabal doesn't complain even though all programs would be happy with a jhc-network 0.7 or a internet-5.0 package. It means that with jhc-network which has 90% of the functionality of network, including everything that 99.9% of all programs need every program will have to either know about jhc-network to edit their cabal file to include it conditionally, or they just won't work at all. Note, this is similar to the problem of symbol versioning placed on shared libraries. There is a fair amount of literature on the subject, most unix's .so's used to have something similar to the current cabal model, a version number with a minor/major part. it was found to lead to dll hell. (well, .so hell) and we don't want to be in the place with haskell (package hell?). Linux hence switched to its current system that has an individual version number for every api function. I am not saying that is the solution for haskell, but I do not see the current cabal approach scaling any better than the old unix one and leading to the same problems. > Suppose you used autoconf tests instead. You might happen to know that > Network.Socket.blah was added at some point and write a test for that, > but alas if you didn't also write a test for Network.Socket.foo (which > your code uses but ends up getting removed in network-1.1) then your code > breaks. Autoconf doesn't help you make your configuration sound, and you > get no prior guarantee that your code will build. And with cabal it breaks there in addition to another 80% of times when it could have worked just fine. The autoconf feature test is strictly superior here. > Now, Cabal's dependencies have the well-known problem that they're > exceptionally brittle, because they either overspecify or underspecify, > and it's not possible to get it "just right". On the other hand, > autoconf configurations tend to underspecify dependencies, because you > typically only write an autoconf test for something that you know has > changed in the past - you don't know what's going to change in the > future, so you usually just hope for the best. For Cabal I can ask the > question "if I modify the API of package P, which other packages might be > broken as a result?", but I can't do that with autoconf. But the only reason they are broken is due to cabal's sledgehammer approach to package versioning. There is no reason an autoconf style system couldn't do the same thing. And again, you are assuming you can even enumerate all the packages that exist to find out which might be broken and what does that really give you in any case? By changing the API you know you are going to break some things, but what about all the company internal software out there that uses haskell? you can't look at all their packages. It just does not seem like a very useful thing to ask. as it is a question that can be answered by 'grep'. > Both systems are flawed, but neither fundamentally. For Cabal I think it > would be interesting to look into using more precise dependencies > (module.identifier::type, rather than package-version) and have them > auto-generated. But this has difficult implications: implementing > cabal-install's installation plans becomes much harder, for example. Again, I would like to see this as another option. I think there are interesting ideas in cabal about configuration management. But there needs to be room for alternates including old standby's like autoconf > >>> So I accept that we do not yet cover the range of configuration choices >>> that are needed by the more complex packages (cf darcs), but I think >>> that we can and that the approach is basically sound. The fact that we >>> can automatically generate distro packages for hundreds of packages is >>> not insignificant. This is just not possible with the autoconf approach. >> >> This is just utterly untrue. autoconfed packages that generate rpms, >> debs, etc are quite common. The only reason cabal can autogenerate >> distro packages for so many is that many interesting or hard ones just >> _arn't possible with cabal at all_. > > Exactly! Cabal is designed so that a distro packager can write a program > that takes a Cabal package and generates a distro package for their > distro. It has to do distro-specific stuff, but it doesn't typically > need to do package-specific stuff. > > To generate a distro package from an autoconf package either the package > author has to include support for that distro, or a distro packager has > to write specific support for that package. There's no way to do generic > autoconf->distro package generation, like there is with Cabal. In cabal you only get it because you convinced the cabal people to put in code to support your distro. Which isn't much different than asking the package manager too. And besides, this ability has nothing to do with cabal's configuration management capabilities, simply its metadata format. which can easily be abstracted out and not tied to cabal. (which I would love to see. cabal has a lot of good ideas, but due to its design, its bad ideas are complete showstoppers rather than things you can replace) and there are many automatic package managers for autoconf style packages. http://www.toastball.net/toast/ is a good one, it even downloads dependencies from freshmeat when needed. in fact, your projects can probably be auto installed by 'toast projectname' and you didn't even know it! http://encap.org/ - one I use on pretty much all my systems. since it is distro independent. > Yes this means that Cabal is less general than autoconf. It was quite a > revelation when we discovered this during the design of Cabal - > originally we were going to have everything done programmatically in the > Setup.hs file, but then we realised that having the package configuration > available *as data* gave us a lot more scope for automation, albeit at > the expense of some generality. Note, I wholeheartedly agree with the idea of package configuration as data. In fact, when cabal first started, I was a huge advocate of it and in fact _lost interest_ in the project because of the decision to go with the programatic Setup.hs rather than a declarative approach. However, I think cabal is a _poor execution_ of the idea. And this problem is compounded by the fact it is being promoted as the haskell way to do things, it's design decisions are affecting development and evolution of the base libraries. And it's monolithic nature and attitude of wanting to take over your whole projects build cycle means that alternate approaches cannot be explored. > That's the tradeoff - but there's still nothing stopping you from using > autoconf and your own build system instead if you need to! But it is a false tradeoff. the only reason one needs to make that tradeoff is because cabals design doesn't allow the useful ability to mix-n-match parts of it. I would prefer to see cabal improved so I _can_ use its metadata format, its configuration manager for simple projects, autoconf's for more complex ones (with full knowledge of the tradeoffs) and without jumping through hoops. >> As for programs written in haskell, I don't want people's first >> impression of haskell being "oh crap, I gotta learn a new way to build >> things just because this program is written in some odd language called >> 'haskell'" I don't care how awesome a language is, I am going to be >> annoyed by having to deal with it when I just want to compile/install a >> program. It will leave a bad taste in my mouth. I would much rather >> peoples first impression be "oh wow, this program is pretty sweet. I >> wonder what it is written in?" hence they all use ./configure && make by >> design rather than necessity. > > Python packages don't have ./configure or make... Some don't. And it bugs the hell out of me. They don't work with my autopackaging tools. >> I sometimes hear that I just shouldn't use cabal for some projects but, >> when it comes down to it. If cabal is a limited build/configuration >> system in any way, why would I ever choose it when starting a project >> when I know it is either putting a limit on my projects ability to >> innovate or knowing that at some point in the future I am going to have >> to switch build systems? > > Because if you *can* use Cabal, you get a lot of value-adds for free > (distro packages, cabal-install, Haddock, source distributions, Hackage). > What's more, it's really cheap to use Cabal: a .cabal file is typically > less than a screenful, so it's no big deal to switch to something else > later if you need to. except suddenly you can't use hackage and have to come up with a new build system and perhaps upset my users as they have to learn a new way to build the project. The fact is that it _is_ a big deal to replace cabal is the main issue I have. switching involves changing your build system completely. you can't replace just parts of it easily. Or integrate cabal from the bottom up rather than the top down. And it wants to be the _one true_ build system in your project. I'd like to see a standardized meta-info format for just haskell libraries, based on the current cabal format without the cabal specific build information. (this is what jhc uses, and franchise too I think) Just like the 'lsm' linux software map files. Preferably YAML, we are pretty darn close already and it will give us parsers in many languages for free. We already have several tools that can use the meta-info, jhc, cabal, franchise, hackage (for the web site layout) so it seems like abstracting it from the build info would be a useful step in the right direction. John -- John Meacham - ?repetae.net?john? From igloo at earth.li Thu Aug 28 19:21:10 2008 From: igloo at earth.li (Ian Lynagh) Date: Thu Aug 28 19:19:38 2008 Subject: Build system idea In-Reply-To: <20080828221615.GB15616@sliver.repetae.net> References: <48A161DA.3010106@gmail.com> <061FA30C-4326-4B65-A80F-096593C81D6C@cse.unsw.edu.au> <20080827100458.GQ15616@sliver.repetae.net> <1219833910.24846.138.camel@localhost> <20080827131324.GR15616@sliver.repetae.net> <1219871939.24846.206.camel@localhost> <20080828022638.GY15616@sliver.repetae.net> <48B6AF34.2010601@gmail.com> <20080828221615.GB15616@sliver.repetae.net> Message-ID: <20080828232110.GA21277@matrix.chaos.earth.li> On Thu, Aug 28, 2008 at 03:16:16PM -0700, John Meacham wrote: > On Thu, Aug 28, 2008 at 02:59:16PM +0100, Simon Marlow wrote: > > > To generate a distro package from an autoconf package either the package > > author has to include support for that distro, or a distro packager has > > to write specific support for that package. There's no way to do generic > > autoconf->distro package generation, like there is with Cabal. > > In cabal you only get it because you convinced the cabal people to put > in code to support your distro. Which isn't much different than asking > the package manager too. I don't understand this. Cabal doesn't have any distro-specific code. > And besides, this ability has nothing to do with cabal's configuration > management capabilities, simply its metadata format. I don't understand this either. You imply you like Cabal's metadata, which says "I depend on network version 1", right? But you don't like Cabal's configuration management? What is Cabal's configuration management, then? > and there are many automatic package managers for autoconf style > packages. > > http://encap.org/ - one I use on pretty much all my systems. since it is > distro independent. OK, so here's an encap package for DBI: http://encap.org/search/encapinfo.fcgi?collection=cites&archive=DBI-1.21-encap-sparc-solaris8.tar.gz ftp://ftp.encap.org/pub/encap/pkgs/cites/DBI-1.21-encap-sparc-solaris8.tar.gz This tarball contains an encapinfo file that says encap 2.1 # libencap-2.2.1 platform sparc-solaris8 date Mon Mar 11 19:38:02 CST 2002 contact "Mark D. Roth" prereq pkgspec >= perl-5.6.1 So this is not a package manager for autoconf-style packages, it is a package manager for encap packages. Mark has had to download DBI, an autoconf-style package, examine its source code, determine that perl >= 5.6.1 is necessary in order to use it, and construct this encap package of DBI. The point of Cabal's design is that we don't want to have to have a Mark going round making encapinfo files; they come with the package. In a sense, writing a Cabal package is like writing an encap package directly, rather than first writing an autoconf-style package and then encapifying it. Thanks Ian From john at repetae.net Thu Aug 28 19:53:52 2008 From: john at repetae.net (John Meacham) Date: Thu Aug 28 19:52:20 2008 Subject: Build system idea In-Reply-To: <20080828232110.GA21277@matrix.chaos.earth.li> References: <48A161DA.3010106@gmail.com> <061FA30C-4326-4B65-A80F-096593C81D6C@cse.unsw.edu.au> <20080827100458.GQ15616@sliver.repetae.net> <1219833910.24846.138.camel@localhost> <20080827131324.GR15616@sliver.repetae.net> <1219871939.24846.206.camel@localhost> <20080828022638.GY15616@sliver.repetae.net> <48B6AF34.2010601@gmail.com> <20080828221615.GB15616@sliver.repetae.net> <20080828232110.GA21277@matrix.chaos.earth.li> Message-ID: <20080828235352.GB30189@sliver.repetae.net> On Fri, Aug 29, 2008 at 12:21:10AM +0100, Ian Lynagh wrote: > You imply you like Cabal's metadata, which says "I depend on network > version 1", right? no, I mean a standard way to specify a package name, a description of it, a category, etc.. > But you don't like Cabal's configuration management? What is Cabal's > configuration management, then? the build-depends field mainly, pretty much everything dealing with cabal building a package rather than just describing the _result_ of a successful building. One is constant between build systems and would be generally useful to standardize independently, the other depends on the specific build system/configuration manager used. John -- John Meacham - ?repetae.net?john? From rl at cse.unsw.edu.au Thu Aug 28 21:43:26 2008 From: rl at cse.unsw.edu.au (Roman Leshchinskiy) Date: Thu Aug 28 21:42:02 2008 Subject: Build system idea In-Reply-To: <20080828171152.GA27108@matrix.chaos.earth.li> References: <48A161DA.3010106@gmail.com> <061FA30C-4326-4B65-A80F-096593C81D6C@cse.unsw.edu.au> <20080827100458.GQ15616@sliver.repetae.net> <1219833910.24846.138.camel@localhost> <20080827131324.GR15616@sliver.repetae.net> <1219871939.24846.206.camel@localhost> <638ABD0A29C8884A91BC5FB5C349B1C32AE8697D91@EA-EXMSG-C334.europe.corp.microsoft.com> <20080828111038.GA15591@matrix.chaos.earth.li> <821873D9-9768-4418-985A-A1DDD2858F08@cse.unsw.edu.au> <20080828171152.GA27108@matrix.chaos.earth.li> Message-ID: <363434C5-F065-4B57-9EAB-97C12BEAEF86@cse.unsw.edu.au> On 29/08/2008, at 03:11, Ian Lynagh wrote: > On Fri, Aug 29, 2008 at 12:57:59AM +1000, Roman Leshchinskiy wrote: >> On 28/08/2008, at 21:10, Ian Lynagh wrote: >> >>> On Thu, Aug 28, 2008 at 10:27:22AM +0100, Simon Peyton-Jones wrote: >>>> >>>> PS: concerning your last point, about "separating the Simple build >>>> system", that might indeed be good. Indeed, the GHC plan described >>>> here http://hackage.haskell.org/trac/ghc/wiki/Design/BuildSystem is >>>> (I think) precisely using the declarative part but not the build- >>>> system part. >>> >>> The >>> * Use Cabal for Haddocking, installing, and anything else we need >>> to do. >>> bullet point uses the build system part. >> >> Hmm, from the previous discussion I got the impression that (large >> parts of) this functionality would be extracted from Simple and could >> then be used by other build systems. Is this wrong? > > I thought that the proposal was to split Cabal into the "declarative > package specification part", and the "how to build the package" part? > > If so, then surely "how to run haddock on the sources" belongs in the > "how to build the package" part? Ignore me, I misunderstood what your original mail. Sorry for the confusion. Roman From s.clover at gmail.com Thu Aug 28 22:00:29 2008 From: s.clover at gmail.com (Sterling Clover) Date: Thu Aug 28 21:59:00 2008 Subject: Build system idea In-Reply-To: <638ABD0A29C8884A91BC5FB5C349B1C32AE8697FFD@EA-EXMSG-C334.europe.corp.microsoft.com> References: <48A161DA.3010106@gmail.com> <061FA30C-4326-4B65-A80F-096593C81D6C@cse.unsw.edu.au> <20080827100458.GQ15616@sliver.repetae.net> <1219833910.24846.138.camel@localhost> <20080827131324.GR15616@sliver.repetae.net> <1219871939.24846.206.camel@localhost> <20080828022638.GY15616@sliver.repetae.net> <48B6AF34.2010601@gmail.com> <638ABD0A29C8884A91BC5FB5C349B1C32AE8697FFD@EA-EXMSG-C334.europe.corp.microsoft.com> Message-ID: <11074408-113F-4BB6-9CA5-4E21F5B2CB16@gmail.com> We do have, although not with easy access, an additional declarative layer "built in" 90% of the time as configuration as type signature. An autoconf style approach to this where each type signature dependency is declared seperately would be needlessly complex and painful. However, there is room for a fruitful middle ground. Thanks to Hackage, at least for those packages that build properly and haddock on it, we have, although not in the best format, information on the type signatures of the functions of packages, across various package versions. So if I, when writing a cabal script, don't particularly want to figure out the exact range of, e.g., Network, packages that provide the correct API, it would be fairly reasonable to statically determine which functions from the Network package that are called, and which versions of Network on hackage provide them, and with the appropriate types no less. Thus, given that we need "Network," a tool could determine what the correct allowable range of versions is, and thus avoid both over- and under- specification. This same tool could be run over existing .cabal files on hackage, statically determining when they are likely to either over- or under- specify, and alerting package maintainers to this. --Sterl. On Aug 28, 2008, at 10:02 AM, Simon Peyton-Jones wrote: > | Yes this means that Cabal is less general than autoconf. It was > quite a > | revelation when we discovered this during the design of Cabal - > originally > | we were going to have everything done programmatically in the > Setup.hs > | file, but then we realised that having the package configuration > available > | *as data* gave us a lot more scope for automation, albeit at the > expense of > | some generality. > > Now there's a useful insight for the paper I hope Duncan (or > someone) is going to write > > configuration as code [autoconf] > vs > configuration as data [cabal] > > Simon > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users@haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users From allbery at ece.cmu.edu Thu Aug 28 22:21:06 2008 From: allbery at ece.cmu.edu (Brandon S. Allbery KF8NH) Date: Thu Aug 28 22:19:38 2008 Subject: Build system idea In-Reply-To: <11074408-113F-4BB6-9CA5-4E21F5B2CB16@gmail.com> References: <48A161DA.3010106@gmail.com> <061FA30C-4326-4B65-A80F-096593C81D6C@cse.unsw.edu.au> <20080827100458.GQ15616@sliver.repetae.net> <1219833910.24846.138.camel@localhost> <20080827131324.GR15616@sliver.repetae.net> <1219871939.24846.206.camel@localhost> <20080828022638.GY15616@sliver.repetae.net> <48B6AF34.2010601@gmail.com> <638ABD0A29C8884A91BC5FB5C349B1C32AE8697FFD@EA-EXMSG-C334.europe.corp.microsoft.com> <11074408-113F-4BB6-9CA5-4E21F5B2CB16@gmail.com> Message-ID: <4D6E0358-93BC-48FA-8C66-EE982606C3EA@ece.cmu.edu> On 2008 Aug 28, at 22:00, Sterling Clover wrote: > We do have, although not with easy access, an additional declarative > layer "built in" 90% of the time as configuration as type signature. Sure? I think it's easier than you think: someone's already written code to extract the information from .hi files (and indeed ghc will dump it for you: ghc --dump-iface foo.hi). In theory there could be a master dictionary of these hosted on hackage, collected from each package's own dictionary, and a given package's dependencies could be computed with high accuracy from it. -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH From rl at cse.unsw.EDU.AU Thu Aug 28 23:48:31 2008 From: rl at cse.unsw.EDU.AU (Roman Leshchinskiy) Date: Thu Aug 28 23:47:03 2008 Subject: Build system idea In-Reply-To: <48B6C4CA.7080808@gmail.com> References: <48A161DA.3010106@gmail.com> <061FA30C-4326-4B65-A80F-096593C81D6C@cse.unsw.edu.au> <20080827100458.GQ15616@sliver.repetae.net> <1219833910.24846.138.camel@localhost> <20080827131324.GR15616@sliver.repetae.net> <1219871939.24846.206.camel@localhost> <20080828022638.GY15616@sliver.repetae.net> <48B6AF34.2010601@gmail.com> <48B6C4CA.7080808@gmail.com> Message-ID: <8B57B7A7-15C5-466F-8CEE-814777BC3C87@cse.unsw.EDU.AU> On 29/08/2008, at 01:31, Simon Marlow wrote: > Roman Leshchinskiy wrote: >> On 28/08/2008, at 23:59, Simon Marlow wrote: >>> The important thing about Cabal's way of specifying dependencies >>> is that they can be made sound with not much difficulty. If I say >>> that my package depends on base==3.0 and network==1.0, then I can >>> guarantee that as long as those dependencies are present then my >>> package will build. ("but but but..." I hear you say - don't >>> touch that keyboard yet!) >>> >>> Suppose you used autoconf tests instead. You might happen to know >>> that Network.Socket.blah was added at some point and write a test >>> for that, but alas if you didn't also write a test for >>> Network.Socket.foo (which your code uses but ends up getting >>> removed in network-1.1) then your code breaks. Autoconf doesn't >>> help you make your configuration sound, and you get no prior >>> guarantee that your code will build. >> Cabal doesn't give this guarantee, either, since it allows you to >> depend on just network or on network>x. > > Indeed. That's why I was careful not to say that Cabal gives you > the guarantee, only that it's easy to achieve it. True, it's easy to specify. But IIUC, if you do so you have to update your package whenever any of the packages you depend on changes even if that change doesn't affect you. This is a very high (if not prohibitive) cost and one which the autoconf model doesn't force on you. >>> Both systems are flawed, but neither fundamentally. For Cabal I >>> think it would be interesting to look into using more precise >>> dependencies (module.identifier::type, rather than package- >>> version) and have them auto-generated. But this has difficult >>> implications: implementing cabal-install's installation plans >>> becomes much harder, for example. >> Interesting. From our previous discussion I got the impression that >> you wouldn't like something like this. :-) > > Sorry for giving that impression. Yes I'd like to solve the > problems that Cabal dependencies have, but I don't want the solution > to be too costly - first-class interfaces seem too heavyweight to > me. But I do agree with most of the arguments you gave in their > favour. I'm not sure what you mean by first-class interfaces. Surely, if you specify the interfaces you depend on you'll want to share and reuse those specifications. Roman From marlowsd at gmail.com Fri Aug 29 04:37:20 2008 From: marlowsd at gmail.com (Simon Marlow) Date: Fri Aug 29 04:35:56 2008 Subject: Build system idea In-Reply-To: <20080828221615.GB15616@sliver.repetae.net> References: <48A161DA.3010106@gmail.com> <061FA30C-4326-4B65-A80F-096593C81D6C@cse.unsw.edu.au> <20080827100458.GQ15616@sliver.repetae.net> <1219833910.24846.138.camel@localhost> <20080827131324.GR15616@sliver.repetae.net> <1219871939.24846.206.camel@localhost> <20080828022638.GY15616@sliver.repetae.net> <48B6AF34.2010601@gmail.com> <20080828221615.GB15616@sliver.repetae.net> Message-ID: <48B7B540.9080605@gmail.com> John Meacham wrote: > On Thu, Aug 28, 2008 at 02:59:16PM +0100, Simon Marlow wrote: >> The important thing about Cabal's way of specifying dependencies is that >> they can be made sound with not much difficulty. If I say that my >> package depends on base==3.0 and network==1.0, then I can guarantee that >> as long as those dependencies are present then my package will build. >> ("but but but..." I hear you say - don't touch that keyboard yet!) > > I can easily achieve this with autoconf or even nothing, I can simply do > a test to see if a system is running fedora core 9 using ghc 6.8.2 and > be assured that my package will build properly. But this misses the > entire point, I want my package to build not on my exact system, I want > it to build on _other_ peoples systems. People running with compilers and > libraries and on operating systems I never heard of. But you can only do that by carefully enumerating all the dependencies of your code. autoconf doesn't help you do that - you end up underspecifying the dependencies. Cabal makes you overspecify. It's a soundness/completeness thing: Cabal is sound(*1), autoconf is complete(*2). You complain that Cabal is incomplete and I complain that autoconf is unsound. I'd like to make Cabal's dependency specs more complete, but I don't want to make it unsound. (*1) as long as you specify dependencies with both upper and lower bounds (*2) as long as you don't overspecify dependencies I'd be interested in discussing how to improve Cabal's dependency specifications, if you have any thoughts on that. > Again, I would like to see this as another option. I think there are > interesting ideas in cabal about configuration management. But there > needs to be room for alternates including old standby's like autoconf autoconf isn't suitable as a replacement for Cabal's dependency specifications, because it doesn't specify dependencies. I couldn't use an autoconf-configured package with cabal-install, for exmaple. >> To generate a distro package from an autoconf package either the package >> author has to include support for that distro, or a distro packager has >> to write specific support for that package. There's no way to do generic >> autoconf->distro package generation, like there is with Cabal. > > In cabal you only get it because you convinced the cabal people to put > in code to support your distro. Which isn't much different than asking > the package manager too. False! All of the distro packaging tools for Cabal are separate entities build using the Cabal library. > and there are many automatic package managers for autoconf style > packages. > > http://www.toastball.net/toast/ is a good one, it even downloads > dependencies from freshmeat when needed. in fact, your projects can > probably be auto installed by 'toast projectname' and you didn't even > know it! As I understand it, toast doesn't download and build dependencies, you have to know what the dependencies are. (maybe I'm wrong, but that's the impression I got from looking at the docs, and if it *does* know about dependencies, I'd like to know how). > http://encap.org/ - one I use on pretty much all my systems. since it is > distro independent. Again, dependencies are not tracked automatically, you (or someone else) have to specify them by hand. >> That's the tradeoff - but there's still nothing stopping you from using >> autoconf and your own build system instead if you need to! > > But it is a false tradeoff. the only reason one needs to make that > tradeoff is because cabals design doesn't allow the useful ability to > mix-n-match parts of it. I would prefer to see cabal improved so I _can_ > use its metadata format, its configuration manager for simple projects, > autoconf's for more complex ones (with full knowledge of the tradeoffs) > and without jumping through hoops. No, it is a tradeoff. We want packages on Hackage to be automatically installable by cabal-install, for one thing. That means they have to say what their dependencies are. > The fact is that it _is_ a big deal to replace cabal is the main issue I > have. switching involves changing your build system completely. you > can't replace just parts of it easily. Or integrate cabal from the > bottom up rather than the top down. And it wants to be the _one true_ > build system in your project. The counterexample again is the GHC build system, we integrate make and Cabal and autoconf, and we're planning to do more of it with make. Have you thought about how to change Cabal to do what you want? It's only code, after all :-) > I'd like to see a standardized meta-info format for just haskell > libraries, based on the current cabal format without the cabal specific > build information. (this is what jhc uses, and franchise too I think) > Just like the 'lsm' linux software map files. Preferably YAML, we are > pretty darn close already and it will give us parsers in many languages > for free. We already have several tools that can use the meta-info, jhc, > cabal, franchise, hackage (for the web site layout) so it seems like > abstracting it from the build info would be a useful step in the right > direction. I think we considered YAML, but I don't remember off-hand what the arguments against were. Maybe someone else knows? Cheers, Simon From marlowsd at gmail.com Fri Aug 29 04:37:50 2008 From: marlowsd at gmail.com (Simon Marlow) Date: Fri Aug 29 04:36:19 2008 Subject: Build system idea In-Reply-To: <4D6E0358-93BC-48FA-8C66-EE982606C3EA@ece.cmu.edu> References: <48A161DA.3010106@gmail.com> <061FA30C-4326-4B65-A80F-096593C81D6C@cse.unsw.edu.au> <20080827100458.GQ15616@sliver.repetae.net> <1219833910.24846.138.camel@localhost> <20080827131324.GR15616@sliver.repetae.net> <1219871939.24846.206.camel@localhost> <20080828022638.GY15616@sliver.repetae.net> <48B6AF34.2010601@gmail.com> <638ABD0A29C8884A91BC5FB5C349B1C32AE8697FFD@EA-EXMSG-C334.europe.corp.microsoft.com> <11074408-113F-4BB6-9CA5-4E21F5B2CB16@gmail.com> <4D6E0358-93BC-48FA-8C66-EE982606C3EA@ece.cmu.edu> Message-ID: <48B7B55E.20909@gmail.com> Brandon S. Allbery KF8NH wrote: > On 2008 Aug 28, at 22:00, Sterling Clover wrote: >> We do have, although not with easy access, an additional declarative >> layer "built in" 90% of the time as configuration as type signature. > > Sure? I think it's easier than you think: someone's already written > code to extract the information from .hi files (and indeed ghc will dump > it for you: ghc --dump-iface foo.hi). In theory there could be a > master dictionary of these hosted on hackage, collected from each > package's own dictionary, and a given package's dependencies could be > computed with high accuracy from it. It's a good idea, but conditional compilation makes it quite a bit harder. Cheers, Simon From igloo at earth.li Fri Aug 29 12:50:25 2008 From: igloo at earth.li (Ian Lynagh) Date: Fri Aug 29 12:48:50 2008 Subject: Version control systems In-Reply-To: <5F93330D-CE2C-4304-A39F-7C67C3B9A271@cse.unsw.edu.au> References: <404396ef0808141534i65ceae28ud23186d3f845714@mail.gmail.com> <83BF150C-20EA-48AA-8C1B-BFC8B6CA71EB@cse.unsw.edu.au> <916b84820808141712t18d87a07v47bf7be012cd7725@mail.gmail.com> <26D36D0E-3A57-4DF2-8D9E-07A876B12DE5@cse.unsw.edu.au> <48A564D4.3000806@charter.net> <9d4d38820808150501n17c8d56g730dc2b5d4e99126@mail.gmail.com> <20080815143840.GB9938@matrix.chaos.earth.li> <20080818092840.GA25432@matrix.chaos.earth.li> <5F93330D-CE2C-4304-A39F-7C67C3B9A271@cse.unsw.edu.au> Message-ID: <20080829165024.GA6922@matrix.chaos.earth.li> On Thu, Aug 28, 2008 at 04:31:16PM +1000, Manuel M T Chakravarty wrote: > Ian Lynagh: > >On Mon, Aug 18, 2008 at 12:21:47PM +1000, Manuel M T Chakravarty > >wrote: > >>From what you are saying, it seems that one "advantage" of git (in- > >>place branch switching) is not going to be useful to GHC in any case > > > >Yes. > > > >>(because we use nested repositories). > > > >That does make it harder, but the main problem is that switching > >between > >branches changes the timestamp of files that differ, meaning the build > >system thinks that recompilation needs to be done. > > > >Also, if you have 2 in-place branches of GHC then only one of them can > >be built at any one time, as they share a working directory. > > That doesn't sound like GHC-specific issues. So, if inplace branches > are useful for other projects -such as the Linux kernel- why shouldn't > it be useful for us? I don't know. Git people, can you fill us in please? Thanks Ian From marco-oweber at gmx.de Sat Aug 30 05:06:26 2008 From: marco-oweber at gmx.de (Marc Weber) Date: Sat Aug 30 05:04:52 2008 Subject: Build system idea, what about a "magic knowledge / refactoring" database? In-Reply-To: <20080827131324.GR15616@sliver.repetae.net> References: <48A161DA.3010106@gmail.com> <061FA30C-4326-4B65-A80F-096593C81D6C@cse.unsw.edu.au> <20080827100458.GQ15616@sliver.repetae.net> <1219833910.24846.138.camel@localhost> <20080827131324.GR15616@sliver.repetae.net> Message-ID: <20080830090626.GC7458@gmx.de> Hi John, I've extracted among others two things you don't like too much about cabal: a) having to specify build dependencies because they may change (eg example split base or different libraries poviding network interfaces ..) b) Cabal can't do everything easily. Examples are the multi stage system of ghc or wxWidgets ... Can't say much to this point. For my needs cabal has been enough and packaging many package for NixOs has been easy (except adding foreign C lib dependencies) You would also prefer a build command which does never change solving the problem that you Setup.hs files maybe can't be read by Cabal vesrions of the future. You'd like to have a cabal independant package description so you can extract information easily? Maybe I got some things not right here.. Anyway, how does a package description look like which would satisfy the write once, let one true buildsystem build my package on foregin architectures, machines, distros without having me to change network to jhc-network or such? And probably without the burden for implementors to have to provide a network-1.0 compatible interface ? Let's talk about an example: module Main where import System.IO import ClassProvidingShowDerivedAB data A = ... {- derive .. - } main = do printLn $ showDerivedA $ A ... printLn $ showDerivedB $ A ... So the description must contain that we need - DrIft or the derive library (assuming that the derive library can read Drift syntax) - a foreign module (probably called ClassProvidingShowDerivedAB) providing showDerivedAB of type (A .. -> String) - a foreign module (probably called System.IO) providing printLn of type (String :: IO ()) where "a foreign module" may also mean or any other set of modules exporting the given functions.. So a configure system should find packages containing those functions beeing used and should know (or be able to figure out itself) that ClassProvidingShowDerivedAB has been split into ClassProvidingShowDerivedA ClassProvidingShowDerivedB on some systems? The type system of haskell will be able to give you much better matches compared to looking for C/C++ interfaces, but String -> IO () is not very uniq.. So how can this dependency be expressed? Only consider package dependencies having the word "network" in either its name or description? You could ask the configure system to test all functions String -> IO () wether they have the desired behaviour (hoping that none is implemnted as showDerivedA = const $ removeRecursive "/").. Anyway it would be quite interesting to see wether we can write an application guessing dependencies this way.. However I don't like this to be done automatically. Then the burden of writing the dependencies into a description file would even become smaller. If we want a package be buildable on a time frame of -10 years (past) -> now -> + 10 years (future) either the configure script or the configure system can check for different substitutes or versions which did exsist from -10 years in the past up to now. However we can't know the changes beeing made in the future or wether different substitutes will become availible.. However some "magic knowledge" could know about my lib and its dependencies at publication and know about changes having been made to dependencies up to now. Then it could try refactoring the published code to fit current versions of the libraries.. In the future maybe this magic knowledge can be found in darcs patches (it alread provides support to changing names to some degree..) or it could be collected by volunteers. Changes which could be resolved automatically are renaming , merging and splitting of functions or modules, refactorings such as adding additional parameters to functions etc.. This magic knowledge could be updated by running a tool such as autoreconf or whatsover.. I even think this could work quite well for if you have kind of package database such as hackage knowing about interface changes from package xx-1.0 to xx-2.0. But it would be hard to implement a refactoring tool which can refactor source containing some #ifdefs ? Wait, we could throw away many #ifdef GHC_VERSION > or < version x.y because the system would know about the differences? To uniqely define a set of transformations of your code which has been written using set of dependencies A so that it can be compiled on another system B you need something like a *.cabal file again to tell the nice configure and rewrite engine where to start.. This could look like this network-1.0 from hackage HaXmL git repo hash XXYYZZ Then you could tell the magic tool that instead of network-1.0 jhc-network-0.8 can be tried.. I would really appriciate such a magic tool knowing abouth thousands of changes/ refactorings a) if it knows a transformation I can just run it and compile b) if it knows the difference but there is no transformation maybe there is a comment helping me fixing the trouble faster Such a hint could look like: From now on there is a lazy and a strict variant, so import either X or Y. Or functions W has been removed, use lib K or L instead. c) The person doing the initial change (breaking things) knows most about the change and knows best how to tell people what to do.. Even if i didn't you can upload a transformation to save other peoples time.. I think this is the way to go in the long run: Create a huge database of refactorings either giving you hints how to make a package compile on a different system or maybe even applying some of them automatically. With some time this has the chance to become some "old deep" knowledge as it is burried in autotools now ? Anyway implementing this would be a lot of work put might pay of one day. Of course this applies not only to haskell systems.. Hopefully it will not result in breakages occur more often because they will become cheaper? What do you think? Sincerly Marc Weber From s.clover at gmail.com Sat Aug 30 14:53:19 2008 From: s.clover at gmail.com (Sterling Clover) Date: Sat Aug 30 14:51:46 2008 Subject: Where STM is unstable at the moment, and how we can fix it Message-ID: This email is inspired by the discussion here: http:// hackage.haskell.org/trac/ghc/ticket/2401 As the ticket discusses, unsafeIOToSTM is, unlike unsafePerformIO or unsafeInterleaveIO, genuinely completely unsafe in that there is no way to use it such that a segfault or deadlock is not at least somewhat encouraged. The code attached to the ticket creates a deadlock solely through using it to write to stdout. But, for the same reason that unsafeIOToSTM is unstable, unsafeInterleaveIO now is very unstable as well -- conceivably, data generated from functions with lazy IO (including those in the prelude) could cause deadlocks within STM, and even segfaults. In summary, a "validation" step is performed on all threads inside atomically blocks during garbage collection. This validation step will, on encountering invalid threads (i.e. ones which should be rolled back) immediately kill them dead and retry. This is different than the implementation described in the STM paper, where rollbacks only occur on commit. However, it does add a measure of efficiency. The problem is that the validation code disregards exception handlers, since rollback is not an exception, and so anything embedded in STM that brackets an IO action, for example, can be rolled back without the final part of the exception even being called. As Simon M. notes, the obvious solution would be to turn rollbacks into regular exceptions, but this would open a number of cans of worms. A start, though not sufficient, would be for stm validation to respect blocked status -- not to block on it, obviously, but simply to refuse to rollback a transaction within it. Validation on GC is, after all, only an efficiency trick and implementation detail, and if it lets the occasional invalid transaction stand due to its blocked status, that transaction will simply be cleaned up later anyway. A more thorough solution would be, as I suggest at the end of the ticket, to add a new primitive with similar semantics to block -- blockRollback, of type STM () -> STM (). Anything that took place within blockRollback could not be stopped by validation. Finally, we could "split the difference" between block and blockRollback, by simply setting a rollbackBlocked flag on a *top level* invocation of block within STM, and thenceforth, not unsetting it until that block is exited, regardless of calls to unblock nested inside. This would effectively, without introducing a new primitive, ensure that rollback did not disrupt things terribly, and thus would be the solution that handled the lazyIO issue the best as well. There are lots of interesting applications of STM that require the ability to extend its semantics. To do this is going to require unsafeIOToSTM, just as unsafePerformIO is used on occasion as a low level tool to create safer and better things on top of (or as unsafeCoerce is, for that matter). However, the current state of STM means that writing these extensions of STM semantics safely is 100% impossible. I'm not sure which, if any, of the solutions that I'm presenting seem the most reasonable. However, without some sort of resolution for this issue, STM is far less powerful and useful than it can and should be. --Sterl.