Re: Porting to DragonFly BSD
On November 9, 2009 12:39:25 Goetz Isenmann wrote: > On Mon, Nov 09, 2009 at 10:44:47AM +, Simon Marlow wrote: > > We should get these patches into GHC. Most of them look > > straightforward, but I'm slightly suspicious of this: > > > > -STANDARD_OPTS += -DCOMPILING_RTS > > +STANDARD_OPTS += -DCOMPILING_RTS -D_POSIX_VERSION=199309 > > > > why was that necessary? > > Good that you ask. Can't remember why it was necessary back in april > to build ghc-6.10.2 on dragonfly-2.2.1. Cannot reproduce the problem > today with ghc-6.10.4 on dragonfly-2.4.1. > > I am glad, that we do not need this define any more. I think it was a > ugly workaround at best. I'm not sure about dragonfly, but there are a bunch of similar options for glibc under Linux. For example, "man feature_test_macros" says you need to define _POSIX_C_SOURCE to 199309 or greater to use POSIX.1b functionality. Cheers! -Tyson 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
GHCI :reload module without erasing previous data
I have a module that loads several dozen megabytes of static data into memory. This module is working properly. I have another module that I'm developing to analyze that data. As I make iterations on the analysis module, I would like it if the data loaded by the data module could stay in memory. In GHCI, every time I reload a module, it clears whatever data I have set with the "let" command. Is there a way to persist that data across calls to :reload, or is there an altogether different workflow I should be using for this? ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Porting to DragonFly BSD
On Mon, Nov 09, 2009 at 10:44:47AM +, Simon Marlow wrote: > We should get these patches into GHC. Most of them look > straightforward, but I'm slightly suspicious of this: > > -STANDARD_OPTS += -DCOMPILING_RTS > +STANDARD_OPTS += -DCOMPILING_RTS -D_POSIX_VERSION=199309 > > why was that necessary? Good that you ask. Can't remember why it was necessary back in april to build ghc-6.10.2 on dragonfly-2.2.1. Cannot reproduce the problem today with ghc-6.10.4 on dragonfly-2.4.1. I am glad, that we do not need this define any more. I think it was a ugly workaround at best. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Three patches for cabal
> I think in the end I'm with Ian on his suggestion that we should allow > the "No" prefix to invert an extension. This would help in this case and > also let us handle things better when the default extensions change. I too agree with this position for the long run. /Niklas ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Three patches for cabal
On Fri, 2009-11-06 at 01:13 +0100, Niklas Broberg wrote: > > Can someone please comment on these two proposed changes. I agree with > > Niklas but I'm a bit reluctant to apply the patches without at least > > some sign of agreement from someone else. > > > > Deprecating PatternSignatures seems uncontroversial, but the > > NoMonoPatBinds is potentially controversial. GHC essentially uses > > -XMonoPatBinds by default, even in H98 mode, and the user can use > > -XNoMonoPatBinds to restore H98 behaviour. Niklas's and my point is that > > the list of language extensions in Language.Haskell.Exceptions are > > differences from H98 so it should be MonoPatBinds to get the difference > > not NoMonoPatBinds to restore H98. > > > > In practise, since ghc uses MonoPatBinds by default it'd mean that > > people who want to get back to H98 would need to use: > > > > ghc-options: -XNoMonoPatBinds > > > > Because the extensions field is additive, not subtractive. Using the > > name MonoPatBinds allows other compilers to implement it without it > > having to be the default. > > I had a look at the source for cabal HEAD and was surprised to see > that this stuff had fallen by the wayside. What's holding it up? I > can't imagine that anyone would be against the deprecation of > PatternSignatures at least. I'd forgotten they were separate patches. I've applied the PatternSignatures one since that is indeed uncontroversial. I don't think the discussion on the other ones were conclusive yet. I think in the end I'm with Ian on his suggestion that we should allow the "No" prefix to invert an extension. This would help in this case and also let us handle things better when the default extensions change. Duncan ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Porting to DragonFly BSD
On 06/11/2009 23:25, Goetz Isenmann wrote: On Wed, Nov 04, 2009 at 03:08:27PM +, Colin Adams wrote: When GHC 6.12.1 is released, I'm going to have a go at porting it to DragonFly BSD (32-bit incarnation). Is the porting page on the wikiup-to-date? Maybe you could start with something like: $ curl -o ghc-6.10.4-3.tar.bz2 \ ; http://www.goetz-isenmann.de/dfly/ghc-6.10.4-3.tar.bz2 $ curl -o cabal http://www.goetz-isenmann.de/dfly/cabal $ tar xzf ghc-6.10.4-3.tar.bz2 -C /var/tmp/isenmann $ PATH=/var/tmp/isenmann/ghc-6.10.4-3/bin:$PATH $ ./cabal update $ ./cabal install --user cabal-install I have just recompiled this ghc with itself using the attached patches and --prefix=/var/tmp/isenmann on dragonfly 2.4.1 (32bit). The patches are only a stupid "do the same for dragonfly as for freebsd" with two exceptions AFAIR: (a) use -pthread not -lthr, and (b) this -D_POSIX_VERSION=199309 in rts/Makefile, that's most probably the wrong way to fix a (can't remember the details) build problem. Until now I had no time and energie to dig deeper into the problem [1], that looks to me, like rts/Linker cannot load any object file that references errno. My guess is, that for dragonflys "extern __thread int errno;" we do not only need to add a new case in rts/Linker.c but also need to generate different code for this thread local storage access. Great work. I've added Dragonfly BSD to the list of Tier 2 platforms: http://hackage.haskell.org/trac/ghc/wiki/Platforms Would you be willing to be the maintainer for GHC on Dragonfly? We should get these patches into GHC. Most of them look straightforward, but I'm slightly suspicious of this: -STANDARD_OPTS += -DCOMPILING_RTS +STANDARD_OPTS += -DCOMPILING_RTS -D_POSIX_VERSION=199309 why was that necessary? Cheers, Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Compiling to ANSI C
On 07/11/2009 18:48, Daniel Peebles wrote: You can use -fvia-C and -keep-hc-files but the generated C code is pretty platform-dependent (at least in terms of word sizes and so on... it may be possible to port across platforms with the same word sizes?), and probably won't help you cross-compile. It also doesn't look much like any c code any human would have written, and I think there are plans to deprecate the via-C compilation pathway eventually. If you are looking to add cross-compilation to GHC, the first thing I'd look at is detaching the choice of native code generator from the preprocessor and hooking it up to a front-end command-line option instead :) We already compile in all the NCG backends, so that should be quite straightforward. What's much harder is arranging the rest of your cross-compilation environment - assembler, linker etc., and making sure you're using the right configuration parameters from the target machine for the build. It's generally easier to get an unregisterised port working first, and then use that to bootstrap an NCG/registerised version. Someone on IRC (his username is dumael, not sure what his real name is) has already been working on an ARM native code generator for GHC recently. Interesting, I didn't know that. There's also the iPhone GHC port, which is unregisterised, I believe. >The recent LLVM back-end development should also make it pretty simple to generate code for other platforms (especially if we have a nice way to pass front-end options to the code generators) Definitely, I think that will be a nice side-effect of the LLVM backend. Cheers, Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
