Re: [ANNOUNCE] GHC 8.0.2 release candidate 1

Thanks Ben, this is great! Installing the binary on the Mac results in the following minor problem: /usr/bin/install -c -m 644 docs/users_guide/build-man/ghc.1 "/usr/local/share/man/man1" install: /usr/local/share/man/man1/ghc.1: No such file or directory make[1]: *** [install_man] Error 71

[ANNOUNCE] GHC 8.0.2 release candidate 1

Hello everyone, The GHC team is happy to (finally!) announce the first candiate of the 8.0.2 release of the Glasgow Haskell Compiler. Source and binary distributions are available at http://downloads.haskell.org/~ghc/8.0.2-rc1/ This is the first of what will hopefully be only two release

Re: Making (useful subsets of) bytecode portable between targets

On 2016-11-25 12:11, Simon Marlow wrote: We basically have two worlds: first, the compile-time world. In this world, we need all the packages and modules of the current package built for the host platform. Secondly, we need the runtime world, with all the packages and modules of the current

Re: Making (useful subsets of) bytecode portable between targets

Excerpts from Shea Levy's message of 2016-11-25 10:30:25 -0500: > > The right thing is to have a clean separation between runtime > > imports and compile-time imports. Perhaps we just annotate some imports to > > say they aren't needed at compile-time for running the TH code. but then > > we

Re: Making (useful subsets of) bytecode portable between targets

There is https://github.com/ghc-proposals/ghc-proposals Sent from my iPhone > On 25 Nov 2016, at 11:30 PM, Shea Levy wrote: > > Simon Marlow writes: > >> The right thing is to have a clean separation between runtime >> imports and compile-time imports.

Re: Making (useful subsets of) bytecode portable between targets

Simon Marlow writes: > The right thing is to have a clean separation between runtime > imports and compile-time imports. Perhaps we just annotate some imports to > say they aren't needed at compile-time for running the TH code. but then > we also need compile-time vs.

Re: IRC: Logging #ghc with ircbrowse.net

> > Note that currently there are no logs for any time prior to the last few > days. However, I have ZNC logs which Chris said he may be able to import > which cover the last several years of #ghc activity. If there is no > objection I would like to have him import these so we have a more >

Re: Making (useful subsets of) bytecode portable between targets

On 25 November 2016 at 07:23, Moritz Angermann wrote: [snip] > To get this back on topic, if we have a architecture independent > interpretable bytecode, > for ghc, could we sidestep the runner solution altogether and have TH for > the target > be evaluated on the host?

Re: Making (useful subsets of) bytecode portable between targets

I totally agree that GHC with TH is crippled and that this is a major restriction off the cross-compilation story. All I am saying is that I see a device runner (and to a degree a simulator runner) not as a solution to this *important* problem. Architecture independent interpretable byte code