Re: RHEL/EPEL 5 ghc packages
> please holler if you need help backporting 7.6 and 7.8 please :) It would be good to have repos for those too, I agree. What I would like to do in the future is to use Software Collections [1] to provide multiple versions of ghc, etc for RHEL in particular. With RHEL's long lifetime, providing just a single version of ghc seems inadequate. This should provide more flexibility and allow people to choose whether they want to use new ghc or to stick with an older version, or both. :) [1] https://fedorahosted.org/SoftwareCollections/ http://docs.fedoraproject.org/en-US/Fedora_Contributor_Documentation/1/html/Software_Collections_Guide/ > > https://admin.fedoraproject.org/updates/FEDORA-EPEL-2013-12484/ghc-7.0.4-45.3.el5,cabal-install-0.10.2-6.1.el5 > > > http://repos.fedorapeople.org/repos/petersen/ghc-7.4.2/ > ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: RHEL/EPEL 5 ghc packages
please holler if you need help backporting 7.6 and 7.8 please :) On Sun, Feb 9, 2014 at 8:49 PM, Jens Petersen wrote: > Hi, > > I wanted to mention some newer ghc builds I have made for RHEL5. > > EPEL5 currently has ghc-6.12.3 in stable, but I have built > ghc-7.0.4 which has been in EPEL5 testing now for over a month. > The update also includes cabal-install. I am planning to push it to > stable this month but I wanted to mention it first here as a heads-up. > > > https://admin.fedoraproject.org/updates/FEDORA-EPEL-2013-12484/ghc-7.0.4-45.3.el5,cabal-install-0.10.2-6.1.el5 > > Please report any problems with this in bugzilla: > > https://bugzilla.redhat.com/enter_bug.cgi?product=Fedora%20EPEL&component=ghc > > Jens > > ps Additionally I have a new ghc-7.4.2 repo for EPEL5 > (which should also work on RHEL6) and includes haskell-platform: > > http://repos.fedorapeople.org/repos/petersen/ghc-7.4.2/ > > which is a backport from Fedora 19. > Please report any problems with this directly to me. > > pps Later this year I plan to backport ghc-7.4.2 officially to EPEL6. > > ___ > 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
RHEL/EPEL 5 ghc packages
Hi, I wanted to mention some newer ghc builds I have made for RHEL5. EPEL5 currently has ghc-6.12.3 in stable, but I have built ghc-7.0.4 which has been in EPEL5 testing now for over a month. The update also includes cabal-install. I am planning to push it to stable this month but I wanted to mention it first here as a heads-up. https://admin.fedoraproject.org/updates/FEDORA-EPEL-2013-12484/ghc-7.0.4-45.3.el5,cabal-install-0.10.2-6.1.el5 Please report any problems with this in bugzilla: https://bugzilla.redhat.com/enter_bug.cgi?product=Fedora%20EPEL&component=ghc Jens ps Additionally I have a new ghc-7.4.2 repo for EPEL5 (which should also work on RHEL6) and includes haskell-platform: http://repos.fedorapeople.org/repos/petersen/ghc-7.4.2/ which is a backport from Fedora 19. Please report any problems with this directly to me. pps Later this year I plan to backport ghc-7.4.2 officially to EPEL6. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: 7.8.1, template haskell, and dynamic libraries
Actually, just to keep it even simpler, so nobody else is confused further: Cabal will *also* properly turn on dynamic builds for regular packages if GHC is dynamic, TemplateHaskell or not. So any library you compile will still work in GHCi as expected. So here's the breakdown: 1) Cabal 1.18 will handle dynamical GHCi correctly, including compiling things dynamically, however it must. 2) Per #1, libraries are compiled dynamically. This means libraries work in GHCi, just like they did. 3) -Executables- are statically linked by default, still. (But because of #1 and #2, it's very easy to turn on dynamic exes as well, without needing to recompile a lot.) 4) TemplateHaskell works as expected due to #1 and #2. But there is one caveat for executables, noted separately below. The caveat with TemplateHaskell is for executables: This is because if you end up with an executable that needs TH and profiling, Cabal must be aware of this. Why? Because GHCi cannot load *profiled* objects, only normal ones. So we must compile twice: once without profiling, and once with profiling. The second compilation will use the 'normal' objects, even though the final executable will be profiled. Cabal doesn't know to do this if it doesn't know TemplateHaskell is a requirement. Does this clear things up? My last message might give the impression some things aren't compiled dynamically, because I merely ambiguously referred to 'packages'. On Sun, Feb 9, 2014 at 2:37 PM, Austin Seipp wrote: > It is correct that Template Haskell now requires dynamic objects. > However, GHC can produce static and dynamic objects at the same time, > so you don't have to recompile a package twice (it's a big > optimization, basically). > > Furthermore, if TemplateHaskell is enabled as a requirement for a > package, and GHC is built dynamically, Cabal will do The Right Thing > by building the shared objects for the dependencies as well. It will > save time by doing so using -dynamic-too, if possible. This is because > it queries GHC before compilation to figure this out (you can run 'ghc > --info' with the 7.8.1 RC to see "GHC Dynamic" and "Supports > dynamic-too" fields.) > > Finally, if you simply run 'ghc Foo.hs' on a file that requires > TemplateHaskell, it will also switch on -dynamic-too for the needed > objects in this simple case. > > There is one caveat, if I remember correctly: if a package uses > TemplateHaskell, it must declare it as such in the Cabal file. This is > because Cabal does not parse the source to detect if TemplateHaskell > is needed in the dependency graph of the compiled modules. Only GHC > can do this reliably. If you don't specify TemplateHaskell as an > extension, Cabal might not do the right thing. This is noted in the > release notes: > >> Note that Cabal will correctly handle -dynamic-too for you automatically, >> especially when -XTemplateHaskell is needed - but you *must* tell Cabal you >> are using the TemplateHaskell extension. > > However, based on the other suggestions in the thread and confusion > around this, a big "Incompatible changes" section with this listed as > the first thing with clear detail would be a good idea. I'll do so. > > If something else is going on, please file a bug. > > On Sun, Feb 9, 2014 at 1:37 PM, George Colpitts > wrote: >> Yes, in general I think the doc needs a section: Incompatible changes. The >> hope is that you can take the release and just work as usual but when (for >> good reasons as in this release) it is not true is is important to have such >> a section. Another case that needs to be there is how to compile so you can >> load compile object files into ghci as what you did in 7.6.3 won't work in >> this release. >> >> >> On Sun, Feb 9, 2014 at 1:11 PM, Carter Schonwald >> wrote: >>> >>> Indeed. The problem is that many folks might have cabal config files that >>> explicitly disable shared. (For the compile times!). They might need clear >>> information about wiping that field. >>> >>> >>> On Sunday, February 9, 2014, Brandon Allbery wrote: On Sun, Feb 9, 2014 at 9:28 AM, Greg Horn wrote: > > Is --enable-shared off by default? It's supposed to be on by default in 7.8. That said, not sure how many people have played with ~/.cabal/config -- brandon s allbery kf8nh sine nomine associates allber...@gmail.com ballb...@sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net >>> >>> >>> ___ >>> 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 >> > > > > -- > Regards, > > Austin Seipp, Haskell Consultant >
Re: 7.8.1, template haskell, and dynamic libraries
Hi, Am Sonntag, den 09.02.2014, 14:37 -0600 schrieb Austin Seipp: > There is one caveat, if I remember correctly: if a package uses > TemplateHaskell, it must declare it as such in the Cabal file. This is > because Cabal does not parse the source to detect if TemplateHaskell > is needed in the dependency graph of the compiled modules. Only GHC > can do this reliably. If you don't specify TemplateHaskell as an > extension, Cabal might not do the right thing. This is noted in the > release notes: > > > Note that Cabal will correctly handle -dynamic-too for you automatically, > > especially when -XTemplateHaskell is needed - but you *must* tell Cabal you > > are using the TemplateHaskell extension. we need -dynamic-too also for everything that a user ever might want to load in GHCi, right? So doesn’t that already imply that Cabal should and will build libHS*so files always anyways? Greetings, Joachim -- Joachim “nomeata” Breitner m...@joachim-breitner.de • http://www.joachim-breitner.de/ Jabber: nome...@joachim-breitner.de • GPG-Key: 0x4743206C Debian Developer: nome...@debian.org signature.asc Description: This is a digitally signed message part ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: 7.8.1, template haskell, and dynamic libraries
It is correct that Template Haskell now requires dynamic objects. However, GHC can produce static and dynamic objects at the same time, so you don't have to recompile a package twice (it's a big optimization, basically). Furthermore, if TemplateHaskell is enabled as a requirement for a package, and GHC is built dynamically, Cabal will do The Right Thing by building the shared objects for the dependencies as well. It will save time by doing so using -dynamic-too, if possible. This is because it queries GHC before compilation to figure this out (you can run 'ghc --info' with the 7.8.1 RC to see "GHC Dynamic" and "Supports dynamic-too" fields.) Finally, if you simply run 'ghc Foo.hs' on a file that requires TemplateHaskell, it will also switch on -dynamic-too for the needed objects in this simple case. There is one caveat, if I remember correctly: if a package uses TemplateHaskell, it must declare it as such in the Cabal file. This is because Cabal does not parse the source to detect if TemplateHaskell is needed in the dependency graph of the compiled modules. Only GHC can do this reliably. If you don't specify TemplateHaskell as an extension, Cabal might not do the right thing. This is noted in the release notes: > Note that Cabal will correctly handle -dynamic-too for you automatically, > especially when -XTemplateHaskell is needed - but you *must* tell Cabal you > are using the TemplateHaskell extension. However, based on the other suggestions in the thread and confusion around this, a big "Incompatible changes" section with this listed as the first thing with clear detail would be a good idea. I'll do so. If something else is going on, please file a bug. On Sun, Feb 9, 2014 at 1:37 PM, George Colpitts wrote: > Yes, in general I think the doc needs a section: Incompatible changes. The > hope is that you can take the release and just work as usual but when (for > good reasons as in this release) it is not true is is important to have such > a section. Another case that needs to be there is how to compile so you can > load compile object files into ghci as what you did in 7.6.3 won't work in > this release. > > > On Sun, Feb 9, 2014 at 1:11 PM, Carter Schonwald > wrote: >> >> Indeed. The problem is that many folks might have cabal config files that >> explicitly disable shared. (For the compile times!). They might need clear >> information about wiping that field. >> >> >> On Sunday, February 9, 2014, Brandon Allbery wrote: >>> >>> On Sun, Feb 9, 2014 at 9:28 AM, Greg Horn wrote: Is --enable-shared off by default? >>> >>> It's supposed to be on by default in 7.8. That said, not sure how many >>> people have played with ~/.cabal/config >>> >>> -- >>> brandon s allbery kf8nh sine nomine >>> associates >>> allber...@gmail.com >>> ballb...@sinenomine.net >>> unix, openafs, kerberos, infrastructure, xmonad >>> http://sinenomine.net >> >> >> ___ >> 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 > -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: 7.8.1, template haskell, and dynamic libraries
Yes, in general I think the doc needs a section: Incompatible changes. The hope is that you can take the release and just work as usual but when (for good reasons as in this release) it is not true is is important to have such a section. Another case that needs to be there is how to compile so you can load compile object files into ghci as what you did in 7.6.3 won't work in this release. On Sun, Feb 9, 2014 at 1:11 PM, Carter Schonwald wrote: > Indeed. The problem is that many folks might have cabal config files that > explicitly disable shared. (For the compile times!). They might need > clear information about wiping that field. > > > On Sunday, February 9, 2014, Brandon Allbery wrote: > >> On Sun, Feb 9, 2014 at 9:28 AM, Greg Horn wrote: >> >>> Is --enable-shared off by default? >>> >> It's supposed to be on by default in 7.8. That said, not sure how many >> people have played with ~/.cabal/config >> >> -- >> brandon s allbery kf8nh sine nomine >> associates >> allber...@gmail.com >> ballb...@sinenomine.net >> unix, openafs, kerberos, infrastructure, xmonad >> http://sinenomine.net >> > > ___ > 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
Re: target audience for the binary distribution
On 14-02-08 01:33 PM, harry wrote: Who actually are "most users" for the bindist? Debian & derivatives have the latest GHC in the package repository No. The other pasture is not greener. The distro you don't use is not more up to date. Chinese proverb: all crows in the whole world are equally black. Debian and derivatives almost always have the wrong version. Wrong version means: * Lagging behind Haskell Platform. And Haskell Platform is already very conservative and has its own wait-and-see period. * If one version has a serious bug, then long after the bugfix version is released, Debian and derivatives still cling on to the bug. Here is a historical example: 6.12.1 had a serious bug, fixed in 6 months. Ubuntu 10.04 and 10.10 both provided 6.12.1, this means 12 months of living with the bug for you. (10.04's case was justifiable, 10.10's was inexcusable.) http://www.vex.net/~trebla/haskell/sicp.xhtml#ghc6121 I use the bindist. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: 7.8.1, template haskell, and dynamic libraries
Indeed. The problem is that many folks might have cabal config files that explicitly disable shared. (For the compile times!). They might need clear information about wiping that field. On Sunday, February 9, 2014, Brandon Allbery wrote: > On Sun, Feb 9, 2014 at 9:28 AM, Greg Horn > > > wrote: > >> Is --enable-shared off by default? >> > It's supposed to be on by default in 7.8. That said, not sure how many > people have played with ~/.cabal/config > > -- > brandon s allbery kf8nh sine nomine > associates > allber...@gmail.com > ballb...@sinenomine.net > unix, openafs, kerberos, infrastructure, xmonad > http://sinenomine.net > ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: 7.8.1, template haskell, and dynamic libraries
On Sun, Feb 9, 2014 at 9:28 AM, Greg Horn wrote: > Is --enable-shared off by default? > It's supposed to be on by default in 7.8. That said, not sure how many people have played with ~/.cabal/config -- brandon s allbery kf8nh sine nomine associates allber...@gmail.com ballb...@sinenomine.net unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: 7.8.1, template haskell, and dynamic libraries
Is --enable-shared off by default? On Feb 9, 2014 9:04 AM, "harry" wrote: > Michael Snoyman wrote > > When upgrading to a new version of GHC, you'll have to reinstall all of > > the > > packages anyway. You can't simply use GHC 7.6 compiled packages with your > > new GHC 7.8. > > This is probably the point at which it would be useful to know that all > this > recompilation will have to be done with dynamic libraries, to avoid having > to do it all a second time when the user tries to use templates. > > > > -- > View this message in context: > http://haskell.1045720.n5.nabble.com/7-8-1-template-haskell-and-dynamic-libraries-tp5743587p5743628.html > Sent from the Haskell - Glasgow-haskell-users mailing list archive at > Nabble.com. > ___ > 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
Re: 7.8.1, template haskell, and dynamic libraries
Michael Snoyman wrote > When upgrading to a new version of GHC, you'll have to reinstall all of > the > packages anyway. You can't simply use GHC 7.6 compiled packages with your > new GHC 7.8. This is probably the point at which it would be useful to know that all this recompilation will have to be done with dynamic libraries, to avoid having to do it all a second time when the user tries to use templates. -- View this message in context: http://haskell.1045720.n5.nabble.com/7-8-1-template-haskell-and-dynamic-libraries-tp5743587p5743628.html Sent from the Haskell - Glasgow-haskell-users mailing list archive at Nabble.com. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: 7.8.1, template haskell, and dynamic libraries
On Sun, Feb 9, 2014 at 10:30 AM, harry wrote: > Carter Schonwald wrote > > Yes. (And thence ghc itself is then invoked with dynamic or dynamic-too) > > > >> The docs for 7.8.1 say "Template Haskell must now load dynamic object > >> files, > >> not static ones". Does this mean that, if I'm using Template Haskell, > >> every > >> package which the templates depend on have to be built with > >> --enable-shared? > > Perhaps there should be a clear warning about this? If I've understood > correctly, anything using Template Haskell will break when upgrading to > 7.8, > until all the dependencies are reinstalled with --enable-shared. > > > When upgrading to a new version of GHC, you'll have to reinstall all of the packages anyway. You can't simply use GHC 7.6 compiled packages with your new GHC 7.8. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: 7.8.1, template haskell, and dynamic libraries
Carter Schonwald wrote > Yes. (And thence ghc itself is then invoked with dynamic or dynamic-too) > >> The docs for 7.8.1 say "Template Haskell must now load dynamic object >> files, >> not static ones". Does this mean that, if I'm using Template Haskell, >> every >> package which the templates depend on have to be built with >> --enable-shared? Perhaps there should be a clear warning about this? If I've understood correctly, anything using Template Haskell will break when upgrading to 7.8, until all the dependencies are reinstalled with --enable-shared. -- View this message in context: http://haskell.1045720.n5.nabble.com/7-8-1-template-haskell-and-dynamic-libraries-tp5743587p5743624.html Sent from the Haskell - Glasgow-haskell-users mailing list archive at Nabble.com. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
