- Glasgow-haskell-users

RE: Bootstrapping with HC files
by Simon Marlow 13 Dec '05

13 Dec '05

On 12 December 2005 22:47, Donald Bruce Stewart wrote: > andrew: >> I run a source based linux distro called Heretix, and I want to make >> a ghc package which will install with or without an existing ghc. At >> the moment, we supply a binary-ghc package, whch is a prerequisite >> of the from-source ghc package. >> >> It seems to me that I can prepare HC tarballs for my target >> platforms (x86, x86_64) which will remove the need for the >> ghc-binary package. My questions: >> >> 1) Can I produce 'registered' hc files? The build manual bangs on >> about cross compiling unregistered hc files, which isn't really what >> I need. >> >> 2) Would a ghc built from registered hgc files every bit as good and >> complete as a normally bootstrapped ghc? > > Yes, the OpenBSD versions of GHC build from registerised .hc tar > balls. It's fast. > > If you're interested in this path, check out: > http://www.openbsd.org/cgi-bin/cvsweb/ports/lang/ghc/ That port is for 6.2.2 - do you have a 6.4.1 port too? Many thanks for keeping the .hc bootstrapping route working, BTW. It's a great help. Cheers, SImon

1 0

Bootstrapping with HC files
by Andrew Walrond 13 Dec '05

13 Dec '05

I run a source based linux distro called Heretix, and I want to make a ghc package which will install with or without an existing ghc. At the moment, we supply a binary-ghc package, whch is a prerequisite of the from-source ghc package. It seems to me that I can prepare HC tarballs for my target platforms (x86, x86_64) which will remove the need for the ghc-binary package. My questions: 1) Can I produce 'registered' hc files? The build manual bangs on about cross compiling unregistered hc files, which isn't really what I need. 2) Would a ghc built from registered hgc files every bit as good and complete as a normally bootstrapped ghc? If 1) and 2) then 3) Why don't you guys supply hc tarballs for bootstrapping on common platforms? They would seem to be rather more versatile than the usual rpms and binary tarballs. Thanks in advance! Andrew Walrond

4 5

Project options for GHC
by Iavor Diatchki 12 Dec '05

12 Dec '05

Hello, I have been using the .ghci file with GHCi to set global options for my project and I find it very useful. The kind of options I put there are: where to put .hi/.o files, what warnings to produce, where to look for code. etc. It works great. I was thinking that it would be very convenient to have the same ability when using 'ghc --make', because at the moment I have a number of the same options duplicated in my Makefile. Also, often I find myslef wanting to compile just one file (and all of its dependents), because GHCi tends to be a bit slow at compiling things, but is quite fast at loading object code. I can do this using 'ghc --make', but I also need to specify all the additional project options. I realize that I can achieve what I want with a little shell script, but a ghc-supported configuration file would be more portable and simpler to use. -Iavor

2 1

RE: recommended build system
by Simon Marlow 12 Dec '05

12 Dec '05

On 12 December 2005 18:49, Frederik Eaton wrote: > $ ghc -pgml gcc -pgmP "gcc -E -undef -traditional" -pgmc gcc --make > Matrix.hs -o matrix Chasing modules from: Matrix.hs > [1 of 2] Compiling Fu.Prepose ( Fu/Prepose.hs, Fu/Prepose.o ) > ghc-6.5.20051208: could not execute: gcc-3.4.3 > > Maybe a more informative error message would be a useful feature as > well. Sorry, also add -pgma gcc. (or wait for tonight's build, which won't have gcc-3.4.3 hardwired). If it still complains, send us the -v output. Cheers, Simon > Frederik > > On Mon, Dec 12, 2005 at 02:28:34PM -0000, Simon Marlow wrote: >> On 10 December 2005 05:08, Frederik Eaton wrote: >> >>> $ ghc -pgmc gcc --make Matrix.hs -o matrix >>> Chasing modules from: Matrix.hs >>> [1 of 2] Compiling Fu.Prepose ( Fu/Prepose.hs, Fu/Prepose.o ) >>> ghc-6.5.20051208: could not execute: gcc-3.4.3 >>> >>> Hard-coding things is ... not ... nice ... >> >> You also need -pgml gcc, and probably -pgmP "gcc -E -undef >> -traditional". >> >> Cheers, >> Simon

2 1

RE: recommended build system
by Simon Marlow 12 Dec '05

12 Dec '05

On 10 December 2005 05:08, Frederik Eaton wrote: > $ ghc -pgmc gcc --make Matrix.hs -o matrix > Chasing modules from: Matrix.hs > [1 of 2] Compiling Fu.Prepose ( Fu/Prepose.hs, Fu/Prepose.o ) > ghc-6.5.20051208: could not execute: gcc-3.4.3 > > Hard-coding things is ... not ... nice ... You also need -pgml gcc, and probably -pgmP "gcc -E -undef -traditional". Cheers, Simon

2 1

instance inference
by Ross Paterson 12 Dec '05

12 Dec '05

I'm puzzled that the following is accepted. Is some sort of greatest fixed point computation used for instances? {-# OPTIONS_GHC -fglasgow-exts #-} module M where class C a b where c :: a -> b -> Bool instance C b b => C (Maybe a) b where c x y = c y y f :: Maybe a -> Bool f x = c x x

1 0

RE: recommended build system
by Simon Marlow 10 Dec '05

10 Dec '05

The nightly binary snapshots for x86/Linux are currently hard-wired to use gcc-3.4.3, because I occasionally change gcc versions to make sure things are still working. I'll change it back to gcc. To workaround it you can add '-pgmc gcc' to the command line. Cheers, Simon On 09 December 2005 03:26, Frederik Eaton wrote: > Does this depend on a certain version of gcc? > > $ ghc -M --make Matrix.hs -o matrix > Chasing modules from: Matrix.hs > [1 of 2] Compiling Fu.Prepose ( Fu/Prepose.hs, Fu/Prepose.o ) > ghc-6.5.20051207: could not execute: gcc-3.4.3 > > I'm wondering why it is trying to execute something which isn't in my > path... > > Frederik > > On Mon, Dec 05, 2005 at 10:51:19AM -0000, Simon Peyton-Jones wrote: >> Simon fixed this recently. The GHC HEAD build will not re-link with >> --make if none of the object files have changed. >> >> Simon >> >>> -----Original Message----- >>> From: glasgow-haskell-users-bounces(a)haskell.org >>> [mailto:glasgow-haskell-users- bounces(a)haskell.org] On Behalf Of >>> Frederik Eaton >>> Sent: 04 December 2005 00:46 >>> To: glasgow-haskell-users(a)haskell.org >>> Subject: recommended build system >>> >>> Hi all, >>> >>> I'm looking for a build system for my projects which will correctly >>> handle all of ghc's dependencies. I.e. every time I ask it to >>> rebuild an output file, it will only do the minimum amount of >>> compilation necessary. This is important to me because "ghc --make" >>> and cabal currently (AFAICT) will always relink an executable even >>> when it is not necessary to do so; thus if I have a project with a >>> bunch of libraries and executables, the cost of making a small >>> modification and recompiling is very high, and it becomes hard to >>> maintain focus on my projects after the initial design phase. I've >>> just been playing around with GNU coreutils and was impressed with >>> how well the build system works, and how fast the recompilation >>> goes. >>> >>> Anyway, the system that darcs uses seems to work pretty well, >>> should I copy that, or do people recommend other alternatives? >>> >>> Frederik >>> _______________________________________________ >>> Glasgow-haskell-users mailing list >>> Glasgow-haskell-users(a)haskell.org >>> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users >> _______________________________________________ >> Glasgow-haskell-users mailing list >> Glasgow-haskell-users(a)haskell.org >> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users >> > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users(a)haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

2 2

RE: Optimizations for mutable structures?
by Simon Marlow 09 Dec '05

09 Dec '05

On 07 December 2005 16:38, Malcolm Wallace wrote: > "Simon Marlow" <simonmar(a)microsoft.com> writes: > >> I should have said that if 'acts' blocks, then the transformation is >> invalid. > > Well that is exactly what I was assuming when I said that the > transformation is invalid. In the general case, for some arbitrary > actions between the write and the read (excluding another write of > course), there is no guarantee that the IORef remains unmodified. This is an analysis that's performed all the time in C compilers, it's quite straightforward to do a good approximation. One simple algorithm is: a store can be forwarded to a matching read as long as there are no intervening writes that may alias, or function calls. C does this and C has threads, so what's the difference? > If you want to restrict the intermediate actions to be non-blocking, > such that another thread cannot run, then that is an extra (and > significant) proof obligation. > > And AFAICS your non-blocking argument only applies to co-operative > scheduling. If pre-emption is permitted (e.g. interrupt-handling), > then all bets are off, because an arbitrary thread could write to > the IORef at any moment. No, that is exactly what I disagree with. Faced with non-derministic semantics, the compiler does *not* have to preserve all possible outcomes. In other words, it does not have to assume that an IORef can be modified between any two arbitrary instructions. If we had to assume this, then indeed all bets would be off, and C compilers would be very much more restricted in what optimisations they could perform. I don't know how I can explain this a different way - it seems pretty obvious to me, but I'm probably not explaining it well :-/ You cut the example from my message - did you agree with the conclusion? Or the conclusion I made from Ian's example? Cheers, Simon

7 7

RE: recommended build system
by Simon Marlow 09 Dec '05

09 Dec '05

This doesn't affect the source snapshots, only the Linux/x86 binaries. I think there are more people using the sources and the Linux/x86_64 binaries. Cheers, Simon On 09 December 2005 10:26, Frederik Eaton wrote: > Would I be the only user of the nightly binary snapshots? > > Frederik > > On Fri, Dec 09, 2005 at 09:23:16AM -0000, Simon Marlow wrote: >> The nightly binary snapshots for x86/Linux are currently hard-wired >> to use gcc-3.4.3, because I occasionally change gcc versions to make >> sure things are still working. I'll change it back to gcc. To >> workaround it you can add '-pgmc gcc' to the command line. >> >> Cheers, >> Simon >> >> On 09 December 2005 03:26, Frederik Eaton wrote: >> >>> Does this depend on a certain version of gcc? >>> >>> $ ghc -M --make Matrix.hs -o matrix >>> Chasing modules from: Matrix.hs >>> [1 of 2] Compiling Fu.Prepose ( Fu/Prepose.hs, Fu/Prepose.o ) >>> ghc-6.5.20051207: could not execute: gcc-3.4.3 >>> >>> I'm wondering why it is trying to execute something which isn't in >>> my path... >>> >>> Frederik >>> >>> On Mon, Dec 05, 2005 at 10:51:19AM -0000, Simon Peyton-Jones wrote: >>>> Simon fixed this recently. The GHC HEAD build will not re-link >>>> with --make if none of the object files have changed. >>>> >>>> Simon >>>> >>>>> -----Original Message----- >>>>> From: glasgow-haskell-users-bounces(a)haskell.org >>>>> [mailto:glasgow-haskell-users- bounces(a)haskell.org] On Behalf Of >>>>> Frederik Eaton Sent: 04 December 2005 00:46 >>>>> To: glasgow-haskell-users(a)haskell.org >>>>> Subject: recommended build system >>>>> >>>>> Hi all, >>>>> >>>>> I'm looking for a build system for my projects which will >>>>> correctly handle all of ghc's dependencies. I.e. every time I ask >>>>> it to rebuild an output file, it will only do the minimum amount >>>>> of compilation necessary. This is important to me because "ghc >>>>> --make" and cabal currently (AFAICT) will always relink an >>>>> executable even when it is not necessary to do so; thus if I have >>>>> a project with a bunch of libraries and executables, the cost of >>>>> making a small modification and recompiling is very high, and it >>>>> becomes hard to maintain focus on my projects after the initial >>>>> design phase. I've just been playing around with GNU coreutils >>>>> and was impressed with how well the build system works, and how >>>>> fast the recompilation goes. >>>>> >>>>> Anyway, the system that darcs uses seems to work pretty well, >>>>> should I copy that, or do people recommend other alternatives? >>>>> >>>>> Frederik >>>>> _______________________________________________ >>>>> Glasgow-haskell-users mailing list >>>>> Glasgow-haskell-users(a)haskell.org >>>>> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users >>>> _______________________________________________ >>>> Glasgow-haskell-users mailing list >>>> Glasgow-haskell-users(a)haskell.org >>>> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users >>>> >>> _______________________________________________ >>> Glasgow-haskell-users mailing list >>> Glasgow-haskell-users(a)haskell.org >>> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

1 0

RE: recommended build system
by Simon Peyton-Jones 09 Dec '05

09 Dec '05

Simon fixed this recently. The GHC HEAD build will not re-link with --make if none of the object files have changed. Simon | -----Original Message----- | From: glasgow-haskell-users-bounces(a)haskell.org [mailto:glasgow-haskell-users- | bounces(a)haskell.org] On Behalf Of Frederik Eaton | Sent: 04 December 2005 00:46 | To: glasgow-haskell-users(a)haskell.org | Subject: recommended build system | | Hi all, | | I'm looking for a build system for my projects which will correctly | handle all of ghc's dependencies. I.e. every time I ask it to rebuild | an output file, it will only do the minimum amount of compilation | necessary. This is important to me because "ghc --make" and cabal | currently (AFAICT) will always relink an executable even when it is | not necessary to do so; thus if I have a project with a bunch of | libraries and executables, the cost of making a small modification and | recompiling is very high, and it becomes hard to maintain focus on my | projects after the initial design phase. I've just been playing around | with GNU coreutils and was impressed with how well the build system | works, and how fast the recompilation goes. | | Anyway, the system that darcs uses seems to work pretty well, should I | copy that, or do people recommend other alternatives? | | Frederik | _______________________________________________ | Glasgow-haskell-users mailing list | Glasgow-haskell-users(a)haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

2 2