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: 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

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

Aren’t we taking this a bit too far off topic? I feared as much when I wrote my initial reply. Please excuse. I agree that ghc + runner is not an optimal, and maybe even for some tasks (iOS) a pretty convoluted solution. This is only if we follow the proven solution to TH that luite in ghcjs

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

Ok, I am not saying that it is technical impossible. I am saying that it is *impractical*. Imagine Travis CI needing to run stuff on my phone that is attached to my Mac (if we are lucky), which is behind NAT somewhere in Australia. Running stuff in the simulator during a build would be

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

Excerpts from Ben Gamari's message of 2016-11-21 16:06:14 -0500: > > 3. Teach cabal to compile dependencies and modules for the build and > >target when cross-compiling and TH is used > > You'll need to speak with the Cabal folks about this. However, it's > probably safe to ignore this for

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

If you use Travis CI or such, do you really want to have a runner accessible from an arbitrary host on the Internet? > Moritz Angermann : > > It's certainly far from ideal, but for CI, what obstacles are there besides > needing a runner accessible from cross compiling

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

Hi, just to also note: that this completely ignores any host / target IO actions that TH might want to run. cheers, moritz > On Nov 24, 2016, at 12:51 PM, Moritz Angermann wrote: > > It's certainly far from ideal, but for CI, what obstacles are there besides >

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

It's certainly far from ideal, but for CI, what obstacles are there besides needing a runner accessible from cross compiling machine? E.g. Start the runner app on an iPhone plugged in into a USB power source and leave it there? Sent from my iPhone > On 24 Nov 2016, at 12:42 PM, Manuel M T

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

Sorry, but I don’t think running on the device is practical. How do you want to do CI, for example? Manuel > Moritz Angermann : > > >> On Nov 23, 2016, at 7:50 PM, Simon Marlow wrote: >> >> […] >> >> My question would be: are you *sure* you can't

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

CCing Luite who has done this sort of thing in the context of GHCJS. Shea Levy writes: > Hi all, > > I'm interested in implementing a general solution for TH during > cross-compilation, which if my naive lack-of-understanding is correct > will broadly involve the following

Making (useful subsets of) bytecode portable between targets

Hi all, I'm interested in implementing a general solution for TH during cross-compilation, which if my naive lack-of-understanding is correct will broadly involve the following three tasks: 1. Make the generation of byte code, or at least the subset needed for useful TH use,