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

25 Nov 2016


      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 seems a much more attractive avenue for me. (Sorry if I didn’t make this clear.)

Manuel
...
Moritz Angermann :
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 pioneered,
and which later found it’s way into ghc through iserv.  If someone proposes a
solution to TH that does not require a runner and allows the TH to be fully
evaluated on the host with no need to evaluate on the target for cross compilation,
that would be great!
If the runner would just require the same architecture, maybe qemu would be a solution
that would not require a device running?  Then again I’m not sure how that would
work with TH that directly or indirectly accesses libraries only available on iOS for
example.
Please don’t get me wrong. IMO ghc without TH is quite crippled, and therefore so is a 
cross compiling ghc. From the solutions I saw to this problem (zeroth, evil-splicer, and
the ghcjs runner approach), the ghcjs runner approach, seems to me at least as the most
promising, that would work for the largest subset of TH.
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?  Is this what Shea initially wanted to go after?
cheers,
moritz
...
On Nov 25, 2016, at 2:38 PM, Manuel M T Chakravarty  wrote:
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 pretty awkward, but running it on the device is not practical.
Manuel
PS: BTW, shipping binary code to the device means it has to be code signed using a distribution profile of a registered developer. That is one thing if Xcode does all the magic behind the scenes, but do you really want to make that part of the GHC build process?
...
Edward Z. Yang :
At least for Travis, you can generate a private key that only Travis
has access to, and use this to authenticate access to the runner.
See https://docs.travis-ci.com/user/encryption-keys/
Edward
Excerpts from Manuel M T Chakravarty's message of 2016-11-24 16:38:34 +1100:
...
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 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 Chakravarty  wrote:
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 run target code at compile time?  Not even with an iphone simulator?
> 
> This should be possible. However for proper development one would need to run on the
> device (iPhone, iPad, …) for armv7 or arm64, as the Simulator is i386 or x86_64.
> 
> There is a bit of additional engineering required here to get the shipping of
> code from ghc to the runner on the target required (e.g. via network).  As executing
> and controlling applications on the actual hardware is limited, I guess a custom
> ghc-runner application would have to be manually started on the device, which could
> trivially be discovered using bonjour/zeroconf (or just giving ghc the host:port information).
> 
> In general though, the runner does not have to obey all the restrictions apple puts
> onto app-store distributed apps, as I expect that everyone could build and install
> the runner themselves when intending to do iOS development with ghc.
> 
> cheers,
> moritz
> _______________________________________________
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
_______________________________________________
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
_______________________________________________
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs