RE: recommended build system
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 -, 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: [EMAIL PROTECTED] [mailto:glasgow-haskell-users- [EMAIL PROTECTED] On Behalf Of Frederik Eaton Sent: 04 December 2005 00:46 To: glasgow-haskell-users@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@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
Re: recommended build system
Would I be the only user of the nightly binary snapshots? Frederik On Fri, Dec 09, 2005 at 09:23:16AM -, 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 -, 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: [EMAIL PROTECTED] [mailto:glasgow-haskell-users- [EMAIL PROTECTED] On Behalf Of Frederik Eaton Sent: 04 December 2005 00:46 To: glasgow-haskell-users@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@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
RE: recommended build system
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 -, 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 -, 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: [EMAIL PROTECTED] [mailto:glasgow-haskell-users- [EMAIL PROTECTED] On Behalf Of Frederik Eaton Sent: 04 December 2005 00:46 To: glasgow-haskell-users@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@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
Re: Optimizations for mutable structures?
Simon Marlow [EMAIL PROTECTED] writes: 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? There is a big difference between C variables and IORefs. For one thing, a C variable can have scope local to a procedure. If so, then the suggested transformation is entirely valid even in the presence of threads, because no other thread is permitted access to the local variable. M[fp+offset(x)] - v ... w - M[fp+offset(x)] === M[fp+offset(x)] - v ... w - v Global variables are more tricky, but I guess it is probably common to permit the elimination of the 'read' there as well, even though technically this is unsafe in the presence of threads. My guess is that this behaviour is the cause of a lot of thread unsafeness in common C libraries however. M[address(x)] - v ... w - M[address(x)] === M[address(x)] - v ... w - v Haskell has neither local nor global variables in the same sense as C. IORefs more closely resemble C pointers. A pointer has indeterminate lifetime and scope. It can be passed around from procedure to procedure, and from thread to thread. There can be aliases to the same memory location in multiple other contexts. If I'm writing a hardware driver, the pointer address might be memory-mapped to a device register, in which case writing to that address and immediately reading back from it may not be an identity. I've certainly dealt with devices where the same hardware port when written to, expects control data, but when read from delivers status data. So here: M[M[x]] - v ... w - M[M[x]] it would be totally incorrect for the compiler to eliminate the read. Regards, Malcolm ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: New bug tracker: Trac
Am Dienstag, 6. Dezember 2005 17:42 schrieb Simon Marlow: [...] Developers with an account on cvs.haskell.org: please add yourselves as users on the Trac, so I can give out permissions to edit tickets. You create a user like this: - log in to cvs.haskell.org - htpasswd /srv/trac/ghc/trac.htpasswd username - type your password when prompted - let me know when you've done this Done! Cheers, S. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: recommended build system
$ 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 ... Frederik On Fri, Dec 09, 2005 at 09:23:16AM -, 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 -, 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: [EMAIL PROTECTED] [mailto:glasgow-haskell-users- [EMAIL PROTECTED] On Behalf Of Frederik Eaton Sent: 04 December 2005 00:46 To: glasgow-haskell-users@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@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
